[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PKINIT from Windows ?
Love Hörnquist Åstrand wrote:
> Craig Huckabee <email@example.com> 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.
I'm sorry - I forgot to mention that we have a working trust in place.
We have an MIT 1.3.6 realm in production with a trust to our Windows
2003 AD tree. My test Heimdal slave is running MIT's kpropd, then I run
a cron job to regularly send the MIT dump through hpropd to import it
In practice, with what I've seen from sniffing the network and my KDC
logs is that, at least in the username/password case, the client always
goes to the trusted realm first and then to the KDC.
I thought, like you said, that when a trusted realm is configured, that
the initial AS-REQ went to the DC first, but that doesn't appear to be
the case. Unless we've implemented something wrong along the way which
is always possible...we followed the Microsoft guides on deploying all
of this (along with the many FAQs online).
>>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.
I've been using a commercial sniffer so far (Sniffer Pro), but I'll
load up Ethereal and see if it decodes things any better.
> 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:
Oh yes, the smartcard login bits are present - the certificates in
question are coming from a DoD CAC card.
>>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 ?