Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_Menen
Participant
Participant
Jump to solution

Priority value of the LDAP-Server is changing randomly

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

0 Kudos
1 Solution

Accepted Solutions
JozkoMrkvicka
Mentor
Mentor

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).

Kind regards,
Jozko Mrkvicka

View solution in original post

0 Kudos
12 Replies
Chris_Atkinson
Employee Employee
Employee

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. 

CCSM R77/R80/ELITE
0 Kudos
Michael_Menen
Participant
Participant

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.

 

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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.

Kind regards,
Jozko Mrkvicka
Michael_Menen
Participant
Participant

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
Mentor
Mentor

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).

Kind regards,
Jozko Mrkvicka
0 Kudos
the_rock
Legend
Legend

@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

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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.

Kind regards,
Jozko Mrkvicka
0 Kudos
the_rock
Legend
Legend

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

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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 🙂

Kind regards,
Jozko Mrkvicka
0 Kudos
Michael_Menen
Participant
Participant

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.

 

0 Kudos
JozkoMrkvicka
Mentor
Mentor

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).

Kind regards,
Jozko Mrkvicka
0 Kudos
Michael_Menen
Participant
Participant

Hi all,

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

Thank you

Best regards.
Michael

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events