Join Log in
Score:1
Francesco avatar Server

Can SSSD authenticate via LDAP with anonymous binding either forbidden in ACLs and with 'olcRequires: authc' enforced?

jp flag
Francesco

I manage a LAN with a list of users accessing their NFS-shared homes while being auhtenticated via NIS/YP (CentOS/Fedora-based clients and servers).

I'm in the painful process of migrating out of NIS/YP (which is slowly but irreversibily being phased out on Red Hat and the like) to what seemed the least-difficult-to-setup replacement for the authenticating part, SSSD (for the clients) and LDAP (for the user database on the servers).

After a number of trials, I've reached what seems an acceptably working setup and started considering a hardening of security but there is something that keeps eluding me.

Mostly everywhere, standard ACLs for querying an LDAP database in order to authenticate users that are logging in are something of this sort:

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

and everything works without problems.

Since I'd rather not let users peek into each other's records, I modified the last one to:

olcAccess: {2}to * by * none

Then I found the 'olcRequires: authc' that should disable anonymous bindings to LDAP (seems an improvement in security, no?) and enabled it, and everything seems to keep working.

Then again, looking at the first ACL, you see that anonymous authentication against a user password is still authorized (which seems redundant if the previous rule is in effect) and I tried removing it:

olcAccess: {0}to attrs=userPassword by self =wx by * none

and nothing works anymore.

Keeping on reading, I found the catch to be that SSSD must be able to minimally query the database in order to retrieve enough structure to convert an username like 'foo' into an LDAP Distinguished Name as 'uid=foo,ou=People,dc=example,dc=com' that LDAP is then able to process.

I understand that SSSD is able to use a 'proxy user' to do just that, so I added such a user in my database, configured SSSD to use it:

ldap_default_bind_dn = cn=autobind,dc=example,dc=com
ldap_default_authtok = verysecretpassword

and, I thought, I added the necessary ACLs to let it just do its work:

olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}to attrs=shadowLastChange by self write by dn="cn=autobind,dc=example,dc=com" read by * none
olcAccess: {2}to * by dn="cn=autobind,dc=example,dc=com" read by * none

Needless to say, it does not work - not only to login, which could very well be SSSD being misconfigured, but the database itself becomes unqueriable returning error 49 (Invalid credentials) even via ldapsearch.

Re-adding by anonymous auth makes it work again; obviously, there is something I'm not getting correctly.

I understand it does not seem like a big deal, apart from that 'anonymous' appearing within my ACLs that irks me very much but does not appear to be able to access anything of importance.

So, my questions are: is it a more secure configuration one where 'anonymous' access is completely removed in the ACLs for my LDAP user database, eventually replacing its necessary functions with those of a proxy user specific to SSSD usage? If not, what would you do to further harden security?

18
0 + 0
Score:1
user1686 avatar Server
fr flag
user1686

one where 'anonymous' access is completely removed in the ACLs for my LDAP user database, eventually replacing its necessary functions with those of a proxy

In this case, no. You can disallow all read/search operations for anonymous connections and have SSSD bind to the machine account before it performs the user search (I use Kerberos for this, SSSD automatically picks up /etc/krb5.keytab), but anonymous clients still need auth rights at minimum.

More specifically, by anonymous auth is necessary in OpenLDAP ACLs for the initial "simple" bind to work, because the connection performing the bind is, still, in anonymous state until after the bind succeeds.

So if you define a "proxy" account, you're just shifting the problem a bit but not actually changing it – an anonymous connection still needs 'auth' rights in order to bind as the proxy account. Or in other words, if you require the client to be already authenticated in order to authenticate, then how is it going to authenticate as the proxy account in the first place?

Also, I wouldn't usually use olcRequires: authc globally for the reason that it prevents reading of the rootDSE entry (null DN), which is how clients discover what authentication mechanisms are available on the server, as well as whether StartTLS is available (if port 636 isn't being used). By preventing anonymous connections from reading attributes on the null DN you're likely to break SASL authentication (e.g. Kerberos/GSSAPI) and limit yourself to password-based 'simple bind' only.

0 + 0
Francesco avatar
jp flag
Francesco
Many thanks, what you tell me matches what others discuss [here](https://stackoverflow.com/questions/61521692/ldap-anonymous-auth) but I wanted to be sure that pulling SSSD into the question would not change the answer. Do you think there's no more possible hardening to be done in such a setup?
0
Reply
user1686 avatar
fr flag
user1686
Denying operations through olcAccess should be sufficient (but if you're doing this via the 'frontend' ACL make sure to grant anonymous read to rootDSE i.e. `dn.exact=""`). It might be useful to put a very restrictive ACL at the top, though, to prevent accidentally opening too much via later ACLs: `to * by anonymous auth by * none break` would stop all further ACL processing for anonymous (so only 'auth' rights are granted), but would fall-through (break) to your main rules for everyone else.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.