Cisco ASA 5505 & Windows Server 2012 - LDAP over SSL
So our Technology team performed an upgrade to our Domain Controllers yesterday. We're now running Windows Server 2012 instead of Windows Server 2008. This upgrade, while everything else appeared normal, broke our Cisco ASA VPN connections with AnyConnect. After troubleshooting this morning with Cisco, they fixed it by unchecking "Enable LDAP over SSL" in our AAA Server settings on the ASDM.
So, my main question is this: what has changed with LDAP and Server 2012 -- why won't our ASA communicate with Server 2012 when LDAP over SSL is enabled?
Thanks!
So, my main question is this: what has changed with LDAP and Server 2012 -- why won't our ASA communicate with Server 2012 when LDAP over SSL is enabled?
Thanks!
ASKER
Thanks, Traoher,
In our setup, Windows Firewall (and other firewall software, i.e. Endpoint Protection) was disabled and/or not yet installed. Was SSL LDAP on 636 with Server 2008?
In our setup, Windows Firewall (and other firewall software, i.e. Endpoint Protection) was disabled and/or not yet installed. Was SSL LDAP on 636 with Server 2008?
Yes SSL LDAP was on 636 in 2008.
Did the 2012 assume the same IP as the 2008 did?
Did the 2012 assume the same IP as the 2008 did?
ASKER
Yep, same IP as the old domain controller. Hmm -- I'll try it again and report back to you.
ASKER
Hi -- just tried it...
I put a tick in the box on the ASDM tool to "Enable LDAP over SSL" -- and it automatically changed the port in the box below to 636... but then the same "Login error." Cisco was stumped on this one too. :-(
I put a tick in the box on the ASDM tool to "Enable LDAP over SSL" -- and it automatically changed the port in the box below to 636... but then the same "Login error." Cisco was stumped on this one too. :-(
from a computer on the network, can you telnet to the 2012 DC on port 636? If so, then port is open and the only thing left is protocol mismatch.
You can also use wireshark to capture the data and see if you get anything meaningful, it things aren't buried inside SSL protocol, you would be able to see the error right on the capture.
You can also use wireshark to capture the data and see if you get anything meaningful, it things aren't buried inside SSL protocol, you would be able to see the error right on the capture.
ASKER
Thanks, Traoher,
I'll try this during my next scheduled maintenance next week and will report back to you -- thanks for your help so far!
I'll try this during my next scheduled maintenance next week and will report back to you -- thanks for your help so far!
ASKER
Hi, Traoher --
I apologize for the radio silence; I've been inundated with projects and am now revisiting this thread so we can close the issue and award points.
I tried telnetting to the 2012 DC on port 636, but receive this message:
Microsoft Telnet> open domaincontroller.internaln
Connecting To domaincontroller.internaln
on port [636]: Connect failed
I tried putting Wireshark on this, but can't seem to get anything useful out of it. Any ideas?
I apologize for the radio silence; I've been inundated with projects and am now revisiting this thread so we can close the issue and award points.
I tried telnetting to the 2012 DC on port 636, but receive this message:
Microsoft Telnet> open domaincontroller.internaln
Connecting To domaincontroller.internaln
on port [636]: Connect failed
I tried putting Wireshark on this, but can't seem to get anything useful out of it. Any ideas?
Hi,
Does the server still have the certificates needed to generate the SSL connection?
Has Group Policy changed which has modified the TLS version supported in Windows?
Regards,
RobMobility.
Does the server still have the certificates needed to generate the SSL connection?
Has Group Policy changed which has modified the TLS version supported in Windows?
Regards,
RobMobility.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can also try connecting to the DC using an LDAP browser that supports LDAPS, I quite like the Softerra LDAP browser.
Hi,
You should be able to use LDP.exe (which I believe is installed by default) to confirm that LDAPS is listening properly on TCP 636.
You might also want to enable firewall logging to see if the incoming packets are being dropped or allowed?
Regards,
RobMobility.
You should be able to use LDP.exe (which I believe is installed by default) to confirm that LDAPS is listening properly on TCP 636.
You might also want to enable firewall logging to see if the incoming packets are being dropped or allowed?
Regards,
RobMobility.
ASKER
Thanks for all of the help! I'm working through the suggested comments posted.
Several points:
1. netstat is showing LDAP is listening on port 636;
2. Windows Firewall is (and has been turned off);
3. RobMobility asked, "Does the server still have the certificates needed to generate the SSL connection?" -- with our prior 2008 setup, no certificate was needed. Looks like it may be needed with 2012.
Stay tuned.
Several points:
1. netstat is showing LDAP is listening on port 636;
2. Windows Firewall is (and has been turned off);
3. RobMobility asked, "Does the server still have the certificates needed to generate the SSL connection?" -- with our prior 2008 setup, no certificate was needed. Looks like it may be needed with 2012.
Stay tuned.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi,
Unless you're using Dynamic Access Policies or something else that is reading LDAP attributes, you could use Kerberos instead?
Regards,
RobMobility.
Unless you're using Dynamic Access Policies or something else that is reading LDAP attributes, you could use Kerberos instead?
Regards,
RobMobility.
ASKER
Followed this article: http://gregtechnobabble.blogspot.co.uk/2012/11/enabling-ldap-ssl-in-windows-2012-part-1.html
Since LDAP over SSL/TLS (LDAPS) is automatically enabled when you install an Enterprise Root CA on a domain controller, I was good to go once I followed the instructions on that URL, above, and rebooted.
Thanks, Experts!!
Since LDAP over SSL/TLS (LDAPS) is automatically enabled when you install an Enterprise Root CA on a domain controller, I was good to go once I followed the instructions on that URL, above, and rebooted.
Thanks, Experts!!
The ASA should have (and trust) the root certificate that is used on the LDAP connection.
Now I'm in front f a computer instead of just on my iphone...
If the ASA was configured with just the certificate used on the LDAP server, then this certificate may have changed.
I would open a SSH session to the ASA,
enable
term mon
! forwards the console to your SSH session
debug ldap 255
! the highest level of LDAP debug
now try to connect and see if the error is obvious
If it isn't obvious, copy the output to a text file, do the usual checks for information that you might not want published ion here, and attach the text file
when you have completed the test, do
no debug ldap
Now I'm in front f a computer instead of just on my iphone...
If the ASA was configured with just the certificate used on the LDAP server, then this certificate may have changed.
I would open a SSH session to the ASA,
enable
term mon
! forwards the console to your SSH session
debug ldap 255
! the highest level of LDAP debug
now try to connect and see if the error is obvious
If it isn't obvious, copy the output to a text file, do the usual checks for information that you might not want published ion here, and attach the text file
when you have completed the test, do
no debug ldap
Also, if you had SSL LDAP port rule, you must change it to match the new 2012 server ip.
non-SSL LDAP is still on 389.