[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PKINIT from Windows ?




Craig Huckabee <huck@spawar.navy.mil> writes:

> 2) Win2K, in an AD domain:
> - completely ignores any trusted domain settings, sends all pkinit
> requests to the DC it is associated with

You got the cross realm working with passwords first. Windows clients will
always send the request to its DC first, and then get a redirection to the
requested domain using referrals.

> 3) Win2K, removed from the AD domain:
> - sends over <certificate subject name>@REALM in the AS-REQ
> - Heimdal rejects this unknown user
> - changed pki-mapping file to:
> 	<user>@REALM:<certificate subject name>
> and restarted the kdc, same results.
>
> I'm guessing in case #3, the client isn't doing PKINIT or my
> pki-mapping file is wrong.  If I can sniff the packets between the
> client and KDC, is there a clue I can look for to see if this the
> AS-REQ is a PKINIT type ?

Yes, if you use ethereal you'll see the requested principal, but I don't
think the ethereal people have a chance to add parsing of the requests
yet. If you share traces and key material, I'm sure they will add it.

Does you certificate have a UPN (universal/unique principal name) in
SubjectAltName, if you check certificates that is generated by windows DC
for smartcard login you'll see that they have added a text version of the
UPN in the certificate, openssl x509 -text describes it as:


            X509v3 Subject Alternative Name: 
                othername:<unsupported>


> My test KDC is built from the Heimdal 20050622 snapshots with one
> patch to lib/hdb/mkey.c to make an MIT master key work.

What patch was needed ?

Love

PGP signature