sss allows extraneous @ characters prefixed to username?

[Paul B. Henson]

We are running the latest RHEL 8.7 which includes sss version 
2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore 
leading @ characters when looking up a username. For example:

# getent passwd '@cpp.a'
cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash

The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how 
many @ signs there are:

# getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash

This is a local account on the system, with the default sssd 
configuration, there is nothing explicitly set:

# find /etc/sssd
/etc/sssd
/etc/sssd/conf.d
/etc/sssd/pki

If I update nsswitch.conf to remove sss from the passwd line this 
behavior goes away.

The same behavior occurs on other systems that are integrated with our 
LDAP and kerberos systems. When logging in, not only is this invalid 
username successfully authenticated, it is passed to other pam modules:

Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for 
'@@@@@@@henson' from 10.104.223.249: Allowing unknown user

This is allowing a bypass of our security policies, in this case, a user 
who should have been forced to do MFA was able to login without it 
because the name passed to the other modules by the login stack was not 
the real username which ended up being logged in.

Is this a bug? A configuration issue? I opened a support ticket with Red 
Hat but as have not as yet received a resolution. I wouldn't think this 
would be intended behavior out-of-the-box.

Thanks…

[Alexey Tikhonov]

Hi,

On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson  wrote:
> We are running the latest RHEL 8.7 which includes sss version
> 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
> leading @ characters when looking up a username. For example:
>
> # getent passwd '@cpp.a'
> cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
>
> The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
> many @ signs there are:
>
> # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
> cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash

