Active Directory, Lion and "AuthenticationAuthority"

Hi Sven

I haven't found a solution, but I filed a bug report with Apple and was told that this is a known issue and they are working on it. I really hope they are working fast - the 10.7.1 update did not address this, it's still not working.

Just out of curiosity: Do you also have users where it is working, or does login fail for all? I suspect the bug has something to do with more than one RecordName and maybe with the userPrincipalName attribute, but at the moment this is pure speculation - I have no means to test that.

Tina

sorry, should read more carefully, obviously you do have users that are working. I'm not at work at the moment, so I can't check, but I have found differences between users that can log in and those that can't. I'll post back tomorrow what exactly that was. Don't want to tell you something wrong...

Tina

Hi Sven

Yes, I agree - the (null)@domain.com entry is the (direct) reason for the failed login, but what is causing this entry to be wrong in the first place? I've been trying to track this down, but all I have is some guesses. I'll try to summarize them as systematically as possible.

AD structure: Our AD is a Win Server 2008 R2. All students and employees have an AD account in the main OU. All those users have the (null) entry (obviously I didn't check them all, but all that I looked at). I have only read access to those user accounts. Some institutions additionally have their own OU, as we do, where we can create users, add computers etc. The users in those OUs can usually log in (i.e. do not have the (null) entry), but not all of them.

User attributes: The "normal" users in the main OU are more "complicated" than the users I create in our OU. They have more different login names and more attributes.

If I look at users with dscl in 10.6 and 10.7, I can see differences in the attributes RecordName, AltSecurityIdentities, userPrincipalName and, of course, AuthenticationAuthority.

Examples:

Mac OS X 10.7, user csiege (can't login), output of dscl (partial):

dsAttrTypeNative:distinguishedName:

CN=Siegenthaler Christina (csiege),OU=Users,OU=Users XYZ,DC=d,DC=xyz,DC=ch

dsAttrTypeNative:name:

Siegenthaler Christina (csiege)

dsAttrTypeNative:sAMAccountName: csiege

dsAttrTypeNative:userPrincipalName: tina.siegenthaler@ieu.xyz.ch

AltSecurityIdentities: Kerberos:tina.siegenthaler@ieu.xyz.ch

AuthenticationAuthority: ;Kerberosv5;;(null)@D.XYZ.CH;D.XYZ.CH; ;NetLogon;(null);XYZ

RealName:

Siegenthaler Christina (csiege)

RecordName: tina.siegenthaler

Note: sAMAccountName is csiege, but RecordName is tina.siegenthaler (only 1 RecordName)

Output of dscl of the same user, but on 10.6:

dsAttrTypeNative:distinguishedName:

CN=Siegenthaler Christina (csiege),OU=Users,OU=Users XYZ,DC=d,DC=xyz,DC=ch

dsAttrTypeNative:name:

Siegenthaler Christina (csiege)

dsAttrTypeNative:sAMAccountName: csiege

dsAttrTypeNative:userPrincipalName: tina.siegenthaler@ieu.xyz.ch

AltSecurityIdentities: Kerberos:csiege@D.XYZ.CH

RealName:

Christina Siegenthaler (csiege)

RecordName:

csiege

tina.siegenthaler

siegenthaler christina (csiege)

csiege@d.xyz.ch

tina.siegenthaler@ieu.xyz.ch

XYZ\csiege

XYZ\siegenthaler christina (csiege)

Christina Siegenthaler (csiege)

tina.siegenthaler@ieu.xyz.ch

Note: Differences to 10.7 in AltSecurityIdentities; sAMAccountName is csiege, first (of 9!) RecordNames is also csiege

Again 10.7, user csiege-adm (one of my "own" users), can log in:

dsAttrTypeNative:distinguishedName:

CN=Siegenthaler Christina (csiege-adm),OU=Admins,OU=IEU,OU=XYZ,DC=d,DC=xyz,DC=ch

dsAttrTypeNative:name:

Siegenthaler Christina (csiege-adm)

dsAttrTypeNative:sAMAccountName: csiege-adm

dsAttrTypeNative:userPrincipalName: csiege-adm@d.xyz.ch

AltSecurityIdentities: Kerberos:csiege-adm@d.xyz.ch

AuthenticationAuthority: ;Kerberosv5;;csiege-adm@D.XYZ.CH;D.XYZ.CH; ;NetLogon;csiege-adm;XYZ

RealName:

Siegenthaler Christina (csiege-adm)

RecordName: csiege-adm

Note: sAMAccountName csiege-adm, RecordName csiege-adm (again, only one, but matches sAMAccountName); difference to user csiege seen from 10.7 in userPrincipalName

Users on AD: As I mentioned, I only have limited access to most AD users (and I'm not very good with AD either), but I have found the following:

User logon name for csiege: tina.siegenthaler@ieu.xyz.ch

User logon name for csiege-adm: csiege-adm@d.xyz.ch

I have no idea if these differences mean anything, and I may be on a completely wrong track here, but I think they are at least suspicious. And they're the only differences I have found so far.

/System/Library/OpenDirectory/Templates/Active Directory.plist:

From this part

<key>dsAttrTypeStandard:AuthenticationAuthority</key>

<dict>

<key>custom</key>

<dict>

<key>attributes</key>

<array>

<string>sAMAccountName</string>

<string>userPrincipalName</string>

</array>

<key>translate</key>

<string>ActiveDirectory:translate_authauthority</string>

</dict>

</dict>

it seems that a function "translate_authauthoriy" uses sAMAccountName and userPrincipalName to calculate the AuthenticationAuthority attribute. I have tried and changed the attribute strings, but to no effect, even if I used some non-existing attribute names.

I really wish they would stop breaking Directory Services with each and every update...

Any thoughts, comments?

Tina

Hm. The userPrincipalName of a (my) not-working account does not contain capital letters... so it must be something else for me.

But I'd like to have a look at such an export file too, how do you get them? In "Active Directory Users and Computers"? Maybe I can find something.

Tina

Edit: Just created a new AD user "Test-IEU"; userPrincipalName Test-IEU@d.xyz.ch -> AuthenticationAuthority is OK, despite the capital letters. I rather suspect that it has something to do with userPrincipalName (the part before the @) and RecordName not being the same, but I can't prove it.

Thanks, that's really a great tool. I have looked at two users, one that can log in and one that can't, and really the only difference is in the attributes userPrincipalName and sAMAccountName.

User who can log in:

sAMAccountName = csiege-adm

userPrincipalName = csiege-adm@d.xyz.ch

User who cannot log in:

sAMAccountName = csiege

userPrincipalName = tina.siegenthaler@ieu.xyz.ch

Since userPrincipalName and sAMAccountName are the attributes that are used to calculate AuthenticationAuthority, it is possible that this difference is causing the problem (i.e. sAMAccountName and the first part of userPrincipalName not being identical).

Ah, yes - just tried it. Created a test user:

sAMAccountName = csiege-ieu

userPrincipalName = csiege-ieu@d.xyz.ch

=> AuthenticationAuthority is OK.

changed the userPrincipalName to tina.test@ieu.xyz.ch

AuthenticationAuthority is (null)...etc.!

OK - is it the part before the @ or after the @?

Tried different versions, and it is the part AFTER the @ in userPrincipalName:

If it is xxxx@ieu.xyz.ch, AuthenticationAuthority is (null)...

If it is xxxx@d.xyz.ch, AuthenticationAuthority is OK.

The part before the @ is not relevant and can be whatever I like, but the part after the @ MUST be the domain.

Comments?

Tina

EDIT: Unfortunately, I can't edit the (original) non-working user csiege. I'd love to test if I can get it to work...

@ Dennis

If I use D.XYZ.CH in the userPrincipalName instead of d.xyz.ch, it is not working either. You did not specify in your post where the upper case letters were - in the user name or in the domain, i.e. before or after the @?

Tina

OK, so can we state the following:

In order to have AD accounts work with Lion, the domain part of userPrincipalName must be exactly the Active Directory domain in lower case letters. Anything else, like the AD domain name in upper case or another domain name (for example, as in my case, the email address), will not work.

Agreed?

Tina