Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4977
  • Last Modified:

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!
0
workforceinsight
Asked:
workforceinsight
  • 7
  • 4
  • 3
  • +2
3 Solutions
 
traoherCommented:
SSL LDAP is on port 636, you will have to check and make sure the local fw on the  2012 server accepts request coming to that port.

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.
0
 
workforceinsightAuthor Commented:
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?
0
 
traoherCommented:
Yes SSL LDAP was on 636 in 2008.  

Did the 2012 assume the same IP as the 2008 did?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
workforceinsightAuthor Commented:
Yep, same IP as the old domain controller.  Hmm -- I'll try it again and report back to you.
0
 
workforceinsightAuthor Commented:
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. :-(
0
 
traoherCommented:
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.
0
 
workforceinsightAuthor Commented:
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!
0
 
workforceinsightAuthor Commented:
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.internalnetwork.com [636]
Connecting To domaincontroller.internalnetwork.com...Could not open connection to the host,
 on port [636]: Connect failed

I tried putting Wireshark on this, but can't seem to get anything useful out of it. Any ideas?
0
 
RobMobilityCommented:
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.
0
 
Aaron TomoskyTechnology ConsultantCommented:
I just did this a few weeks ago and the solution was to put the right type of cert in the personal cert store on the ad controller (I had to add the adcs role as its the same box for me).

This helped me get the cert and cert template right:
http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

I know it's for 08 but it worked for me for 12
0
 
ArneLoviusCommented:
I would guess that when they "upgraded" to 2012, they didn't enable LDAPS with a relevant certificate. You can check with netstat on the Domain Controller to see if it listening on port 636.
0
 
ArneLoviusCommented:
You can also try connecting to the DC using an LDAP browser that supports LDAPS, I quite like the Softerra LDAP browser.
0
 
RobMobilityCommented:
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.
0
 
workforceinsightAuthor Commented:
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.
0
 
RobMobilityCommented:
0
 
RobMobilityCommented:
Hi,

Unless you're using Dynamic Access Policies or something else that is reading LDAP attributes, you could use Kerberos instead?

Regards,


RobMobility.
0
 
workforceinsightAuthor Commented:
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!!
0
 
ArneLoviusCommented:
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
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 7
  • 4
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now