Re: [Fedora-directory-users] Active Directory PW sync works for console but not user initiated PW changes

[John A. Sullivan III]

On Tue, 2009-04-28 at 08:05 -0600, Rich Megginson wrote:
>  John A. Sullivan III wrote:
>  > On Mon, 2009-04-27 at 21:17 -0400, John A. Sullivan III wrote:
>  >   
>  >> On Mon, 2009-04-27 at 19:07 -0600, Rich Megginson wrote:
>  >>     
>  >>> John A. Sullivan III wrote:
>  >>>       
>  >>>> Hello, all.  This is a sequel to the last email on this subject now
> that
>  >>>> we've resolved the shadowLastChange problem.  Fixing that problem
> did
>  >>>> not fix the DS 8.0 / AD password synchronization problem.  To
> reiterate,
>  >>>> the passwords synchronize if the change is made from idm-console or
> from
>  >>>> AD.  But they do not change when our Ubuntu/KDE users change their own
>  >>>> passwords.  It fails when changed from both the KDE password change
>  >>>> interface and using passwd at the command line.
>  >>>>   
>  >>>>         
>  >>> Take a look at the directory server access log - I think the change is 
>  >>> being rejected before it even gets into the replication code, which is 
>  >>> why the error log output below is not too helpful.
>  >>>       
>  >> <snip>
>  >> Ah, I forgot to mention that the password change is successful in DS.
>  >> It just doesn't synchronize.  Would that be the case if there was an
>  >> access failure? I'll enable the access logs and give it a check - John
>  >>     
>  > Oops! I forgot to mention that we had enabled the access logs and
>  > followed them in case the change was being made by some ID other than
>  > the user but the access logs look fine as far as we can tell.  Here is
>  > what we see:
>  >
>  > [27/Apr/2009:21:43:50 -0400] conn=359 fd=66 slot=66 connection from 172.29.32.12 to
> 172.30.10.48
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=0 EXT
> oid="1.3.6.1.4.1.1466.20037" name="startTLS"
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=0 RESULT err=0 tag=120 nentries=0 etime=0
>  > [27/Apr/2009:21:43:50 -0400] conn=359 SSL 256-bit AES
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=1 BIND
> dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" method=128
> version=3
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=1 RESULT err=0 tag=97 nentries=0 etime=0
> dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=b
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=2 MOD
> dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz"
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=2 RESULT err=0 tag=103 nentries=0 etime=0
> csn=49f65f56000000010000
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=3 UNBIND
>  > [27/Apr/2009:21:43:50 -0400] conn=359 op=3 fd=66 closed - U1
>  > [27/Apr/2009:21:43:51 -0400] conn=360 fd=66 slot=66 connection from 172.29.32.12 to
> 172.30.10.48
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=0 EXT
> oid="1.3.6.1.4.1.1466.20037" name="startTLS"
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=0 RESULT err=0 tag=120 nentries=0 etime=0
>  > [27/Apr/2009:21:43:51 -0400] conn=360 SSL 256-bit AES
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=1 BIND
> dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz" method=128
> version=3
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=1 RESULT err=0 tag=97 nentries=0 etime=0
> dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=b
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=2 MOD
> dn="uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz"
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=2 RESULT err=0 tag=103 nentries=0 etime=0
> csn=49f65f57000000010000
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=3 UNBIND
>  > [27/Apr/2009:21:43:51 -0400] conn=360 op=3 fd=66 closed - U1
>  >
>  > I'm assuming this shows success and an entry into the Change log.  Is
>  > that correct? If so, where do we look next to solve this problem? Thanks
>  > - John
>  >   
>  I suppose you could try to enable the audit log - see what attribute it 
>  is modifying, and what value.  nss_ldap/pam_ldap (e.g. the interface 
>  that the passwd command uses) can be configured to store a pre-hashed 
>  password which will not work with winsync.  You must have the clear text 
>  password in order to sync it to AD. 
<snip>
That was it.  Ubuntu defaulted to pam_password md5 in /etc/ldap.conf.  I
changed this to pam_password clear and it worked.  Am I correct to
assume this is safe as long and only as long as I am using tls to
encrypt the communication between the client and the ldap server? Thanks
- John
-- 
John A. Sullivan III
Open Source Development Corporation
[phone]
jsullivan(a)opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society