Error: At least one DC is currently disconnected

[Bernardes]

Hello Friends,

I have an issue regarding AD Queries for Identity Awareness.

Environment: SMS Smart-1 Cloud + SG Open Server Nutanix (active/standby cluster)

The monitor shows a warning related to Identity Awareness: Error: At least one DC is currently disconnected; the AD Query Status shows Bad Credentials.

When I will create an access role, it find normally the AD users and groups, but when the access role is attached to a security policy, it doesn't work.

I double-checked the credentials (they didn't expire); The communication between gateways end AD Server is ok (ping, telnet, etc); There's no security policy blocking this communication because I test it with an "accept any any".

Any advice? Is there any specific log I can check to better understand the issue?

Thank you.

[the_rock]

Hey,

Check if below applies.

https://community.checkpoint.com/t5/Management/At-least-one-DC-is-currently-disconnected/td-p/25305

Also, run adlog a dc from expert mode, make sure shows right output.

Did this ever work before?

As far as the log thats relevant, maybe check for IP address of the AD server or any logs related to IA blade -> from logs and servers -> blade: Identity Awareness

[Bernardes]

Hello @the_rock ,

I've already tried it from the link, but it has not been resolved. The logs from blade Identity Awareness are just "Alert" with Information: Communication problem @ <[AD Server IP]> 

and

Error Description: Internal Error. Contact Check Point Support for assistance.

The SMS is on Cloud and the cluster Gateways is on 81.10 version with the latest take 78.

[PhoneBoy]

Sounds like a good reason to open a TAC case.

[the_rock]

MAKE SURE if its cloud mgmt server that in dashboard, in ldap account unit object, under "object management" tab (2nd from the right), its selected to "network is secured" and then proxy "your cluster"(management server needs proxy to reach AD server)

Push policy and test. If thats already there, then maybe check with TAC.

[Bernardes]

@the_rock, this configuration is already checked, and since the beginning it's right.

[Bernardes · Accepted solution]

Hello guys!

First of all, thank you to everyone that contributed in some way!

I found the issue's cause and the solution on this Microsoft KB https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-...

Resuming, after Windows Server Update a hardening change DCOM was done, and this caused problems with Check Point's AD Query. There are two ways to solve this problem:

First: Disable the hardening changes by register editor as shown in KB link above.

Second: Installing the Check Point's Identity Collector in Server and connecting to gateway.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_IdentityAwareness_AdminGuide/Topic...

Thank you all!

[PointOfChecking]

The identity collector option is not available for quantum appliance.  Does anyone know another way to fix this?

Also, I have 3 DCs, 2 of them are OK, but one of them is not (new Server 2022).  Already upgraded everything to R80.40 Latest take 180, so shouldn't be the KB5004442 issue.  Unless we need to do something on the server itself?

BTW, opening the server record in the LDAP account unit, I am able to click Fetch and get the same server fingerprint as running the below command on the server:

cpopenssl s_client -connect X.X.X.X:636 2>&1 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | cpopenssl x509 -noout -md5 -fingerprint

Any ideas welcome

[PhoneBoy]

When you say "Identity Collector is not available for Quantum appliance" what precise appliance are you referring to?
I presume you're referring to the "Spark" (SMB) appliances.
However, this limitation was resolved in R81.10.xx firmware as shown here: https://support.checkpoint.com/results/sk/sk178604 
This may require the latest version (R81.10.05).

If you have older Quantum Spark appliances (e.g. running R77.20.xx), you can use Identity Sharing with a gateway that is able to acquire identities via Identity Collector. 

[PointOfChecking]

Thanks.  Yes using spark appliance on 80.20.  Will upgrade that.

What if I just want to do AD Query.  Anyone have any idea how to make that work on this one DC that's not working?

Thanks,

[PhoneBoy]

Microsoft has made numerous changes to WMI in response to security vulnerabilities.
With the most recent patches, if the user configured for ADQuery is not an admin user, a workaround needs to be applied.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 
I assume this applies for Windows Server 2022 as well.

The clear recommendation is to use Identity Collector instead of ADQuery.

[PointOfChecking]

Thanks. The user is already an admin account.  

I forgot to mention, when running the command adlog a dc, I get the below message.

connection had internal error [ntstatus = 0x80010111]

I Appreciate the ID Collector is now the recommended method, however, we'd still like to continue using ADQuery.

I found another article that shows we can use ldapsearch to test the connection:

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

After running the command: 

ldapsearch -h x.x.x.x -p 636 -Z -D "CN=Administratoraccount blablabla" -w password -b "DC=acmedomain" "(sAMAccountName=someusername)"

The user's LDAP information is successfully returned, meaning it's not a connection issue right?

Thanks

[PhoneBoy]

The issue you're running into is known: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Unfortunately, at this time, your only choices are to use a lower version of Windows Server or to use Identity Collector.

[Gaurav_Pandya]

We have couple of customers who uses Azure AD (In cloud) and I have been informed that Identity collector is not supported for AD is in cloud. 

[PhoneBoy]

AzureAD only sees the user's public IP, therefore it's inadequate as an identity source on its own or with Identity Collector.
Captive Portal on a Check Point gateway can capture the private IP and can be configured to authenticate with AzureAD.
This can be made relatively transparent to end users with Kerberos ticketing, though it will likely require HTTPS Inspection to be enabled. 

[PointOfChecking]

Hi PhoneBoy,

I've installed the identity collector onto the new 2022 AD.

Configured the pool.  (Connection test successful)

Configured the GW.  (Connection test successful)

I've removed AD query for the 2022 server from the IA source in the GW and added Identity Collector as the source for it.

However, when I click on AD Query Status on the GW, it only shows the 2 working servers.  The server collected via Identity Collector is not showing. (Image attached)

Is the server that uses Identity Collector viewed somewhere else?

thanks.

[PhoneBoy]

Yes, because that screen refers to ADQuery configured servers, not Identity Collector.
From the gateway, use the command pdp idc status to verify the gateway is connected to Identity Collector. 

[PointOfChecking]

Thanks PhoneBoy, thought as much and thank you for the command

When I run the command pdp idc status it shows:

Identity Collector IP: X.X.X.X  (The IP of the AD with IDC installed)
Identity Sources:
No information about identity sources

So it's successfully connected to the IDC, but does this mean it's failed to collect any data?

On the IDC, it shows as connected and sending data.

[PhoneBoy]

What it likely means is that it is not receiving monitoring data from the IDC.
This is expected as it requires a specific registry key to be set. 

[PointOfChecking]

Thanks.

as the_rock says, "works, no issues."  Is it necessary to set that "specific registry key"?

Also, with "AD Query", you can clearly see if it works or not via the GUI when you log in, via a green or yellow icon.

With IDC, are we supposed to go to CLI and run this command every now and then to see if it's working?

When we do run the command, we get an unclear "No information about identity sources" error, so it's hard to see if it's working or not.

If IDC is being pushed as the way forward, should we not have an identifier in the GUI showing one of these?

"GREEN" it's working

"YELLOW" something is wrong

"RED" Oh-my-gosh-battle-stations

Again, thanks PhoneBoy for your input and help

[PhoneBoy]

Only if you want the specific monitoring data from IDC to be made available via that command is it necessary to set that registry key.
It also makes the data available to be monitored via SNMP on the gateway per: https://support.checkpoint.com/results/sk/sk108235

As far as having this in SmartConsole, that would currently be an RFE.

[the_rock]

Well, here is another reason to use IDC ; - )

Check Point response to CVE-2021-26414 - "Windows DCOM Server Security Feature Bypass"

[the_rock]

I get same output and mine works, no issues.

[the_rock]

Its is available as @PhoneBoy said, 100% works fine, as long a you are referring adding it to IDC software.

[cdelcarmen]

this was fixed in my environment by using the correct domain user inside the ldap acount unit.

domain\username

[the_rock]

I also had similar issue yesterday with the client and that exact thing turned out to be the issue...I would say 9 times out of 10, it turns out to be the cause.

Best,

Andy

[Roadrunner88]

Hello, I have the same issue in a cluster but only the passive Firewall shows this error, when I make a failover it changes to the other Firewall.

[the_rock]

Personally, I always found that error is caused by 2 things...either windows firewall being on OR windows update.

Best,

Andy

[Roadrunner88]

do you mean on the DC Server?

[the_rock]

Yup.