For the past few weeks I have been seeing a problem where certain users in my lab seem to authenticate against AD when logging in to our Lion machines, but do not get a proper home directory and cannot run anything. I fired up dscl and noticed right off the bat that the (generated) AuthenticationAuthority attribute was listing baaad data, like so:

;Kerberosv5;;(null)@DOMAIN.FOREST.MYSCHOOL.EDU;DOMAIN.FOREST.MYSCHOOL.EDU;
;NetLogon;(null);DOMAIN

For users who weren’t having problems, it should look like:

;Kerberosv5;;[email protected];DOMAIN.FOREST.MYSCHOOL.EDU;
;NetLogon;username;DOMAIN

After comparing the AD records of affected and unaffected users, the only difference in the native attributes that I could find was in the userPrincipalName attribute. For the users having problems it had changed from “[email protected]” to “[email protected]”. Sure enough, when I spoke to these users they had all recently received Live@edu (outlook live) accounts.

A little more digging turned up this Apple support thread on problems with Lion’s AD plugin and malformed UPNs:

https://discussions.apple.com/message/16015242#16015242

Has anyone encountered something similar resulting from Live@edu? Thoughts? I reached out to the AD admins here, but we are a VERY large institution and I am betting that they won’t alter the Live@edu deployment for something as trivial as AD authentication on Macs (grumble grumble).

Man, I am so glad I spent all that time getting my Lion AD stuff to work well. 😐