cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

2109
Views
25
Helpful
11
Replies
Highlighted
Cisco Employee

ISE 2.6 - how to 'force' AD Connector to use port 636 (LDAPS)

Hi Team, 

my customer is asking around what level of encryption ISE uses for communication with AD (Integration with AD as external identity source via AD connector). From my own research I found a few comments from past forum discussions that ISE supports LDAPS/port 636 connections to AD on the AD connector. However, this is not something thats configurable within ISE itself.

 

The customer has done some packet captures and claims that not all communication between ISE and AD seems to happen via LDAPS despite them configuring their AD server to do so.

 

Questions:

1, Does ISE automatically decide whether to use port 389 or 636?

2, If so, how does it make that decision, based on what flow or communication with AD?

3, Is it purely a setting on the AD server side that the customer has to configure to force LDAPS connections instead of port 389? Or is there anything else that needs to be done (ie. on the ISE side)? 

4, I'm not an AD pro, so basic question would be - anyone knows where on the AD server this needs to be configured that the server wants to use 636 and not port 389? The customer sent me some screenshots from their settings where they modified parameters under the DNS settings but I am doubtful that is the correct place to do it. Any pointers would be much appreciated.

 

For reference, below is what the customer sent me:

 

------------------------------------------

The way ISE communicates with AD is that it tries to find domain controllers by doing a DNS query for _ldap._tcp.dc.msdcs.<domainname> (it queries for SRV records) which you can see below at frame 61631. The response in my lab is that it receives 3 domain controllers. The SRV record contains target, port, priority and weight.

 

 

 

Once it has the LDAP servers that are available in the domain it queries all of them via CLDAP (connection-less LDAP). What I was trying was to modify the DNS SRV records for my domain controllers and change them to 636 manually:

 

 

Unfortunately, you can see here that there 2 records now as AD registers a new DNS for LDAP on port 389 shortly after I changed it to 636 (faster than I can get ISE to join against AD) so ISE will just utilise those again.

------------------------

 

Thanks

Thomas

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

I got a response from Engineering about the AD Connector's use of encryption:

Proper native AD connection will encrypt LDAP differently.  It will use port 389/3268 then negotiate encrypted LDAP using something call GSS (Windows AD thing) rather than forced SSL connection.  That allows Windows to negotiate different mechanisms for the encryption.  You can see it in wireshark if you take a sniff.

 

View solution in original post

11 REPLIES 11
Highlighted
Cisco Employee

When you are configuring a LDAP identity source, you have the ability to specific whether or not the connection is secure. ISE does not automatically determine whether the connection is secure or not. Please reference the ISE administration guide for more information.

Regards,
-Tim
Highlighted

Hi Tim, 

thanks for the speedy reply! Sorry if my original message was not completely clear - the customer is not trying to use LDAP as Identity Store but direct AD integration. So the question is in relation to how ISE can support a secure connection to the AD server since the default port used is always 389. As noted earlier, I assume this needs to be setup on the AD server to use port 636 but the question is whether ISE would be able to use port 636 automatically if the AD server is configured for it or does ISE only AD connection over port 389?
Thanks

Thomas

 

Highlighted

Hi,

Sorry, LDAPS in the question title is what through me off because you can also use AD as the schema when setting up a new LDAP connection. To be honest, this is something I haven't tested so I can't say for sure. My recommendation is that the customer tests the configuration in a lab environment first as a best practice.

Regards,
-Tim
Highlighted


@Timothy Abbott wrote:
Hi,

Sorry, LDAPS in the question title is what through me off because you can also use AD as the schema when setting up a new LDAP connection. To be honest, this is something I haven't tested so I can't say for sure. My recommendation is that the customer tests the configuration in a lab environment first as a best practice.

Regards,
-Tim

This is not something that can be changed without an enhancement, if you have an issue please reach out to our product managers.

To contact our product team for future enhancement requests, externally for cisco customers/partners at http://cs.co/ise-feedback for cisco employees internally at http://cs.co/ise-pm

 

I'd recommend also looking at the ISE AD connector cisco live by @ChrisMurray https://cs.co/ise-training

What's new in ISE Active Directory connector - BRKSEC-2132
Chris Murray, Technical Leader, Cisco
Cisco Identity Services Engine (ISE) integrates with Active Directory using a new connector. We will introduce new features, concepts and troubleshooting tools as well as Best Practices to help you avoid and resolve issues. This session is a pre-requisite to any ISE deployment when you have been deploying multiple Active Directory in your Company.

Highlighted

Hi Jason, 

thanks for the reply, much appreciated!

Had a brief look (will do more in detail later) at the Cisco Live preso you referenced, great material. Looking at that though there is no mention about port 636 usage anywhere. Does that mean the encryption is basically all done via SASL but ISE will always communicate on port 389 with AD?

I guess what I am trying to confirm is whether my customer can stop trying to change settings on their AD server to make this work on port 636 ?

Also what do you mean by "This is not something that can be changed without an enhancement" - what can't be changed? The option of port 389 or 636 when using the AD connector (similar to how we can set it for an LDAP identity source)?

 

Thanks

Thomas

 

Highlighted

I am also seeing this behavior in 2.4 as well as 2.6 patch 3

My firewall logs are showing the connections to the Active Directory join point using 389 and there are no settings anywhere for changing to 636 and therefore SSL.

 

Could do with some advice on the issue here, as when AD admins start forcing SSL for security reasons, this could potentially break the connection from ISE and therefore client network authentications throughout an enterprise network. 

Highlighted

Hi,

   

     LDAPS is supported, you need to first import into ISE the full chain of certificates for the CA that issued the certificate for your LDAP server; afterwards, when you configure LDAP in ISE, check the "secure authentication" in connection settings and point to the imported CA chain.

 

Regards,

Cristian Matei.

Highlighted

This is not the question, since most users are using the AD connector, not LDAP. The Ad connector inturn is using LDAP to communicate with the AD server.

Highlighted

I have LDAP configured with LDAPS over 636 and that works fine, and can communicate securely.

 

However, using the AD Connector there are no option for SSL, and I can see it is using LDAP over port 389 through our firewalls.

 

As mentioned, LDAP and AD Connector are two different types of External Identity Sources.

Highlighted

Hi all,

are there any new insights regarding AD Connector and LDAPS?

AFAIK Microsofts want to disable LDAP and force the use of LDAPS.

Can we still integrate the AD servers via AD connector then? Has anyone tested this?

 

Many thanks.

Highlighted

I got a response from Engineering about the AD Connector's use of encryption:

Proper native AD connection will encrypt LDAP differently.  It will use port 389/3268 then negotiate encrypted LDAP using something call GSS (Windows AD thing) rather than forced SSL connection.  That allows Windows to negotiate different mechanisms for the encryption.  You can see it in wireshark if you take a sniff.

 

View solution in original post

Content for Community-Ad