Kerberos.app AD UPN & SAM authentication issue

[Michael B Allen]

On 10/4/07, Russ Allbery <rra at stanford.edu> wrote:
> "Michael B Allen" <ioplex at gmail.com> writes:
>
> > Active Directory does not use the userPrincipalName attribute to do
> > Kerberos authentication. It uses sAMAccountName at dnsRoot.
>
> I just tested against our Active Directory with an account that had both
> userPrincipalName and sAMAccountName set to different values and was able
> to authenticate using either of the two names via kinit from a Debian
> system.  Either returned valid tickets for the principal name that I used,
> and both had the same password and hence were using the same Active
> Directory record.

Hey Russ,

Ok, I messed this up a little.

Windows clients always use sAMAccountName at dnsRoot to intiate Kerberos
authentication but, you're right too, AD will accept the
userPrincipalName. To demonstrate this, try logging into a Windows
workstation joined to an AD domain using the userPrincipalName. Then
run kerbtray and look at the Client Principal Name. You'll see the
sAMAccountName at dnsRoot form. The only way it could get a TGT like that
is if it translated the userPrincipalName to sAMAccountName at dnsRoot
before it requested the it.

So my conclusion was wrong, Kerberos.app should work for Ben. Not sure
why it doesn't.

Note that this creates issues for apps that use the client principal
name as an identity used to search for stuff or hang data on in a DB
(same thing) because now there are two possible identities. This is
why all of our products normalize on the sAMAccountName. Otherwise,
with our MediaWiki plugin for example, the same user could end up with
two accounts.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/