Active Directory Architecture and Management Questions

Direct answer

Active Directory Domain Services (AD DS) is an on-premises directory for domain-joined computers: Kerberos (ticket-based sign-in) and NT LAN Manager (NTLM, an older challenge-response sign-in) authentication, Lightweight Directory Access Protocol (LDAP, the protocol for querying and updating the directory), organizational units (OUs), Group Policy, domain controllers, forests and trusts. Microsoft Entra ID is a cloud identity service for SaaS and modern apps: OAuth 2.0 (token-based access for web and mobile apps), OpenID Connect (sign-in built on OAuth 2.0), and Security Assertion Markup Language (SAML) and WS-Federation (XML-based sign-in assertions used by SaaS and older federated apps), role-based administration, Conditional Access (rules that allow, block or add a step such as multifactor authentication for a sign-in), and device management through Microsoft Intune (Microsoft's cloud device management service). Entra ID is organized as a tenant, your organization's own dedicated instance of the service. They are different systems, not one hosted copy of the other. For a hybrid design, AD DS usually stays the source of authority for synced users, Microsoft Entra Connect (or cloud sync) copies identities to Entra ID, and you choose a sign-in method and a device join model deliberately. Microsoft Entra Domain Services is a third thing: managed domain controllers in Azure for legacy applications.

Side by side

Device states matter in a hybrid plan: Entra registered (personal devices), Entra joined (company-owned, not joined to AD DS), and Entra hybrid joined (company-owned and joined to AD DS). Example (illustrative): an employee's personal phone is Entra registered, a new company laptop that never touches the domain is Entra joined, and an office desktop that is domain-joined and also known to Entra is hybrid joined.

Entra Domain Services

It provides domain join, Group Policy, LDAP and Kerberos or NTLM authentication from two Microsoft-managed domain controllers, with no DCs for you to patch. It is a standalone managed domain with one-way synchronization from Entra ID, not an extension of the on-premises domain. Compared with self-managed AD DS you get no Domain or Enterprise Admin rights and no schema extensions; LDAP writes apply only to objects created in the managed domain. It requires password hash synchronization to receive credentials, and a forest trust to on-premises AD DS is possible when you need hybrid access.

What changes for a hybrid team

1. Authority and identity key. The synced object is matched by an immutable sourceAnchor (the ms-DS-ConsistencyGuid attribute or objectGUID): a value that never changes, like a permanent ID badge, which ties the on-premises user to its cloud copy. If it changed, the sync would treat the user as a different person and create a duplicate. It cannot be changed after the object syncs, so choose it before the first sync.
2. Sign-in name. Entra sign-in uses the user principal name (UPN), the name@suffix form of sign-in name. If a user's UPN suffix (the part after the @) is not a verified custom domain in the tenant (a domain you own and proved ownership of with a public DNS record), Entra replaces it with the tenant's onmicrosoft.com name. Non-routable suffixes such as contoso.local cannot be verified.
3. Sign-in method (PHS, PTA or federation) and Seamless SSO.
4. Devices: hybrid join, Entra join or both.
5. Writeback and resilience: password writeback, a staging sync server.
6. Legacy apps: application proxy or Domain Services.

Worked example

Contoso has users with UPNs in contoso.com and a few with corp.local. Run this before the first sync:

# Run before the first sync: users whose UPN suffix is not a verified domain in the Entra tenant
$verified = @('contoso.com', 'contoso.co.uk')
Get-ADUser -Filter * -Properties userPrincipalName |
    Where-Object { $_.userPrincipalName -and ($_.userPrincipalName.Split('@')[-1] -notin $verified) } |
    Select-Object SamAccountName, userPrincipalName

It lists users whose suffix is not in the verified list, so you can repair UPNs first. Illustrative output:

SamAccountName userPrincipalName
-------------- -----------------
asmith         asmith@corp.local
bjones         bjones@corp.local

Each row is a user who would be given a @contoso.onmicrosoft.com sign-in name at sync, because corp.local is not a verified domain (Microsoft Entra builds the replacement name from the user's mailNickName attribute plus the tenant's initial domain, so the part before the @ can change as well); an empty result means every UPN suffix is safe.

Common synchronization pitfalls

• Password expired and account locked-out states are not synced.
• accountExpires is not synced, so an expired AD account stays active in the cloud unless you script disabling it.
• PHS sets the cloud password to never expire by default for synced users.
• Disabled accounts can lag up to 30 minutes with PHS.
• Smart-card-required accounts have randomized AD passwords that PHS syncs; rotate or re-scramble them.
• Installing Entra Connect inside a Domain Services managed domain is not supported.

Trade-offs

• Domain Services is faster to adopt than extending AD DS to Azure, but gives up schema and admin control.
• Staying hybrid keeps legacy compatibility but keeps the attack surface of on-premises AD.

Direct answer

An OU (organizational unit) is a container in the directory tree. Use it to answer "who administers this object, and which Group Policy applies to it". A group is a collection of accounts that can be listed in permissions. Use it to answer "who can access this resource". The two are not alternatives: an object lives in exactly one OU but can belong to many groups, so you design the OU tree for administration and policy, and use groups for access.

What each is for

Decision rule for the debate: if the answer is about where an object sits for management, restructure OUs. If the answer is about what an object may reach, change group membership. If both, do each in its own tool.

Worked example

Contoso has Sales, HR and Engineering, and a help desk.

• Delegation: put users and computers in OUs by management need (for example Users\Sales, Workstations\Sales). Grant the group HelpDesk-Admins the right to reset passwords on the Users OU. Every user placed there inherits it. In Active Directory Users and Computers this is a right-click on the OU, then Delegate Control, then the group, then the common task "Reset user passwords and force password change at next logon". Behind the wizard it adds permission entries (access control entries, ACEs) for that group to the OU's permission list, and child objects inherit them.
• Policy: the "Sales laptop baseline" GPO is linked to Workstations\Sales. Moving a laptop into that OU applies it at the next refresh.
• Exception: only the contractors in Sales need a stricter "Contractor lockdown" GPO. Link it to Users\Sales and use security filtering so it applies only to the group Sales-Contractors. The OU tree stays untouched.
• Access: a Sales-only share is granted to a domain local group that contains the Sales role group, not to the Sales OU.

Constraints and pitfalls

• Protected accounts ignore OU delegation. AdminSDHolder is a special object in the domain whose permissions act as a template for privileged accounts. SDProp is the background process that, every 60 minutes by default on the PDC emulator, copies that template over the accounts in the protected groups (Domain Admins, Administrators, Account Operators and others) and turns off inheritance on them, which wipes any permission the OU delegation had given. Illustrative example: Dana, a Domain Admin, sits in the same OU as ordinary staff. The help desk can reset everyone else's password, but their attempt on Dana's account is denied, because Dana's permissions come from the template rather than from the OU. That is by design.
• Do not mirror the org chart. A department rename or reorganization should not force an OU rebuild. Organize by what the objects are (users, servers, workstations, service accounts) and by who manages them.
• Depth costs. A distinguished name (DN, the full path of an object in the tree) grows with every OU level. A simple LDAP bind (the basic sign-in in which an application sends a full DN and a password) accepts a user DN of at most 255 characters, and OU names are limited to 64 characters. Illustrative example: CN=Olivia Montgomery-Hartley,OU=Accounts-Finance,OU=Departments-EMEA,OU=Regional-Operations,OU=Corporate-Users,DC=corp,DC=contoso,DC=com is already 136 characters (counted in python) with four OU levels, and each further level of similar names adds about 20 characters, so seven levels reach roughly 200 and about ten levels pass 255 (Microsoft's archived limits article shows a 261-character DN with eleven OU levels failing a simple bind). Long OU names bring that point closer, so keep the tree shallow and the names short.
• Moving an object changes its policy and delegation at once. Treat OU moves as a controlled change. Protect OUs from accidental deletion.
• One GPO strategy. A computer or user can process at most 999 GPOs. Linking at OU level and filtering by group avoids GPO sprawl.

Direct answer

Look the account up with Get-ADUser -Filter, which returns nothing for an unknown name, test for that case explicitly, and then read Enabled, LastLogonDate and the group memberships. LastLogonDate is a convenient but delayed value: it is converted from the lastLogonTimestamp attribute, which is replicated (copied from one domain controller to the others) and only updated when the previous value is old enough, so it can lag real activity by up to roughly two weeks (Microsoft's Ask the Directory Services Team blog puts the lag at 9 to 14 days with default settings). For an exact last sign-in, query the lastLogon attribute on every domain controller (DC, a server that holds a copy of the directory and signs users in) and take the newest, because lastLogon is not replicated.

Script

function Get-UserSummary {
    [CmdletBinding()]
    param([Parameter(Mandatory)][string]$LogonName)

    $user = Get-ADUser -Filter { SamAccountName -eq $LogonName -or UserPrincipalName -eq $LogonName } `
        -Properties Enabled, LastLogonDate
    if (-not $user) {
        Write-Warning "No account found for '$LogonName'."
        return
    }

    # lastLogon is not replicated, so ask every domain controller and keep the newest value
    $newest = 0
    foreach ($dc in Get-ADDomainController -Filter *) {
        try {
            $u = Get-ADUser -Identity $user.DistinguishedName -Server $dc.HostName -Properties LastLogon
            if ($u.LastLogon -gt $newest) { $newest = $u.LastLogon }
        }
        catch { Write-Warning "Skipped $($dc.HostName): $($_.Exception.Message)" }
    }

    [pscustomobject]@{
        LogonName      = $user.SamAccountName
        Enabled        = $user.Enabled
        LastLogonDate  = $user.LastLogonDate    # converted from the replicated lastLogonTimestamp
        LastLogonExact = if ($newest -gt 0) { [DateTime]::FromFileTime($newest) } else { $null }
        Groups         = (Get-ADPrincipalGroupMembership -Identity $user | Sort-Object Name).Name -join '; '
    }
}

Usage: Get-UserSummary -LogonName asmith or Get-UserSummary -LogonName asmith@example.com. Illustrative output (values invented, not captured from a live domain):

LogonName      : asmith
Enabled        : True
LastLogonDate  : 9/29/2026 8:14:02 AM
LastLogonExact : 10/6/2026 7:55:41 AM
Groups         : Domain Users; Sales; VPN-Users

Read it as: the account is enabled, the replicated value says the last sign-in was on 9/29, and the newest per-DC value says it was this morning. The 7-day gap is normal for lastLogonTimestamp. For an account that has never signed in, LastLogonDate and LastLogonExact are both empty. The filter matches either the pre-Windows 2000 logon name (sAMAccountName) or the user principal name (UPN), the name@domain form.

How it works

• Unknown user. -Filter returns nothing for a name that does not exist, so if (-not $user) writes a warning and returns nothing. The caller can tell "no such user" (no output) from "never signed in" (an object whose last sign-in fields are empty).
• Quoting. Because the filter is written in curly braces, $LogonName is used unquoted, as the Get-ADUser help describes. The module treats the variable as a value rather than as query text, so a name containing a quote character is compared as text; confirm this with a test name that contains a quote.
• Last sign-in, two ways. LastLogonDate comes from the one replicated copy. The loop asks each DC from Get-ADDomainController -Filter * for that DC's own lastLogon through -Server $dc.HostName, keeps the largest value, and converts it with [DateTime]::FromFileTime. A DC that has never authenticated the user returns 0, which is ignored. A DC that cannot be reached produces a warning and is skipped, so one offline DC does not fail the report.
• Groups. Get-ADPrincipalGroupMembership returns the groups that have the user as a member, and it needs a global catalog. A global catalog (GC) is a DC that also holds a searchable partial copy of every domain's objects in the forest, which lets the cmdlet find memberships held in groups of other domains.

Why the two dates differ

Microsoft's Ask the Directory Services Team blog on lastLogonTimeStamp explains the rule. msDS-LogonTimeSyncInterval is an attribute of the domain that sets how often the value is updated; it defaults to 14 days, and a domain where it shows as Not Set is using that default. At sign-in the domain controller compares the age of the stored lastLogonTimestamp with the interval minus a random amount of up to 5 days (the randomization stops many accounts from updating at once), and it rewrites the attribute only when the stored value is at least that old. The same post states that with default settings the value is 9 to 14 days behind the current date, so treat the exact figure as environment-specific and read the interval on your own domain. In every case the lag runs from zero up to the interval, not always the full interval. Example: the stored lastLogonTimestamp is 4 days old and the user signs in again today. Four days is below every threshold in the 9 to 14 day range, so the attribute is not rewritten, LastLogonDate keeps showing the date from 4 days ago, and only the per-DC lastLogon values show today. That makes LastLogonDate good for finding accounts unused for 30 days or more, and wrong for questions about the last day or two.

Trade-offs and pitfalls

• Querying every DC costs one directory call per DC per user. For a single lookup that is fine. For a bulk report, use LastLogonDate and only drill into suspect accounts.
• Get-ADPrincipalGroupMembership needs a global catalog it can reach, and Microsoft documents a non-terminating error when none is available, so a branch whose users cannot reach a global catalog gets an error instead of a group list.
• Return an object rather than formatted text so the result can be piped into Export-Csv or filtered.

Direct answer

In Active Directory a site is a named set of well-connected IP subnets, normally one office or data centre, and a subnet object is the directory record that says "this IP range belongs to that site". A site link joins two sites and has a cost, a number where lower means the path is preferred. A Windows client asks its local Netlogon service (the Windows component that locates DCs; its API is DsGetDcName) to find a domain controller (DC). Netlogon queries DNS for service (SRV) records, first for the domain and then for the client's own Active Directory site, sends an LDAP ping (a tiny UDP query that asks a DC to identify itself and report the client's site) over UDP to the candidates, and uses the first that answers. The DC it reaches checks the client's IP address against the subnet objects in Active Directory to learn the client's site and, if it is not in that site, tells the client which site it belongs to. The client then repeats the search for DCs in that site and caches the result. A client that keeps using a distant DC almost always has a wrong or missing subnet-to-site mapping, a site with no DC of its own, or a stale cache.

How the locator works, in order

1. The client asks Netlogon (the DsGetDcName API). Netlogon builds an SRV query such as _ldap._tcp.<domain>.
2. Domain controllers register SRV records in DNS: domain-wide ones and site-specific ones of the form _ldap._tcp.<SiteName>._sites.<domain>. In DNS Manager they appear under _msdcs\dc\_tcp and _msdcs\dc\_sites\<SiteName>\_tcp, with _kerberos and _ldap services.
3. The client sends a UDP LDAP ping (port 389) to the DCs returned. The first DC that responds is returned, and the answer is cached so later requests use the same DC.
4. The responding DC maps the client's IP to a site using subnet objects. If it is not the best site, the DC returns the client's site name and the client repeats the site-specific lookup.
5. If the DC found is not in the client's own site, the client discards the cached entry after 15 minutes and tries again for a better one.
6. If a site has no DC for a domain, a DC in the lowest-cost neighbouring site registers site records for it, so every site still has a default DC. Get-ADDomainController -NextClosestSite follows the same idea: the site with the lowest site-link cost.

Investigating a client that uses a distant DC

Start with rows 1 and 2, which show what the client believes and which DC it got; rows 3 and 4 explain why; rows 5 to 7 refine or test the cause.

Run on the client, in this order:

Illustrative nltest /dsgetdc:corp.contoso.com /force output for the worked example below (abbreviated, values invented; for a client whose address matches no subnet object the Our Site Name line may be absent, so only the DC's site shows):

           DC: \\DC-CHI1.corp.contoso.com
      Address: \\10.10.1.5
 Dc Site Name: Chicago

Dc Site Name is the site of the DC that answered, and Our Site Name is the site the client was assigned. If Our Site Name is missing, or is not the office you are standing in, the subnet mapping is absent or wrong; if it is right but Dc Site Name is a different site, look at DC placement and DNS records.

Get-ADDomainController -Discover -ForceDiscover | Format-List *
Get-ADDomainController -Discover -ForceDiscover -SiteName 'Frankfurt' | Format-List *

Forcing a particular DC

For diagnosis only, klist add_bind CORP dc-fra1.corp.contoso.com sets a preferred DC for Kerberos and klist purge_bind removes it. As a fix, pinning is wrong: it breaks failover. Repair the cause (subnet, site, DC placement, site-link cost) so the locator chooses correctly.

Worked example

Frankfurt laptops move to a new Wi-Fi VLAN, 10.30.9.0/24. Active Directory knows only 10.30.8.0/24 for Frankfurt. A laptop at 10.30.9.57 is in the unmapped range, which you can check by hand. A /24 fixes the first three numbers of the address (the last number, 0 to 255, is free). 10.30.9.57 starts 10.30.9, so it is not in 10.30.8.0/24 (which needs 10.30.8) but it is in 10.30.9.0/24. No subnet matches the laptop's address, so no DC can tell it a site to search, and it keeps whichever DC answered first for the domain-wide records, which here was in Chicago. nltest /dsgetdc /force shows a Chicago DC and a missing or wrong "Our Site Name". The administrator adds the subnet 10.30.9.0/24 to the Frankfurt site, and after the client's cached entry expires (the cache is flushed after 15 minutes for a DC outside the best site), the laptop finds DC-FRA1.

Pitfalls

• Fixing symptoms with a pinned DC instead of the site mapping.
• Assuming DNS is the problem when UDP 389 is blocked and local DCs simply never answer the ping.
• Forgetting that a site with no DC for a domain is covered by another site and may land on a distant DC by design; fix with a DC placed there or with correct site-link costs.
• Testing right after the fix without using /force, and seeing the old cached DC.

Direct answer

Use loopback processing: enable the policy Configure user Group Policy loopback processing mode in a GPO linked to the OU (organizational unit, a container) that holds the kiosk computers. Normally user settings come from GPOs that follow the user; with loopback the user settings of the GPOs that follow the computer are applied to whoever logs on. Choose Replace for an identical locked-down experience, or Merge when the kiosk should keep some of each user's normal settings.

How to set it up

1. Put the kiosk computers in their own OU so nothing else is affected.
2. Create a GPO linked to that OU. In its Computer Configuration, Policies, Administrative Templates, System, Group Policy, enable Configure user Group Policy loopback processing mode and pick Replace or Merge.
3. In the same GPO define the User Configuration settings the kiosk needs (hide Control Panel, restrict the Start menu, wallpaper). Both halves of the GPO must be enabled, because the computer half carries the loopback switch and the user half carries the settings.
4. Run gpupdate /force on a kiosk, log off, sign in as a normal user and check with gpresult /h kiosk.html.

Replace versus Merge

One rule drives both modes: when two GPOs set the same setting, the one processed last wins, so a list processed later has higher precedence than a list processed earlier. A GPO list is just the ordered set of policies, applied from first to last.

• Replace: the list of GPOs for the user is not gathered at all. Only the user settings from the computer's GPOs are applied.
• Merge: the user's GPO list is gathered first, then the computer's list is added at the end, so they are processed last and win any conflict. Where they conflict the computer's user settings win; where they do not, the user's own settings survive.

Worked example: the sales user's normal GPOs set wallpaper blue and screen saver timeout 900 seconds. The kiosk GPO sets wallpaper grey and removes the Start menu.

Side effects to watch

• Every user, including administrators, gets the kiosk restrictions on those machines. Keep admin-capable machines in a different OU and test with an admin account.
• Under Replace the user's drive maps, folder redirection and logon scripts from their normal GPOs do not apply on the kiosk.
• Settings only processed at logon or startup (folder redirection, software installation, scripts) need a fresh logon, not a background refresh.
• It is easy to forget the user half is part of the computer's GPO: a loopback GPO with its user half disabled does nothing.
• Troubleshooting becomes harder because the same user gets different settings on different machines; always read gpresult on the machine in question and look at which GPO list supplied each setting.

Pitfalls

Do not link loopback GPOs to a domain-wide OU, and do not use Merge when you need guaranteed uniformity, because any non-conflicting user setting survives.