John A. Sullivan III wrote:
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
Yes.
- John