In `sssd_nss.log`:
[sss_parse_name_for_domains] (0x0200): [CID#1] name '@@@ftp' matched
without domain, user is ftp

Did you try it with other domains (i.e. non-local users)?

Probably issue is with `SSS_DEFAULT_RE`:
https://github.com/SSSD/sssd/blob/master/src/util/util.h#L253

I guess the idea is that the username can't begin with '@'...
> This is a local account on the system, with the default sssd
> configuration, there is nothing explicitly set:
>
> # find /etc/sssd
> /etc/sssd
> /etc/sssd/conf.d
> /etc/sssd/pki
>
> If I update nsswitch.conf to remove sss from the passwd line this
> behavior goes away.
>
> The same behavior occurs on other systems that are integrated with our
> LDAP and kerberos systems. When logging in, not only is this invalid
> username successfully authenticated, it is passed to other pam modules:
>
> Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
> '@@@@@@@henson' from 10.104.223.249: Allowing unknown user
>
> This is allowing a bypass of our security policies, in this case, a user
> who should have been forced to do MFA was able to login without it
> because the name passed to the other modules by the login stack was not
> the real username which ended up being logged in.
>
> Is this a bug? A configuration issue? I opened a support ticket with Red
> Hat but as have not as yet received a resolution. I wouldn't think this
> would be intended behavior out-of-the-box.

[Tomas Halman]

Hi, Alexey is right.

The character @ is not expected in the username. A particular set of
allowed characters may differ, depending on your setup.

I found nice summary here: https://systemd.io/USER_NAMES/

The SSSD default does not expect/allow '@' in username. To fix that you can
configure the re_expression parameter according to your needs.
Setting

re_expression = (?P<name>^@{0,1}[^@]+)@?(?P<domain>[^@]*$)

may help - this allows leading '@' (see '^@{0,1}' in the name. But there is
not enough information about your environment to be sure that this change
will work in all other cases as well.

HTH
Tomáš

On Mon, Mar 20, 2023 at 12:11 PM Alexey Tikhonov 
wrote:
> Hi,
>
> On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson  wrote:
> > We are running the latest RHEL 8.7 which includes sss version
> > 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
> > leading @ characters when looking up a username. For example:
> >
> > # getent passwd '@cpp.a'
> > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
> >
> > The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
> > many @ signs there are:
> >
> > # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
> > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
>
> In `sssd_nss.log`:
> [sss_parse_name_for_domains] (0x0200): [CID#1] name '@@@ftp' matched
> without domain, user is ftp
>
> Did you try it with other domains (i.e. non-local users)?
>
> Probably issue is with `SSS_DEFAULT_RE`:
> https://github.com/SSSD/sssd/blob/master/src/util/util.h#L253
>
> I guess the idea is that the username can't begin with '@'...
> > This is a local account on the system, with the default sssd
> > configuration, there is nothing explicitly set:
> >
> > # find /etc/sssd
> > /etc/sssd
> > /etc/sssd/conf.d
> > /etc/sssd/pki
> >
> > If I update nsswitch.conf to remove sss from the passwd line this
> > behavior goes away.
> >
> > The same behavior occurs on other systems that are integrated with our
> > LDAP and kerberos systems. When logging in, not only is this invalid
> > username successfully authenticated, it is passed to other pam modules:
> >
> > Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
> > '@@@@@@@henson' from 10.104.223.249: Allowing unknown user
> >
> > This is allowing a bypass of our security policies, in this case, a user
> > who should have been forced to do MFA was able to login without it
> > because the name passed to the other modules by the login stack was not
> > the real username which ended up being logged in.
> >
> > Is this a bug? A configuration issue? I opened a support ticket with Red
> > Hat but as have not as yet received a resolution. I wouldn't think this
> > would be intended behavior out-of-the-box.
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[External] Re: sss allows extraneous @ characters prefixed to username?

[Prentice Bisbal]

I came here to say the same thing, and provide the same link. Using an @ 
symbol like that in a username isn't a good practice, since it's used to 
separate a username from a domain name, hostname, or kerberos realm. 
While you may be able to customize the regular expression used by SSSD 
as Tomas as shown, I would be reluctant to do that, as upgrades may 
break that if you don't manage that in a configuration management 
system, and since it's not expected, the QC of sssd and other programs 
that need to parse usernames my not be checking for proper behavior in 
that specific case.

Prentice

On 3/20/23 11:32 AM, Tomas Halman wrote:
> Hi, Alexey is right.
>
> The character @ is not expected in the username. A particular set of 
> allowed characters may differ, depending on your setup.
>
> I found nice summary here: https://systemd.io/USER_NAMES/
>
> The SSSD default does not expect/allow '@' in username. To fix that 
> you can configure the re_expression parameter according to your needs.
> Setting
>
> re_expression = (?P<name>^@{0,1}[^@]+)@?(?P<domain>[^@]*$)
>
> may help - this allows leading '@' (see '^@{0,1}' in the name. But 
> there is not enough information about your environment to be sure that 
> this change will work in all other cases as well.
>
> HTH
> Tomáš
>
> On Mon, Mar 20, 2023 at 12:11 PM Alexey Tikhonov  
> wrote:
> Hi,
>
> On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson <[e-mail]>
> wrote:
> >
> > We are running the latest RHEL 8.7 which includes sss version
> > 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
> > leading @ characters when looking up a username. For example:
> >
> > # getent passwd '@cpp.a'
> > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
> >
> > The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
> > many @ signs there are:
> >
> > # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
> > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
>
> In `sssd_nss.log`:
> [sss_parse_name_for_domains] (0x0200): [CID#1] name '@@@ftp' matched
> without domain, user is ftp
>
> Did you try it with other domains (i.e. non-local users)?
>
> Probably issue is with `SSS_DEFAULT_RE`:
> https://github.com/SSSD/sssd/blob/master/src/util/util.h#L253
>
> I guess the idea is that the username can't begin with '@'...
>
>
> >
> > This is a local account on the system, with the default sssd
> > configuration, there is nothing explicitly set:
> >
> > # find /etc/sssd
> > /etc/sssd
> > /etc/sssd/conf.d
> > /etc/sssd/pki
> >
> > If I update nsswitch.conf to remove sss from the passwd line this
> > behavior goes away.
> >
> > The same behavior occurs on other systems that are integrated
> with our
> > LDAP and kerberos systems. When logging in, not only is this invalid
> > username successfully authenticated, it is passed to other pam
> modules:
> >
> > Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
> > '@@@@@@@henson' from 10.104.223.249 <http://10.104.223.249>:
> Allowing unknown user
> >
> > This is allowing a bypass of our security policies, in this
> case, a user
> > who should have been forced to do MFA was able to login without it
> > because the name passed to the other modules by the login stack
> was not
> > the real username which ended up being logged in.
> >
> > Is this a bug? A configuration issue? I opened a support ticket
> with Red
> > Hat but as have not as yet received a resolution. I wouldn't
> think this
> > would be intended behavior out-of-the-box.
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to
> [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> -- 
> Tomáš Halman
>
> sssd-users mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[External] Re: sss allows extraneous @ characters prefixed to username?

[Paul B. Henson]

On 3/20/2023 8:57 AM, Prentice Bisbal wrote:
> While you may be able to customize the regular expression used by SSSD 
> as Tomas as shown, I would be reluctant to do that, as upgrades may 
> break that if you don't manage that in a configuration management 
> system, and since it's not expected, the QC of sssd and other programs 
> that need to parse usernames my not be checking for proper behavior in 
> that specific case.

I'm sorry if my initial email was confusing; but I am not complaining 
about not being able to use @'s in usernames, I am complaining that sss 
both allows and ignores them:

# getent passwd '@@@@@@@@henson'
henson:*:1005:1012:Paul B. Henson:/user/henson:/bin/bash

It's interesting that the consensus seems to be that what I am 
empirically experiencing should not be happening :). I look forward to 
the implementation being fixed to match the consensus ;).

Thanks…

[External] Re: sss allows extraneous @ characters prefixed to username?

[Prentice Bisbal]

Paul,

Sorry for the misunderstanding Much different problem!

Prentice

On 3/20/23 3:33 PM, Paul B. Henson wrote:
> On 3/20/2023 8:57 AM, Prentice Bisbal wrote:
> > While you may be able to customize the regular expression used by 
> > SSSD as Tomas as shown, I would be reluctant to do that, as upgrades 
> > may break that if you don't manage that in a configuration management 
> > system, and since it's not expected, the QC of sssd and other 
> > programs that need to parse usernames my not be checking for proper 
> > behavior in that specific case.
>
> I'm sorry if my initial email was confusing; but I am not complaining 
> about not being able to use @'s in usernames, I am complaining that 
> sss both allows and ignores them:
>
> # getent passwd '@@@@@@@@henson'
> henson:*:1005:1012:Paul B. Henson:/user/henson:/bin/bash
>
> It's interesting that the consensus seems to be that what I am 
> empirically experiencing should not be happening :). I look forward to 
> the implementation being fixed to match the consensus ;).
>
> Thanks…
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

[External] Re: sss allows extraneous @ characters prefixed to username?

[Tomas Halman]

Ah I see, sorry for misunderstanding.

The default in sssd was designed to find something and split it into
username and domain-name.
I believe that the (default) regular expression can be simply prepend with
"^" and it will work the way you want.

re_expression = ^(?P<name>[^@]+)@?(?P<domain>[^@]*$)

I commented on the ticket...
Tom

On Mon, Mar 20, 2023 at 8:34 PM Paul B. Henson  wrote:
> On 3/20/2023 8:57 AM, Prentice Bisbal wrote:
> > While you may be able to customize the regular expression used by SSSD
> > as Tomas as shown, I would be reluctant to do that, as upgrades may
> > break that if you don't manage that in a configuration management
> > system, and since it's not expected, the QC of sssd and other programs
> > that need to parse usernames my not be checking for proper behavior in
> > that specific case.
>
> I'm sorry if my initial email was confusing; but I am not complaining
> about not being able to use @'s in usernames, I am complaining that sss
> both allows and ignores them:
>
> # getent passwd '@@@@@@@@henson'
> henson:*:1005:1012:Paul B. Henson:/user/henson:/bin/bash
>
> It's interesting that the consensus seems to be that what I am
> empirically experiencing should not be happening :). I look forward to
> the implementation being fixed to match the consensus ;).
>
> Thanks…
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Alexey Tikhonov]

