ISE 3.2 - nodes are contacting DCs via LDAP, LDAP is not configured

[TedB123]

hi

were in the process of decommissioning some domain controllers and ive noticed that our new ISE nodes are contacting these DCs over LDAP port 389.... now this is odd because LDAP is not configured on the nodes as we use Azure AD to authenticate to log onto the ISE portal.
the requests happen once a day at around 1am.
our ISE nodes are connected to the domain but the DCs configured are not the ones we are decomissioning.
We use ISE for radius 802.1x authentication... we use device certificates not user certs.

there are no AD Groups configured either.

I feel like ive gone though every single option in ISE and i cannot find any reference to LDAP.. or anything that could potentially be pointing at LDAP.
ive checked the ldap logs and could not see anything helpful there either.

So the question is... where and why are these LDAP connections coming from?
does anybody have any suggestions/thoughts on what to check or what could be doing this?

thanks

[marce1000]

 - Difficult to tell ; perhaps some global discovery mechanism ; you may need to capture this traffic and analyze with Wireshark (e.g.) in order to get insights , 

 M.

[TedB123]

wouldnt a global discovery mechanism be visible in the configuration somewhere?
the show running config command via cli doesnt show anything pointing at the dcs mentioned.

the only thing that currently springs to mind is that the configuration used on the new nodes was imported from an older node (v2.7) which was hosted in the same location as the DCs its currently contacting.
the old config did have some AD groups configured and the old node was joined to the domain via one of the DCs in question.

So many theres some legacy config somewhere thats embedded into ise but not visible anywhere?
saying this, LDAP was not configured on the old node either.
authentication mode (admin access) on the old node was purely via AD not LDAP.

New node is using azureAD for its admin access..

I will try and get some wireshark captures from this node.

[Arne Bier]

Hi @TedB123 

The LDAP attempts are probably coming from your PSNs that are performing a CRL download. Have you configured CRL downloads ? If you don't configure a static URL in ISE, then ISE will look in the CDP (CRL Distribution Point) of the client certificate and try the URLs it finds there. Windows CA by default populates an LDAP URL in there and ISE tries that and will always fail. Hence why it's better to hard code your CRL URLs in ISE. I had to run a lot of tcpdumps on ISE PSNs to come to that conclusion. It was back in ISE 2,x days but I think now it's still the same.

[TedB123]

---

@Arne Bier wrote:

Hi @TedB123 

The LDAP attempts are probably coming from your PSNs that are performing a CRL download. Have you configured CRL downloads ? If you don't configure a static URL in ISE, then ISE will look in the CDP (CRL Distribution Point) of the client certificate and try the URLs it finds there. Windows CA by default populates an LDAP URL in there and ISE tries that and will always fail. Hence why it's better to hard code your CRL URLs in ISE. I had to run a lot of tcpdumps on ISE PSNs to come to that conclusion. It was back in ISE 2,x days but I think now it's still the same.

---

i am not aware of any CRL configurations within our ISE setup.... i will take a look as this is the first time im hearing about this.

having a quick google i assume this relates to the certificates?

i will post back soon...

[TedB123]

so we dont have anything configured for the CRL in our scepman cert (intune built machines)

when i look at the authentication details for a device, the only mention of CRL is the following

12571

ISE will continue to CRL verification if it is configured for specific CA - certificate for ce5687f7-xxxxxxxx

There are no other entries saying that its either failed or bypassed.

should we add a URL to the scepman cert?

[Arne Bier]

By default ISE will check the CDP of the client cert. If you look at one example client cert, the http URL of the CRL might be published there (of the CA admins chose to publish it). If it's not there, then ask your CA admins what the http location is for the CRL. Paste the URL into ISE as a static setting for the Trusted CA that issues client certs. Very import. If your PKI has a hierarchy of:

Root CA
 -- > Intermediate CA
           ---> Issuing CA

then don't set a CRL download for the Root or Intermediate CA. Only set it for the Issuing CA cert. 

And you can also set the frequency of CRL download to daily. Even if the CRL is only published every 2 weeks (Windows CA default I think), ISE downloads the same file every day - but it should be quick if the CRL is not large. You can download the CRL yourself to see the size. 

Not sure if the LDAP errors will disappear, but at least you can be 100% sure that you are download the CRL (if your CA admins don't publish a CRL or don't revoke certs, then this is also a moot point). But the idea is to stop ISE from trying to use LDAP to speak to download the CRL:)

[TedB123]

---

@Arne Bier wrote:

 If you look at one example client cert, the http URL of the CRL might be published there...
If it's not there, then ask your CA admins what the http location is for the CRL.

---

ive had a look at my local comp cert and theres no CRL details published
ill speak to the guys next week about this and see if i can get the http for it...

i did some more digging around with what the ISE server is contacting... and it seems that its not only contacting the DCs that i mentioned. Its sending LDAP requests out to all of our DCs.. regardless of where they are located, every DC is getting hit with an LDAP request.

thanks for your help with this so far... ill post back next week with an update.

[TedB123]

I stand corrected.. i found the CRL Distribution Point URL in our Company Root CA.

as you said above....

Very import. If your PKI has a hierarchy of:

Root CA
 -- > Intermediate CA
           ---> Issuing CA

then don't set a CRL download for the Root or Intermediate CA. Only set it for the Issuing CA cert. 

As we use scepman certs for our intune machines, there is a scepman CA Configured in ISE... does this mean we'd need to add that CRL URL into this trusted certificate?

what happens if you add it to the primary company root CA and the scepman CA?

cheers!

[Arne Bier]

ISE only checks the CRL of client certs. Therefore, find one example, open it (eg in Windows) and look at the structure. Which CA issued that cert? That is the Trusted CA in ISE whose CRL URL you must edit. In general, the issuing CA publishes the CRL for certs it has issued. Any http server can play the role of that URL. The file that is published must be a valid CRL thought. 

[JonasNobs · Accepted solution]

looking at your first printscreen it looks like there is AD integration for the "external identity source".
If I'm not mistaken what happens there is - besides other protocols - also LDAP on tcp/389

When selecting the object within the "Active Directory" folder, you should see which domain controllers are contacted for the individual nodes in the deployment.
I suspect this is where the LDAP connection is coming from.

Also as you select one node and then go to "Diagnostic Tool" on top, you will see that one of the checks performed is indeed LDAP.

[TedB123]

---

@JonasNobs wrote:

looking at your first printscreen it looks like there is AD integration for the "external identity source".
If I'm not mistaken what happens there is - besides other protocols - also LDAP on tcp/389

When selecting the object within the "Active Directory" folder, you should see which domain controllers are contacted for the individual nodes in the deployment.
I suspect this is where the LDAP connection is coming from.

Also as you select one node and then go to "Diagnostic Tool" on top, you will see that one of the checks performed is indeed LDAP.

---

ah man i never clicked on that before...

i can see LDAP tests running daily.. the time stamp matches what im seeing in our firewall logs.
interestingly....
on some of the tests it shows you which DCs are available.. .and the DCs that i mention in this thread are not actually specified in the test results. it looks like its only listed the DCs located in our azure tenant.

When i rerun the LDAP test DCs availability test, i can see on the firewall that its hitting all DCs including the DCs that we are going to decommission.

i think that solves the question as to whats happening here.

thanks for all your help

cheers,