Re: CRL Checking....
- From: Magnus Lööf <MagnusLf@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 28 Feb 2007 23:43:13 -0800
Talk about ranting...
"Paul Adare" wrote:
So, I have deduced, that it is NOT possible to turn off CRL checking in
Windows when using SmartCards.
There was no need for you to "deduce" this,
Don't be a smart ass. I "deduced" it by reading the posts.
I am not sure whether or not you are mixing up me with Joe who wrote the
original post (who was actually having problems). I just stumbled on this
post in search of a way of allowing KDC to use an expired CRL, and thought I
would share some thoughts with the community.
I don't think it is fair to pound, humiliate, flame or accuse me of ranting
(as Brian did).
you were told
explicitly this isn't possible.
Yes, I was. Unfortunately, you are wrong.
The KB article I mention turns off the time validity checking, which was
exactly what *I* was talking about in my post (and I am sorry I made the case
for it *before* finding the article).
Splitting hairs again, but I believe Joe (original poster) wanted to disable
CRL checking altogether, because he was having problems.
I want to be able let KDC be lenient by accepting a CRLs validity beyond its
*real* validity lifespan.
Imagine that you are using a high-security CA with frequent CRL publishing.
(So that a lost smartcard will be revoked quickly, say in days or in a week.)
look at OCSP, not CRLs.
Just a plain dumb, ignorant statement. If I was able to use OCSP, I would
not be looking for extending CRL Validity Checking, right?
One day, for one reason or another, the CRL-file is inaccessible. (Can be a
third-party CA that is having problems, can be problem with AD replication,
can be configuration error with IIS etc).
This is why you need to plan for redundant, highly
available CDP locations.
Of course, already done. As you may have deduced (intentional pun), business
continuity is very important to this project.
Soon, workers will not be able to log in using their smartcards (when the
presumably cached copy of the CRL will time-out on the DCs).
Now, in an *agile* business, the Security Manager is faced with a Risk
Management Decision:
1) accept potentially revoked smartcards
Disable the AD account.
OR
2) shutting out the workers of the IT-environment.
Why?
You are getting me wrong. *If* the SecMan would change the registry values
to extend the validity of CRLs, he could potentially, unknowingly, allow
smartcards that were revoked by the third party CA.
That is the negative security effect. The positive business effect would be
that users can log on, even though the CRL has expired.
Of course, if the SecMan knows about a lost smartcard, SecMan should disable
the AD account immediately. (Rather that wait a week for the CRL to come
around, hehe, that would indeed be a rather cumbersome business process.)
implement an automated
way of turning off "Require SmartCard-logon" if such a scenario would arise.
Scripting is relatively trivial.
Yep, finally, we agree on something.
Since I wanted an open discussion, I just thought I would toss in a
potential (and rather easy) solution if others would come to the same
conclusion as we did in this project.
I did not know at that time that, by installing the hotfix, I actually could
let the SecMan make the decision I was talking about.
Over and out,
/M
.
- References:
- Re: CRL Checking....
- From: Paul Adare
- Re: CRL Checking....
- Prev by Date: Re: Web App Security Model.
- Next by Date: Re: Lose ability to decrypt EFS files after reboot
- Previous by thread: Re: CRL Checking....
- Next by thread: Re: Web App Security Model.
- Index(es):
Relevant Pages
|
