[Fedora-directory-users] Update user passwords with "passwd"

Rich Megginson rmeggins at redhat.com
Mon Jan 26 15:56:29 UTC 2009


Tim Hartmann wrote:
> This is what I see in access from my master:
>
> I don't see any output from error...
>
>
>
> [23/Jan/2009:21:12:08 -0500] conn=1939 fd=67 slot=67 SSL connection from
> 140.247.35.169 to 140.247.30.52
> [23/Jan/2009:21:12:08 -0500] conn=1939 SSL 256-bit AES
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=0 BIND dn="" method=128 version=3
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn=""
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=1 SRCH
> base="dc=dept,dc=school,dc=edu" scope=2
> filter="(&(objectClass=posixAccount)(uidNumber=23030))" attrs="uid
> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
> description objectClass"
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=2 SRCH
> base="dc=dept,dc=school,dc=edu" scope=2
> filter="(&(objectClass=posixAccount)(uid=foo))" attrs="uid userPassword
> uidNumber gidNumber cn homeDirectory loginShell gecos description
> objectClass"
> [23/Jan/2009:21:12:08 -0500] conn=1939 op=2 RESULT err=0 tag=101
> nentries=1 etime=0
> [23/Jan/2009:21:12:08 -0500] conn=1940 fd=68 slot=68 SSL connection from
> 140.247.35.169 to 140.247.30.52
> [23/Jan/2009:21:12:08 -0500] conn=1940 SSL 256-bit AES
> [23/Jan/2009:21:12:08 -0500] conn=1940 op=0 BIND dn="" method=128 version=3
> [23/Jan/2009:21:12:08 -0500] conn=1940 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn=""
> [23/Jan/2009:21:12:08 -0500] conn=1940 op=1 SRCH
> base="dc=dept,dc=school,dc=edu" scope=2 filter="(uid=foo)" attrs=ALL
> [23/Jan/2009:21:12:08 -0500] conn=1940 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
> [23/Jan/2009:21:12:13 -0500] conn=1940 op=2 BIND
> dn="uid=foo,ou=People,dc=dept,dc=school,dc=edu" method=128 version=3
> [23/Jan/2009:21:12:13 -0500] conn=1940 op=2 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=foo,ou=people,dc=dept,dc=school,dc=edu"
> [23/Jan/2009:21:12:13 -0500] conn=1940 op=3 BIND dn="" method=128 version=3
> [23/Jan/2009:21:12:13 -0500] conn=1940 op=3 RESULT err=0 tag=97
> nentries=0 etime=0 dn=""
> [23/Jan/2009:21:12:18 -0500] conn=1939 op=3 SRCH
> base="dc=dept,dc=school,dc=edu" scope=2
> filter="(&(objectClass=posixAccount)(uidNumber=23030))" attrs="uid
> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
> description objectClass"
> [23/Jan/2009:21:12:18 -0500] conn=1939 op=3 RESULT err=0 tag=101
> nentries=1 etime=0
> [23/Jan/2009:21:12:21 -0500] conn=1940 op=4 BIND
> dn="uid=foo,ou=People,dc=dept,dc=school,dc=edu" method=128 version=3
> [23/Jan/2009:21:12:21 -0500] conn=1940 op=4 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=foo,ou=people,dc=dept,dc=school,dc=edu"
> [23/Jan/2009:21:12:21 -0500] conn=1940 op=5 RESULT err=50 tag=103
> nentries=0 etime=0
>   
We're missing the actual request that's causing the problem - there is a 
line for conn=1940 op=5 RESULT, but there is no line that has the actual 
operation e.g. conn=1940 op=5 MOD dn="uid=foo,..." etc.
>
>
>
>
>
>
>
>
>
> George Holbert wrote:
>   
>> Tim Hartmann wrote:
>>     
>>> Hi!
>>>
>>> So I can into yet another pot-hole in the road to LDAP bliss...
>>> We have a root suffix in our directory that stores the basic Posix
>>> attributes including password,  I've been able to configure my client to
>>> use ldap for directory services, and authenticate against my replica's,
>>> so far so good! Then I tried to change my users password .. and thats
>>> where I started getting a bit hung up..
>>>
>>> At first I thought that it was because my replicas weren't sending the
>>> update request/ referrals back to the masters. (We have two masters that
>>> sit behind four consumers)
>>>
>>> Then I decided to change my ldap.conf files to point directly to my
>>> masters.... but I still receaved the same errors "Can't contact LDAP
>>> Server" , which was strange since I can do ldap searches against it all
>>> day, and even bind to the servers to do searches! and Insufficient write
>>> privileges, which made me think that maybe it was an ACI.. but I have
>>> selfwrite enabled for the userPassword attribute...
>>>
>>> Here's the output of my failed attempt to change my user's password
>>> after logging in successfully to the server..
>>>
>>> Changing password for user foo.
>>> Enter login(LDAP) password:
>>> New UNIX password:
>>> Retype new UNIX password:
>>> LDAP password information update failed: Can't contact LDAP server
>>> Insufficient 'write' privilege to the 'userPassword' attribute of entry
>>> 'uid=foo,ou=people,dc=dept,dc=school,dc=edu'.
>>>
>>> passwd: Permission denied
>>>
>>>   
>>>       
>> What do your LDAP server access and error logs show at the time of the
>> attempted password change?
>>
>>
>>     
>>> If anyone has any thought I'd be grateful! I'm pretty perplexed!
>>>
>>>
>>> Best,
>>>
>>> Tim
>>>
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>   
>>>       
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>     
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090126/401d0df8/attachment.bin>


More information about the 389-users mailing list