How to uniquely identify an user in a forest across domains :
Security IDs (SIDs)
A security identifier (SID) is a unique number created by the
security subsystem of the Windows 2000 operating system, and assigned to
security principal objects, that is, to user, group, and computer
accounts. Every account on your network is issued a unique SID when that
account is first created. Internal processes in the Windows 2000
operating system refer to an account's SID rather than to the account's
user or group name.
Each Active Directory object is protected by access control entries
(ACEs) that identify which users or groups can access that object. Each
ACE contains the SID of each user or group who has permission to access
that object and defines what level of access is allowed. For example, a
user might have read-only access to certain files, read-and-write access
to others, and no access to others.
If you create an account, delete it, and then create an account with
the same user name, the new account does not have the rights or
permissions previously granted to the old account, because the accounts
have different SID numbers.
User Principal Name
In Active Directory, each user account has a user principal name (UPN) in the format <user>@<DNS-domain-name>.
A UPN is a friendly name assigned by an administrator that is shorter
than the LDAP distinguished name used by the system and easier to
remember. The UPN is independent of the user object's DN, so a user
object can be moved or renamed without affecting the user logon name.
When logging on using a UPN, users no longer have to choose a domain
from a list on the logon dialog box.
The UPN's three parts are the UPN prefix (user logon name), the @
character, and the UPN suffix (usually, a domain name). The default UPN
suffix for a user account is the DNS name of the Active Directory domain
where the user account is located9. For
example, the UPN for user John Doe, who has a user account in the
OrgName.com domain (if OrgName.com is the only domain in the tree), is
JDoe@OrgName.com.The UPN is an attribute (userPrincipalName) of the
security principal object. If a user object's userPrincipalName
attribute has no value, the user object has a default UPN of
If your organization has many domains forming a deep domain tree,
organized by department and region, default UPN names can become
unwieldy. For example, the default UPN for a user might be
sales.westcoast.microsoft.com. The logon name for a user in that domain
is email@example.com. Instead of accepting the
default DNS domain name as the UPN suffix, you can simplify both
administration and user logon processes by providing a single UPN suffix
for all users. (The UPN suffix is used only within the Windows 2000
domain and is not required to be a valid DNS domain name.) You can
choose to use your e-mail domain name as the UPN
suffix—userName@companyName.com. This gives the user in the example the
UPN name of firstname.lastname@example.org.
For a UPN–based logon, a global catalog may be necessary, depending
on the user logging on, and the domain membership of the user's
computer. A global catalog is needed if the user logs on with a
non-default UPN and the user's machine account is in a different domain
than the user's user account. That is, if, instead of accepting the
default DNS domain name as the UPN suffix (as in the example just given,
email@example.com), you provide a single UPN suffix for all users (so that the user then becomes simply user@ microsoft.com), a global catalog is required for logon.
You use the Active Directory Domains and Trusts tool to manage UPN
suffixes for a domain. UPNs are assigned at the time a user is created.
If you have created additional suffixes for the domain, you can select
from the list of available suffixes when you create the user or group
account. The suffixes appear in the list in the following order:
Alternate suffixes (if any; last one created appears first).
The current domain.
SAM Account Name
A Security Account Manager (SAM) account name is required for compatibility with Windows NT 3.x
and Windows NT 4.0 domains. The Windows 2000 user interface refers to
the SAM account name as the "User logon name (pre-Windows 2000)."
SAM account names are sometimes referred to as flat names
because—unlike DNS names—SAM account names do not use hierarchical
naming. Because SAM names are flat, each one must be unique in the
LDAP URL Names
Active Directory supports access using the LDAP protocol from any
LDAP-enabled client. RFC 1959 describes a format for an LDAP Uniform
Resource Locator (URL) that lets Internet clients have direct access to
the LDAP protocol. LDAP URLs are also used in scripting. An LDAP URL
begins with the prefix "LDAP," and then it names the server holding
Active Directory services followed by the attributed name of the object
(the distinguished name). For example:
LDAP-based Active Directory Canonical Names
By default, Active Directory administrative tools display object names using the canonical name
format, which lists the RDNs from the root downward and without the RFC
1779 naming attribute descriptors (dc=, ou=, or cn=). The canonical
name uses the DNS domain name format, that is, the constituents of the
domain labels section of the name are separated by
periods—USRegion.OrgName.com. Table 3 contrasts the LDAP DN with the
same name in canonical name format.
LDAP DN format contrasted with the canonical name format Same Name in Two Formats LDAP DN Name: cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName.dc=com Canonical Name: USRegion.OrgName.com/Manufacturing/Widgets/JDoe
In addition to its LDAP DN, every object in Active Directory has a globally unique identifier
(GUID), a 128-bit number assigned by the Directory System Agent when
the object is created. The GUID, which cannot be altered or removed, is
stored in an attribute, objectGUID, which is a required attribute for
every object. Unlike a DN or RDN, which can be changed, the GUID never
When storing a reference to an Active Directory object in an external
store (for example, a Microsoft SQL Server™ database), the objectGUID
value should be used.
Identity Management products developer since 2003. Currently working on development of Identity Management Products. Have past experience in development of Oblix, Sun and Oracle IdM products.
(Email: abburi.lakshman at gmail dot com)