First published on CloudBlogs on Jul, 10 2006
First, let me start off by announcing the slight name change of the blog to Active Directory Blog. It just seems too searchalicious, certainly better than previous, where I could tell that I had a very small but loyal following. Since my goal is to spread words around I thought it'd be good to change. Give me a holler and let me know what you think (if you end up seeing the blog now).
Occasionally I'll try to post about issues which are particularly time consuming or difficult. The main goal is to shortcut the Headache step in the Problem->Headeache->Resolution routine.
We occasionally alter our product implementations under the hood. It may shock some folks to hear that this may not always be well documented. No, it's true, I won't deny it.
We have a lot of people who work very hard to make sure everyone "out there" has access to the info they need to get their job done, but sometimes there's a gap.
I get "gapped" a lot. That's my job, ladies and gentleman.
For example, take this scenario. Though technically not Active Directory specific, it falls under the sombrero shadow of Directory Services, hence a fitting topic for the blog.
The scenario was that this company had written a web application running in the IIS application pool which would accept Internet Explorer connnections via Secure Socket Layer (SSL) to retreive and display data for the end user. Very typical.
What was atypical was that the connections were being delayed approximately 20 seconds (it varied slightly) for every initial connection from a client. However, the connections always succeeded. Subsequent connections via SSL from the same client would succeed without delay.
When examining the certificates in use on client and server they all seemed to be valid, CRLs reachable, and of the correct type (client authentication on the client cert, server auth. for the server cert). So, no obvious problem there.
Traces taken of this behavior would simply show us that there was that maddening 20 (or so) second delay, right before the client responded with it's "change cipher spec" reply.
We have some configurable behavior for timing out on failed CRL lookups and other similar things and, despite the certificates appearing healthy, we tried them. No progress.
Ultimately we took some sequential dumps of the services involved and saw there were some files and directories being accessed during the delay.
It just so happened to be where the local computer certificate store is. To make a long story short, we had to add permissions for the connecting client to query these files. This connection is done under the context of NT AuthorityNetwork Service, an authenticated but restricted account.
As part of the SSL negotiation the certificates needed to be directly accessed. They delay was a result of the session moving forward with server SSL authentication only, rather than client and server both.
If you see this, edit the permissions of the directory below, and any child file and folder objects, so that NT AuthorityNetwork Service has the Read and Execute Allow permission. Keep in mind that not all items there inherit permissions, so consider using Subinacl.exe to get that job done.
subinacl /subdirectories "C:Documents and SettingsAll UsersApplication DataMicrosoftcrypto*.*" /grant="NT AuthorityNetwork Service"=E
As always, take care out there, and post if you have any questions, comments, requests, suggestions or mild rants.
