LDAP caching - timeouts question

[meddle01_]

For an LDAP auth server, does it cache the imported groups or is each query done in real time?

For example, I used AD groups tied to roles, but when that AD group moved to a different OU, it broke the authentication process.  Membership results were not returned.   In my LDAP preferences, I'm searching the entire OU structure, so it's not as though hit moved outside the particular OU that was being exclusively searched.

Thnx

[kalagesan_]

Hi,

As  per my understanding SA LDAP auth server caches the first time results for sometime which helps in catalog search next time

SA fetch all groups during server catalog search, The idea of search catalog is that we want to show all the groups available in the domain and the trusted domains (which could be many) and then allow admin to select from the list.

Regards,

Kannan

[Kita_]

The issue with AD and moving a group object is it would change the group sid.  With AD, the SA does remember the group sid to help speed up the group lookup process.  If the sid changes, this does cause a number of issues for the SA device for group lookup with AD.

For LDAP, I do not believe this occurs and will be sending a ldap query for each lookup.

[meddle01_]

I don't think the SID changes when you simply move an object.  It would only change if you deleted it and readded it back.  If it changed the SID, then moving it back to the original spot would still render it useless, as it would have yet another unique SID, but I moved it back and it was fine again.

[ruc_]

>>For an LDAP auth server, does it cache the imported groups or is each query done in real time?

There is no caching of a user's group membership. The query is executed each time Authorization needs to be done (each login).

Having said that, in a LDAP auth server case, when a role mapping rules based on 'Group Membership' is created the rule uses the Group's DN as the main identifier. If a group is moved its DN will change. And the SA role mapping rule will have to be recreated else the SA will use the previous DN.

If I were to take a guess without looking at your config this changed group DN might the reason authorization failed in your case. If you look at a tcpdump and Policy trace you will be able to verify this.

Hope it helps.