thr3ads.net - Fedora directory users - [Fedora-directory-users] Active Directory PW sync works for console but not user initiated PW changes [Apr 2009]

If this information is useful, please help other people find it:
Share via:

John A. Sullivan III

2009-Apr-27 23:44 UTC

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

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.

Windows Event Viewer is not giving me any useful information.  There is
quite a bit of information in the DS logs but I''m not quite sure what
they are telling me.  I''ll post pertinent snippets below (please pardon
the left truncation but I''m screen scraping):

icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000000010000 into pending list
icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000100010000 into pending list
icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
icationPlugin - ruv_update_ruv: successfully committed csn 49f632dd000100010000
icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000200010000 into pending list
icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
icationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): State:
wait_for_changes -> wait_for_changes
icationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): State:
wait_for_changes -> ready_to_acquire_replica
(this seemed to happen immediately upon password change and not in the normal
five minute sync routine)
.
.
.
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv:
successfully committed csn 49f632dd000200010000
[27/Apr/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
.
.
.
r/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully
committed csn 49f632dd000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f63084000200010000
49f63084
r/2009:18:34:05 -0400] - acquire_replica, supplier RUV is newer
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Trying secure
slapi_ldap_init
NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
binddn = cn=Synch Manager,cn=Users,dc=mycompany,dc=com,  passwd = {DES}tOBO
.
.
.
[27/Apr/2009:18:34:05 -0400] - windows_conn_connect : detected Win2k3 peer
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No linger to cancel on the
connection
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin - windows_acquire_replica
returned success (101)
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> sending_updates
[27/Apr/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Consumer RUV:
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f63084000200010000
49f63084
[27/Apr/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Supplier RUV:
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session start:
anchorcsn=49f63084000200010000
05 -0400] NSMMReplicationPlugin - changelog program -
agmt="cn=a0000-0010(EBC)" (timberline:636): CSN 49f63084000200010000
found, position set for replay
05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1 rec=1
csn=49f632dd000000010000
8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=ssiservices.biz
ldap01->ldap02" (ldap02:636): No linger to cancel on the connection
8:34:05 -0400] - windows_search_entry: recieved 2 messages, 1 entries, 0
references
8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_create_remote_entry: Password is already hashed.  Not
syncing.
**** THIS ENTRY ABOUT NOT SYNCING CERTAINLY JUMPED OUT AT ME BUT I
DON''T KNOW WHAT IT MEANS *****
8:34:05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1
rec=2 csn=49f632dd000100010000
NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
.
.
.
- windows_search_entry: recieved 2 messages, 1 entries, 0 references
NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1 rec=3
csn=49f632dd000200010000
NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
.
.
.
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain starting
[27/Apr/2009:18:34:05 -0400] - windows_search_entry: recieved 2 messages, 1
entries, 0 references
NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
- repl5_inc_result_threadmain: read result for message_id 0
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
.
.
.
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
[27/Apr/2009:18:34:05 -0400] agmt="cn=a0000-0010(EBC)"
(timberline:636) - clcache_load_buffer: rc=-30989
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No more updates to send
(cl5GetNextOperationToReplay)
[27/Apr/2009:18:34:05 -0400] agmt="cn=a0000-0010(EBC)"
(timberline:636) - session end: state=5 load=1 sent=3 skipped=0
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Beginning linger on the
connection
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Linger timeout has expired
on the connection
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 6
[27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: result 3, 0, 0, 6,
(null)
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=ssiservices.biz ldap01->ldap02" (ldap02:636):
replay_update: Consumer successfully sent oper
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Disconnected from the
consumer
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: sending_updates
-> wait_for_changes
[27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> ready_to_acquire_replica
[27/Apr/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
r/2009:18:34:05 -0400] NSMMReplicationPlugin - windows_acquire_replica returned
consumer_was_uptodate (104)
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> wait_for_changes
.
.
.
.
r/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully
committed csn 49f632dd000500010000
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
7
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> wait_for_changes
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> ready_to_acquire_replica
r/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000500010000
49f632dd
r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
r/2009:18:34:05 -0400] - acquire_replica, supplier RUV is newer
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Trying secure
slapi_ldap_init
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
7
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): binddn = cn=SSI
Synchronization Manager,cn=Users,dc=ebc-co,dc=c
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
8
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: result 3, 0, 0, 8, (null)
r/2009:18:34:05 -0400] - windows_conn_connect : detected Win2k3 peer
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No linger to cancel on the
connection
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
8
r/2009:18:34:05 -0400] NSMMReplicationPlugin - windows_acquire_replica returned
success (101)
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> sending_updates
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
8
r/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Consumer RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for message_id
8
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
r/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Supplier RUV:
r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000500010000
49f632dd
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session start:
anchorcsn=49f632dd000200010000
5 -0400] NSMMReplicationPlugin - changelog program -
agmt="cn=a0000-0010(EBC)" (timberline:636): CSN 49f632dd000200010000
found, position set for replay
5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1 rec=1
csn=49f632dd000500010000
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
5 -0400] - windows_search_entry: recieved 2 messages, 1 entries, 0 references
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) -
clcache_load_buffer: rc=-30989
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): No more updates to send (cl5GetNextOperationToReplay)
5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session end:
state=5 load=1 sent=1 skipped=0
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Beginning linger on the connection
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): State: sending_updates -> wait_for_changes
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Linger timeout has expired on the connection
5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Disconnected from the consumer
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
6 -0400] - repl5_inc_result_threadmain: read result for message_id 8
6 -0400] - repl5_inc_waitfor_async_results: 8 8
6 -0400] - repl5_inc_result_threadmain: read result for message_id 8
7 -0400] - repl5_inc_result_threadmain exiting
.
.
.
.
27/Apr/2009:18:34:07 -0400] - repl5_inc_waitfor_async_results: 0 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: result 3, 0, 0, 12,
(null)
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:08 -0400] - repl5_inc_waitfor_async_results: 12 12
[27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
[27/Apr/2009:18:34:09 -0400] - repl5_inc_result_threadmain exiting
[27/Apr/2009:18:34:09 -0400] agmt="cn=ssiservices.biz
ldap01->ldap02" (ldap02:636) - session end: state=5 load=1 sent=1
skipped=0

Does anyone see the problem? How do I get synchronization working when
the users change their own passwords? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

Rich Megginson

2009-Apr-28 01:07 UTC

head link

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

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.> Windows Event Viewer is not giving me any useful information.  There is
> quite a bit of information in the DS logs but I''m not quite sure
what
> they are telling me.  I''ll post pertinent snippets below (please
pardon
> the left truncation but I''m screen scraping):
>
> icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000000010000 into pending list
> icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
> icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000100010000 into pending list
> icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
> icationPlugin - ruv_update_ruv: successfully committed csn
49f632dd000100010000
> icationPlugin - ruv_add_csn_inprogress: successfully inserted csn
49f632dd000200010000 into pending list
> icationPlugin - Purged state information from entry
uid=mlap,ou=Desks,o=a0000-0010,o=Internal,dc=ssiservices,dc=biz up to CSN
49ecf604000200010000
> icationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
State: wait_for_changes -> wait_for_changes
> icationPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636):
State: wait_for_changes -> ready_to_acquire_replica
> (this seemed to happen immediately upon password change and not in the
normal five minute sync routine)
> .
> .
> .
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv:
successfully committed csn 49f632dd000200010000
> [27/Apr/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
> .
> .
> .
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully
committed csn 49f632dd000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f63084000200010000
49f63084
> r/2009:18:34:05 -0400] - acquire_replica, supplier RUV is newer
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Trying secure
slapi_ldap_init
> NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): binddn = cn=Synch Manager,cn=Users,dc=mycompany,dc=com, 
passwd = {DES}tOBO
> .
> .
> .
> [27/Apr/2009:18:34:05 -0400] - windows_conn_connect : detected Win2k3 peer
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No linger to cancel on the
connection
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
windows_acquire_replica returned success (101)
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> sending_updates
> [27/Apr/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Consumer RUV:
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
> tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica
1 ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f63084000200010000
49f63084
> [27/Apr/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Supplier RUV:
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
> tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica
1 ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> 05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session
start: anchorcsn=49f63084000200010000
> 05 -0400] NSMMReplicationPlugin - changelog program -
agmt="cn=a0000-0010(EBC)" (timberline:636): CSN 49f63084000200010000
found, position set for replay
> 05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1
rec=1 csn=49f632dd000000010000
> 8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
> 8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=ssiservices.biz
ldap01->ldap02" (ldap02:636): No linger to cancel on the connection
> 8:34:05 -0400] - windows_search_entry: recieved 2 messages, 1 entries, 0
references
> 8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
> 8:34:05 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_create_remote_entry: Password is already hashed.  Not
syncing.
> **** THIS ENTRY ABOUT NOT SYNCING CERTAINLY JUMPED OUT AT ME BUT I
DON''T KNOW WHAT IT MEANS *****
> 8:34:05 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) -
load=1 rec=2 csn=49f632dd000100010000
> NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
> .
> .
> .
> - windows_search_entry: recieved 2 messages, 1 entries, 0 references
> NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
> agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1 rec=3
csn=49f632dd000200010000
> NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
> .
> .
> .
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain starting
> [27/Apr/2009:18:34:05 -0400] - windows_search_entry: recieved 2 messages, 1
entries, 0 references
> NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
> - repl5_inc_result_threadmain: read result for message_id 0
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
> .
> .
> .
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
> [27/Apr/2009:18:34:05 -0400] agmt="cn=a0000-0010(EBC)"
(timberline:636) - clcache_load_buffer: rc=-30989
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No more updates to send
(cl5GetNextOperationToReplay)
> [27/Apr/2009:18:34:05 -0400] agmt="cn=a0000-0010(EBC)"
(timberline:636) - session end: state=5 load=1 sent=3 skipped=0
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Beginning linger on the
connection
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Linger timeout has expired
on the connection
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 6
> [27/Apr/2009:18:34:05 -0400] - repl5_inc_result_threadmain: result 3, 0, 0,
6, (null)
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=ssiservices.biz ldap01->ldap02" (ldap02:636):
replay_update: Consumer successfully sent oper
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Disconnected from the
consumer
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: sending_updates
-> wait_for_changes
> [27/Apr/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> ready_to_acquire_replica
> [27/Apr/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - windows_acquire_replica
returned consumer_was_uptodate (104)
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> wait_for_changes
> .
> .
> .
> .
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully
committed csn 49f632dd000500010000
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 7
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> wait_for_changes
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State: wait_for_changes
-> ready_to_acquire_replica
> r/2009:18:34:05 -0400] - acquire_replica, supplier RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - supplier: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000500010000
49f632dd
> r/2009:18:34:05 -0400] - acquire_replica, consumer RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer:
{replicageneration} 49e5ebb3000000010000
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - consumer: {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> r/2009:18:34:05 -0400] - acquire_replica, supplier RUV is newer
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): Trying secure
slapi_ldap_init
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 7
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): binddn = cn=SSI
Synchronization Manager,cn=Users,dc=ebc-co,dc=c
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 8
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: result 3, 0, 0, 8,
(null)
> r/2009:18:34:05 -0400] - windows_conn_connect : detected Win2k3 peer
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): No linger to cancel on the
connection
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 8
> r/2009:18:34:05 -0400] NSMMReplicationPlugin - windows_acquire_replica
returned success (101)
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): State:
ready_to_acquire_replica -> sending_updates
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 8
> r/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Consumer RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
> r/2009:18:34:05 -0400] - repl5_inc_result_threadmain: read result for
message_id 8
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replica 1
ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000200010000
49f632dd
> r/2009:18:34:05 -0400] - _cl5PositionCursorForReplay
(agmt="cn=a0000-0010(EBC)" (timberline:636)): Supplier RUV:
> r/2009:18:34:05 -0400] NSMMReplicationPlugin -
agmt="cn=a0000-0010(EBC)" (timberline:636): {replicageneration}
49e5ebb3000000010000
> tionPlugin - agmt="cn=a0000-0010(EBC)" (timberline:636): {replica
1 ldap://ldap01.ssiservices.biz:389} 49e70122000000010000 49f632dd000500010000
49f632dd
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session
start: anchorcsn=49f632dd000200010000
> 5 -0400] NSMMReplicationPlugin - changelog program -
agmt="cn=a0000-0010(EBC)" (timberline:636): CSN 49f632dd000200010000
found, position set for replay
> 5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - load=1
rec=1 csn=49f632dd000500010000
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Looking at modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
(ours,user,not group)
> 5 -0400] - windows_search_entry: recieved 2 messages, 1 entries, 0
references
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): windows_replay_update: Processing modify operation local
dn="uid=mlap,ou=desks,o=a0000-0010,o=internal,dc=ssiservices,dc=biz"
remote dn="<GUID=5b0db1b95d6dca44aaef260be70ee31b>"
> 5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) -
clcache_load_buffer: rc=-30989
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): No more updates to send (cl5GetNextOperationToReplay)
> 5 -0400] agmt="cn=a0000-0010(EBC)" (timberline:636) - session
end: state=5 load=1 sent=1 skipped=0
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Beginning linger on the connection
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): State: sending_updates -> wait_for_changes
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Linger timeout has expired on the connection
> 5 -0400] NSMMReplicationPlugin - agmt="cn=a0000-0010(EBC)"
(timberline:636): Disconnected from the consumer
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 5 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 6 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 6 -0400] - repl5_inc_waitfor_async_results: 8 8
> 6 -0400] - repl5_inc_result_threadmain: read result for message_id 8
> 7 -0400] - repl5_inc_result_threadmain exiting
> .
> .
> .
> .
> 27/Apr/2009:18:34:07 -0400] - repl5_inc_waitfor_async_results: 0 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 0
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: result 3, 0, 0,
12, (null)
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:07 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:08 -0400] - repl5_inc_waitfor_async_results: 12 12
> [27/Apr/2009:18:34:08 -0400] - repl5_inc_result_threadmain: read result for
message_id 12
> [27/Apr/2009:18:34:09 -0400] - repl5_inc_result_threadmain exiting
> [27/Apr/2009:18:34:09 -0400] agmt="cn=ssiservices.biz
ldap01->ldap02" (ldap02:636) - session end: state=5 load=1 sent=1
skipped=0
>
> Does anyone see the problem? How do I get synchronization working when
> the users change their own passwords? Thanks - John
>

