- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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:
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?
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
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
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
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).
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.
Hi Daniel,
Yes, I managed to get it sorted.
Thanks!
What did you do to get it solved? Maybe others can benefit from your experiences.
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
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?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
32 | |
17 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 |
Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesWed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesTue 28 Oct 2025 @ 11:00 AM (EDT)
Under the Hood: CloudGuard Network Security for Google Cloud Network Security Integration - OverviewAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY