Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
John_Colfer
Contributor

Domain Controller Redundancy

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

10 Replies
G_W_Albrecht
Legend
Legend

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

CCSE CCTE CCSM SMB Specialist
0 Kudos
_Val_
Admin
Admin

The question is about authentication, not about Identity Awareness.

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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.

Kind regards,
Jozko Mrkvicka
John_Colfer
Contributor

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?

0 Kudos
JozkoMrkvicka
Mentor
Mentor

Yes, exactly.

Kind regards,
Jozko Mrkvicka
0 Kudos
Norbert_Bohusch
Advisor

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
Contributor

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
Participant

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?

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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.

Kind regards,
Jozko Mrkvicka
0 Kudos
Wolfgang
Authority
Authority

@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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events