Question : Windows Server 2003 LDAPS communication issues

Hello all,

Here is my current dilemma, we have an outside vendor that we use for a specific service for the students here.  Since we would like to move to a single sign on, we want them to authenicate to our Active Directory server.  They require using LDAPs.
Received instructions from them as to how to setup LDAPS and it did not work, so  I setup our domain controller as a certificate authority and followed the instructions from this webpage:
http://www.linuxmail.info/enable-ldap-ssl-active-directory/

After I did this, 389 and 636 worked internally; however, as soon as I was external to the firewall 389 worked but 636 did not.  I checked the firewall and verified that it was indeed passing that traffic.  The latest we heard from the vendor to fix the issue is that we need to purchase an 3rd party certificate, so we purchased one from verisign.  I installed the cert no problem, but now I can not seem to connect on 389, 636, or 443.  Checking the firewall all of the packets are passing, so the domain controller is definately dropping them for some reason.  
Any help would be greatly appreciated.

Answer : Windows Server 2003 LDAPS communication issues

1) Has the vendor gotten this to work correctly with other partners before?

2) Can you use ADSIEdit (from 2003 support tools) to connect to the secured LDAP directly from the server on port 636?  How about from a client box on your LAN?

3) Are they using passwords to log into the secured LDAP or smartcard authentication?

4) Is there a software firewall, etc. (e.g. Windows Firewall) on the DC that may be blocking 636?

5) Check to see if your firewall supports passing secured UDP traffic, or if it is restricted to TCP only.  Both UDP and/or TCP may be in use here - maybe only some of the traffic is being passed?


Side suggestion to research:
Allowing any 3rd party direct access to your Active Directory is generally not a good idea.  There may be specific cases where it is necessary, however 9/10 time this can be avoided by using Active Driectory Application Mode (ADAM) which is an isolated LDAP server.  That way you can give the partner whatever access necessary to that LDAP but they will not have any ability to browse or in some worse cases modify your AD.  This is a bit more complex of a topic, but may just be worth looking into... If the time and learning how to work directly with LDAP goes beyond what you can afford, maybe looking for a consultant that deals with this specifically might be wise.