ISE AD-Connector integration with LDAPs support

[AhmedEissa]

Dears,

AD-Connector is using listed below protocols between ISE-AD, all connections are secured and encrypted using SALS for LDAP, RPC is encrypted using AES or higher based on AD version

So Currently, Is LDAPs Supported on AD-Connector ? Is this feature on roadmap/plans for future? if, yes when it will be released ?

The other Workaround is to use LDAP-Connector but you have some limitation for this connector 

• Cant use Certificate Smart Search Option
• PEAP, EAP-FAST are not supported
• Passive IDentity Connector is not supported
•  restrictions on group memberships when Active Directory is configured as an LDAP store:
       - Users or computers must be direct members of the group defined in the policy conditions to match the policy rule.
       - The defined group may not be a user's or computer's primary group. This restriction is applicable only when AD is configured as an LDAP store

[Damien Miller]

So as you already pointed out, secure ldap is supported today, and there is a built in schema out of the box for integrating with Active Directory.

But it is not supported on the AD connector, you can only set it up as an LDAP external identity store. If you want this functionality to be explored then you will have to submit an ISE ehancement request.

Now I'm not certain on the limitations you identified. I have used LDAP for PEAP, and eap-fast with eap chaining. 

[AhmedEissa]

Thanks Damien for your reply

• What did you mean with " there is a built in schema out of the box for integrating with Active Directory" ? Do you mean LDAP-Connector ??
• Did you used Mschapv2 as inner method for PEAP and EAP-FAST? or it was a certificate??

[paul]

Damien,

Please clarify your LDAP comment on PEAP because the admin guide and the GUI both make it very clear it is not supported.  I believe I have tried it as well and it doesn't work.  If you are doing PEAP with cert as inner method well that is a different story.

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_01110.html#concept_BD3A270FEC0C411DA10FB808C14B48D5

[AhmedEissa · Accepted solution]

Dears,

I have Got Confirmation from BU that AD-Connector is supporting LDAPs.

Thanks All

[Nayan.Patel85]

@AhmedEissa ,

I am looking at Admin Guide for ISE 2.4

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_01110.html#concept_BD3A270FEC0C411DA10FB808C14B48D5

Under “Prerequisites for Integrating Active Directory and Cisco ISE”, LDAP is one of port necessary for Communication between Domain Controllers and ISE.

I don't see LDAPS (secure LDAP) in the table.

This is going to be big issue in March 2020 as MS is releasing patch to disable LDAP.

https://msandbu.org/upcoming-change-microsoft-to-disable-use-of-unsigned-ldap-port-389/

What does this mean for customers who uses MS AD integration for External Identity Sources?

Do we need to set up LDAP using port 686 and Cert as new External Identity Source?

This would mean I have to import all the groups, update all the authentication polices, update all the authorization rules.

And on top of that I am counting on few Cisco Bugs that I will have to tackle along the way.

Does any one have run into this yet?

[andy!doesnt!like!uucp]

i guess u r right with "Do we need to set up LDAP using port 686 and Cert as new External Identity Source?" & it's quite easy to implement as soon as servers & ISE CA certs r in place. we have similar activity planned & i've checked it working on the secondary LDAP in customer's ISE.

well.. considerations ~Cisco BUGs r always actual :0) but i guess u overdo with "This would mean I have to import all the groups, update all the authentication polices, update all the authorization rules" as subject is about ISE<>LDAP-server(s) communications only (if i didnt miss something else :0)

[Nayan.Patel85]

Based on the ISE documentation PEAP is not supported if you are using LDAP as external Identity source on your Dot1x authc/authz rules.

But based on the updated I received from cisco TAC ISE will not impacted by the Microsoft Advisory ADV190023

But Don't hold me accountable.

[Nayan.Patel85]

we had a TAC case opened I have some good news to share with you all, but do not hold me accountable on this.

Another thing I want to point out" based on ISE Admin guide LDAP External Identity Source Does not support PEAP for dot1x authentication" so this would have been night mare.

Here is what I got from the TAC.

Some background:

There are 2 Types of LDAP Client/Server connections.

LDAP (TCP 389) – Credentials based

LDAP over SSL (Port 636) – Certificate based

LDAP V3 supports three types of Bind Authentication:

Anonymous- A client that sends a LDAP request without doing a "bind" is treated as an anonymous client

Simple - Simple authentication aka client sending credentials in clear-text.

SASL - Simple authentication  and Security Layer specifies a challenge-response protocol in which data is exchanged between for authentication and establishment of a security layer on which to carry out subsequent communication. By using SASL, LDAP can support any type of authentication agreed upon by the LDAP client and server.

Within LDAP SASL there are different mechanisms:

ANONYMOUS SASL Mechanism -- used to destroy a previous authentication session.

CRAM-MD5 – Hash of password exchanged, no connection integrity or confidentiality.

DIGEST-MD5 -- Stronger than CRAM-MD5 SASL mechanism. Provides connection integrity and confidentiality.

GSSAPI -- This mechanism provides a way for users to authenticate to the server using a Kerberos V5 session. Provides connection integrity and confidentiality.

PLAIN -- It is similar to the protection offered by Simple Authentication.

SPNEGO - aka GSS-SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a GSSAPI "pseudo mechanism" that is used to negotiate one of a number of possible real mechanisms.

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

Microsoft Advisory 190023 elevates security posture of Microsoft Active Directory controller in a way that:

The Domain Controller

rejects LDAP Simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. >> Not applicable to ISE- Ad integration, as simple binds are not used.

or

rejects LDAP Over SSL requests from clients that do not enforce Channel Binding Tokens(CBT). >> Not applicable to ISE- Ad integration, as LDAP 389 is used for ISE AD communication.

                                                or

rejects LDAP SASL binds that do not request signing (integrity verification)  >> Not applicable to ISE- Ad integration, due to below reasons.

ISE to Active Directory integration is using LDAP (389) and uses SASL Bind with GSS-SPNEGO (GSSAPI) Mechanism with Kerberos V5 Encryption type = AES256-CTS-HMAC-SHA1-96. This Encryption type supports connection Integrity and confidentiality  or SASL Binding.

Hence ISE-AD connectivity is not affected by this advisory.

The same is tested using basic SST flows around AD integration like Domain Join, Authentications, Performance tests after applying the MS Advisory changes on MS Domain controllers.

Tested: ISE Ver 3.0.x Builds, MS Domain controllers 2016, 2019.

Note: The troubleshooting option “TROUBLESHOOTING.EncryptionOffPeriod” only presents the the LDAP Search attributes in clear text. The bind is unaffected by this option(meaning the bind still uses encrypted tokens). We have not seen any difference in the troubleshooting option before/after applying Microsoft Hotfixes on AD Servers. Attaching packet captures.

Summary: ISE- ActiveDirectory Integration is not impacted by “ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing”. Authz evaluation troubleshooting for DN/Grouplookups using hidden commands by TAC is also not affected.