Windows Server for beginners. Part 3: How Active Directory works
All parts of the series “Windows Server for beginners”Before Active Directory, every Windows server had its own account database — the SAM, Security Account Manager — and a user with ten servers had ten passwords. Windows NT domains solved half of this: one server, the PDC, held the database, and the other controllers, BDCs, received a read-only copy, while the database remained a flat list of names capped at 40 thousand entries with no structure at all and a proprietary protocol for everything. In Windows 2000 Microsoft replaced it with a directory built from open standards: the data lives in an LDAP directory, authentication is done by Kerberos, servers are found through DNS, and replication runs between equal controllers with no single master. That is how Active Directory came to be, and in 26 years its design has hardly changed.
There are no commands that change anything in this part: before running Install-ADDSForest in the next one, you need to understand what this command will create. We'll go through the directory from top to bottom: the logical structure, objects, partitions, files on disk, and at the end, the protocols all of it speaks.
Forest, tree, domain, OU
Forest corp.example.com
┌─────────────────────────────────────────────────────────────┐
│ shared schema, shared configuration, Enterprise Admins │
│ │
│ Tree 1 Tree 2 │
│ corp.example.com ◄── forest shop.example.net │
│ │ root domain │
│ ├── eu.corp.example.com ◄── child domain │
│ └── us.corp.example.com │
│ │
│ Inside the corp.example.com domain: │
│ OU=Departments │
│ ├── OU=Sales │
│ │ ├── CN=Alice │
│ │ └── CN=Bob │
│ └── OU=IT │
│ OU=Servers │
│ OU=Workstations │
└─────────────────────────────────────────────────────────────┘
A domain is the unit of administration and replication. It has a DNS name (corp.example.com), a short NetBIOS name (CORP), its own database of users, computers and groups, its own password policy and its own administrators — the Domain Admins group. Domain controllers hold a full copy of its data and replicate it among themselves.
A tree is a chain of domains with a contiguous namespace: eu.corp.example.com is a child domain of corp.example.com. A two-way transitive trust is created automatically between parent and child, so a user of any domain in the tree can get access to resources of any other.
A forest is one or more trees that share a schema and a configuration. The first domain created is the forest root domain, and that's forever: you can rename it, but you can't make another domain the root. The root domain hosts two groups with forest-wide authority: Enterprise Admins and Schema Admins. The forest is the security boundary: an administrator of any domain in the forest can technically gain rights in any other (through the schema, the configuration or SID spoofing in replication), so "a separate domain for a department we don't trust" doesn't work. If you need real isolation, you need a separate forest, and we'll talk about that in the part about multiple forests.
A rule for beginners: one forest, one domain. Child domains are needed in two cases — when a separate password policy is legally required (since Windows Server 2008 this is solved with fine-grained policies inside a single domain) and when a division is so large that replicating its objects over slow links becomes a problem. Both cases are rare. The multi-domain forests you will come across were mostly built back when fine-grained policies didn't exist yet, or appeared through company mergers.
An organizational unit (OU) is a container inside a domain. OUs are needed for exactly two things: linking group policies and delegating administrative rights. "Sales users get these settings, and this person creates their accounts and resets their passwords" — that's an OU. The OU structure doesn't affect security of access to resources, isn't reflected in the logon name and isn't visible to the user; it's the directory's internal organization for the administrator.
Next to OUs there are containers — CN=Users, CN=Computers, CN=Builtin, CN=System. They are created when the domain is installed, and group policy can't be linked to them. New users and computers end up in Users and Computers by default, and the first thing an administrator does is move them to their own OUs or redirect the default with the redirusr and redircmp commands.
Names
Every object in the directory has several names, and they are easy to confuse.
Distinguished name, DN, is the path to the object in the tree, written from the leaf to the root:
CN=Alice,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com
CN is the object's common name, OU is the organizational unit, DC is a domain component: the domain corp.example.com splits into three components. A DN is unique in the forest and changes when the object is moved to another OU, so referencing an object by DN in scripts is a bad idea.
objectGUID is a 128-bit identifier the object receives when it's created and never changes, through any moves and renames. The only reliable name.
objectSid is the security identifier. Only security principals have one: users, computers and groups, that is, those who can be granted permissions. A SID consists of the domain SID and a relative identifier, the RID:
S-1-5-21-3623811015-3361044348-30300820-1104
│ │ │ └──────── domain SID ───────────┘ └ RID
│ │ └ NT Authority
│ └ revision
└ "S" means SID
RIDs are handed out in order from a pool, and some are reserved: 500 is the built-in Administrator, 501 is Guest, 502 is krbtgt (the Kerberos service account, more on it in part 6), 512 is Domain Admins, 513 is Domain Users, 516 is Domain Controllers, 519 is Enterprise Admins. Permissions on files, registry keys and directory objects are granted by SID; an access control list (ACL) stores SIDs, not names, so a renamed user keeps all their permissions, while one deleted and recreated with the same name does not.
sAMAccountName is the short logon name, up to 20 characters, unique in the domain: alice. It's used in the CORP\alice format. It came from Windows NT, and some programs work only with it.
userPrincipalName, UPN, is the logon name in address format: alice@corp.example.com. Unique in the forest. The suffix may differ from the domain name: an administrator can add an alternative suffix example.com to the forest, and the user will sign in as alice@example.com. This matters for cloud synchronization, and we'll come back to it in the part about Entra ID.
Objects, attributes, schema
The directory is a database of objects. Each object belongs to a class (user, computer, group, organizationalUnit, contact, …) and consists of attributes: cn, givenName, sn, mail, memberOf, pwdLastSet, lastLogonTimestamp and several hundred more. Which classes exist, which attributes are mandatory and allowed for each, what type they are and whether an attribute can have multiple values — all of this is defined by the schema. There's one schema per forest, and that is one of the reasons the forest is the boundary: a schema extension (Exchange adds hundreds of attributes, Entra Connect a few) applies to all domains of the forest at once and can't be undone.
The computer class is a descendant of the user class: a computer in a domain is also an account, with a password the machine changes by itself every 30 days, and with a name like WS1$ (a dollar sign at the end). That's why a computer can authenticate to the domain before any user has signed in on it, and receive its own group policies.
Groups deserve a separate discussion, because they have two independent characteristics. Type: security (has a SID, can be granted permissions) or distribution (just a mailing list for email). And scope:
| Scope | Who can be a member | Where permissions can be granted | Where membership is stored |
|---|---|---|---|
| Domain local | anyone from any trusted domain and forest | only in its own domain | in its own domain |
| Global | only principals of its own domain | in any domain of the forest and in trusting forests | in its own domain |
| Universal | principals of any domain of its forest | anywhere | in the global catalog |
These scopes make up the classic rule for granting permissions — AGDLP. It's an acronym for a chain in which each letter is a link, and the order of letters shows what goes into what:
- A — Accounts: users and computers;
- G — Global groups: accounts are placed into them by role — "Accountants", "Sales", "1C servers";
- DL — Domain Local groups: global groups are placed into them by resource and access level — "Finance share: read", "Finance share: modify";
- P — Permissions: only a domain local group is added to a resource's access list (the ACL of a folder, printer or directory object).
alice, bob ──► G "Accountants" ──► DL "Finance: modify" ──► ACL of folder \\fs1\Finance: Modify
carol ───────► G "Auditors" ─────► DL "Finance: read" ────► ACL of folder \\fs1\Finance: Read
The point is that each link is owned by its own knowledge. Who does what job is known by a manager or HR, and that's membership in global groups. Who is entitled to which resource is decided by the resource owner, and that's membership of global groups in domain local ones. The folder ACL is never touched: it is set up once for two domain local groups, and from then on access changes only through membership. A new accountant — one addition to "Accountants", and they get everything accountants are entitled to, on all resources at once. They left — one removal. Auditors need read access for a month — their group goes into "Finance: read" for a month. The question "who has access to Finance" is answered by the membership of one group, not by walking every ACL on the server.
Why global groups go on the outside and domain local ones on the inside follows from the table above: a global group can contain only its own and is good for permissions anywhere, while a domain local group accepts anyone but is good only for its own domain — exactly what a group standing at a resource needs. In a forest of several domains, universal groups are added between G and DL (AGUDLP) to gather roles from different domains into one. In a single domain the whole chain seems excessive, and small organizations often grant permissions directly to global groups. The scheme shows its value with trusts between forests, where only a domain local group can accept a member from a foreign forest, and we'll see that in the part about access across a trust.
Directory partitions
A controller's database isn't monolithic. It is split into partitions (naming contexts, NC), and each has its own replication scope:
Controller dc1.corp.example.com stores:
┌─ CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com ──────────────────────┐
│ Schema NC: classes and attributes. One per forest, on every forest DC. │
├─ CN=Configuration,DC=corp,DC=example,DC=com ────────────────────────────────┤
│ Configuration NC: sites, subnets, replication topology, list of domains, │
│ partitions, extensions. One per forest, on every forest DC. │
├─ DC=corp,DC=example,DC=com ─────────────────────────────────────────────────┤
│ Domain NC: users, computers, groups, OUs, GPO containers. │
│ One per domain, in full on every DC of that domain. │
├─ DC=DomainDnsZones,DC=corp,DC=example,DC=com ───────────────────────────────┤
│ Application NC: DNS zones replicated to the DNS-server DCs of this domain. │
├─ DC=ForestDnsZones,DC=corp,DC=example,DC=com ───────────────────────────────┤
│ Application NC: the _msdcs zone, to the DNS-server DCs of the forest. │
└─────────────────────────────────────────────────────────────────────────────┘
The split exists so that nothing unnecessary travels over the network: a controller in eu.corp.example.com needs the forest's schema and configuration, but not the users of us.corp.example.com. Application partitions appeared in Windows Server 2003 for application data with its own replication scope; in practice there are two of them, both for DNS, and in the part about DNS we'll see why zones are best kept exactly there.
The global catalog (GC) is an add-on on top of this. A controller with the GC role holds, in addition to its own domain, a partial copy of every other domain in the forest: not all attributes, only those marked in the schema as "in GC" (names, SIDs, UPNs, universal group membership). It's needed for forest-wide search (Outlook looks up recipients in the GC) and for logon: when a user enters alice@corp.example.com, the controller has to find out which domain of the forest that UPN lives in, and asks the GC. The GC listens on a separate LDAP port — 3268 (3269 with TLS). In a single-domain forest all controllers are GCs, and the first controller gets this role automatically.
Replication between controllers is multi-master: data can be changed on any controller, and the change will spread to the rest. There are five exceptions, called FSMO roles, and they get a part of their own. How replication works — sites, topology, USNs — is the subject of part 10; for now it's enough to know it exists and that between controllers in the same site a change arrives within seconds.
What's on disk
On a controller, the directory lives in two places.
%SystemRoot%\NTDS is the database:
C:\Windows\NTDS\
ntds.dit the database itself, all partitions, ESE format (Extensible Storage Engine, aka Jet Blue —
the same engine as Exchange and Windows Search); from hundreds of megabytes to gigabytes
edb.log transaction log: a change is written here first, then to the database
edb00001.log … older logs until they are applied
edb.chk checkpoint: how far the logs have already been applied
temp.edb temporary space
It's an ordinary transactional database: after a power failure, the controller replays the logs at startup and stays consistent. Inside ntds.dit there is one big object table where each attribute is a column, a link table for multi-valued reference attributes (group membership) and a security descriptor table. Nobody accesses the database directly: all access goes through the directory service inside the lsass.exe process. The ntdsutil utility can check, compact and move it, and we'll come back to it in the parts about backups and decommissioning controllers.
SYSVOL is the shared folder %SystemRoot%\SYSVOL\sysvol\corp.example.com, reachable over the network as \\corp.example.com\SYSVOL and \\dc1\SYSVOL:
\\corp.example.com\SYSVOL\corp.example.com\
Policies\
{31B2F340-016D-11D2-945F-00C04FB984F9}\ Default Domain Policy
GPT.INI policy version
Machine\ computer settings: registry.pol, scripts, security templates
User\ user settings
{6AC1786C-016F-11D2-945F-00C04fB984F9}\ Default Domain Controllers Policy
scripts\ logon scripts; this is also \\corp.example.com\NETLOGON
A group policy lives in two places: a container in the directory (CN={GUID},CN=Policies,CN=System,…) with the name, version and links, and a folder in SYSVOL with the settings themselves. The client reads the first over LDAP and the second over SMB. SYSVOL is replicated not by the directory service but by DFS-R (Distributed File System Replication), independently of the database, and a version mismatch like "15 in the directory, 14 in SYSVOL" is one of the classic problems we'll learn to diagnose.
How a client finds a controller
The workstation ws1 powers on and has to authenticate itself and the user. It has no controller address at all — only the domain name. From here DC Locator, part of the Netlogon service, takes over, and it works through DNS.
At startup a controller registers a set of SRV records in DNS (their format is covered in part 12 of the networking series):
_ldap._tcp.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.dc._msdcs.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.Office._sites.dc._msdcs.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
_kerberos._tcp.corp.example.com. SRV 0 100 88 dc1.corp.example.com.
_kerberos._tcp.dc._msdcs.corp.example.com. SRV 0 100 88 dc1.corp.example.com.
_kpasswd._tcp.corp.example.com. SRV 0 100 464 dc1.corp.example.com.
_gc._tcp.corp.example.com. SRV 0 100 3268 dc1.corp.example.com.
_ldap._tcp.pdc._msdcs.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.<domain GUID>.domains._msdcs.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
<GUID of the DC's NTDS Settings>._msdcs.corp.example.com. CNAME dc1.corp.example.com.
The naming logic: _service._protocol.[role.]_msdcs.domain. dc._msdcs means all controllers, pdc._msdcs the one holding the PDC emulator role, gc._msdcs the global catalogs, <site>._sites the controllers of a particular site, <domain GUID>.domains the controllers of a domain by its GUID (in case the domain is renamed). The last record, the CNAME, exists one per controller: the name in it is the GUID of that controller's NTDS Settings object (also called the DSA GUID), and it's by this record that controllers find their replication partners, as discussed in part 10. A domain with four controllers has four such CNAMEs. The _msdcs subdomain (Microsoft DC services) is the one stored in the ForestDnsZones partition.
The client queries _ldap._tcp.dc._msdcs.corp.example.com, gets a list, sends each controller a short LDAP ping (an unbound query to RootDSE over UDP 389 with a domain filter); the first to answer tells the client which site it's in, judging by its address, and the client repeats the lookup with _sites to find the nearest controller. The result is cached; to see it:
C:\> nltest /dsgetdc:corp.example.com
DC: \\dc1.corp.example.com
Address: \\192.168.1.10
Dom Guid: 7a1b2c3d-4e5f-6071-8293-a4b5c6d7e8f9
Dom Name: corp.example.com
Forest Name: corp.example.com
Dc Site Name: Office
Our Site Name: Office
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 DS_13 KEYLIST
The command completed successfully
The flags are what the controller reported about itself in reply to the LDAP ping: it's the PDC, a global catalog, a KDC, a time source, writable, in the same site as the client. This leads to a rule that explains half of all "the domain doesn't work" problems: a domain client must use a DNS server that knows the domain's zone. An ISP's public DNS has never heard of _ldap._tcp.dc._msdcs.corp.example.com, and a machine using it won't join the domain, however correct the rest of the network is. That's why controllers are almost always DNS servers as well, and part 7 is devoted to that.
Protocols
Now we can put the whole picture together. User Alice signs in on ws1:
ws1 DNS dc1 (KDC, LDAP, SMB)
│ │ │
├─ SRV _ldap._tcp.dc._msdcs ►│ │ 1. DC Locator: where the controllers are
│◄───── dc1, 192.168.1.10 ───┤ │
├─ LDAP ping (UDP 389) ──────────────────────► │ 2. is it alive, which site
│◄──── site Office, flags ─────────────────────┤
├─ Kerberos AS-REQ (ws1$) ───────────────────► │ 3. the machine gets its TGT
│◄──── AS-REP, TGT ────────────────────────────┤
├─ Kerberos AS-REQ (alice) ──────────────────► │ 4. the user gets a TGT
│◄──── AS-REP, TGT ────────────────────────────┤
├─ TGS-REQ (ldap/dc1) ───────────────────────► │ 5. a ticket for the controller's LDAP
│◄──── TGS-REP ────────────────────────────────┤
├─ LDAP search: user's OU, gPLink ───────────► │ 6. which GPOs to apply
│◄──── GPO list, versions ─────────────────────┤
├─ TGS-REQ (cifs/dc1) ───────────────────────► │ 7. a ticket for the controller's files
├─ SMB \\dc1\SYSVOL\…\Policies ──────────────► │ 8. download the policy settings
│◄──── registry.pol, scripts ──────────────────┤
├─ RPC/Netlogon, SAMR, DRS as needed ────────► │ 9. service calls
Five protocols, each with its own role.
LDAP (Lightweight Directory Access Protocol, RFC 4511) is access to directory data: bind (client authentication), search with a filter, reading attributes, modification. Port 389 (TCP, and UDP for pings), 636 with TLS (LDAPS), 3268 and 3269 for the global catalog. Everything that reads or changes objects — snap-ins, the ActiveDirectory module via ADWS, Linux machines via sssd, applications with "AD integration" — speaks LDAP. Part 5 is devoted entirely to it.
Kerberos (RFC 4120) is authentication. The client proves once to the controller that it knows the password and receives a TGT; after that, for each service it presents the TGT and gets a service ticket, without sending the password anywhere. Port 88 (UDP and TCP), 464 for password changes. A controller acting in the Kerberos role is called a KDC (Key Distribution Center). A service is identified by an SPN — a name like cifs/dc1.corp.example.com, ldap/dc1.corp.example.com, HTTP/web.corp.example.com — and a ticket is issued for a specific SPN. Part 6.
NTLM is challenge-response authentication that came from Windows NT: the server sends a random number, the client encrypts it with the password hash, and the server asks the controller over the Netlogon secure channel to verify it. Three round trips per connection; the password isn't transmitted, but the password hash is equivalent to the password, and the protocol is vulnerable to relaying. Kerberos has displaced NTLM, but NTLM remains the fallback: when a client connects to a server by IP address rather than by name (no SPN), when the server isn't in a domain, when the controller is unavailable and the server caches the check. In security logs, NTLM authentication where Kerberos was expected is a sign of misconfiguration, and we'll learn to find it.
SMB (Server Message Block) means files and named pipes. Port 445. Over SMB the client reads SYSVOL and NETLOGON, users access file servers, and some RPC calls run over SMB named pipes (\PIPE\netlogon, \PIPE\samr, \PIPE\lsarpc). The current version is SMB 3.1.1 with encryption and signing; SMB1 has been removed from Windows Server; if an old device requires it, it's better to upgrade the device than to bring back a protocol without signing and encryption. Since 2025, SMB signing is required by default for outbound connections, which breaks connections to really old NAS devices.
RPC (Remote Procedure Call, the MSRPC implementation on top of DCE/RPC) is procedure calls between Windows services. Directory replication between controllers (the DRS interface), the Netlogon secure channel, account management (SAMR), security policies (LSARPC), remote management of services and logs — all of it is RPC. It works in two steps: the client asks the Endpoint Mapper on port 135 which port the required interface listens on, and gets a number from the dynamic range 49152–65535. For a firewall between networks this is inconvenient: nobody wants to open the whole range. The solution is to pin the replication and Netlogon ports in the registry (the TCP/IP Port value for NTDS and DCTcpipPort for Netlogon) or to narrow the dynamic port range with netsh int ipv4 set dynamicport tcp start=49152 num=1000. We'll recall this in the part about sites.
A summary table of controller ports worth keeping at hand:
| Port | Protocol | Purpose |
|---|---|---|
| 53 TCP/UDP | DNS | name resolution and locating controllers |
| 88 TCP/UDP | Kerberos | authentication |
| 123 UDP | NTP | time (signed SNTP for domain members) |
| 135 TCP | RPC Endpoint Mapper | finding RPC service ports |
| 389 TCP/UDP | LDAP | directory; UDP is only for LDAP ping |
| 445 TCP | SMB | SYSVOL, NETLOGON, RPC named pipes |
| 464 TCP/UDP | Kerberos kpasswd | password change |
| 636 TCP | LDAPS | LDAP over TLS |
| 3268, 3269 TCP | LDAP GC | global catalog, without and with TLS |
| 5985, 5986 TCP | WinRM | PowerShell Remoting |
| 9389 TCP | ADWS | AD Web Services for the ActiveDirectory module and the Administrative Center |
| 49152–65535 TCP | RPC dynamic | replication, Netlogon, SAMR, LSARPC and more |
| 137–139 | NetBIOS | only for very old clients; not needed on a modern network |
A hands-on look
We don't have a domain yet, but you can already look at these mechanisms — from any work machine that belongs to some domain — or come back to this section after the next part.
Finding a controller through DNS, in its pure form:
PS C:\> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.com -Type SRV
Name Type TTL Section NameTarget Priority Weight Port
---- ---- --- ------- ---------- -------- ------ ----
_ldap._tcp.dc._msdcs.corp.example.com SRV 600 Answer dc1.corp.example.com 0 100 389
_ldap._tcp.dc._msdcs.corp.example.com SRV 600 Answer dc2.corp.example.com 0 100 389
The same lookup done by Netlogon, with all the site logic: nltest /dsgetdc:corp.example.com above, and the list of all domain controllers — nltest /dclist:corp.example.com.
Who you are from the domain's point of view:
PS C:\> whoami /user
USER INFORMATION
----------------
User Name SID
========== =============================================
corp\alice S-1-5-21-3623811015-3361044348-30300820-1104
PS C:\> whoami /groups /fo list | Select-String -Pattern 'Group Name|SID' | Select-Object -First 6
Group Name: Everyone
SID: S-1-1-0
Group Name: BUILTIN\Users
SID: S-1-5-32-545
Group Name: CORP\Domain Users
SID: S-1-5-21-3623811015-3361044348-30300820-513
The user's RID 1104 marks one of the first accounts created (the pool starts at 1000, and a few go to built-in objects); 513 for Domain Users is the reserved one from the table above. S-1-5-32-545 is the local machine's built-in Users group: S-1-5-32 is BUILTIN, and this SID is the same on every computer in the world.
Kerberos tickets issued in the current session:
PS C:\> klist
Current LogonId is 0:0x3e7a1
Cached Tickets: (3)
#0> Client: alice @ CORP.EXAMPLE.COM
Server: krbtgt/CORP.EXAMPLE.COM @ CORP.EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 10/15/2026 9:02:11 (local)
End Time: 10/15/2026 19:02:11 (local)
Renew Time: 10/22/2026 9:02:11 (local)
#1> Client: alice @ CORP.EXAMPLE.COM
Server: cifs/dc1.corp.example.com @ CORP.EXAMPLE.COM
...
#2> Client: alice @ CORP.EXAMPLE.COM
Server: ldap/dc1.corp.example.com/corp.example.com @ CORP.EXAMPLE.COM
...
Ticket #0 with the server krbtgt/… is the TGT itself; it lives for 10 hours and can be renewed for a week; #1 and #2 are service tickets for the controller's SMB and LDAP, obtained at logon exactly as in the diagram above. We'll go through what each field means in part 6.
And finally, what a controller tells about itself to anyone who asks, without authentication. This is the RootDSE object, the root of the LDAP tree, and it answers everyone on port 389:
PS C:\> (Get-ADRootDSE -Server dc1.corp.example.com) | Select-Object dnsHostName, defaultNamingContext, configurationNamingContext, schemaNamingContext, namingContexts, domainFunctionality, forestFunctionality, isGlobalCatalogReady
dnsHostName : dc1.corp.example.com
defaultNamingContext : DC=corp,DC=example,DC=com
configurationNamingContext : CN=Configuration,DC=corp,DC=example,DC=com
schemaNamingContext : CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
namingContexts : {DC=corp,DC=example,DC=com, CN=Configuration,DC=corp,DC=example,DC=com,
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com, DC=DomainDnsZones,DC=corp,DC=example,DC=com,
DC=ForestDnsZones,DC=corp,DC=example,DC=com}
domainFunctionality : Windows2016Domain
forestFunctionality : Windows2016Forest
isGlobalCatalogReady : TRUE
The five partitions from the diagram above, the forest and domain functional levels (their meaning is in the part about replacing controllers), and global catalog readiness. Every LDAP client starts with this object, and so will our conversation about LDAP from the inside.
Now it's clear what we should end up with. All that's left is to create it.
Next — Part 4: the first domain controller. Installing the AD DS role, Install-ADDSForest and its parameters, what happens during promotion, what appears on disk and in DNS after the reboot, checking with dcdiag, and why the first controller is the most important server in the organization.
Only registered users can leave a comment.
Sign in or register to leave a comment.