Priority value of the LDAP-Server is changing randomly

[Michael_Menen]

Good morning all,

we are facing a strange issue with the priority value of the configured LDAP-Server on the "User Directory" pane.

On the onsite gateways the priority is configured to prefer local LDAP-Server (On the gateway in the UK, UK-LDAP-Server does have Prio 1 and all other are on Prio 1001, on the Gateway in Peru the local Peru-LDAP-Server does have Prio 1 and all other are on Prio 1001.....and so on).

Double checking the priorities we can see that sometime the priority value is randomly changing on one Gateway.

In November the Priority on the Gateway in Ecuador was set to Prio 1 for the local LDAP-server and today it's set to Prio 1 for the LDAP-Server loacted in Spain.

All other priorities on all other gateways remain unaffected.

All Gateways are running R81.10 Take 96

I have no clue what is changing the priority values nor do I have any idea in which file I can find information about what is actually happening.

Anyone here who knows this problem or knows where I can find the information for troubleshooting?

Much appreciate

Best regards

Michael Menen

[Chris_Atkinson]

I would review sk107378 for relevance and follow-up with TAC as appropriate.

Per sk44261 we plan to introduce a proximity based solution in future. 

[Michael_Menen]

sk107378 has already been checked.

sk107378 is poiting the the issue, that priority value of an LDAP server changes automatically in all Security Gateways if priority was changed in one of these Security Gateways - but in my case nothing was changed.

[JozkoMrkvicka]

Make sure the fingerprint for Ecuador LDAP is the same as on LDAP itself. Within the main LDAP Account Unit, open Ecuador LDAP object and click on "fetch fingerprint". If you see change in the fingerprint, it is the cause why Ecuador LDAP was skipped, since fingerprint didnt match.

[Michael_Menen]

Not using fingerprints for LDAP-communication.

The issue with using fingerprints for LDAPS is, that a fingerprint might change if something is changing on the Windows LDAP-Server

sk42905 -> Workaround 2

[JozkoMrkvicka]

How did you notice that the priority was changed by itself? Over SmartConsole ? Over CLI checking which LDAP is using port 389/636 (netstat -anop | grep 636 ) ?

Did you try to use priority of 2, 3 for non-local LDAPs ? Why using 1001 if it should be used as a backup ?

I can imagine that priority of 1001 can be in some cases interpreted as 1 (as first digit is 1).

[the_rock]

@Michael_Menen I see what @JozkoMrkvicka is saying...why use priority 1001 is they are supposed to be backup? Just use 2 or 3 or something close to 1, as 1 is always highest priority.

Best,

Andy

[JozkoMrkvicka]

in addition to that, if local prior 1 LDAP is for some reason down and not responding, all other non-local LDAPs shouldnt be used at all, since priority 1001 means they are skipped and not used at all. If the only usable LDAP (local, prior 1) is not working, the outage of VPN is very likely. This is logic problem and redundancy should be ensured (and tested) in such a case.

[the_rock]

I searched for anything related to this in Guidbedit, but cant really find much.

Might be worth opening TAC case to check further.

Best,

Andy

[JozkoMrkvicka]

Did you check audit logs if someone else didnt change the LDAP priorities within gateway in Ecuador ? I had dozens of cases where someone from the firewall team did change something but didnt inform anyone about the change 🙂

[Michael_Menen]

Hi all,

happy new year!

1) Using priority 1001 works fine most of the time, but it might be worth trying to change it to 8 or 9.

2) Priority is not only changing in Ecuador but randomly across the whole enviroment.

3) Double checking changes - no correlation.

4) A scheduled task is in place to check the priority every month. Last check the priority on the gateway in Ecuador has been canched. The check before nothing changed.

5) Nothing shown in the logs.

6) Because of nothing shown in the logs and the issue only occurs every 1 or 2 months we could not provide any logs and the TAC-case was closed.

[JozkoMrkvicka · Accepted solution]

all the best in 2024 ! 🙂

My suggestion is to schedule task to check current priority for 12 hours. You will have plenty of hours left once all logs (.elg files) are overwritten and possibly perform cpinfo/snapshot/backup on management and gateway to found the reason. At the same time re-open the case and provide needed debug files. On the other hand, there should be some debug plan available (from TAC/R&D) in case the issue happened again in the future.

You may be even able to see if there is some pattern when exactly is the priority changed, if you check the current status more often (on daily/hours basis).

[Michael_Menen]

Hi all,

totally agree that re-open the case will be the best we can do.

Thank you

Best regards.
Michael