On 10/4/07, Ben W Young wrote:
> Hi,
> Has anyone come across an issue where you cannot authenticate using the
> Kerberos.app (or kinit) with an AD account with a different name for the UPN
> and SAM? The SAM will authenticate but not the UPN? If the UPN and the SAM
> are the same it authenticates. Hope I explained my self ok...?
> E.g.
> Trying to authenticate as "bob.jackson"
> Account:
> UPN: bob.jackson@test
> SAM: bjackson
> ....Doesn't work
> Trying to authenticate as "bjackson"
> UPN: bob.jackson@test
> SAM: bjackson
> ....works!

Hi Ben,

Active Directory does not use the userPrincipalName attribute to do
Kerberos authentication. It uses sAMAccountName@dnsRoot.

The Windows credential dialog will accept the userPrincipalName but it
queries the directory, retrieves the sAMAccountName and uses that name
to initiate Kerberos authentication instead.

> If I change the SAM account to the UPN bob.jackson it works?

Yes. If the userPrincipalName is the same as the sAMAccountName then
of course it will work. AD doesn't really use the userPrincipalName
attribute for much of anything that I'm aware of. I asked around about
this once and got some cryptic answers. So it is used but not for
initiating Kerberos authentication. My impression is that it's just
some kind of indirection mechanism.

> Also, why cant I authenticate with the true UPN name: bob.jacskson@test?
> Is it something I have to change in the edu.mit.kerberos file? See below
> example?

No and no. There's nothing you can do. Kerberos.app would have to be
modified to detect AD and query for the sAMAccountName and then build
the required client principal name using it (which is problematic in
itself because it would need a "machine account" of some kind to be
able to search anything beyond the RootDSE).


Michael B Allen
PHP Active Directory Kerberos SSO