Haven't tried it--I don't have any other LDAP servers around that support SSL to play with. :)
I know for sure that the part about enumerating the domain controllers won't work. You'd need to supply the list of server names a different way. However, the actually bind/SSL stuff should work fine. I think my code assumes LDAP V3, but that's a pretty good assumption in most cases (and easy to change in the code too). Feel free to pass it along. The source is easy to modify. Joe On 8/3/06, Brian Desmond <[EMAIL PROTECTED]> wrote:
Have you tested against other LDAP systems (like SunONE)? Have a client who encountered this little issue. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Thursday, August 03, 2006 8:47 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Potentially useful tool and sample posted on my blog Hi all, My blog (http://www.joekaplan.net/) has a new article (http://www.joekaplan.net/Example1ForSDSPSSLCertificates.aspx) posted that may be of potential interest to some of you. I mention this here for three reasons: 1) I just started blogging, and some of you who are blog fans may find that interesting in and of itself. I'm mainly writing about the stuff I'm good at, namely .NET directory services programming, Windows security and (now) ADFS. 2.) The article in question is part of a series that explains the differences of the two LDAP "stacks" in .NET (the ADSI one and the new LDAP API-based one) and shows examples of stuff that actually requires the lower level protocol, since they have a lot of overlap in functionality and it isn't always easy to know when you need the big guns! This topic is marginally relevant to scripters too since they are basically limited to what ADSI gives them, unless they are wrapping joeware tools. :) 3.) The article actually provides a working sample of something that might help some of you get real work done and isn't easy to do otherwise. For those not at all interested in the first 2 points, here's the skinny. The tool is a simple command line app that allows you to enumerate the domain controllers in a domain (specified on the command line) and make an SSL LDAP connection to each one. It then grabs the server's certificate and prepares a list of their expiration dates. When it is done, it dumps out the certificates in order of expiration. This sort of thing is most helpful to those of you who use SSL LDAP and have third-party (non MS CA) certificates that require manual renewal and such (such as our organization). This may help prevent prevent unpleasant application outages due to forgetting to renew a certificate in a timely fashion (not that such a thing has ever happened in our organization...cough...). The tool is also multithreaded, so that it attempts to connect to many domain controllers simultaneously, making it vastly faster than something that processed the list serially. It is not a particularly a robust tool with nice error messages and hand-holding. It is not "joeware" quality, and is more of a "scripting" sample that demonstrates a technique. However, it may still be useful as is. It does require .NET 2.0 (as that was what this was about in the first place). You can run it on any machine you want. I'm pretty sure it doesn't even need to be domain joined. Source and binary in the download. Let me know what you think. Joe K.
List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
