Thanks for your reply.
This is my configuration on 389ds server.
Please tell me if the attribute of "oneWaySync: fromWindows" is correct.
Now, the new users in AD can't be synced to 389ds every 5 minutes, I have to click
"Initiate full Re-synchronized" manually. I'm stuck for days.
Thanks in advance!
dn: cn=ou1,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description: OU=ou1,OU=Accounts,DC=example,DC=com
cn: ou1
nsds7WindowsReplicaSubtree: OU=ou1,OU=Accounts,DC=example,DC=com
nsds7DirectoryReplicaSubtree: ou=Accounts, dc=example,dc=com
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: off
nsds7WindowsDomain:
example.com
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost:
tc-dc-2.example.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=ad_bind,cn=Users,dc=example,dc=com
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials:
*oneWaySync: fromWindows*
nsds50ruv: {replicageneration} 5d5a75d80000ffff0000
*nsDS5ReplicaUpdateSchedule: 1200-1210 4*
dn: cn=ou2,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description: OU=ou2,OU=Accounts,DC=example,DC=com
cn: ou2
nsds7WindowsReplicaSubtree: OU=ou2,OU=Accounts,DC=example,DC=com
nsds7DirectoryReplicaSubtree: ou=Accounts, dc=example,dc=com
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: off
nsds7WindowsDomain:
example.com
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost:
tc-dc-2.example.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=ad_bind,cn=Users,dc=example,dc=com
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials:
*oneWaySync: fromWindows*
nsds50ruv: {replicageneration} 5d5a75d80000ffff0000
nsDS5ReplicaUpdateSchedule: 1211-1220 4
Sincerely,
--
DaV
On Tue, Aug 27, 2019, at 02:18, Mark Reynolds wrote:
> On 8/23/19 5:38 AM, DaV wrote:
>> Hi all,
>> For OneWaySync, AD to 389ds.
>
>> I have read this guide
>>
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>
>>> Synchronization works two ways. The Directory
Server sends its updates to Active Directory on a configurable schedule, similar to
replication, using the *nsds5replicaupdateschedule* attribute. The Directory Server polls
the Active Directory to check for changes; the frequency that it checks the Active
Directory server is set in the *winSyncInterval* attribute.
>>> By default, the Directory Server update schedule is to always be in sync. The
Active Directory interval is to poll the Active Directory every five minutes.
>>> To change the schedule the Directory Server uses to send its updates to the
Active Directory, edit the nsds5replicaupdateschedule attribute. The schedule is set with
start (SSSS) and end (EEEE) times in the form HHMM, using a 24-hour clock. The days to
schedule sync updates are use ranging from 0 (Sunday) to 6 (Saturday).
>
>> I want to know how to disable the
*nsds5replicaupdateschedule *attribute. Because I just want sync from AD to 389ds.
>
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
You can set it to "`0000-0001 0" to disable synchronizing
according to the link above`
``
>> Thanks in advance!
>
>> Sincerely,
>> --
>> DaV
>
>> On Fri, Aug 23, 2019, at 08:18, DaV wrote:
>> > Hi William,
>> > Thanks for your reply.
>>
>> > Sorry for incorrect
message yesterday.
>> > My windows sync agreement exactly is:
>>
>> > agreement1:
>> > >> DS Host: 389ds:389
>> > > >> Windows Host: dc01.example.com:389
>> > > >> DS Subtree: ou=Users,dc=example,dc=com
>> > > >> Windows Subtree: ou=ou1,OU=Accounts, DC=example,DC=com
>> > > >> Replicated subtree: dc=example,dc=com
>>
>> > agreement2:
>> > >> DS Host: 389ds:389
>> > > >> Windows Host: dc01.example.com:389
>> > > >> DS Subtree: ou=Users,dc=example,dc=com
>> > > >> Windows Subtree: ou=ou2,OU=Accounts, DC=example,DC=com
>> > > >> Replicated subtree: dc=example,dc=com
>>
>>
>> > The windows AD has two OUs, and I want the two
OUs are synced to the
>> > same ou(ou=users,dc=example,dc=com) in 389ds server.
>> > Maybe you would say I can create two same OUs in 389ds first and then
>> > create the sync agreement. But I don't want this because I want all
>> > accounts under the same ou in 389ds(no sub-ou).
>>
>>
>> > I have another question about this issue.
>> > After the two sync agreements created, I create a new user on AD side,
>> > after 5 minutes(default), nothing happens, the account hasn't been
>> > synced to 389ds correctly. I must click the "Initiate full
>> > Re-syncronization" to sync the account info, and then change account
>> > password on AD side manually so that the passsync can sync the
>> > password.
>>
>> > >My concern is
moving an account from ou1 to ou2 and how
>> > > that would work (or break).
>> > Because the digestion is same OU in 389ds, so move an account from ou1
>> > to ou2 on AD side, nothing happens .
>>
>>
>> > Another issue is :
>> > OnewaySync
>> > I want all data flow is AD to 389ds.
>> > I have configured the OnewaySync followed this link
>> >
https://directory.fedoraproject.org/docs/389ds/howto/howto-one-way-active...
>> > for every sync agreement, I add one line
>> > oneWaySync: fromWindows
>>
>>
>> > The error message
/var/log/dirsrv/slapd-INSTANCE/errors like this:
>> > [23/Aug/2019:08:14:58.033989856 +0800] - WARN - NSMMReplicationPlugin -
>> > windows sync - windows_inc_run - agmt="cn=others" (tc-dc-2:389):
>> > Replica has no update vector. It has never been initialized.
>> > [23/Aug/2019:08:15:01.071494645 +0800] - WARN - NSMMReplicationPlugin -
>> > windows sync - windows_inc_run - agmt="cn=others" (tc-dc-2:389):
>> > Replica has no update vector. It has never been initialized.
>>
>> > I don't want the
sync agreement to be bi-directional. So how to resolve
>> > this error message.
>> > Thanks in advance!
>>
>>
>> > Sincerely,
>> > --
>> > DaV
>>
>> > On Fri, Aug 23, 2019,
at 07:38, William Brown wrote:
>> >
>> >
>> > > > On 21 Aug 2019, at 22:10, DaV
<snowfrs(a)gmail.com> wrote:
>> > >
>> > > > Hi guys,
>> > > > Just update for this issue.
>> > >
>> > > > Finally, I
create multi windows sync agreement for each OU to sync the user account.
>> > > > like this:
>> > >
>> > > >> DS
Host: 389ds:389
>> > > >> Windows Host: dc01.example.com:389
>> > > >> DS Subtree: ou=ou1,ou=Users,dc=example,dc=com
>> > > >> Windows Subtree: OU=Accounts, DC=example,DC=com
>> > > >> Replicated subtree: dc=example,dc=com
>> > >
>> > > >> DS
Host: 389ds:389
>> > > >> Windows Host: dc01.example.com:389
>> > > >> DS Subtree: ou=ou2,ou=Users,dc=example,dc=com
>> > > >> Windows Subtree: OU=Accounts, DC=example,DC=com
>> > > >> Replicated subtree: dc=example,dc=com
>> > > > So the user account sync is done.
>> > >
>> > > > For
password sync, now I can't sync user's password with an " Initiate full
Re-syncronization". I must reset all users one-by-one on AD server to sync the
password. This is not convenient.
>> > >
>> > > > Do you have
any advice?
>> > >
>> >
>> > > I think Mark is the person who knows the
most about this. I agree your
>> > > solution isn't really optimal here so I totally get you wanting to
>> > > improve this. My concern is moving an account from ou1 to ou2 and how
>> > > that would work (or break).
>> >
>> >
>> >
>>
>
>> > >
>>
> > > This is the log info:
>> > > >> [21/Aug/2019:08:56:57.876105371 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica
"agmt="cn=chuxun" (tc-dc-2:389)".
>> > > >> [21/Aug/2019:08:56:58.546297794 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_process_total_add -
agmt="cn=chuxun" (tc-dc-2:389) - Cannot replay add operation.
>> > > >> [21/Aug/2019:08:56:58.575112136 +0800] - ERR -
NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=chuxun"
(tc-dc-2:389): Replication bind with SIMPLE auth resumed
>> > > >> [21/Aug/2019:08:56:58.577280706 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=chuxun"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >> [21/Aug/2019:08:56:58.579569199 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=chuxun"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >> [21/Aug/2019:08:56:59.581808252 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=wangxun"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > >
>> > > > Sincerely,
>> > > > --
>> > > > DaV
>> > >
>> > >
>> > >
>>
> >
>> > > > On Tue, Aug
20, 2019, at 09:28, DaV wrote:
>> > > >> Hi all,
>> > > >> I'm using a new 389 directory server on CentOS 7.6 with
389-ds-base.x86_64 (1.3.8.4-15.el7), and I want to sync user and password from Windows
2016 to 389ds one way.
>> > > >> The Synchronization Agreement like this:
>> > > >> DS Host: 389ds:389
>> > > >> Windows Host: dc01.example.com:389
>> > > >> DS Subtree: ou=Users,dc=example,dc=com
>> > > >> Windows Subtree: OU=Accounts, DC=example,DC=com
>> > > >> Replicated subtree: dc=example,dc=com
>> > > >
>> > > >> Here is
my question:
>> > > >> The sync agreement can only sync top-level OU=Accounts,
DC=example, DC=com from Win2016 to 389ds server.
>> > > >> In fact, I have
>> > > >> ou=ou1,ou=accounts,dc=example,dc=com
>> > > >> ou=ou2,ou=accounts,dc=example,dc=com
>> > > >> on Win2016 server.
>> > > >> I want the sync agreement can sync not only the top-level but
also the child ou.
>> > > >
>> > > >> This is
the error log for your reference. Thanks!
>> > > >>> [20/Aug/2019:07:58:40.307031692 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica
"agmt="cn=389ds" (tc-dc-2:389)".
>> > > >>> [20/Aug/2019:07:58:40.309113230 +0800] - INFO -
slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests
>> > > >>> [20/Aug/2019:08:34:21.730939271 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >>> [20/Aug/2019:08:34:21.733526550 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >>> [20/Aug/2019:08:34:24.735819391 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >>> [20/Aug/2019:08:34:27.738228528 +0800] - WARN -
NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds"
(tc-dc-2:389): Replica has no update vector. It has never been initialized.
>> > > >>> [20/Aug/2019:08:34:30.873896680 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica
"agmt="cn=389ds" (tc-dc-2:389)".
>> > > >>> [20/Aug/2019:08:34:33.170822223 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica
"agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries.
>> > > >>> [20/Aug/2019:08:34:33.186359842 +0800] - ERR -
NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds"
(tc-dc-2:389): Replication bind with SIMPLE auth resumed
>> > > >>> [20/Aug/2019:08:47:30.032935119 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica
"agmt="cn=389ds" (tc-dc-2:389)".
>> > > >>> [20/Aug/2019:08:47:31.035850854 +0800] - ERR -
NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica
"agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries.
>> > > >>> [20/Aug/2019:08:47:31.051614890 +0800] - ERR -
NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds"
(tc-dc-2:389): Replication bind with SIMPLE auth resumed
>> > > >>> [20/Aug/2019:08:50:59.533268105 +0800] - WARN -
NSMMReplicationPlugin - prot_stop - Incremental protocol for replica
"agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly.
>> > > >>> [20/Aug/2019:09:01:00.155477769 +0800] - WARN -
NSMMReplicationPlugin - prot_stop - Total protocol for replica
"agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly.
>> > > >
>> > > >
>> > > >> Sincerely,
>> > > >> --
>> > > >> DaV
>> > > >
>> > > >
>> > > >
>>
> >
>> > > >
_______________________________________________
>> > > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> > > > To unsubscribe send an email to
389-users-leave(a)lists.fedoraproject.org
>> > > > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > > > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>> >
>> > > —
>> > > Sincerely,
>> >
>> > > William Brown
>> >
>> > > Senior Software
Engineer, 389 Directory Server
>> > > SUSE Labs
>> > > _______________________________________________
>> > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> > > To unsubscribe send an email to
389-users-leave(a)lists.fedoraproject.org
>> > > Fedora Code of Conduct:
>> > >
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > List Archives:
>> > >
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>> > >
>> > _______________________________________________
>> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> > Fedora Code of Conduct:
>> >
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> >
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>> >
>
>> _______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>
> --
389 Directory Server Development Team