13

I need to bind to an OpenLDAP server to authenticate users, but I don't want this low-privileged or "delegated administrator" to be able to see more attributes than strictly necessary.

How do I reduce the attributes a bind user can see using a whitelist? What attributes are strictly necessary to authenticate users?

For example, there's no need for this specific bind user to see NTPassword and I suppose other attributes like home directory, etc.

This is what I did so far:

  1. I have disabled anonymous bind:

    # disable anon bind dn: cn=config changetype: modify add: olcDisallows olcDisallows: bind_anon dn: cn=config changetype: modify add: olcRequires olcRequires: authc dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcRequires olcRequires: authc

  2. I've created an "Applications" OU and a "gitlab" user:

    # file: applications.ldif dn: ou=Applications,dc=example,dc=com objectclass: top objectClass: organizationalunit ou: Applications dn: cn=gitlab,ou=Applications,dc=example,dc=com cn: gitlab objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: {CRYPT}.....

  3. To create the user, I've used the LDAP admin user:

    ldapadd -xvvv -f applications.ldif -D 'cn=admin,dc=example,dc=com' -W

  4. To restrict the 'gitlab' privileges, I've tried this:

    # file: give-applications-access.ldif dn: cn=config changetype: modify # allow Applications (e.g. GitLab) access to userPassword access to dn.chidren="ou=People,dc=example,dc=com" attrs=userPassword by dn.exact="ou=Applications,dc=eaxmple,dc=com" read

  5. Then I've used ldapmodify to apply the previous LDIF:

    ldapmodify -xvvv -D 'cn=admin,dc=example,dc=com' -W -f give-applications-access.ldif

Now I can successfully authenticate users in ou=People from gitlab. However, if I use e.g. jxplorer or ldapsearch with the gitlab user credentials, I can see all the user attributes except userPassword:

ldapsearch -h ldaps://ldap.example.com -p 636 -LLL -D 'cn=gitlab,ou=Applications,dc=example,dc=com' -s base -b "ou=People,dc=example,dc=com" -s sub -W "(objectclass=*)" | grep -i userpassword | wc -l 0

What's going on here? I suppose gitlab is using sambaNTPassword to authenticate.. but I thought attrs=userPassword was read only, and now it's not even in the attributes.

Apologies for pasting all the commands - I'm leaving them here in the hope that others will find this useful. Most of the documentation I've found describes every single option available but doesn't give any good examples that are usable on recent versions of OpenLDAP; and most of the examples available concern editing slapd.conf and not the "new" database (cn=config) type, so it's hard to understand what's relevant.

UPDATE - the current ACL is:

olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read

I've followed this answer to read the ACLs which in my case were on {0}mdb: ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config 'olcDatabase={1}mdb'

Improve this question
3
  • Please include your full current ACL. Commented Nov 21, 2018 at 3:14
  • @84104 I've updated my question with the ACLs. It's at the end Commented Nov 21, 2018 at 6:46
  • 2
    I have a feeling from reading your ACLs that the only two attributes that are restricted ar the userPassword and shadowLastChange. Rule {2} clearly states that everything else is readable by anyone else... if I am not mistaken Commented Jun 1, 2021 at 15:01

1 Answer 1

Reset to default
0

When GitLab authenticate users over LDAP (not only GitLab but most other application) it goes like this:

  1. A binding enabled user (ie. your cn=gitlab - having credentials stored in GitLab configuration) is used to perform a lookup over the "username" of login screen, it might be the email address or the uid or whatever attribute you mapped in configuration, to retrieve the DN of the entry.
  2. Using the previously found DN, GitLab, attempts a BIND action to LDAP using the password provided by the person at logon screen (checking the password, hence, is delegated to LDAP)

This kind of delegation is useful because userPassword can be hashed/salted in various formats or even delegated to Kerberos or any other external authentication mechanism.

Going back to your specific need of limiting your cn=gitlab user, you should create a more complex ACL avoiding a grant all like * by * read.

I can give you a sample in old slapd.conf format, but you can translate it in cn=config format easily, syntax is not so different:

# Restrict sensitive attributes to app-ro and app-rw access to attrs="userPassword,homeDirectory" by anonymous auth by self write by dn.exact="cn=app-ro,ou=Applications,dc=example,dc=com" read by dn.exact="cn=app-rw,ou=Applications,dc=example,dc=com" write by users none # Allow to read others public info. access to attrs="cn,sn,gn,givenName,telephoneNumber" by anonymous auth by self write by dn.exact="cn=app-ro,ou=Applications,dc=example,dc=com" read by dn.exact="cn=app-rw,ou=Applications,dc=example,dc=com" write by users read # User attrs. access to attrs="employeeNumber,mail,accountStatus,shadowAddress,memberOfGroup" by anonymous auth by self read by dn.exact="cn=app-ro,ou=Applications,dc=example,dc=com" read by dn.exact="cn=app-rw,ou=Applications,dc=example,dc=com" write by users read # # Set ACL for application ro/rw users. # access to dn="cn=app-ro,ou=Applications,dc=example,dc=com" by anonymous auth by self write by users none access to dn="cn=app-rw,ou=Applications,dc=example,dc=com" by anonymous auth by self write by users none # # Set permission for "cn=*,dc=example,dc=com". # access to dn.regex="cn=[^,]+,dc=example,dc=com" by anonymous auth by self write by users none # # Set default permission. # access to * by anonymous auth by self write by users read

Please note and remember: this is just an example, it takes care of a RO and a RW application users and operates over a few attributes that you might or might not have, depending on your schema so, adapt it to your real needs and test it.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.