Directory Programming .NET

Hi, I have some S.DS.P code that has been working fine for months searching for a dn and then binding to a Sun Directory Server version 5.2.  This was done on Windows 2003.

Now, I'm getting very slow response times from specifically the Sun Directory Servers running version 6.3 from my Win2003 server.  If I target Sun version 5.2, it's fast as usual.

The weird thing is when I run the same code from vs.net 2008 and the built in web server, I get fast responses from the same Sun 6.3 servers that are slow from win 2003.

Not sure if I have a bug in my code that is manifesting itself only on Sun 6.3, or if Sun has a bug/memory leak in Sun 6.3 ?   Also confused that my code works fine against Sun 6.3 from VS.net's webserver.

Not sure whether to open a support ticket with Sun or Microsoft or both.

thanks, Bruce

turned on schannel verbose logging on the win2003 server, and I'm seeing this behavior:

using S.DS.P on win2003 with the Sun version 6.3 server:
step 1:  Creating an SSL client credential.
7 seconds from step 1: The SSL client credential's private key has the following properties...  
13 seconds from step 1:  An SSL client handshake completed successfully...

using S.DS.P on win2003 with the Sun version 5.2 server:
step 1:  Creating an SSL client credential.
0 seconds from step 1: The SSL client credential's private key has the following properties...
0 seconds from step 1:  An SSL client handshake completed successfully...

It seems like my slowness might be related to the SSL handshake I guess.  I'm confused about what a server cert vs. client cert is in this situation.  From the old .net 1.1 days I know that the only cert that was involved with S.DS interation with Sun Directory Server was the ldap server's certificate.  I'm not sure anymore with S.DS.P.

In my c# code, I am forcing a true for ldapConnection.SessionOptions.VerifyServerCertificate, which didn't seem to matter when I took that code out.

Still not sure if this an issue to speak with Sun about, or Microsoft.

Interesting. It looks like the client is attempting SSL client cert auth in one of your deployments. The process running that code must have access to a certificate with private key that has client authentication EKU and is trusted by the Sun Server.

I'm not sure why it is so slow although I've definitely seen these types of delays caused by client cert auth. Might be delay from CRL validation or something like that as CRLs are accessed via HTTP calls typically. A network sniff might show the details.

If you don't want client cert auth (and I'm guessing you don't care about it), then you might be able to disable this behavior by implementing the other callback (QueryClientCertificate or somethign like that? I don't have the docs in front of me) and basically telling the SSL stack to ignore client certs.

The Sun directory admins may also be able to disable client cert auth on their end but they might not want to because someone else might need. Best to control in client code as well.

Figuring out which cert is being used and removing it would also work although that might break something else. The option then is the attempt to permission  the private key file so that the processes running your SDS.P code don't have read access to the private key file but the processes that DO need it retain access. That sounds more challenging to figure out though so hopefully the code-based solution works.

Hi Joe,

I'd prefer to disable the client cert handshake in my .net code.  I read yesterday about the memory leak in that part of S.DS.P so I'm wary.    This was what I read:

www.joekaplan.net/JoeRichardsFindLDAPClientAPIBugThatAffectsSDSProtocols.aspx

Any advice on a safe way to disable the client cert stuff and avoid the memory leak?  Maybe Microsoft has a fix for it by now.

thanks for helping on this, Bruce

Ah, I totally forgot about that. Thanks for digging up my old blog post. So, unless there has been a patch to SDS.P (which I doubt), you don't want to use the client cert callback.

So, the thing to do is figure out which certificate is being used as a client cert by SDS.P and then try to configure things so that it won't be available to the process that is trying to use it. Do the schannel logs tell you which certificate it is that is being used? Can you find that configured on the machine in cert manager with a private key?

Hi Joe, I figured that post would ring a bell, thank you for researching that, I never would have known until it was too late.

The Event View isn't showing me much re: which cert.  I have a theory though, I suspect it might be the Equifax SSL cert installed in IIS. 

It seems that if both my .net client app (s.ds.p and IIS 6) and the ldap server (with client cert enabled) are capable of engaging in the client cert verification, then the conversation occurs and the slowdown exists.

If my .net app is running from my laptop without SSL, the conversation is aborted.

If the ldap server doesn't have my IIS server's SSL cert authority trusted, then the conversation is aborted.

If I use .net S.DS code, the conversation is aborted since I assume S.DS couldn't handle the verification.

I think I'll speak with Microsoft about the hotfix that Joe Richards hints of.

thanks a ton!
-Bruce

Joe, I had a thought re: the memory leak.

What if I added this to my code:

conn.SessionOptions.QueryClientCertificate = new QueryClientCertificateCallback(ClientCallback);

private static X509Certificate ClientCallback(LdapConnection conn, byte[][] trustedCAs)
{
     return null;
}

Maybe no memory leak if ClientCallback is just returning null as opposed to really loading in any real certs ??

just hoping :)

I think you get the leak if you reference it at all. It might be fixed in a service pack or something though. It is worth a shot. Look closely for memory leak behavior with perfmon counters.

Joe, I opened a support case with Microsoft to research this memory leak to see if it's still there and if a fix exists.  Any idea if it's possible to find out from Joe Richards who at Microsoft he worked with or if he had any kind of case #?  I tried emailing him but maybe he shared some of that with you in the past ?  thanks, Bruce

This was quite a while ago. I'll see him next week (I think) and can ask him in person. I have no idea if he actually ever had a support case open related to this or not.

Let me know what you hear from MS support otherwise.

Microsoft confirmed that the memory leak does exist, and that it's fixed in Windows 2008 R2 and Windows 7.   I encouraged them to write up a KB article to document the leak for Windows 2003 customers, we'll see.

For now, I'll disable client cert verification using the properties of the SSL cert itself via the MMC snap-in.

thanks for your help, as always.

-Bruce

Thanks for following up with the info. Appreciated. As it turns out I didn't see Joe Richards that week as he didn't come to the Summit. Too bad. I got very little done on addressing all the weird bugs that have piled up here lately. I just didn't get enough time to sit down with the right devs. Was too bad.

Disabling client cert auth via SSL settings is probably the way to go.