[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Issue with Referral+pwdReset
On Friday 20 June 2008 17:51:36 Anthony Porcano wrote:
> I am having a problem that I am hoping the list can help with. When
> using the pwdReset attribute to force a password change the user
> receives the following error when trying to reset the password on SSH
> login:
>
> LDAP password information update failed: Can't contact LDAP server
> passwd: Permission denied
>
> This only occurs for clients using a slave to authenticate, and only
> when changing the password on login in combination with the pwdReset
> attribute. A non-forced password change works fine when a user runs
> the passwd command manually on one of the slave clients. So it seems
> referrals by themselves work OK. Forced password changes using the
> pwdReset attr also work for clients that use the master directly, so
> the issue is specific to slave-authentication+pwdReset+referral.
>
> The debug log on the master shows that it is being reached by the
> client, but slapd refused to perform the action:
> slapd[1079]: conn=1 op=1 BIND
> dn="uid=jschmo,ou=users,dc=example,dc=com" method=128
> slapd[1079]: conn=1 op=1 RESULT tag=97 err=53 text=unauthenticated
> bind (DN with no password) disallowed
>
> The debug log on the slave shows the following error:
> slapd[11339]: conn=5 op=10 MOD
> dn="uid=jschmo,ou=users,dc=example,dc=com"
> slapd[11339]: conn=5 op=10 MOD attr=userPassword
> slapd[11339]: conn=5 op=10 RESULT tag=103 err=10 text=
>
> I've tried searching for information on this, but to date nothing I
> have found resolved the issue. One attempt involved setting an allow
> statement in the master slapd.conf for "bind_anon_dn". This did
> prevent the err=53, but produced another error:
> Jun 19 12:21:12 admin5-ash slapd[30555]: conn=4 op=2 RESULT tag=103
> err=8 text=modifications require authentication
>
> The following applies to both master and slave servers:
>
> OpenLDAP: openldap-2.3.39-3.rhel5 (Buchan's Packages)
> OS: Centos 5.1
>
> For the client I have tried the following configurations:
>
> OpenLDAP: openldap-2.2.13-8 (RH Stock)
> PAM_LDAP: nss_ldap-226-20 (RH Stock)
> OS: RHEL4.6
>
> OpenLDAP version: openldap-2.3.39-3.rhel5 (Buchan's Packages)
> PAM_LDAP: nss_ldap-253-5.el5 (Centos Stock)
> OS: Centos 5.1
>
> If any other information is needed let me know. Thanks to all.
As far as I can tell, this can really only be a bug in pam_ldap.
While I haven't managed to test it myself (the only environment I was able to
test on until now is using load-balanced slaves, and some of the slaves in
the pool aren't replicating operational attributes on the only database that
has ppolicy enabled, and besides that, I also have ITS 5569 which means that
I won't get a successful password change until I log a change to remove
smbk5pwd from the master configuration).
However, if you can change passwords on the master via ldappasswd (the other
tests I did via ldappasswd on a standalone master worked fine, when not
running with smbk5pwd), then any client that changes passwords on the master
should succeed.
So, as far as I can tell, there seems to be a problem in pam_ldap in rebinding
when it has received a specific password policy control.
I will try and test this myself, but it can take a few days to get a
configuration change logged and completed - otherwise I will have to spend
time setting up another environment to test with.
Regards,
Buchan