Identity Awareness - Could not connect to AD server

[Daniel_Kuhl1]

Hello everyone,

I tried to test the Identity Awareness Blade on my lab and connect to a AD server but always got the error message on SmartDashboard (R80.30):

"SmartDashboard could not connect to x.x.x.x - Could not communicate with server."

I did several troubleshooting things like mentioned on the link below:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

I can connect to the AD server without any error from the cli on my security gateway using "test_ad_connectivity" and "ldapsearch" but from SmartDashboard it does not work.

I moved on with checking the box "Ignore the errors and continue to configure the LDAP account" and put in the login DN which worked fine. I also activated Browser-based Authentication which I could test successfully from my test client.

I did a packet capture on the AD server to check if there is any traffic from the security gateway to the AD server during the activation of AD Query within the Wizard, but there are no packets arrived on the AD server.

I also tried to add a LDAP Account Unit before activating the Identity Awareness blade, so that you can choose it from the dropdown within the configuration wizard. Adding the LDAP Account Unit worked also without errors, but during the AD Query activation it failed again to connect like before.

Anyone had similar issues or any experiences with that error?

[Maarten_Sjouw · Accepted solution]

2 things to check:
Can your client directly access the AD server?
Can your Management server directly access the AD server?
Have you enabled NTLMv2 and pushed policy?
From expert mode run: adlogconfig a
Check the setting for NTLMv2 make sure it is enabled, if not enable it and push policy!

[Daniel_Kuhl1]

Hi Maarten, thanks a lot for your reply. I could solve the issue now. As I already thought it was a simple error. The problem was that I was not able to connect to the AD server from the management client pc.

[HeikoAnkenbrand · Accepted solution]

Firewall rules?

Source: SmartConsole IP  

Destination: AD Server IP

Service: Port 135 AD query

More read here:

R80.x - Ports Used for Communication by Various Check Point Modules

[Juan_Concepcion]

The client your connecting from, the firewall(cluster) and SmartCenter should be able to connect to the AD server. The client workstation proxies on behalf of the management station and the firewall also verifies it can communicate to the AD server.  If you go into expert mode on firewall and run following:

nslookup

> set type=srv

>_ldap._tcp.<domain_name>

It should return back the AD servers in the environment.  If it does not then you need to fix either (a) reverse lookup for your domain (b) the dns server on the firewall.  I have seen where people will use the ISP dns servers and this breaks AD query.  Also, I would suggest you look at Identity Collector (sk108235) it is much more stable way of doing identity awareness and is less resource intensive on both your firewall and AD server(s).

[Daniel_Kuhl1]

Hi Heiko, thanks a lot for your reply. The link you posted was very helpful for troubleshooting and I bookmarked it for future usage.

[sauloaraujo]

Hey Daniel!

I'm having the same issue with the Identity Awareness blade. But my problem is with the AD server setting on the CheckPoint.

The Identity Awareness wizard is detecting mu domain but it is trying to connect to a AD server that has been decommissioned long ago.

[Daniel_Kuhl1]

Were you able to solve the issue? Seems like you need to re-initialize (disable/enable) Identity Awareness... (I'm only guessing because I don't know your environment)

[sauloaraujo]

Hi Daniel,

Yes, I managed to get it sorted.

Thanks!

[Daniel_Kuhl1]

What did you do to get it solved? Maybe others can benefit from your experiences.

[sauloaraujo · Accepted solution]

You're right, Daniel.

So, one of the Active Directory servers was decommissioned on the environment, that was the cause of the issue.

First, I checked the Identity Awareness settings on the SmartConsole:

Gateway Cluster Properties > Identity Awareness > Active Directory Query > Settings and confirmed the name of the Object that define the Active Directory Domains.

Then, I located the FIDELITY.LOCAL__AD object and removed the decommissioned server from the servers list.

After publishing the changes and installing the policies, the issue was resolved.

Hope that it was helpful.

Cheers!

Saulo

[Daniel_Kuhl1]

Thank you Saulo!

[PointOfChecking]

Hi,

Like you, we have 3 domain controllers, but in our scenario, one of the servers was not decommissioned, but just crashed one day.

The purpose of listing the 3 DCs in the LDAP unit is for redundancy.

However, when that server crashed, IA completely failed and did not work anymore.  Remote Access users could not be authenticated until that server was restarted.

Do I need to specifically set "If you can't access this DC, use that DC instead" anywhere, to get this to work?

Isn't that the point of listing multiple DCs in the LDAP unit?