Distinguished Name

原文：Distinguished Name — theDXT (Daniel Keer)

Everything in AD (Active Directory) has a Distinguished Name. A Distinguished Name can be used in many situations such as setting up an application to use a service account or adding AD groups or users into applications and so much more.

A Distinguished Name is also known as a DN. A benefit of an using a DN is that no two objects in Active Directory can ever have the same DN.

In this post I'll show step-by-step how to get the Distinguished Name for the various items in Active Directory via the GUI and PowerShell, and then cover the syntax rules, where a DN turns up in real integrations, and the mistakes that bite people who copy a DN out of one tool and paste it into another.

What a Distinguished Name Actually Is

Active Directory is a hierarchical database, and a DN is the full address of one object inside that tree. Read a DN from right to left and you walk from the forest root down to the object itself:

CN=Daniel Keer,OU=Users,OU=Wellington,DC=contoso,DC=com
CN=Group 1,OU=Groups,DC=contoso,DC=com
CN=Computer1,CN=Computers,DC=contoso,DC=com

Every comma-separated chunk is a Relative Distinguished Name (RDN) — CN=Daniel Keer is one RDN, OU=Users is the next. The DN is just the RDNs joined with commas, in the order the directory stores them. The attribute prefixes you will see in practice are:

• DC= — domain component, one label of the DNS name, so contoso.com becomes DC=contoso,DC=com.
• OU= — organizational unit, the container objects you actually organise users and computers into.
• CN= — common name. Used for users, groups, computers, the built-in CN=Computers and CN=Users containers, and the domain root object itself.
• O= and C= — organisation and country, mostly seen in other LDAP directories and in X.500-era tooling.

Uniqueness comes from the parent, not the name: two users called jsmith can exist in different OUs, and their DNs differ because the path differs. That is exactly why applications like a DN for a service account — the path cannot be ambiguous, so the application always resolves the same object.

DN Syntax Rules and Escaping

A DN is an LDAP string, and LDAP has reserved characters: , + " \ < > ; =. If an OU or a display name contains one of those — very common with names like "Smith, John" or an OU called "Research & Development" — the character must be escaped with a backslash, or the whole value must be a quoted string:

CN=Smith\, John,OU=Users,DC=contoso,DC=com
CN=Research & Development,OU=Departments,DC=contoso,DC=com
CN="Smith, John",OU=Users,DC=contoso,DC=com

The backslash form and the quoted form are equivalent, and both are valid input to LDAP and to the cmdlets below. What is not valid is an unescaped comma, which silently turns one RDN into two and produces a DN that does not exist. When a DN works in the Attribute Editor but fails in an application, an unescaped character in the middle is the first thing to check.

GUI Way

• Open Active Directory Users and Computers

• Click on View > Advanced Features

• Right click on anything in AD and click on Properties

• Click on the Attribute Editor tab.

• Scroll down until you find the attribute named distinguishedName double click it (or click View) to view the details.

• You can now see the Distinguished Name for that item.

The process is the exact same for any item in AD. Note that Advanced Features is the step everyone forgets: without it the Attribute Editor tab is simply missing, and the DN attribute is hidden from the standard attribute list.

PowerShell Way

The PowerShell method is a bit more specific than just right clicking on something. Here is a breakdown for each item I could think of that you could need the DN for. All of the examples below use the ActiveDirectory module, which ships with RSAT or is added on a domain controller with:

Import-Module ActiveDirectory
Get-Module -ListAvailable ActiveDirectory | Select-Object Name, Version

OU (Organizational Unit)

• To get the DN for all OUs run the following command Get-ADOrganizationalUnit -Filter 'Name -like "*"' | FL Name, DistinguishedName

• To return the DN as a plain string rather than a formatted list, select the property directly — this is what you want when piping into another command: (Get-ADOrganizationalUnit -Identity "OU=Wellington,DC=contoso,DC=com").DistinguishedName

Groups

• To get the DN for a group run the following command and replace GROUP NAME with the name of the group you want to get the DN of Get-ADGroup -Identity "GROUP NAME" | FL Name, DistinguishedName

