Re: Smart Card Logon Failure with Windows 2003 Server (works with Windows 2000 server)

From: Peter Schlephendorfer (p_s_consulting_at_hotmail.com)
Date: 10/24/03 

Date: Fri, 24 Oct 2003 13:08:11 -0700

Well, it appears as though CertUtil -urlfetch -verify has
decided to work now. Go figure. (CDC still won't get the
CRL though.)

Tried a couple of other things with CertUtil -url
<filename> and found a couple of interesting things.
(Hang on; I have a point.) We copied all the cert*.*
files from C:\Windows\System32 to a disk and put them on
various machines -- Windows 2000 Professional, Windows XP
Professional, Windows 2000 Server and Windows 2003
Server. We then tried to retrieve CRLs for certificates
issued from various of the external third party CA's. We
noticed that on Windows XP and 2003, the timeout parameter
we specified was implemented, but on Windows 2000 (both
Server and Professional), the timeout was not "obeyed" --
the machine continued to download the CRL. It correctly
marked the status as "Failed," but it continued to
download and reported the retrieval time.

Here's the point... This mirrors what is occurring at the
CDCs -- on a Windows 2000 CDC, it will download the CRL
irrespective of how large it is or how long it takes.
(Incidentally, the CertUtil URL Retrieval Tool reports
it's taking between 17-19 seconds to download the 4+ meg
CRL -- the time appears to be independent of the OS.)
But, on a Windows 2003 CDC, if it can't download the CRL
within X seconds, it aborts the entire process (whereas
Windows 2000 aborts the login but not the CRL download).

