Syncing users from 389 Directory Server to Active Directory

Hello, I have set up a “toWindows” sync between 389 Directory Server and Active Directory. Everything seems to be working fine except for me needing to manually Re-initialize the agreement if I were to decide to sync a user on 389DS (can be either existing or newly created user) to Active Directory. I have modified the user entry according to what is described inside the RedHat documentation. However, the user does not appear on the AD side of things unless I go on the web console > Replication > Winsync Agreements > Initialize Agreement. I have set my Synchronization Interval to 60 seconds.

Edit:
I have also tried changing the agreement to “both” for bi-directional sync and created a new user inside AD. This new user does appear inside 389DS without needing to anything. So now I’m suspecting that it might be something with the objectClasses/attributes of users inside 389DS which causes the entry to not be detected as a user to be synced to AD? I will add the entry details of the user that is not syncing to AD below the logs I provided.

Edit 2:
I did find the solution; it was because the user that I was trying to sync did not have the correct objectClasses assigned to it because I was creating the users with “Create a new custom entry” inside the web console. If I create the user with “Create a new user” it would add the objectClasses: nsPerson, nsAccount, nsOrgPerson to the entry. After creating a new user this way, the user is synced to AD without manual intervention.

Now I have another question, is there a way for me to change what is detected by Winsync so that it is not limited to the objectClasses nsPerson, nsAccount, nsOrgPerson? I’m not sure if I should create a new post for this question or not.

Here are the logs:

[28/Mar/2025:10:01:49.697218979 +0800] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636)): Consumer RUV:
[28/Mar/2025:10:01:49.698348157 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:01:49.699288494 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:01:49.700197204 +0800] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636)): Supplier RUV:
[28/Mar/2025:10:01:49.700972227 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:01:49.701756702 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:01:49.702652396 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_get_buffer - found thread private buffer cache 0x7f84aa062800
[28/Mar/2025:10:01:49.703615516 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_get_buffer - _pool is 0x7f84c296a560 _pool->pl_busy_lists is 0x7f84aa0ed650 _pool->pl_busy_lists->bl_buffers is 0x7f84aa062800
[28/Mar/2025:10:01:49.704805334 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_initial_anchorcsn - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - (cscb 0 - state 1) - csnPrevMax () csnMax (67e66496003300010000) csnBuf (67e66496003300010000) csnConsumerMax (67e66496003300010000)
[28/Mar/2025:10:01:49.706371306 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_load_buffer - rc=-12797
[28/Mar/2025:10:01:49.708043350 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_return_buffer - session end: state=5 load=0 sent=0 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0
[28/Mar/2025:10:01:49.709446484 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): No changes to send
[28/Mar/2025:10:01:49.711067252 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_start_linger - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Beginning linger on the connection
[28/Mar/2025:10:01:49.711976819 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): State: sending_updates -> wait_for_changes
[28/Mar/2025:10:02:49.743074722 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - periodic_dirsync - Running Dirsync 
[28/Mar/2025:10:02:49.745376463 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - linger_timeout - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Linger timeout has expired on the connection
[28/Mar/2025:10:02:49.746888157 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - close_connection_internal - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Disconnected from the consumer
[28/Mar/2025:10:02:49.748881920 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): State: wait_for_changes -> wait_for_changes
[28/Mar/2025:10:02:49.750700575 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): State: wait_for_changes -> ready_to_acquire_replica
[28/Mar/2025:10:02:49.751948708 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - acquire_replica, supplier RUV:
[28/Mar/2025:10:02:49.753490649 +0800] - DEBUG - NSMMReplicationPlugin - supplier: {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:02:49.754248876 +0800] - DEBUG - NSMMReplicationPlugin - supplier: {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:02:49.755396742 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - acquire_replica, consumer RUV:
[28/Mar/2025:10:02:49.756334492 +0800] - DEBUG - NSMMReplicationPlugin - consumer: {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:02:49.757162794 +0800] - DEBUG - NSMMReplicationPlugin - consumer: {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:02:49.758525512 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_connect - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Trying secure slapi_ldap_init_ext
[28/Mar/2025:10:02:49.761231317 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_connect - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): binddn = CN=389ds-psync,CN=Managed Service Accounts,DC=testad,DC=com,  passwd = {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUmxObUk0WXpjM1l5MHdaVE5rTXpZNA0KTnkxaE9XSmhORGRoT0MwMk1ESmpNV014TUFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRHFKaS8zdGd5a2R6UmRvT2hpQ2pZaQ==}nAHfpV6aMccS/WLxLyxFyQ==
[28/Mar/2025:10:02:49.777272138 +0800] - INFO - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Replication bind with SIMPLE auth resumed
[28/Mar/2025:10:02:49.778623909 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_connect - detected Win2k3 or later peer
[28/Mar/2025:10:02:49.779743074 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_cancel_linger - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): No linger to cancel on the connection
[28/Mar/2025:10:02:49.780522910 +0800] - DEBUG - _csngen_adjust_local_time - gen state before 67e664960036:1743127309:24969:0
[28/Mar/2025:10:02:49.781725520 +0800] - DEBUG - _csngen_adjust_local_time - gen state after 67e664960036:1743127369:24909:0
[28/Mar/2025:10:02:49.783056635 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - windows_acquire_replica returned success (101)
[28/Mar/2025:10:02:49.784057036 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): State: ready_to_acquire_replica -> sending_updates
[28/Mar/2025:10:02:49.785727839 +0800] - DEBUG - csngen_adjust_time - gen state before 67e664960037:1743127369:24909:0
[28/Mar/2025:10:02:49.787065988 +0800] - DEBUG - csngen_adjust_time - gen state after 67e664960037:1743127369:24909:0
[28/Mar/2025:10:02:49.788322218 +0800] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636)): Consumer RUV:
[28/Mar/2025:10:02:49.789609751 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:02:49.790822000 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:02:49.791894704 +0800] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636)): Supplier RUV:
[28/Mar/2025:10:02:49.793075346 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replicageneration} 67dd6660000000010000
[28/Mar/2025:10:02:49.793979484 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): {replica 1 ldap://localhost.localdomain:389} 67dd667e000000010000 67e66496003300010000 67e602da
[28/Mar/2025:10:02:49.794955298 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_get_buffer - found thread private buffer cache 0x7f84aa062800
[28/Mar/2025:10:02:49.796239236 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_get_buffer - _pool is 0x7f84c296a560 _pool->pl_busy_lists is 0x7f84aa0ed650 _pool->pl_busy_lists->bl_buffers is 0x7f84aa062800
[28/Mar/2025:10:02:49.797006610 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_initial_anchorcsn - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - (cscb 0 - state 1) - csnPrevMax () csnMax (67e66496003300010000) csnBuf (67e66496003300010000) csnConsumerMax (67e66496003300010000)
[28/Mar/2025:10:02:49.797665330 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_load_buffer - rc=-12797
[28/Mar/2025:10:02:49.798840917 +0800] - DEBUG - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636) - clcache_return_buffer - session end: state=5 load=0 sent=0 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0
[28/Mar/2025:10:02:49.799867744 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): No changes to send
[28/Mar/2025:10:02:49.801138615 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_conn_start_linger - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): Beginning linger on the connection
[28/Mar/2025:10:02:49.802045049 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=agreement1" (WIN-PK3JVMCSHIO:636): State: sending_updates -> wait_for_changes

Here are the entry details of the user that is not syncing automatically:

Attribute	Value
dn	uid=normaluser4,o=testorg,o=testdomain
ntUserDeleteAccount	true
ntUserCreateNewAccount	true
objectClass	top
objectClass	organizationalPerson
objectClass	inetOrgPerson
objectClass	person
objectClass	ntUser
sn	Normal User4
cn	Normal User4
ntUserDomainId	normaluser4
uid	normaluser4
userPassword	********

I’ve never worked with such a system, but wouldn’t you want one or the other of those attributes, not both?

Hi, thank you for your reply. It seems the name might be a bit misleading. After seeing your reply, I read the Redhat documentation and it says:

If ntUserDeleteAccount has the value true , the corresponding Windows entry be deleted when the Directory Server entry is deleted. Otherwise, the entry remains in Active Directory, but is removed from the Directory Server database if it is deleted in the Directory Server.

1 Like

You can get a list of users with ldapsearch, then loop through the list and modify the attributes with ldapmodify.