For example I want to get the DN of the group named Group 1, the command I will run is Get-ADGroup -Identity "Group 1" | FL Name, DistinguishedName

• To find every group whose DN sits under a given OU, use -SearchBase so the search does not have to walk the whole domain: Get-ADGroup -Filter * -SearchBase "OU=Groups,DC=contoso,DC=com" | FL Name, DistinguishedName

Service Accounts

• To get the DN for a service account run the following command and replace SERVICE ACCOUNT NAME with the name of the service account you want to get the DN of Get-ADServiceAccount -Identity "SERVICE ACCOUNT NAME" | FL Name, DistinguishedName

For example I want to get the DN for the service account named Service1, the command I will run is Get-ADServiceAccount -Identity Service1 | FL Name, DistinguishedName

A standalone managed service account has a DN in the normal form. A group managed service account (gMSA) created before the domain functional level of Windows Server 2016 may have its DN under CN=Managed Service Accounts instead, so resolve it with Get-ADServiceAccount -Filter * -Properties DistinguishedName | FL Name, DistinguishedName rather than assuming the OU.

Computers

• To get the DN of a computer run the following command and replace COMPUTER NAME with the name of the computer you want to get the DN of Get-ADComputer -Identity "COMPUTER NAME" | FL Name, DistinguishedName

For example I want to get the DN for the computer named Computer1, the command I will run is Get-ADComputer -Identity Computer1 | FL Name, DistinguishedName

• Find every machine in one OU, which is the usual way to build an inventory before a bulk operation: Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=contoso,DC=com" -Properties DistinguishedName | FL Name, DistinguishedName

Users

• To get the DN for a user run the following command and replace USERNAME with the name of the user account you want to get the DN of Get-ADUser -Identity "USERNAME" | FL Name, DistinguishedName

For example I want to get the DN of the user named User1, the command I will run is Get-ADUser -Identity User1 | FL Name, DistinguishedName

Do it in bulk and export the result, which is what you actually need when filling in an application configuration screen for a hundred accounts:

