Domain Controller Redundancy

[John_Colfer]

Hi

I was just wondering how domain controller redundancy works in Checpoint policy. You create LDAP Account Unit for a domain and add in your 2 ldap server objects (domain controllers).

Then on the "Objects Management" tab you can only choose 1 of these 2 servers

Today the cert on irbdc04 changed which meant ldaps queries stopped working until the fingerprint was fetched. The customer asked us, "why didnt the other domain controller take over serving authentication queries". 

So I'm wondering even though I have 2 servers defined in the ldap account unit, but only 1 defined Objects management tab does this mean that if irbdc04 is not working there is no ldap server redundancy? At what point will phdc03 take over serving requests?

Thanks in advance

John

[G_W_Albrecht]

i would use CP Identity Collector here - see sk108235 Identity Collector - Technical Overview for details !

[_Val_]

The question is about authentication, not about Identity Awareness.

[JozkoMrkvicka]

We had EXACTLY the same issue like you a year ago and it looks that priority does nothing in this case because LDAP is reachable, but cannot fetch anything = no issue at all for Check Point.

in case first LDAP is not reachable (telnet 636 not possible), it will go to the other LDAP in priority list.

In your case first LDAP was reachable (can you confirm ?) and thats all fine accorrding Check Point design.

[John_Colfer]

Hi Jozko

Yeah the ldap server was reachable (the server was up), but the fingerprint on the cert had changed so it could not retrieve anything. So does that mean that if the server is up and reachable it will not use the next server in the list, even though it cannot query the directory?

[JozkoMrkvicka]

Yes, exactly.

[Norbert_Bohusch]

That’s a big problem of LDAPS configuration in Check Point Account Unit, as there is no check of when certificate expires and a warning upfront. 

That’s why I prefer LDAP in this case (at least if everything is internal traffic), even though we send it in clear.

[John_Colfer]

Thanks Norbert. I suggested this to customer but they prefer not to send usernames/passwords in the clear. Is there any other way around this? Is this issue addressed in a subsequent version?

Thanks again

John

[Scott_Bily]

Does anyone know if the fingerprint is cached for a period of time on the gateways?     Our DC's are configured to auto-renew their certificates annually.   But I don't know how much time(if any) we have after the certificates are renewed on the DC's to Fetch the new fingerprint and push policy?

[JozkoMrkvicka]

This is indeed good question, I second that.

The best would be to test it in LAB to see real world scenario. I suspect that fingerprint is not cached, it could depends how often you are downloading CRLs from DC, or what is requesting from gateway to DC.

[Wolfgang]

@Scott_Bily 

The fingerprint is not cached on the gateway. Fingerprint will be installed on the gateway if you fetched from LDAPS-server and did a policy install. Until you change the policy nothing is changed on the gateway. If the fingerprint changes on the LDAP-server you have to refectory again and install policy.

There is only one way to overcome the fingerprint problem following  LDAP failing with "SSL finger print does not match" , but with a little bit lower security.

As a security company Check Point should should solve such a small problem.

Wolfgang