AD UPN & SAM authentication issue

Ben W Young ben.w.young at
Mon Oct 22 00:58:46 EDT 2007

Thanks Guy's for helping me think through this. We have very large complex
AD environment and to suggest changes like turning on "translation" between
the UPN and the SAM would be like trying to get blood out of a stone.

For my script I have worked around it by doing my own "translation" by
querying the SAM account that belongs to the UPN in AD.  So it now doesn't
matter if they use the UPN expect they cant include the @domain part. I
could also write into the script to remove the last part of the UPN...but I
am over it..maybe the next version.

Thanks again!


On 7/10/07 4:09 AM, "Markus Moeller" <huaraz at> wrote:

> That is what I saw too and I create a special kinit and a patch for
> mod_auth_kerb(basic auth fallback) which sets the principal type to 10 when
> @ is part of the username to be able to use the UPN. Unfortunately  MIT nor
> Heimdal support client canonicalisation as described in the referral draft.
> Markus
> "Michael B Allen" <ioplex at> wrote in message
> news:78c6bd860710061046n4eeec95bx70a4e8d4c8e8c77b at
>> On 10/5/07, Markus Moeller <huaraz at> wrote:
>>> I think you have to differentiate between the different principal types.
>>> MS can use the enterprise principal type 10 which is matched against the
>>> UPN. Also when using the UPN with the canonicalisation flag set AD
>>> returns
>>> the Samaccountname.
>> Hi Markus,
>> Interesting. To see for my self exactly what was happening in the XP
>> workstation login w/ userPrincipalName scenario I described, I took a
>> capture and indeed I see:
>> AS-REQ: test at EXAMPLE.COM type 10
>> AS-REP: testsam at EXAMPLE.COM type 1
>> So it seems canonicalization is on and working in my test AD
>> environment. There's no "translation" going on as I suspected
>> previously. I didn't think I changed any settings so I assume
>> canonicalization is on by default in AD.
>> Now we could use GSS_C_NT_ENTERPRISE_PRINCIPAL for gss_import_name. I
>> see Heimdal's gss_import_name doesn't handle it yet (although it does
>> at the krb5 level).
>> Thanks,
>> Mike
>> -- 
>> Michael B Allen
>> PHP Active Directory SPNEGO SSO
>> ________________________________________________
>> Kerberos mailing list           Kerberos at
> ________________________________________________
> Kerberos mailing list           Kerberos at

Ben W Young
Technology Services Administrator
DET NSW - Northern Sydney Region
3a Smalls Road, Ryde 2114.
Mobile 0423604634
Email ben.w.young at

This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.

More information about the Kerberos mailing list