I've installed 389-ds and created a user and a couple groups. I then configured
authconfig on a client to use the
LDAP instance to authenticate the user. I've logged in successfully as that user. All good so far.
Now, I want to turn off anonymous access:
dn: cn=config replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: off
PAM uses anonymous binding by default, I need to put a
/etc/pam_ldap.conf, and create that user in the
LDAP instance. No problems, there.
What I can't find documented anywhere is whether or not I need to give that
binddn "user" some sort of Access Control List to allow it to see any user's passwords.
Question the First: Do I need to configure an ACL for my
I saw one note go by to the effect that
PAM just binds long enough to verify the user exists and the actual authentication attempt is binding as the User Requesting Access (URA). That was a couple sentences in a link I've since lost. So, I can't go back and try to find an expansion on that scenario. If
PAM works that way, it wouldn't need a specific ACL, right?
Question the Second: Does the
binddn just need to be able to search for the URA, or does it need additional privileges?
I shut off anonymous access, as above, and got some interesting things in the access log for my dirsrv instance.
[21/Sep/2014:22:33:45 -0700] conn=111 op=0 UNPROCESSED OPERATION - Anonymous access not allowed [21/Sep/2014:22:33:45 -0700] conn=111 op=0 RESULT err=48 tag=101 nentries=0 etime=0 [21/Sep/2014:22:33:45 -0700] conn=111 op=1 UNPROCESSED OPERATION - Anonymous access not allowed [21/Sep/2014:22:33:45 -0700] conn=111 op=1 RESULT err=48 tag=101 nentries=0 etime=0 [21/Sep/2014:22:33:45 -0700] conn=111 op=2 UNBIND [21/Sep/2014:22:33:45 -0700] conn=111 op=2 fd=65 closed - U1 [21/Sep/2014:22:33:45 -0700] conn=112 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1 [21/Sep/2014:22:33:45 -0700] conn=112 SSL 128-bit AES [21/Sep/2014:22:33:45 -0700] conn=112 op=0 BIND dn="cn=dafydd2277,ou=users,dc=localdomain" method=128 version=3 [21/Sep/2014:22:33:45 -0700] conn=112 op=1 UNBIND [21/Sep/2014:22:33:45 -0700] conn=112 op=1 fd=64 closed - U1 [21/Sep/2014:22:33:45 -0700] conn=112 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=dafydd2277,ou=users,dc=localdomain"
I compared this with login attempts allowing anonymous bind. Those were all
SRCH searches, with no actual bind attempts. Which makes sense.
The next experiment will be to try to change my password with anonymous bind shut off. Will I bind as me, or will PAM attempt an anonymous bind? (I have a guess...)
I'm drifting to the conclusion that PAM's access is solely for searches. Any modifications to a given user are handled through that user's own credentials. This means that I can create a user for PAM to connect with, without worrying about that user's access.
So, I've added an account for PAM to use for searches, and set
/etc/pam_ldap.conf. The bad news is that I'm still getting the
UNPROCESSED OPERATION attempts, and I can't prove that PAM is now using the DN I gave it. (Also, behavior doesn't change with
authconfig. Where's the boundary between PAM and SSS?) More research to follow...