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

[Peter Schlephendorfer]

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

 

[Laudon Williams [MSFT]]

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.

 

[Peter Schlephendorfer]

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]]

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.

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]" <[email protected]> wrote in message

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.

 

[Peter Schlephendorfer]

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.

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]" <[email protected]>

wrote in message
certificates have the
appropriate at the CRL and see
what and confers no
rights.

.

 

[Laudon Williams [MSFT]]

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.

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.

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]" <[email protected]>

wrote in message

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.

and confers no
rights.

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

.

 

[Peter Schlephendorfer]

The only errors from certutil were to the effect that the
certificate could not be validated because the revocation
status was not knowable. I will run certutil again report
specific messages shortly, but I believe it reports that
the CDP server is offline/unavailable/not reachable.

The error message from the event log on the CDC is in the
original post (copied here): 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.

The local workstation event log does not report an error.

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.

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.

and
confers no rights.

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]"

wrote in message look
at the CRL and see warranties,
and confers no

wrote in message logon
does not work. smartcard
logon. The chain to
check revocation chains
and validates, it each
5 seconds apart, from
the CDP (or at from
each Search

.

 

[Peter Schlephendorfer]

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.

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.

and
confers no rights.

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]"

wrote in message look
at the CRL and see warranties,
and confers no

wrote in message logon
does not work. smartcard
logon. The chain to
check revocation chains
and validates, it each
5 seconds apart, from
the CDP (or at from
each Search

.

 

[Laudon Williams [MSFT]]

Did some digging. XP and WS2003 do continue to download the CRL even if the
authentication attempt times out. What timeout parameter are you referring
to setting? On another note, why is the CRL so large? Seems really big,
especially for a CA that issues authentication certs.

Also, the inconsistent certutil behavior. Was this using the same certutil?

--
This posting is provided "AS IS" with no warranties, and confers no rights.

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.

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" <[email protected]>
wrote in message
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]"

wrote in message
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"

wrote in message

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


.

.

 

[Peter Schlephendorfer]

OK. Time to reveal some proprietary info here, but I
can't do that in a public newsgroup. Can you ping my
email ([email protected]) and I'll respond?

PS

-----Original Message-----
Did some digging. XP and WS2003 do continue to download the CRL even if the
authentication attempt times out. What timeout parameter are you referring
to setting? On another note, why is the CRL so large? Seems really big,
especially for a CA that issues authentication certs.

Also, the inconsistent certutil behavior. Was this using the same certutil?

--
This posting is provided "AS IS" with no warranties, and confers no rights.

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? and
confers no rights.

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" <[email protected]>
wrote in message
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]"

wrote in message
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"

wrote in message

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


.



.

.