On Mon, Mar 20, 2023 at 4:33 PM Tomas Halman  wrote:
> Hi, Alexey is right.
>
> The character @ is not expected in the username. A particular set of allowed characters may differ, depending on your setup.
>
> I found nice summary here: https://systemd.io/USER_NAMES/

But probably SSSD should refuse to handle this kind of names
immediately, instead of cutting unallowed chars off and handling what
remains?
Otherwise it leads to a kind of security issue, as shown in the
original email...
> The SSSD default does not expect/allow '@' in username. To fix that you can configure the re_expression parameter according to your needs.
> Setting
> re_expression = (?P<name>^@{0,1}[^@]+)@?(?P<domain>[^@]*$)
>
> may help - this allows leading '@' (see '^@{0,1}' in the name. But there is not enough information about your environment to be sure that this change will work in all other cases as well.
>
> HTH
> Tomáš
>
> On Mon, Mar 20, 2023 at 12:11 PM Alexey Tikhonov  wrote:
> > Hi,
> >
> > On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson  wrote:
> > > We are running the latest RHEL 8.7 which includes sss version
> > > 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
> > > leading @ characters when looking up a username. For example:
> > >
> > > # getent passwd '@cpp.a'
> > > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
> > >
> > > The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
> > > many @ signs there are:
> > >
> > > # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
> > > cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
> >
> > In `sssd_nss.log`:
> > [sss_parse_name_for_domains] (0x0200): [CID#1] name '@@@ftp' matched
> > without domain, user is ftp
> >
> > Did you try it with other domains (i.e. non-local users)?
> >
> > Probably issue is with `SSS_DEFAULT_RE`:
> > https://github.com/SSSD/sssd/blob/master/src/util/util.h#L253
> >
> > I guess the idea is that the username can't begin with '@'...
> > > This is a local account on the system, with the default sssd
> > > configuration, there is nothing explicitly set:
> > >
> > > # find /etc/sssd
> > > /etc/sssd
> > > /etc/sssd/conf.d
> > > /etc/sssd/pki
> > >
> > > If I update nsswitch.conf to remove sss from the passwd line this
> > > behavior goes away.
> > >
> > > The same behavior occurs on other systems that are integrated with our
> > > LDAP and kerberos systems. When logging in, not only is this invalid
> > > username successfully authenticated, it is passed to other pam modules:
> > >
> > > Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
> > > '@@@@@@@henson' from 10.104.223.249: Allowing unknown user
> > >
> > > This is allowing a bypass of our security policies, in this case, a user
> > > who should have been forced to do MFA was able to login without it
> > > because the name passed to the other modules by the login stack was not
> > > the real username which ended up being logged in.
> > >
> > > Is this a bug? A configuration issue? I opened a support ticket with Red
> > > Hat but as have not as yet received a resolution. I wouldn't think this
> > > would be intended behavior out-of-the-box.
> >
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Tomáš Halman
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Paul B. Henson]

On 3/20/2023 9:13 AM, Alexey Tikhonov wrote:
> But probably SSSD should refuse to handle this kind of names
> immediately, instead of cutting unallowed chars off and handling what
> remains?

Yes please, as the current implementation
> Otherwise it leads to a kind of security issue, as shown in the
> original email...

effectively aliases the set of '@+<username>' to '<username>' which I 
can't imagine is desirable or intended behavior.

Thanks…

[Alexey Tikhonov]

On Mon, Mar 20, 2023 at 8:37 PM Paul B. Henson  wrote:
> On 3/20/2023 9:13 AM, Alexey Tikhonov wrote:
> > But probably SSSD should refuse to handle this kind of names
> > immediately, instead of cutting unallowed chars off and handling what
> > remains?
>
> Yes please, as the current implementation

Could you please open a ticket at
https://github.com/SSSD/sssd/issues
with reference to this thread?
> > Otherwise it leads to a kind of security issue, as shown in the
> > original email...
>
> effectively aliases the set of '@+<username>' to '<username>' which I
> can't imagine is desirable or intended behavior.
>
> Thanks…
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Paul B. Henson]