Get-ADUser -Filter * -SearchBase "OU=Users,DC=contoso,DC=com" `
  -Properties DistinguishedName |
  Select-Object SamAccountName, DistinguishedName |
  Export-Csv .\users-dn.csv -NoTypeInformation

The Domain Root and the Domain Controllers

Applications that bind with a search base need the domain DN, not a user DN. Get it directly instead of typing DC= labels by hand:

Get-ADDomain | FL Name, DistinguishedName
Get-ADForest | FL Name, RootDomain
"DC=contoso,DC=com"   # built from (Get-ADDomain).DistinguishedName

Turning a DN Back into a Friendly Name

The reverse direction is just as common — someone gives you a DN and you want to know what it is. Get-ADObject accepts a DN as its -Identity:

Get-ADObject -Identity "OU=Groups,DC=contoso,DC=com" -Properties canonicalName, objectClass
Get-ADUser -Identity "CN=User1,OU=Users,DC=contoso,DC=com" | Select-Object Name, SamAccountName

Getting a DN Without the ActiveDirectory Module

You will often be on a machine where RSAT is not installed — a jump host, a Linux box, a management appliance's shell. These alternatives all work:

• The current user's own DN, from any command prompt, no module required: whoami /fqdn. This is the quickest sanity check that you are looking at the right domain, and it works over a WinRM or SSH session.
• dsquery (deprecated but still present on servers with the AD DS tools): dsquery user -name "User1" prints the DN in quotes. dsquery ou -name "Wellington" and dsquery computer -name "Computer1" do the same for other object types.
• ADSI from an existing PowerShell session, which needs nothing but the .NET Framework:

  $root = [ADSI]"LDAP://rootDSE"
  $root.defaultNamingContext
  $searcher = [ADSISearcher]"(sAMAccountName=User1)"
  $searcher.FindOne().Properties.distinguishedname

• The LDAP root DSE directly to confirm which naming context you should be searching: ldapsearch -x -H ldap://dc1.contoso.com -s base -b "" namingContexts defaultNamingContext from a Linux host with openldap-clients.

If you are editing attributes rather than just reading them, the ADSI route is also the escape hatch for values the cmdlets will not touch — the same technique used in Mass Edit ADSI Values, where a DN is used as the identity for each object being changed.

DN vs the Other Identifiers

Choosing the right identifier is half the battle, because most "the application lost its group membership after a reorganisation" tickets are really "somebody hard-coded a DN".

• distinguishedName — the full path. Human readable, hierarchical, and it changes whenever the object is moved to another OU or renamed.
• canonicalName — the same path in DNS order (contoso.com/Users/User1), which some tools expect instead. Swap the comma-separated form for this one only when the application asks for it.
• sAMAccountName — the pre-Windows 2000 logon name, still the attribute most applications use for authentication. Cannot be relied on for uniqueness across the whole forest.
• userPrincipalName — user1@contoso.com, the modern logon name and what you should use in application bind configurations when the app supports it.
• objectGUID — a byte array that never changes, not even when the object moves, is renamed, or is restored from the Recycle Bin. This is the identifier to persist in your own databases.
• objectSid — the security identifier. Unchanging within a domain, but a different SID is generated if the object is recreated in another domain. ACLs and file permissions store SIDs, not DNs, which is why permissions survive an OU move while DN-based configuration does not.

The practical rule: read a DN when you are configuring something today, store the GUID or SID when you are coding something that must keep working next year.

Where the DN Shows Up in Practice

The original use cases — service accounts and adding groups into applications — look like this in the real world:

• LDAP bind configuration in Jenkins, Grafana, SonarQube, GitLab or a NAS: the bind account is usually entered as its DN, and the user search base as the domain DN.
• LDAP group filters, where the full DN of the group is embedded in the filter string:

  (&(objectClass=user)(memberOf=CN=App-Users,OU=Groups,DC=contoso,DC=com))

• Service account identity for a scheduled task, IIS application pool or a third-party service, where the wizard accepts the DN or the UPN but the documentation usually shows the DN.
• Attribute-level targeting in Group Preferences, where individual items are scoped to a security group identified by its DN.
• Integrations that write back to the directory — a ticketing system granting a licence to a DN it read at import time. When that object moves, the next sync fails with "object not found" until the DN is re-resolved.

If the surrounding identity work is cloud-adjacent rather than on-premises, the same concepts reappear in Microsoft Entra ID Governance access packages, where the grouping objects are referenced by ID rather than by path. The attribute vocabulary itself is worth understanding before you touch any of it — the AD schema defines distinguishedName as a constructed, non-writable attribute built from the object's RDN and its parent chain, which is why you can never "set" a DN directly: you move or rename the object, and the DN follows.

Common Pitfalls

• Unescaped special characters. A group called "IT, Ops" needs CN=IT\, Ops. Without the backslash the DN points somewhere that does not exist, or worse, to a different valid object.
• The DN changes when the object moves. Renaming an OU does not break SID-based permissions, but it instantly invalidates every configuration field that stored a DN.
• Wrong property case in filters. LDAP attribute names are case-insensitive in searches but the directory will reject distinguishedname in some third-party clients that validate against the schema strictly. distinguishedName is the safe spelling.
• Truncation in application text fields. Deeply nested OUs produce very long DNs, and plenty of older web UIs silently cut the value off at 255 characters. Test with the longest DN in your directory, not the shortest.
• Mixing DN and FQDN. contoso\user1, user1@contoso.com and CN=User1,OU=Users,DC=contoso,DC=com are three different strings for the same person. Entering the wrong one produces "invalid credentials" style errors that look like a password problem.
• Restores from the Recycle Bin. A restored object comes back with a new DN under CN=Deleted Objects until it is restored to its original location, so re-check the DN after any recovery operation.

Summary

Everything in AD has a Distinguished Name, and there are two reliable routes to it: the Attribute Editor in Active Directory Users and Computers — provided View > Advanced Features is enabled — or a one-line Get-AD* command with | FL Name, DistinguishedName. Use the DN when a tool asks you for it, expect it to change when the object moves, and store something immutable like the objectGUID if you are writing the integration yourself.

Those are all the various methods to get a distinguished name from Active Directory.

原文链接：https://thedxt.ca/2023/07/distinguished-name/