Bottom Line... Somehow, somewhere there has got to be a
difference in the way 2000 and 2003/XP are handling LDAP
timeouts (or it may be more generic than LDAP, but that's
all I've looked at). I have a workaround -- a script that
will grab the CRLs and place them in the proper place on
the CDC, but I would really like to present my client with
a more difinitive answer than what I've got so far.

I *REALLY* appreciate your assistance thus far. Can we
continue this just a couple more iterations via email?

PS

>-----Original Message-----
>I'm not aware of any way to adjust the timeout from a
certificate services
>perspective. One thing you can try is to add an http
location for CRL
>retrieval. It tends to be a bit more efficient with
downloads (less protocol
>overhead). Did you look for errors on the server side?
There really
>shouldn't be a different between Win2K and WS2003 in this
regard.
>
>Were you getting any specific errors when you tested with
certutil?
>
>--
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>
>
>"Peter Schlephendorfer" <p_s_consulting@hotmail.com>
wrote in message
>news:0ce201c39a4f$c6ac7270$a501280a@phx.gbl...
>> It works when we do not manually load the CRLs -- when
the
>> server OS is Windows 2000 (and I've just verified that
>> this is the case). When the OS is 2003, the CDC makes
the
>> LDAP calls to the CDP, but aborts/denies the login
before
>> the CRL is downloaded. Moreover, there is no CRL on the
>> 2003 CDC after an attempted login (whereas on the 2000
>> CDC, there is a CRL -- in Default User\Temp Internet
>> Files). (I mention this because of the sheer size of
the
>> CRL. We have seen where slow connectivity to the CDP
>> results in Windows 2000 timing out on login due to
>> downloading a 4+ meg CRL. However, even then, the CRL
>> appears on the 2000 CDC, and once it does, login is
>> allowed. In my testing this morning, the 4+ meg CRL was
>> downloaded, checked, and I was able to login in one
>> attempt.)
>>
>> PS
>>
>>
>> >-----Original Message-----
>> >A few more questions...
>> >
>> >How was the CRL published? Do you know if it is being
>> published as binary,
>> >or Base64? I'm not clear if it ever works when you have
>> not manually pulled
>> >down the CRL.
>> >
>> >--
>> >This posting is provided "AS IS" with no warranties,
and
>> confers no rights.
>> >
>> >
>> >"Peter Schlephendorfer" <p_s_consulting@hotmail.com>
>> wrote in message
>> >news:78290d88.0310240455.3ccf45e4@posting.google.com...
>> >> Thanks for the swift response.
>> >>
>> >> That would make sense to me, except that when the CRL
>> is either
>> >> deleted or exipred, the Child Domain Controller *IS*
>> attempting to get
>> >> the CRL (verified this with NETMON on the CDC).
>> >>
>> >> All the AD stuff is there, right where it's supposed
to
>> be (unless
>> >> those places have changed between 2000 and 2003?).
>> >>
>> >> We have the exact same setup with a Windows 2000
Server
>> platform
>> >> (root, child and CA servers) and 2000 works like a
>> charm. On our 2003
>> >> Server platform, however, we get this (apparent)
>> timeout issue.
>> >>
>> >> For what it's worth, a colleague located NTDSUTIL
from
>> KB #315071, and
>> >> I verified that all the settings in our 2003 AD are
>> essentially the
>> >> same as what's in that article.
>> >>
>> >> PS
>> >>
>> >> "Laudon Williams [MSFT]"
<laudonw@online.microsoft.com>
>> wrote in message
>> >news:<#FkLEYdmDHA.2424@TK2MSFTNGP10.phx.gbl>...
>> >> > Peter, a few questions. Do the end-entity
>> certificates have the
>> >appropriate
>> >> > CDP and AIA extensions? Sounds like you may have
>> identified the general
>> >> > problem (CRL checking is failing). I would also
look
>> at the CRL and see
>> >what
>> >> > the NextUpdate time is.
>> >> >
>> >> > --
>> >> > This posting is provided "AS IS" with no
warranties,
>> and confers no
>> >rights.
>> >> >
>> >> >
>> >> > "Peter Schlephendorfer"
<p_s_consulting@hotmail.com>
>> wrote in message
>> >> >
>> news:78290d88.0310231123.7527d69b@posting.google.com...
>> >> > > Setup:
>> >> > > Root Domain Controller
>> >> > > '
>> >> > > '-- Subordinate Enterprise CA (issuing Domain
>> Controller certs)
>> >> > > '
>> >> > > '-- Child Domain Controller (CDC)
>> >> > > '
>> >> > > '-- Windows 2000 Professional workstation
>> >> > >
>> >> > > Certs on the smart card are non-Microsoft certs
>> from an external third
>> >> > > party CA.
>> >> > >
>> >> > > Issue:
>> >> > > When the server OS is Windows 2000 Server,
>> everything works. When the
>> >> > > server OS is Windows 2003 Server, smart card
logon
>> does not work.
>> >> > >
>> >> > > We can get smart card logon to work by manually
>> loading the CRLs into
>> >> > > the CDC. However, if the CRLs are subsequently
>> deleted or expire, the
>> >> > > CDC does not obtain new CRLs and the smart card
>> logon fails.
>> >> > >
>> >> > > The Event Log on the CDC shows: The client
>> certificate for the user
>> >> > > <domain>\<user> is not valid, and resulted in a
>> failed smartcard
>> >> > > logon. Please contact the user for more
>> information about the
>> >> > > certificate they're attempting to use for
smartcard
>> logon. The chain
>> >> > > status was : The revocation function was unable
to
>> check revocation
>> >> > > because the revocation server was offline.
>> >> > >
>> >> > > CertUtil -urlfetch -verify <filename> (my memory
>> may have the
>> >> > > parameters wrong, but hey, that's why we have
>> certutil /?, right?)
>> >> > > yields mixed results. Sometimes it will chain,
>> other times it will
>> >> > > not -- although it appears as though once it
chains
>> and validates, it
>> >> > > will continue to chain and validate for certs
>> issued from the same
>> >> > > external third party CA.
>> >> > >
>> >> > > NETMON running on the CDC reveals that the CDC is
>> making LDAP calls to
>> >> > > the correct place to obtain the CRLs (which,
>> incidentally, are upwards
>> >> > > of 4 megs). The log shows an LDAP Bind Request
>> from the CDC to the
>> >> > > CDP, followed by an LDAP Bind Response from the
>> CDP, followed by an
>> >> > > LDAP Search Request from the CDC. Five seconds
>> later, the same series
>> >> > > of events repeats itself (Bind Request/Bind
>> Response/Search Request).
>> >> > > It appears that the CDC makes three attempts,
each
>> 5 seconds apart,
>> >> > > then, after another 5 seconds, sends an LDAP
>> Abandon Request to the
>> >> > > CDP server. There is never a Search Response
from
>> the CDP (or at
>> >> > > least, there isn't one within 5 or so seconds
from
>> each Search
>> >> > > Request).
>> >> > >
>> >> > > Since we are able to manually obtain and load the
>> CRLs from the CDC,
>> >> > > connectivity is obviously not the issue. It
>> appears as though the CDC
>> >> > > is a bit impatient by default (at least for this
>> scenario).
>> >> > >
>> >> > > I've scoured Google and Microsoft.com for any
>> indication as to where a
>> >> > > registry setting for LDAP timeout might be hidden
>> (I even searched on
>> >> > > LDAP in RegEdit -- found lots of interesting
>> things, but no difinitive
>> >> > > timeout setting) to no avail.
>> >> > >
>> >> > > Any ideas? Again, the only difference between it
>> working and not
>> >> > > working is Windows 2000 Server vs. Windows 2003
>> Server on the Domain
>> >> > > Controllers and internal subordinate enterprise
CA.
>> >> > >
>> >> > > Peter Schlephendorfer
>> >
>> >
>> >.
>> >
>
>
>.
>

Relevant Pages
Quantcast