Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
daniel1820815
Contributor
Jump to solution

Identity Awareness - Could not connect to AD server

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."

Bildschirmfoto 2019-12-22 um 16.41.27.jpg

 

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?

3 Solutions

Accepted Solutions
Maarten_Sjouw
Champion
Champion
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!
Regards, Maarten

View solution in original post

HeikoAnkenbrand
Champion Champion
Champion

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

➜ CCSM Elite, CCME, CCTE

View solution in original post

sauloaraujo
Participant

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.

Capture.PNG

Capture.PNG

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

Capture.PNG

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

Hope that it was helpful.

Cheers!

Saulo

View solution in original post

0 Kudos
12 Replies
Maarten_Sjouw
Champion
Champion
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!
Regards, Maarten
daniel1820815
Contributor
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.
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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

➜ CCSM Elite, CCME, CCTE
Juan_Concepcion
Advisor

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).

 

 

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

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.

0 Kudos
daniel1820815
Contributor
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
Participant

Hi Daniel,

Yes, I managed to get it sorted.

Thanks!

0 Kudos
daniel1820815
Contributor

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

0 Kudos
sauloaraujo
Participant

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.

Capture.PNG

Capture.PNG

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

Capture.PNG

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

Hope that it was helpful.

Cheers!

Saulo

0 Kudos
daniel1820815
Contributor
Thank you Saulo!
0 Kudos
PointOfChecking
Collaborator

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?

 

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events