What's in a name?

[Alex Simons (AZURE)]

First published on CloudBlogs on Feb, 27 2008

Have you ever heard the Shakespeare paraphrased saying “a rose by any other name is still a rose?”.    Well, the same holds true for objects in AD.  Not that we have “rose” class objects, but the point being that simply renaming an object doesn’t really fundamentally alter that object.

Here’s how this came up, and I think you’ll agree that this is a really interesting issue.

Since there are many Microsoft products that utilize Active Directory and security for their purposes it’s not uncommon for a Directory Services person to get contacted by our colleagues who support Exchange or SQL or <insert any of a myriad of products here>.  We take it all in stride even though we often have little clue about how the other product works in depth.

A while ago I was contacted by one of my Exchange colleagues who wanted a little guidance on a problem he was seeing with Exchange 2007.  It seems that one user in particular was having difficulty sending and receiving email.  That user (and only that user) would get an error and the events below would appear on the Exchange server:

Event Type:     Warning

Event Source:  MSExchangeIMAP4

Event Category:          General

Event ID:        1005

Date:               10/15/2007

Time:               7:10:55 AM

User:                N/A

Computer:       SERVER2

Description:

Authenticated user DOMAINAbilly.bob attempts to access IMAP but is disabled for that protocol.

and…

Event Type:         Warning

Event Source:     MSExchangeTransport

Event Category:                SmtpReceive

Event ID:              1020

Date:                     10/15/2007

Time:                     5:45:06  PM

User:                     N/A

Computer:          SERVER2

Description:

The account 'DOMAINAbilly.bob' provided valid credentials, but is not authorized to use the server; failing authentication.

Since the messages talk about authentication it made sense that we would be consulted, though in all honesty the Exchange person really contacted me just to confirm what he already knew.

So why was the user failing to send and receive email?  The reason became apparent when the user’s object was viewed using LDP.EXE.  Below is an edited version of that dump with something of particular interest made bold.

User Billy Bob

Expanding base 'CN=Billy Bob,OU=Midwest,OU=North America,DC=DOMAINA,DC=NET'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=Billy Bob,OU=Midwest,OU=North America,DC=DOMAINA,DC=NET

4> objectClass: top; person; organizationalPerson; user;

1> cn: Billy Bob;

1> sn: Bob;

1> title: VP IT;

&n bsp;      1> description: Vice President of Information Technology;

1> physicalDeliveryOfficeName: Kansas City;

1> telephoneNumber: +1 555 867 5309

1> givenName: Billy;

1> distinguishedName: CN=Billy Bob,OU=Midwest,OU=North America,DC=DOMAINA,DC=NET;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 12/01/2001 13:05:54 Central Standard Time Central Daylight Time;

1> whenChanged: 09/14/2007 10:01:15 Central Standard Time Central Daylight Time;

1> displayName: Billy Bob;

1>     uSNCreated: 12426;

2>     > uSNChanged: 22348056;

1> mDBUseDefaults: TRUE;

3>             1> mAPIRecipient: TRUE;

4>             1> mailNickname: billy.bob;

5>             1> replicatedObjectVersion: 0;

6>             1> name: Billy Bob;

7>             1> objectGUID: cb-88515-5521-86r3-378854b33385309;

8>             1> userAccountControl: 0x10200 = ( UF_NORMAL_ACCOUNT | UF_DONT_EXPIRE_PASSWD );

9>             1> pwdLastSet: 10/02/2007  08:17:01 Central Standard Time Central Daylight Time;

10>          1> primaryGroupID: 519;

11> 1> objectSid: S-1-5-21-11235-136055884-8675309-500;

12>          1> sAMAccountName: billy.bob;

13>          1> sAMAccountType: 805306368;

So why is the objectSID in bold as a supposed problem?    Well, take a look at the similarity between the problematic user above and a dump of my built in Administrator account from a test domain:

Expanding base 'CN=Administrator,CN=Users,DC=adatum,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=Administrator,CN=Users,DC=adatum,DC=com

4> objectClass: top; person; organizationalPerson; user;

1> cn: Administrator;

1> description: Built-in account for administering the computer/domain;

1> distinguishedName: CN=Administrator,CN=Users,DC=adatum,DC=com;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 02/16/2006 14:22:49 Central Standard Time Central Daylight Time;

1> whenChanged: 02/18/2008 15:01:08 Central Standard Time Central Daylight Time;

1> uSNCreated: 8194;

1> uSNChanged: 262176;

1> name: Administrator;

1> objectGUID: f76f7866-0abc-4068-80a5-823398b79aa1;

1> userAccountControl: 0x10200 = ( UF_NORMAL_ACCOUNT | UF_DONT_EXPIRE_PASSWD );

1> badPwdCount: 0;

1> codePage: 0;

1> countryCode: 0;

1> badPasswordTime: 02/20/2008 10:51:22 Central Standard Time Central Daylight Time;

1> lastLogoff: 01/01/1601 00:00:00 UNC ;

1> lastLogon: 02/27/2008 02:39:56 Central Standard Time Central Daylight Time;

1> pwdLastSet: 11/28/2005 08:28:14 Central Standard Time Central Daylight Time;

1> primaryGroupID: 513;

1> objectSid: S-1-5-21-1971571114-3692455964-847255220-500;

1> adminCount: 1;

1> accountExpires: 09/14/30828 02:48:05 UNC ;

1> logonCount: 172;

1> sAMAccountName: Administrator;

1> sAMAccountType: 805306368;

1> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=adatum,DC=com;

1> isCriticalSystemObject: TRUE;

1> lastLogonTimestamp: 02/18/2008 15:01:08 Central Standard Time Central Daylight Time;

-----------

So the objectSIDs in both instances end with -500 .  This denotes a built-in, otherwise known as a “Well Known” security identifier (SID).  Every principal (users, computers) in Active Directory will have a unique security identifier and we have some security identifiers which are reserved and used for principals that are built into the product.  Here’s a Knowledge Base article that lists the well known SIDs.

So that leaves us with why does this user have that SID and why can’t he send and receive email?  Well, since SIDs are protected from alteration for security reasons it is apparent that the user Billy Bob’s account is actually the original domain Administrator accout renamed.  Combine that with a Exchange 2007 not allowing send and receive from the built in Administrator account and you have your problem.  It looks like Billy Bob is simply the domain built in Administrator account renamed to Billy Bob.

Now, it is an accepted and recommended idea to rename the built in Administrator account.  It’s just a good idea to do so.  However it is not a good idea to use that account for a general user.  Besides the Exchange reason we’ve discussed here we have a feature called AdminSDHolder .  The KB article discusses it at more length but essentially Administrator and some other objects have permissions “restamped” onto them periodically from what their default schema security is.  This is done as an excellent security feature but can wreak havoc with security delegation for object rights or distribution group memberships on those objects.

Good one, right folks?

Special thanks to Mike Brown from our Exchange support for bringing this one to my attention.  It was certainly a new one to me.