John A. Sullivan III

2009-Apr-28 01:17 UTC

head link

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

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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III

2009-Apr-28 01:52 UTC

head link

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

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 -
JohnOops! 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
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

Rich Megginson

2009-Apr-28 14:05 UTC

head link

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

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.

John A. Sullivan III

2009-Apr-28 15:24 UTC

head link

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

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>
Thankfully, we do have audit logging enabled and I do see a difference.
When the admin changes the password, we see:
replace: userPassword
userPassword: {SSHA}7HPjLII39xB1e9thS1El28NXGPiootUlbqhn+g=
and when the user changes the password, we see:
replace: userPassword
userPassword: {crypt}$1$bY3o6YfX$HubSLAtZfgY65mx942Xm41

I am guessing that is what you are referring to.  I''ll take a look and
see if I can figure out how to change pam_ldap to handle it differently.
Would anyone know off-hand what needs to be done? Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

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

John A. Sullivan III

2009-Apr-28 16:19 UTC

head link

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

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
+1 207-985-7880
jsullivan@opensourcedevel.com

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

Rich Megginson

2009-Apr-28 16:24 UTC

head link

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

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
>

Fedora directory users - Apr 2009 - Active Directory PW sync works for console but not user initiated PW changes

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

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

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

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

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

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

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

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