# LDAP Realm User Cache configuration

**URL:** <https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295>\
**Category:** Elasticsearch\
**Created:** [December 5, 2017, 9:04am UTC](https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295 "2017-12-05T09:04:29Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ize0j10](https://avatars.discourse-cdn.com/v4/letter/i/7ea924/32.png) [@ize0j10](https://discuss.elastic.co/u/ize0j10)\
**Post date:** [December 5, 2017, 9:04am UTC](https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295/1 "2017-12-05T09:04:29Z")

</div>

Hello,

we are using elastic stack 5.6.4 and we configured elasticsearch to use LDAP realm with user cache:

security:  
transport.ssl.enabled: true  
http.ssl.enabled: true  
authc:  
realms:  
therealm:  
cache:  
ttl: 20m  
type: ldap  
[...]

Roles and role mappings are organized file-based. Authentication/ Authorization works as expected.

When a user loggs on into Kibana and switches Menu Tabs within Kibana a lot of LDAP auth is triggered at the elasticsearch backend. I would expect that this information is chached within interval of 20m as configured and not queried against LDAP Server again and again. For every user I see a log full of (Log anonymized [...]):

Dec 05 09:54:02 ...: [2017-12-05T09:54:02,053][DEBUG][o.e.x.s.a.l.LdapRealm] [...] realm [...] authenticated user [...], with roles [[...]]  
Dec 05 09:54:02 ...: [2017-12-05T09:54:02,062][DEBUG][o.e.x.s.a.e.ReservedRealm] [...] user [...] not found in cache for realm [reserved], proceeding with normal authentication

Did we miss something to proper configure the LDAP User Cache?

Kind regards,  
ize0j10

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [December 5, 2017, 9:26am UTC](https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295/2 "2017-12-05T09:26:02Z")

</div>

> [@ize0j10](#):
>
> Dec 05 09:54:02 ...: [2017-12-05T09:54:02,053][DEBUG][o.e.x.s.a.l.LdapRealm] [...] realm [...] authenticated user [...], with roles [[...]]

Those log messages don't indicate that there are queries being performed against the LDAP Server.  
Do you have some other reason to think that the cache isn't working, or is your conclusion based purely on these logs?

If the cache wasn't working, you would see messages saying

```
[LdapRealm] ... user [...] not found in cache for realm [ldap], proceeding with normal authentication

```

The _realm [...] authenticated user_ message indicate which realm handled the authentication for a particular request. Since the cache is per-realm, you will see those messages regardless of whether the user was cached or not.

---

<div class="post-metadata">

**Author:** ![ize0j10](https://avatars.discourse-cdn.com/v4/letter/i/7ea924/32.png) [@ize0j10](https://discuss.elastic.co/u/ize0j10)\
**Post date:** [December 5, 2017, 10:01am UTC](https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295/3 "2017-12-05T10:01:22Z")

</div>

If the cache wasn't working, you would see messages saying

```
[LdapRealm] ... user [...] not found in cache for realm [ldap], proceeding with normal authentication

```

The _realm [...] authenticated user_ message indicate which realm handled the authentication for a particular request. Since the cache is per-realm, you will see those messages regardless of whether the user was cached or not.  
[/quote]

Thank you. That answered my question. I did not expect the query against every realm (the "reserved").

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 2, 2018, 10:01am UTC](https://discuss.elastic.co/t/ldap-realm-user-cache-configuration/110295/4 "2018-01-02T10:01:26Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.