RE: [ActiveDir] Secure LDAP queries from the outside

[Williams, Robert]

Mike,   I’ve been thinking of this answer for a bit but had to research more to get the info I needed.  I wish my knowledge of Certificates was better, but it would seem there is a way to have the client log something somewhere saying it can’t get to the CRL….maybe one of the smart folks will speak up J   If your external client can’t get to the CRL, you could possibly bring the CRL to the external client…Maybe you could publish the CRL to an alternate location which the client can get to?   If that’s not possible which makes sense, maybe you can set up your CA to publish the CRL to another location and then take that CRL and copy it to the location on the client where the CRL is cached.  This is the information I’ve been hunting for the past 20 minutes or so…I think you can read about it here:   http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx   <SNIP> Certificates are cached when CryptoAPI retrieves them from a certificate store or a URL. The cache location varies depending on the source where a certificate or a CRL was retrieved. A certificate or a CRL can exist in one or several of the following locations. • Memory  All valid certificates and CRLs that have been touched by the chain-building engine since the last reboot are cached in memory. • Certificate Store  All certificates that are not treated as root CA certificates and that have been retrieved from an HTTP–, LDAP– or FILE–URL reference via the AIA certificate extension are cached in the certificate store if the certificates are found to be part of a valid chain by the CryptAPI. Root CA certificates are not automatically cached and must be added explicitly by the interactive user to the corresponding certificate store. • Local File System  When a certificate or CRL is retrieved via LDAP or HTTP by a Windows 2000 client with MS04-11, Windows XP SP2 client, or Windows Server 2003 client, it is cached by CAPI in the “Application Data” folder. The per-user cache location is “C:\Documents and Settings\{user name}\Application Data\Microsoft\CryptnetUrlCache” and the per-machine cache location is “%WINDIR%\System32\config\SystemProfile\Application Data\Microsoft\CryptnetUrlCache”. Windows 2000 with MS04-11, Windows XP, and Windows Server 2003 handle caching for HTTP–, LDAP–, or FILE–URL references exclusively with CAPI. Earlier versions of CryptoAPI used WinInet instead of CAPI for this purpose. Note  On computers where the Windows Server 2003 version of certutil is available, cached CRLs can be listed by typing Certutil –urlcache CRL at a command-line prompt. This command is also available on Windows XP computers that have the Windows Server 2003 Administration Pack installed. </SNIP>   The following link may help too.  It talks about an offline CA…which for all apparent purposes, from the perspective of your client, the CA would seem to be ‘offline’:   http://technet2.microsoft.com/WindowsServer/en/library/45c28bf8-9952-4ca1-b124-7d86afb83f691033.mspx?mfr=true Thanks for the question…I like the learning! Have a great day! Robert Williams From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Tuesday, August 22, 2006 9:36 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Secure LDAP queries from the outside   Hi Robert,     Yes, the command is *exactly* the same.  We are thinking that our CRL location is not available outside of the firewall.  We generate our own certificates; we don’t use a “well known” provider.   Mike Thommes   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Williams, Robert Sent: Tuesday, August 22, 2006 9:16 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Secure LDAP queries from the outside   Hey Mike,   When you say “It works fine behind our firewall”, are you meaning that the *exact same* command line works and you get the object returned?   I tried using adfind to connect to my test DC using port 636 and got the exact same error…but I don’t have a cert installed on my DC so I’d expect mine not to work. Robert Williams From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Tuesday, August 22, 2006 6:19 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Secure LDAP queries from the outside   Hi,    We are trying to set up secure LDAP queries from the outside to AD for pulling email addresses but are running into an issue.  Port 636 has been opened up to our DCs but we get a 0x51 error like the one shown below in this example of using “adfind”:   adfind -h dc1.abc.com:636 -u [EMAIL PROTECTED] -up *  -default -nodn -f sn=thommes extensionAttribute2   AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005   LDAP_BIND: [rhino221.anl.gov] Error 0x51 (81) - Server Down Terminating program.   (extensionAttribute2 is used for email address)   Portqry shows that the DC is listening on port 636.  Using “ldp”, the bind operation seems to want to default to port 389 (which is not open).   It works fine behind our firewall.  Is there some other port that needs to be open (besides 389)?  Or maybe some security feature (we are running w2k3/sp1 on our DCs) that is getting in the way?  Any help is appreciated!   TIA, Mike Thommes     2006-08-22, 10:35:32 The information contained in this e-mail message and any attachments may be privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this e-mail and delete the message and any attachments from your computer. 2006-08-22, 11:32:10 The information contained in this e-mail message and any attachments may be privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this e-mail and delete the message and any attachments from your computer.