MIT kinit with AD userPrincipalName with SMTP domain and not proper realm?

[Michael B Allen]

Hi,

Is it possible to acquire credentials using kinit from AD using the
userPrincipalName on an AD account if the DNS domain does not match
the AD realm?

Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM
and userPrincipalName attributes on accounts in AD use the SMTP domain
like al...@EXAMPLE.COM can initial credentials be acquired?

If I try kinit I get:

$ kinit -f al...@EXAMPLE.COM
kinit(v5): Cannot resolve network address for KDC in realm
EXAMPLE.COM while getting initial credentials

If I then add the following to my krb5.conf:

[realms]
EXAMPLE.COM = {
dc1.example.local
}

and try kinit again I get:

$ kinit -f al...@EXAMPLE.COM
kinit(v5): KRB5 error code 68 while getting initial credentials

and a capture shows the AS-REQ realm and service realm is EXAMPLE.COM.
Error code 68 is KDC_ERR_WRONG_REALM.

Adding .example.com = EXAMPLE.COM to [domain_realm] doesn't appear to
have any effect.

Of course using the implied principal name <sAMAccountName>@<dnsRoot> works:

$ kinit -f al...@EXAMPLE.LOCAL
Password for al...@EXAMPLE.LOCAL: ...

Windows must be able to do this. How does a Windows client know that
the SMTP domain should be substituted with a proper realm and which
one?

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

[Michael B Allen]

Well it's all coming back to me now. It seems this has been discussed before:

http://mailman.mit.edu/pipermail/kerberos/2007-October/012373.html

The userPrincipalName is only used if the principal type is 10
(KRB5_NT_ENTERPRISE_PRINCIPAL or perhaps GSS_C_NT_ENTERPRISE_PRINCIPAL
if GSSAPI supported such a thing). AD will also canonicalize the
supplied name in the AS-REP to the sAMAccountName@dnsRoot.

As for the domain, I'm still a little fuzzy there as well. I would
have to take some captures to see if the Windows client tries to
lookup the domain name supplied or if it simply ignored the @domain
and sent the AS-REQ to the default authority.

Mike

On Fri, Nov 20, 2009 at 7:48 PM, Michael B Allen <iop...@gmail.com> wrote:
> Hi,
>
> Is it possible to acquire credentials using kinit from AD using the
> userPrincipalName on an AD account if the DNS domain does not match
> the AD realm?
>
> Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM
> and userPrincipalName attributes on accounts in AD use the SMTP domain
> like al...@EXAMPLE.COM can initial credentials be acquired?
>
> If I try kinit I get:
>

> �ｿｽ$ kinit -f al...@EXAMPLE.COM
> �ｿｽkinit(v5): Cannot resolve network address for KDC in realm

> EXAMPLE.COM while getting initial credentials
>
> If I then add the following to my krb5.conf:
>

> �ｿｽ[realms]
> �ｿｽ �ｿｽEXAMPLE.COM = {
> �ｿｽ �ｿｽ �ｿｽdc1.example.local
> �ｿｽ �ｿｽ}

>
> and try kinit again I get:
>

> �ｿｽ$ kinit -f al...@EXAMPLE.COM
> �ｿｽkinit(v5): KRB5 error code 68 while getting initial credentials

>
> and a capture shows the AS-REQ realm and service realm is EXAMPLE.COM.
> Error code 68 is KDC_ERR_WRONG_REALM.
>
> Adding .example.com = EXAMPLE.COM to [domain_realm] doesn't appear to
> have any effect.
>
> Of course using the implied principal name <sAMAccountName>@<dnsRoot> works:
>

> �ｿｽ$ kinit -f al...@EXAMPLE.LOCAL
> �ｿｽPassword for al...@EXAMPLE.LOCAL: ...

[Luke Howard]

> Meaning if I have a realm EXAMPLE.LOCAL and an SMTP domain EXAMPLE.COM
> and userPrincipalName attributes on accounts in AD use the SMTP domain
> like al...@EXAMPLE.COM can initial credentials be acquired?
>
> If I try kinit I get:
>

> $ kinit -f al...@EXAMPLE.COM

> kinit(v5): Cannot resolve network address for KDC in realm
> EXAMPLE.COM while getting initial credentials

kinit -E -f al...@example.com@EXAMPLE.LOCAL

NB: if this doesn't work in 1.7, try trunk, I think it may have been
broken in 1.7.

-- Luke

[Michael B Allen]

Hi Luke,

I understand now. Unfortunately, in practice, I need much more than
kinit. I'm integrated with an old version of Heidmal so it seems I'll
need to work on moving to a newer Heimdal and possibly work on
krb5/principal.c:build_principal et al if the latest Heimdal doesn't
already have it. I also want to do this with Java but given the
spotted history of Java's builtin Kerberos implementation I don't
expect that to be tackled easily. I kinda wish I just had a really
solid ASN.1 compiler and crypto lib for the various languages. Ho-hum.

Thanks,

[Love Hörnquist Åstrand]

>
> I understand now. Unfortunately, in practice, I need much more than
> kinit. I'm integrated with an old version of Heidmal so it seems I'll
> need to work on moving to a newer Heimdal and possibly work on
> krb5/principal.c:build_principal et al if the latest Heimdal doesn't
> already have it.

Heimdal 1.3.1 supports enterprise names. Both with PKINIT and password based initial credentials fetching.

Love

[Luke Howard]

Hi Mike,

> I understand now. Unfortunately, in practice, I need much more than
> kinit. I'm integrated with an old version of Heidmal so it seems I'll
> need to work on moving to a newer Heimdal and possibly work on
> krb5/principal.c:build_principal et al if the latest Heimdal doesn't

> already have it. I also want to do this with Java but given the
> spotted history of Java's builtin Kerberos implementation I don't
> expect that to be tackled easily. I kinda wish I just had a really
> solid ASN.1 compiler and crypto lib for the various languages. Ho-hum.

Ah, I assumed you were using MIT.

For those that are, there is AS referral support in 1.7, but from
memory there are some bugs (which really should be fixed in a patch
release). I don't have the details on hand. It definitely works in
trunk and thus 1.8.

-- Luke