Windows Server for beginners. Part 4: The first domain controller
All parts of the series “Windows Server for beginners”In the previous part we went through what a forest, a domain, directory partitions and the global catalog are. Today all of it will appear on the disk of the dc1 server we prepared in part 1. Promoting a server to a domain controller is a ten-minute, one-command operation, but in those ten minutes almost everything changes: the local account database disappears, and a directory database, DNS zones, shared folders and six new services appear. Let's go step by step and look at each one.
The domain name
The only decision you can't change later without pain is the domain name. Renaming a domain is technically possible (rendom), but in practice nobody does it. Here are the rules.
The domain should be a subdomain of a name you own. corp.example.com, ad.example.com, internal.example.com are fine if example.com is registered to the organization. Then server names like dc1.corp.example.com are globally unique, you can get publicly trusted certificates for them, and they won't collide with anyone else's zone.
Don't use .local or other non-existent TLDs. That was the advice in the 2000s, and company.local domains still turn up. There are two problems: .local is reserved for mDNS (serverless name resolution used by macOS and Linux on the local network, where .local is resolved without going to your DNS), and since 2015 public certificate authorities don't issue certificates for names in non-existent zones. The .lan, .internal and .corp domains are formally unclaimed, but they lack the first advantage: one day ICANN may delegate such a TLD, as happened with .dev.
Don't make the domain name the same as your public website. A domain example.com with www.example.com on the internet means that inside the network the name example.com resolves to the controllers (they register an A record for the domain name itself, and it can't be removed), and the site stops opening by its short name. This is called split-brain DNS; you can live with it, but there's no reason to.
The NetBIOS name is up to 15 characters, by default the first label of the DNS name in uppercase: CORP. Users see it in the CORP\alice format and on the sign-in screen, and it can't be changed later either.
So: the forest and domain corp.example.com, NetBIOS CORP.
Installing the role
The role is installed without a reboot, like any other:
PS C:\> Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Domain Services, Group Policy Management, Remote Server Administration Tools, ...}
These are only the binaries: the directory services aren't configured or running yet. -IncludeManagementTools adds the PowerShell modules ActiveDirectory, ADDSDeployment, GroupPolicy and, on Desktop Experience, the snap-ins. We don't install the DNS Server role separately: the promotion command installs it by itself.
What has appeared:
PS C:\> Get-Command -Module ADDSDeployment
CommandType Name Version Source
----------- ---- ------- ------
Cmdlet Add-ADDSReadOnlyDomainControllerAccount 1.0.0.0 ADDSDeployment
Cmdlet Install-ADDSDomain 1.0.0.0 ADDSDeployment
Cmdlet Install-ADDSDomainController 1.0.0.0 ADDSDeployment
Cmdlet Install-ADDSForest 1.0.0.0 ADDSDeployment
Cmdlet Test-ADDSDomainControllerInstallation 1.0.0.0 ADDSDeployment
Cmdlet Test-ADDSDomainControllerUninstallation 1.0.0.0 ADDSDeployment
Cmdlet Test-ADDSDomainInstallation 1.0.0.0 ADDSDeployment
Cmdlet Test-ADDSForestInstallation 1.0.0.0 ADDSDeployment
Cmdlet Test-ADDSReadOnlyDomainControllerAccountCreation 1.0.0.0 ADDSDeployment
Cmdlet Uninstall-ADDSDomainController 1.0.0.0 ADDSDeployment
A module of ten cmdlets, one per scenario: a new forest, a new domain in an existing forest, an additional controller, a read-only controller, demotion. In this series we'll use all of them except Install-ADDSDomain. Before Windows Server 2012 the same was done by the dcpromo utility with an answer file, and "dcpromo" still means "promote to a domain controller".
Promotion parameters
Install-ADDSForest takes a couple dozen parameters. The important ones:
| Parameter | What it sets | Our choice |
|---|---|---|
-DomainName |
DNS name of the forest root domain | corp.example.com |
-DomainNetbiosName |
NetBIOS name; without the parameter, the first label | CORP |
-ForestMode, -DomainMode |
forest and domain functional levels | WinThreshold (2016) |
-InstallDns |
install the DNS role and create the zones | yes |
-CreateDnsDelegation |
create a delegation in the parent zone | no: the parent zone isn't ours |
-DatabasePath, -LogPath, -SysvolPath |
where NTDS and SYSVOL live |
the defaults, C:\Windows\NTDS and C:\Windows\SYSVOL |
-SafeModeAdministratorPassword |
Directory Services Restore Mode password | we set it |
-NoRebootOnCompletion |
don't reboot automatically | no, let it reboot |
-Force |
don't ask questions | yes, in a script |
The functional level determines which directory features are enabled and restricts which Windows Server versions can be controllers: at level 2016, Windows Server 2012 R2 can't become a controller. The levels are Win2008, Win2008R2, Win2012, Win2012R2, WinThreshold (the code name for 2016; there are no separate levels for 2019 and 2022) and, starting with Windows Server 2025, Win2025. Level 2025 requires all controllers to be 2025 and is needed only for that version's new features — 32 KB database pages instead of 8 and some Kerberos improvements. For a lab forest made only of 2025 servers you can choose it right away; for an organization that may need a 2022 controller a year from now, 2016 is better. You can always raise the level, but never lower it.
The DSRM password (Directory Services Restore Mode) is a separate password not tied to any domain account. A controller can be booted into a special safe mode where the directory service isn't running and the database is available as a file: that's how the directory is restored from a backup or a corrupted database is repaired. You can sign in to this mode only as the local Administrator with the DSRM password, because domain accounts don't work there: the directory isn't running. Write the password down wherever you keep your hypervisor passwords: you'll need it on the worst day, and it can't be changed without a working directory. While the directory is running, you can change it: ntdsutil "set dsrm password" "reset password on server null" q q.
Paths. In production the database and logs go on a separate disk for the same reasons as with any database: space and performance. For a lab the system disk is enough.
Testing and promotion
Every Install-* in the module has a matching Test-* that runs all the checks but changes nothing:
PS C:\> $dsrm = Read-Host -AsSecureString 'DSRM password'
PS C:\> Test-ADDSForestInstallation -DomainName corp.example.com -DomainNetbiosName CORP -ForestMode WinThreshold -DomainMode WinThreshold -InstallDns -SafeModeAdministratorPassword $dsrm
WARNING: Windows Server 2025 domain controllers have a default for the security setting named "Allow cryptography algorithms compatible with Windows NT 4.0" that prevents weaker cryptography algorithms when establishing security channel sessions.
For more information about this setting, see Knowledge Base article 942564 (http://go.microsoft.com/fwlink/?LinkId=104751).
WARNING: A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found or it does not run Windows DNS server. If you are integrating with an existing DNS infrastructure, you should manually create a delegation to this DNS server in the parent zone to ensure reliable name resolution from outside the domain "corp.example.com". Otherwise, no action is required.
Message Context RebootRequired Status
------- ------- -------------- ------
Operation completed successfully Test.VerifyDcPromoCore.DCPromo.General.80 False Success
Both warnings are expected. The first says the controller will refuse a secure channel to clients using NT 4.0-grade algorithms, and that's right. The second says it couldn't create a delegation for corp in the example.com zone: the example.com zone lives at a registrar or hosting provider, not on this server. Delegation is needed if corp.example.com names have to resolve from the internet; usually they don't.
If Test- passed, run the same thing without Test-:
PS C:\> Install-ADDSForest -DomainName corp.example.com -DomainNetbiosName CORP -ForestMode WinThreshold -DomainMode WinThreshold -InstallDns -CreateDnsDelegation:$false -SafeModeAdministratorPassword $dsrm -Force
WARNING: Windows Server 2025 domain controllers have a default for the security setting ...
WARNING: A delegation for this DNS server cannot be created ...
Message Context RebootRequired Status
------- ------- -------------- ------
You must restart this computer to complete the operation. DCPromo.General.4 True Success
Between the warnings and the final table, progress lines run across the screen for several minutes: "Validating environment and user input", "Creating the NTDS settings object", "Configuring the DNS Server service", "Replicating the schema directory partition", "Creating the SYSVOL directory". After the final table the server reboots by itself.
What happened in those minutes
Let's look at the log promotion leaves behind: C:\Windows\debug\DCPROMO.LOG — a line-by-line record of everything the wizard did — and the Directory Service event log. Here is the sequence.
1. The database. C:\Windows\NTDS\ntds.dit was created from the template C:\Windows\System32\schema.ini with five partitions: the schema (about 1,500 classes and attributes of the base schema), the forest configuration, the domain corp.example.com, DomainDnsZones and ForestDnsZones. The forest has just one domain — it's the root, which means the Enterprise Admins and Schema Admins groups were created in it.
2. Domain objects. The containers Users, Computers, Builtin, System, ForeignSecurityPrincipals, Managed Service Accounts, Program Data, and the Domain Controllers OU. The built-in users Administrator, Guest, krbtgt and groups — Domain Admins, Domain Users, Domain Computers, Domain Controllers, DnsAdmins and about thirty more. Two group policy objects: Default Domain Policy and Default Domain Controllers Policy.
3. Accounts. The local SAM database on the controller stops being used. The local Administrator, with the password you set when installing Windows, becomes the domain's CORP\Administrator: same password, new SID, with RID 500 in the domain. From this moment there are no local users and groups on the controller: Get-LocalUser will return an error. The server itself gets the computer account DC1$ in the Domain Controllers OU.
4. Kerberos. The krbtgt account was created with a random password — this is the key the KDC uses to encrypt every TGT it issues. An NTDS settings object for the controller was created in the configuration partition (CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,…): this object is what makes the server a controller in everyone else's eyes.
5. Roles. All five FSMO roles — Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master — were assigned to the first controller, because there are no others. It's also a global catalog. What these roles are and why there are five of them, we'll cover in part 17.
6. SYSVOL. The C:\Windows\SYSVOL folder was created, containing the domain folder with the two default policies; DFS-R replication was configured (alone for now), and the SYSVOL and NETLOGON shares were published.
7. DNS. The DNS Server role was installed. The zones corp.example.com (in the DomainDnsZones partition) and _msdcs.corp.example.com (in ForestDnsZones) were created, both directory-integrated, with secure dynamic updates. The server's DNS client was switched to 127.0.0.1. After the reboot, Netlogon will register the controller's SRV records and A record in the zones.
8. Site. The first site, Default-First-Site-Name, was created, and the controller placed in it. The site has no subnets; we'll rename it to Office and attach 192.168.1.0/24 in the part about replication.
9. Services. Enabled and set to start automatically: NTDS (Active Directory Domain Services, running inside lsass.exe), Kdc (Kerberos Key Distribution Center), Netlogon, DNS, DFSR, IsmServ (Intersite Messaging), ADWS (Active Directory Web Services). The W32Time service was reconfigured: the controller holding the PDC role becomes the time source for the domain.
After the reboot
Sign in as CORP\Administrator with the password the local administrator had. On the sign-in screen, Server Core shows the domain in the prompt, Desktop Experience in the user name field.
The first check is that everything started:
PS C:\> Get-Service NTDS, Kdc, Netlogon, DNS, DFSR, ADWS, W32Time | Format-Table Name, Status, StartType -AutoSize
Name Status StartType
---- ------ ---------
NTDS Running Automatic
Kdc Running Automatic
Netlogon Running Automatic
DNS Running Automatic
DFSR Running Automatic
ADWS Running Automatic
W32Time Running Automatic
What the domain knows about itself:
PS C:\> Get-ADDomain | Select-Object Name, DNSRoot, NetBIOSName, DomainMode, DomainSID, PDCEmulator, RIDMaster, InfrastructureMaster, ReplicaDirectoryServers
Name : corp
DNSRoot : corp.example.com
NetBIOSName : CORP
DomainMode : Windows2016Domain
DomainSID : S-1-5-21-3623811015-3361044348-30300820
PDCEmulator : dc1.corp.example.com
RIDMaster : dc1.corp.example.com
InfrastructureMaster : dc1.corp.example.com
ReplicaDirectoryServers : {dc1.corp.example.com}
PS C:\> Get-ADForest | Select-Object Name, ForestMode, RootDomain, SchemaMaster, DomainNamingMaster, GlobalCatalogs, Sites
Name : corp.example.com
ForestMode : Windows2016Forest
RootDomain : corp.example.com
SchemaMaster : dc1.corp.example.com
DomainNamingMaster : dc1.corp.example.com
GlobalCatalogs : {dc1.corp.example.com}
Sites : {Default-First-Site-Name}
Five roles on one server, one global catalog, one site. DomainSID is the prefix from the previous part that the SIDs of all users and groups in this domain start with.
The controller itself:
PS C:\> Get-ADDomainController | Select-Object HostName, IPv4Address, Site, IsGlobalCatalog, IsReadOnly, OperatingSystem, OperationMasterRoles
HostName : dc1.corp.example.com
IPv4Address : 192.168.1.10
Site : Default-First-Site-Name
IsGlobalCatalog : True
IsReadOnly : False
OperatingSystem : Windows Server 2025 Standard Evaluation
OperationMasterRoles : {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster}
Files on disk, as promised in the previous part:
PS C:\> Get-ChildItem C:\Windows\NTDS | Select-Object Name, Length
Name Length
---- ------
edb.chk 8192
edb.log 10485760
edb00001.log 10485760
ntds.dit 25165824
temp.edb 2162688
PS C:\> Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON' | Select-Object Name, Path
Name Path
---- ----
NETLOGON C:\Windows\SYSVOL\sysvol\corp.example.com\SCRIPTS
SYSVOL C:\Windows\SYSVOL\sysvol
A 25 MB database is an empty domain: the schema, the configuration and a hundred objects. With a thousand users it will grow to hundreds of megabytes, and with Exchange in the schema, several times more.
DNS:
PS C:\> Get-DnsServerZone | Format-Table ZoneName, ZoneType, IsDsIntegrated, ReplicationScope, DynamicUpdate -AutoSize
ZoneName ZoneType IsDsIntegrated ReplicationScope DynamicUpdate
-------- -------- -------------- ---------------- -------------
_msdcs.corp.example.com Primary True Forest Secure
corp.example.com Primary True Domain Secure
TrustAnchors Primary True Forest None
PS C:\> Get-DnsServerResourceRecord -ZoneName _msdcs.corp.example.com -RRType Srv | Format-Table HostName, @{n='Target'; e={$_.RecordData.DomainName}}, @{n='Port'; e={$_.RecordData.Port}} -AutoSize
HostName Target Port
-------- ------ ----
_ldap._tcp.dc dc1.corp.example.com. 389
_ldap._tcp.Default-First-Site-Name._sites.dc dc1.corp.example.com. 389
_kerberos._tcp.dc dc1.corp.example.com. 88
_kerberos._tcp.Default-First-Site-Name._sites.dc dc1.corp.example.com. 88
_ldap._tcp.gc dc1.corp.example.com. 3268
_ldap._tcp.Default-First-Site-Name._sites.gc dc1.corp.example.com. 3268
_ldap._tcp.pdc dc1.corp.example.com. 389
_ldap._tcp.7a1b2c3d-4e5f-6071-8293-a4b5c6d7e8f9.domains dc1.corp.example.com. 389
The domain's two zones and the auxiliary TrustAnchors for DNSSEC. The _msdcs records are the ones from the previous part; Netlogon registered them at startup and will re-register them every hour. If some record disappears, nltest /dsregdns makes it do so right now.
dcdiag
The main tool for checking a controller is dcdiag, a set of thirty tests that check everything from connectivity to replication and DNS. On a fresh controller it should be green all the way:
PS C:\> dcdiag
Directory Server Diagnosis
Performing initial setup:
Trying to find home server...
Home Server = dc1
* Identified AD Forest.
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-Name\DC1
Starting test: Connectivity
......................... DC1 passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\DC1
Starting test: Advertising
......................... DC1 passed test Advertising
Starting test: FrsEvent
......................... DC1 passed test FrsEvent
Starting test: DFSREvent
......................... DC1 passed test DFSREvent
Starting test: SysVolCheck
......................... DC1 passed test SysVolCheck
Starting test: KccEvent
......................... DC1 passed test KccEvent
Starting test: KnowsOfRoleHolders
......................... DC1 passed test KnowsOfRoleHolders
Starting test: MachineAccount
......................... DC1 passed test MachineAccount
Starting test: NCSecDesc
......................... DC1 passed test NCSecDesc
Starting test: NetLogons
......................... DC1 passed test NetLogons
Starting test: ObjectsReplicated
......................... DC1 passed test ObjectsReplicated
Starting test: Replications
......................... DC1 passed test Replications
Starting test: RidManager
......................... DC1 passed test RidManager
Starting test: Services
......................... DC1 passed test Services
Starting test: SystemLog
......................... DC1 passed test SystemLog
Starting test: VerifyReferences
......................... DC1 passed test VerifyReferences
Running partition tests on : ForestDnsZones
...
Running partition tests on : Schema
...
Running enterprise tests on : corp.example.com
Starting test: LocatorCheck
......................... corp.example.com passed test LocatorCheck
Starting test: Intersite
......................... corp.example.com passed test Intersite
What each important test checks, and what its failure means:
| Test | What it checks |
|---|---|
| Connectivity | the controller is found via DNS and responds over LDAP and RPC |
| Advertising | the controller advertises itself as DC, GC, KDC, time source (the flags from nltest /dsgetdc) |
| SysVolCheck, NetLogons | the SYSVOL and NETLOGON shares are published and accessible |
| KccEvent, Replications, ObjectsReplicated | the replication topology is built, partners respond, objects are replicated |
| KnowsOfRoleHolders, RidManager | the controller knows the FSMO holders; it has a RID pool for new objects |
| MachineAccount | the DC1$ account is in place, with the right flags and SPNs |
| Services | all the services listed above are running |
| SystemLog, DFSREvent, FrsEvent | no errors in the System and DFSR logs over the last hour |
| LocatorCheck | the PDC, GC, KDC and time source holders can be found in the forest |
One test isn't run by default — DNS, because it takes a long time. Run it separately; it's mandatory after installation:
PS C:\> dcdiag /test:dns /v
Testing server: Default-First-Site-Name\DC1
Starting test: DNS
DNS Tests are running and not hung. Please wait a few minutes...
...
Summary of DNS test results:
Auth Basc Forw Del Dyn RReg Ext
_________________________________________________________________
Domain: corp.example.com
dc1 PASS PASS WARN PASS PASS PASS n/a
......................... corp.example.com passed test DNS
Seven subtests: zone authority, basic configuration, forwarders, delegation, dynamic registration, record registration, external name. The WARN for forwarders is because we haven't configured them yet, and the server reaches the internet through the root servers (root hints); it works, but in part 7 we'll set forwarders explicitly. Remember this output: when someone complains a year from now that "the domain is slow", dcdiag /test:dns will be the first thing you run.
Two less formal signs of a healthy controller are events 1000 ("Microsoft Active Directory Domain Services startup complete") and 1394 ("All problems preventing updates to the Active Directory Domain Services database have been cleared") in the Directory Service log, and event 4602 ("The DFS Replication service successfully initialized the SYSVOL replicated folder") in the DFS Replication log:
PS C:\> Get-WinEvent -LogName 'Directory Service' -MaxEvents 200 | Where-Object Id -in 1000, 1394 | Format-Table TimeCreated, Id, Message -Wrap
PS C:\> Get-WinEvent -LogName 'DFS Replication' | Where-Object Id -eq 4602 | Select-Object TimeCreated, Id
Until 4602 appears, the SYSVOL and NETLOGON folders aren't published and the controller doesn't advertise itself to clients. On the first controller this takes seconds; on an additional one it depends on replication.
The controller's DNS client
Promotion switched the server's DNS client to 127.0.0.1. That works, but we'd rather have an explicit address: in the part about the second controller we'll set the partner as the first DNS server and the server itself as the second, and explain why. For now, set itself:
PS C:\> Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 192.168.1.10
PS C:\> Register-DnsClient
PS C:\> Resolve-DnsName dc1.corp.example.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
dc1.corp.example.com A 1200 Answer 192.168.1.10
And a forwarder to the router or the ISP's DNS, so that internet names are resolved through it rather than by going to the root servers directly:
PS C:\> Add-DnsServerForwarder -IPAddress 192.168.1.1
PS C:\> Resolve-DnsName www.vitaliy.org -Server 192.168.1.10 | Select-Object Name, IPAddress
Zones, forwarders and everything else are covered in detail in part 7, but without this line the domain clients we're about to join would be left unable to reach the internet by name.
The first domain members
A controller without clients is useless. Let's join the member server srv1 and the workstation ws1 to the domain. Each takes two steps, and the first matters more than the second.
Step 1: DNS. The machine must ask the controller for names. With DNS from the router it won't find the domain, however correctly everything else is configured — remember DC Locator from the previous part.
PS C:\> Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 192.168.1.10
PS C:\> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.com -Type SRV | Select-Object NameTarget, Port
NameTarget Port
---------- ----
dc1.corp.example.com 389
If the SRV record is found, the domain will be found. On a network with DHCP this is done by option 6 in the scope, and in part 8 we'll configure it so we don't have to walk around the machines by hand.
Step 2: joining.
PS C:\> Add-Computer -DomainName corp.example.com -Credential CORP\Administrator -Restart
The command asks for the password, creates the account SRV1$ in the Computers container (or in the OU from the -OUPath parameter), establishes the machine's secure channel with the controller, stores the computer account secret on the machine and reboots. On joining, the machine registers its own A record in the corp.example.com zone, gets the DNS suffix corp.example.com and switches the interface's network profile to Domain.
The new objects are immediately visible on the controller:
PS C:\> Get-ADComputer -Filter * | Select-Object Name, DNSHostName, Enabled, DistinguishedName
Name DNSHostName Enabled DistinguishedName
---- ----------- ------- -----------------
DC1 dc1.corp.example.com True CN=DC1,OU=Domain Controllers,DC=corp,DC=example,DC=com
SRV1 srv1.corp.example.com True CN=SRV1,CN=Computers,DC=corp,DC=example,DC=com
WS1 ws1.corp.example.com True CN=WS1,CN=Computers,DC=corp,DC=example,DC=com
To check the secure channel from a domain member if something went wrong: Test-ComputerSecureChannel -Verbose; to repair it without leaving the domain: Test-ComputerSecureChannel -Repair -Credential CORP\Administrator. This command fixes the "The trust relationship between this workstation and the primary domain failed" error, which sooner or later everyone sees who has reverted a virtual machine to an old snapshot: the machine changes its account password every 30 days, and after a revert the controller no longer knows the old password.
The first account
There's no need to work as CORP\Administrator: it's the RID 500 account that the lockout policy doesn't lock, that shows up in every log as "Administrator" with no person's name, and that can't be deleted. The rule is simple: every administrator has their own named account in Domain Admins, while the built-in one gets a long password and stays in the safe.
PS C:\> New-ADUser -Name 'Alice Admin' -SamAccountName alice.admin -UserPrincipalName alice.admin@corp.example.com -AccountPassword (Read-Host -AsSecureString 'Password') -Enabled $true
PS C:\> Add-ADGroupMember -Identity 'Domain Admins' -Members alice.admin
PS C:\> Get-ADGroupMember 'Domain Admins' | Select-Object Name, SamAccountName
Name SamAccountName
---- --------------
Administrator Administrator
Alice Admin alice.admin
Alice will get a separate account for everyday work without administrator rights in the part about PowerShell for AD, where we'll cover the ActiveDirectory module in full. For now: sign out of Administrator, sign in as CORP\alice.admin and make sure the domain accepts it:
PS C:\> whoami /groups | Select-String 'Domain Admins'
CORP\Domain Admins Group S-1-5-21-3623811015-3361044348-30300820-512 Mandatory group, Enabled by default, Enabled group
Why the first controller is the most important server
Right now everything converges on this server: it alone stores the directory, it alone issues Kerberos tickets, it alone answers the domain's DNS queries, it's the time source for all domain members, and it holds all five FSMO roles. If it goes down, no user will sign in on any domain machine (cached credentials will let you sign in locally on a workstation, but it won't open a single network resource).
This situation is tolerable only until part 10, where the second controller appears. Until then it's worth doing two things: don't experiment on dc1 with anything you can do on srv1, and write down the DSRM password. One more habit worth starting now: a domain controller is a domain controller and nothing else. You don't install SQL Server on it, don't host web applications on it and don't keep file shares with documents on it. The exceptions are DNS and DHCP, which have traditionally lived together with the controller and are the subject of the parts after LDAP and Kerberos.
The directory exists, and it already contains a hundred objects created without our involvement. It's high time to look inside and see how they're really built — not through the eyes of a snap-in, but through the eyes of the protocol every program uses to work with them.
Next — Part 5: LDAP from the inside. How an object's name is built and what an attribute consists of, what RootDSE is and why it answers everyone without a password, how to write LDAP filters, how to read the directory with ldp.exe and ADSI Edit, what lives in CN=System and in the schema, and which edits there break the domain with no way back.
Only registered users can leave a comment.
Sign in or register to leave a comment.