StuGreentree
asked on
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ADAM can run in its own instance on any server and use a different port - commonly 50000 & 50001 or 50389 & 50636. Its a free MS thing - in 2008 server it is even available as normal installation utility.
The reason I asked about the firewall - some firewalls will drop secured UDP traffic, especially if they're connecting through a VPN. Even if you 'allow' it, it doesn't mean it isn't getting shunted.
I assume the process you followed is similar to this:
http://support.microsoft.com/kb/321051
Was the cert issued from your own CA or commercial CA? Is the root CA in your external test client's & vendor's trusted root certificate store? Since external, may not be getting the GPO to distribute within your LAN.
I assume patches are up to date for DC. Also check your firewall for what updates are available and see if they may apply to your situation.
The reason I asked about the firewall - some firewalls will drop secured UDP traffic, especially if they're connecting through a VPN. Even if you 'allow' it, it doesn't mean it isn't getting shunted.
I assume the process you followed is similar to this:
http://support.microsoft.com/kb/321051
Was the cert issued from your own CA or commercial CA? Is the root CA in your external test client's & vendor's trusted root certificate store? Since external, may not be getting the GPO to distribute within your LAN.
I assume patches are up to date for DC. Also check your firewall for what updates are available and see if they may apply to your situation.
This is a fairly common scenario having firewall rules that permit TCP636 from a given set of source IPs for vendor authentication...
Make sure the old cert you issued from your own CA is removed from the DC's certificate store.
Thanks,
Brian Desmond
Active Directory MVP
Make sure the old cert you issued from your own CA is removed from the DC's certificate store.
Thanks,
Brian Desmond
Active Directory MVP
ASKER
Initially the certificate was a Microsoft CA, we ran into a few issues and had to remove the certificate authority role on the server. We then purchased a commerical cert with Verisign. As far as I can see, the old certificate has been deleted from the DC's cert store. The process for the cert was similiar to KB321051.
In an attempt to upgrade our firewall to a more recent version, apparently there is not enough room on the firewall to perform the upgrade. In an attempts to upgrade and speaking with Checkpoint's support, it made the firewall brain dead. Needtheless to say 7 hours later, we were able to get the firewall to its original state, but with no hotfixes. I think you are both on the correct path and I think that at the very least if I can get the firewall to the latest hotpatch and make sure the nokia is at the most current IPSO, then I will probably be able to move forward.
Interestingly enough, now with the new cert I am not able to connect to hearth external to the firewall at all now, where before I was able to connect on 389.
Thanks for your input, I will keep you posted.
In an attempt to upgrade our firewall to a more recent version, apparently there is not enough room on the firewall to perform the upgrade. In an attempts to upgrade and speaking with Checkpoint's support, it made the firewall brain dead. Needtheless to say 7 hours later, we were able to get the firewall to its original state, but with no hotfixes. I think you are both on the correct path and I think that at the very least if I can get the firewall to the latest hotpatch and make sure the nokia is at the most current IPSO, then I will probably be able to move forward.
Interestingly enough, now with the new cert I am not able to connect to hearth external to the firewall at all now, where before I was able to connect on 389.
Thanks for your input, I will keep you posted.
You might have remnants in AD of the old CA...
How to decom a CA server properly from AD:
http://support.microsoft.com/kb/889250
How to decom a CA server properly from AD:
http://support.microsoft.com/kb/889250
ASKER
Spoke with a different vendor and they basically had to rip out the certificate authority, did the steps you provided. Was not able to connect on 389 and 636 because the rule on the firewall somehow got switched to hide rather than static. After that was switched back, was able to telnet on 389 and 636 internal and external, which leads me back to the certificate. The vendor said that since the internal and external DNS have the same name for this server it is creating a conflict due to an internal embedded IP address. They are having me create an internal A record with a new name ex: server-os.place.edu pointing to the external address, and then they had me create an alias with our external dns that will point server-os,place.edu to server.place.edu. The explanation was that this was the embedded IP addresses match. My question is though, I have been through the certification process a few times, so at what point does that IP get embedded into the certificate? If during the certification process I am using a FQDN, shouldnt it use the appropriate DNS regardless of being internal or external? Or during the certificate install on the server does it embed that IP? I have been taken down so many avenues with this, so I want to make sure that I am not heading down another dead end. Thanks in advance.
Unless you issue the certificate with the IP address being the subject name instead of using a hostname or DNS name, the IP address is not embedded in the certificate.
They may be on to something with the multiple IP address thing for internal vs. external traffic, but that's about it. The cert is good for the name it is issued to - if you assigned it to the DNS alias then you are fine. You may need an internal vs. external DNS name, depending how you have things set up, in which case you would need either two certs - one for each interface, or one cert with both names applied - either as a wildcard (*.domain.com) or a SAN (dc1.domain.com & dc1.domain.local).
To use a SAN cert you need to enable a registry key on the CA:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALT
net stop certsvc
net start certsvc
More info here:
http://support.microsoft.com/kb/931351
Might also want to read this:
http://support.microsoft.com/kb/938703
They may be on to something with the multiple IP address thing for internal vs. external traffic, but that's about it. The cert is good for the name it is issued to - if you assigned it to the DNS alias then you are fine. You may need an internal vs. external DNS name, depending how you have things set up, in which case you would need either two certs - one for each interface, or one cert with both names applied - either as a wildcard (*.domain.com) or a SAN (dc1.domain.com & dc1.domain.local).
To use a SAN cert you need to enable a registry key on the CA:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALT
net stop certsvc
net start certsvc
More info here:
http://support.microsoft.com/kb/931351
Might also want to read this:
http://support.microsoft.com/kb/938703
ASKER
2) I have been using LDP.exe to test the various connections, internally and externally.
3) They are using passwords to login to secured LDAP.
4) Unfortunately, there is no software firewall, we have syamantec endpoint, but it only has antivirus and antispyware protection.
5) For testing purposes, I opened up the all ports from their IPs as well as our box that is external to try and get this working.
This third party we have a contract with, and this is coming from a superior to get this done. Basically we are trying to get a single sign on, and this is the last piece. We want them to authenicate against our active directory tree. and they need to do so on a LDAPs connection. I would love to setup an isolated LDAP server, unfortunately due to monetary restrictions currently we are unable to set that up currently.