On Mon, Mar 20, 2023 at 09:26:31PM +0100, Alexey Tikhonov wrote:
> Could you please open a ticket at
> https://github.com/SSSD/sssd/issues
> with reference to this thread?

Done, thanks much...

https://github.com/SSSD/sssd/issues/6635

[Paul B. Henson]

On 3/20/2023 8:32 AM, Tomas Halman wrote:
> The SSSD default does not expect/allow '@' in username. To fix that you 
> can configure the re_expression parameter according to your needs.

I believe you misunderstood my problem report; I neither have nor want 
@'s in usernames. However, sss appears to accept them:

# getent passwd '@@@@@@@@henson'
henson:*:1005:1012:Paul B. Henson:/user/henson:/bin/bash

Please make it actually work the way you are saying it should work :).

Thanks…

[Paul B. Henson]

On 3/20/2023 4:10 AM, Alexey Tikhonov wrote:
> Did you try it with other domains (i.e. non-local users)?

Yes, I have systems configured into LDAP as shown in the configuration 
below. I've never tried before, but it seems I can also login as 
'user@domain', which also appears to pass that explicit string to other 
parts of the login process and the logs:

Mar 20 12:20:24 login-dev-01 sshd[1140132]: pam_sss(sshd:auth): 
authentication success; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=10.104.223.252 user=henson@cpp
Mar 20 12:20:35 login-dev-01 sshd[1140072]: Postponed 
keyboard-interactive for henson@cpp from 10.104.223.252 port 37802 ssh2 
[preauth]
Mar 20 12:20:36 login-dev-01 sshd[1140072]: Connection closed by 
authenticating user henson@cpp 10.104.223.252 port 37802 [preauth]

I don't really want anything other than the explicit username all by 
itself to be able to be used to login or to show up in the logs. In my 
opinion, that should be the default configuration, and being able to 
login using different domain suffixes should be an option. Particularly 
for people that simply migrated from nss_ldap suddenly having variations 
of usernames that were not previously valid show up in the logs or be 
accepted is surprising. That's a different issue though, as opposed to 
ignoring prepended @'s in usernames which seems buggy.

Thanks…

--------------------------

[sssd]

domains = cpp

[domain/cpp]

timeout = 10

dns_discovery_domain = cpp.edu
id_provider = ldap
sudo_provider = none
auth_provider = none
chpass_provider = none

ignore_group_members = TRUE

ldap_uri = ldap://ldap.cpp.edu/
ldap_id_use_start_tls = true
ldap_search_base = dc=cpp,dc=edu
ldap_user_search_base = ou=user,dc=cpp,dc=edu
ldap_group_search_base = ou=group,dc=cpp,dc=edu
ldap_user_gecos = displayname
ldap_group_name = uid

entry_cache_nowait_percentage = 50
entry_cache_user_timeout = 1800
entry_cache_group_timeout = 1800