Basics: How users are identified in UNIX and in Active Directory

In UNIX:  UIDs and more...

UNIX users are identified in the system by their user identifier (UID for short), but a complete UNIX identity has more than that.  For a simple structure, it has stood the test of time:

1. Login name:  this is basically the user account in understandeable format.  Login names are important subjects of planning, because in there are older versions of UNIX that don't like more than 8 characters in the login name.  
2. UID:  user identifier or unique identifier.  This is the number that the OS assigns to files/folders,  processes for permissions, etc.  Typically UIDs from 0 to 100 are reserved.  The root account has UID 0.
3. Group ID or GID:  This is the default group that the user belongs to.  In modern systems, there's a concept of the auto private group, this means that users by default belong to the GID that matches their UID.
4. GECOS field:  Typically the description field.  For humans is just heir Display Name and other information like their phone extension. 
5. Home Directory:  Location of the users's files.  Typically /home, or /exports/home or whatever the standardized location for users is.
6. Shell (or login Shell):  The command interpreter for the end user.  This field also requires a bit of planning because not all shells may be installed in all systems.

User identity information in stand alone systems is stored in the /etc/passwd file.  The format is as follows:

Login name : Encrypted Password (deprecated) : UID : GID : GECOS : Home Path : Shell Path

Example:
login: Jim
UID/GID: 305
GECOS: James T Brown
Home: /home/jim
Shell: /bin/bash

jim:x:305:305:James T. Brown:/home/jim:/bin/bash

Ahhh simplicity!!!!

In Active Directory:  UPNs and more....

Active Directory does things a bit different, as an LDAP directory it uses a lot of X.500 legacy fields, but for the purposes of simplifying the process, here are the key fields:

Note:  When you create a user in AD, all you need to specify are the User logon name, either a name, last name or middle initial and a password.  However, it's a little bit more complex than this.  It will create these key fields:

1. User Principal Name or UPN:  typically in the format of <user>@ad-domain-name 
2. sAMAccountName: This is the account's short name (<20 characters)
3. System Identifier:   In AD speak, the system identifier is called ObjectSID.  It contains the unique domain identifier, plus a globally unique identifier.

However, if you look at our user Jim, here's all the information that was added just by typing the default info:

Dn: CN=Jim Brown,OU=IT,OU=Staff,DC=contoso,DC=com
accountExpires: 9223372036854775807 (never);
badPasswordTime: 0 (never);
badPwdCount: 0;
cn: Jim Brown;
codePage: 0;
countryCode: 0;
displayName: Jim Brown;
distinguishedName: CN=Jim Brown,OU=IT,OU=Staff,DC=contoso,DC=com;
dSCorePropagationData: 0x0 = (  );
givenName: Jim;
instanceType: 0x4 = ( WRITE );
lastLogoff: 0 (never);
lastLogon: 0 (never);
logonCount: 0;
name: Jim Brown;
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=contoso,DC=com;
objectClass (4): top; person; organizationalPerson; user;
objectGUID: 6698f079-e870-43be-9c14-02260dfbafff;
objectSid: S-1-5-21-3571224596-3006733700-3057749774-1297;
primaryGroupID: 513 = ( GROUP_RID_USERS );
pwdLastSet: 12/10/2013 9:28:34 PM Eastern Standard Time;
sAMAccountName: james.brown;
sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT );
sn: Brown;
userAccountControl: 0x200 = ( NORMAL_ACCOUNT );
userPrincipalName: james.brown@contoso.com;
uSNChanged: 282804;
uSNCreated: 282799;
whenChanged: 12/10/2013 9:28:34 PM Eastern Standard Time;
whenCreated: 12/10/2013 9:28:34 PM Eastern Standard Time;

Notice that there are significantly more fields created.  A lot of them are internal, others iexternal, like the DN. This is the x.500 format of the directory location of the object.  It says that the user object is in the Organizational Unit IT, under the OU Staff.

Depending on how the Active Directory schema has been modified, it's possible that more fields are added by default.  For example, on an AD that has been modified for Microsoft Exchange, depending on how things are set up, an e-mail address may be provisioned.   Notice that the e-mail address can be different (or the same) as the UserPrincipalName.

So what is a Schema then?

In the context of databases a schema simply specifieswhich attributes can be defined.  It's also known to old System Analysts like me like a Data Dictionary.  The best way to illustrate it is with an example.  

The white pages has a very simple schema:

Lastname, First Name

Address

Phone Number

Suppose that tomorrow a decision is made to include e-mail addresses in the  white pages.  The schema of the white pages has to be "extended" to accommodate e-mail address.  This means that we have to think

a) How many characters can we allow before the @ symbol?

b) Are we going to validate that the domain is valid?

All these decisions have impact on the size of the white pages database.  If tomorrow the White Pages team realizes that nobody will use their service to find email addresses, the database will have been extended and another project has to be initiated to eliminate this field.

In my previous post, I discussed that the Windows Administrator is worried about the use of proprietary schema extensions in AD, because the more schema extensions, the larger the AD database can be and if the product does not cut it, there's no way to go back in and remove those extensions.

In practical terms, there are two mitigating factors about the size concern:  the bandwidth in corporate networks and the database technology in AD  (Extensible Database Engine or ESE) that only replicates the deltas (but that's a topic for another post).
However, the concern is perfectly legitimate when it comes to proprietary extensions.  Can the solution guarantee success?

Centrify's Approach to UNIX Identities in Active Directory

The benefit of using Centrify is that it leverages schema extensions existing in AD since version 31 (Windows Server 2003 R2) specifically RFC 2307.  So do not worry Windows admins, no schema extensions required;  when you combine this with Centrify's proprietary Zones, System Administrators have a very flexible model that allows for a robust UNIX Identity Management model that can satisfy the needs of the most complex enterprises.

UNIX Profile properties for an end user in Centrify Access Manager