LDAP cache TTL

[gpallis]

Hello all! That's a question for those of you that have configured your C-Mode filer with LDAP authentication. The default value for the LDAP cache is 86400sec which means 24h:

::*> diag secd cache show-config -node NodeA -cache-name ldap-username-to-creds

Current Entries: 0
Max Entries: 512
Entry Lifetime: 86400

I was wondering if anybody has tweaked this setting to be less than 24h, preferably something like 15min. If yes, was there any unexpected behaviour by the filer or is everything good? FYI, The filer I manage is an AFF8080 with CDOT 8.3.2P5. Thanks in advance for any response.

[hadrian]

Hello Friend,

I work for NetApp doing ONTAP9 architecture and migration planning.  The short answer is:  Some people adjust the cache values, and it depends on how it will affect your environment based on LDAP server health/load, LDAP structure, NFS load, latency, etc. 

Before adjusting it down, I'd say ensure your LDAP infrastructure and latency between the storage controller to LDAP is very good.  Read up on LDAP server best practices on pg 40 of the Name Services Best Practices guide:  http://www.netapp.com/us/media/tr-4379.pdf

Pgs 53 through 55 detail all the default and recommended cache values, there is also the generic point of contacting support before endeavoring to adjust the TTL.   

If this helped out or answered your question, be sure to hit the Kudos / Mark as Answered button 😃

Hadrian Baron

Practice Architect

[parisi]

So, I wrote the mentioned TR as well as TR-4073.

Hadrian is right - it's very much an "it depends" scenario.

Keep in mind the following:

- When you increase the cache lifetime, that means we store stuff longer. Storing stuff longer = faster lookups, but less accurate because it's not "up to the minute."

- When you decrease the cache lifetime, we flush more often, which means more accurate and up to date info, but more processing on the cluster nodes and the secd process.

Also keep in mind that there are caches at the node level aside from secd that store credentials. These are also covered in TR-4379.

[gpallis]

Hello. Apologies for the late response. Yeah, what you explain makes absolute sense and it's what one would expect. I just wanted to see how other fellow sys admins manage this situation when users are added and removed into AD/LDAP groups in a kind of a frequent basis and what their experiences were in case they reduced the LDAP related caches TTL.

The latency between the filer and the AD servers is extremelly low as they all run in a 10Gb LAN. Plus the CPU utilisation is very low (less than 10% average as far as I can see from the current and historical data in our monitoring system).

The two documents you mentioned are awesome. Thanks for sharing 🙂

[gpallis]

Hello again! I modified the following secd cache TTLs:

ldap-userid-to-creds

ldap-username-to-creds

down to 20'. But this change doesn't seem to be reflected when adding a user to an AD group after that time. The user gets a permission denied when trying to access a share via NFS (CIFS is fine).

I 've read again paragraph 5.10 from TR-4379 which explains all the different caches, but couldn't identify what I am doing wrong. Is there anything that I am missing here? Thank you.

[parisi]

Likely the nblade/NAS layer cache. Clear that manually and it should work fine.

page 52 of TR-4379

[gpallis]

Hello. It took me a while to get back, but I had NetApp's support to help with this. So, I still can't understand if this was necessary, but we additionaly tweaked the value of these caches:

ldap-username-to-info-batch
username-to-info

(By the way, any idea what these two do? didn't quite get it plus didn't find any other documentation other that what is mentioned here)

What definetly helped was changing the value for the TTL of the positive cached credentials for the NFS server. The default here is yet again 24h.

https://library.netapp.com/ecmdocs/ECMP12454943/html/GUID-FAF76B58-BB2B-4A3F-9AB4-2FFB7F96F6C8.html

::> set adv
::> vserver nfs modify -vserver vserver_name -cached-cred-positive-ttl time_to_live

All good now. Thanks for the help 🙂

[gpallis]

After a couple of years this needs some updating. For those that do not know, ONTAP 9.3 and later introduce a change with regards to group caching in the form of the new Global Nameservice Caching functionality . The associated command is "name-service cache group-membership". For more information you can look the following KB:

https://kb.netapp.com/app/answers/answer_view/a_id/1074594