Noriko,
/I have one question. In your first email, you wrote this, in which
the problem is in 2012R2, but not in 2008R2./
*Sorry, I don't have any 2008 r2 in my lab... I just tested with 2012
r2 and it failed. *
*
*
*Here's my scenarios*
*
*
*My lab environment:*
*389-ds-base 1.3.4.8 + win 2012 r2*
*
*
*OU just in 389 side with users: Full sync failed, log error:*
*
*
*
[17/May/2016:14:19:44 -0300] - Attempting to add entry cn=mais um
teste,ou=teste,ou=RNP,dc=homolog,dc=rnp to AD for local entry
uid=teste.teste,ou=teste,ou=RNP,dc=homolog,dc=rnp
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32
(0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0,
best match of: 'OU=RNP,DC=homolog,DC=rnp' ) for add operation
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636):
windows_process_total_add: Cannot replay add operation.
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the
connection
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed
to obtain data to send to the consumer; LDAP error - 1
[17/May/2016:14:19:44 -0300] - Calling dirsync search request plugin
[17/May/2016:14:19:44 -0300] - Sending dirsync search request
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Cancelling linger on the
connection
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Disconnected from the
consumer
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync -
windows_inc_runs: cancelled dirsync: 7fa660001d60, rval: 1
*
*
*
*OU just in AD side with users: Full sync ok*
*
*
*My production environment:*
*389-ds-base 1.3.2.19 + win 2008 r2 *
*
*
*OU just in 389 side with users: Full sync ok*
*OU just in AD side with users: Full sync ok*
*
*
*
*
*If you need any other info, please let me know.*
*
*
*
*
On Tue, May 17, 2016 at 2:54 PM, Noriko Hosoi <nhosoi(a)redhat.com
<mailto:nhosoi@redhat.com>> wrote:
Thank you for your input, Alberto.
On 05/17/2016 07:38 AM, Alberto Viana wrote:
> Rich,
>
> I'm aware of that, what I'm trying to say is: Is the expected
> behavior to sync do not complete or stop because of one or more
> OUs does not exists in one of the sides (389 or AD)? Is not
> suppose to just generate some error and must go on?
I think so, too.
I have one question. In your first email, you wrote this, in
which the problem is in 2012R2, but not in 2008R2.
> I'm trying to setup a new scenario with 389 and AD 2012 R2 (So
far I'm using with AD 2008 R2 and everything works fine).
Did you have a chance to run "full sync" against 2008R2, as well?
Or just against 2012R2 and it failed?
There should not be a difference there, IMO...
Thanks,
--noriko
> Thanx
>
> On Tue, May 17, 2016 at 11:26 AM, Rich Megginson
> <rmeggins(a)redhat.com <mailto:rmeggins@redhat.com>> wrote:
>
> On 05/17/2016 08:01 AM, Alberto Viana wrote:
>> Noriko,
>>
>> Just to let you know, after I replicated/created the exactly
>> same OU structure on both side, the replication seems to
>> works fine. I'm still not sure that is the expected behavior:
>
> Yes, it is. Winsync does _not_ sync the OU structure - you
> have to set that up manually so that the OU structure in AD
> matches the OU structure in 389.
>
>
>>
>> [17/May/2016:10:56:53 -0300] - windows_conn_connect :
>> detected Win2k3 or later peer
>> [17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows
>> sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No
>> linger to cancel on the connection
>> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
>> gen state before 573b22010001:1463493115:0:6
>> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
>> gen state after 573b232c0000:1463493414:0:6
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
>> sync - windows_acquire_replica returned success (101)
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
>> sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
>> ready_to_acquire_replica -> sending_updates
>> [17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state
>> before 573b232c0001:1463493414:0:6
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin -
>> changelog program - _cl5GetDBFile: found DB object 1b9d570
>> for database
>>
/opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d99000000c80000.db
>>
>>
>> On Tue, May 17, 2016 at 10:08 AM, Alberto Viana
>> <albertocrj(a)gmail.com <mailto:albertocrj@gmail.com>> wrote:
>>
>> Noriko,
>> /
>> /
>> /Did you use the same version of 389-ds-base against AD
>> on 2008 R2 and 2012 R2?/
>> /389-Directory/1.3.4.8 <
http://1.3.4.8> B2016.063.1654/
>> /Please share the output frpm this command line "rpm -q
>> 389-ds-base"?/
>>
>> *I compiled 389 manually once the package in apt repo is
>> too old for me (I'm using ubuntu 14.04 LTS). What
>> specific info do you need?*
>> *ds-base is 1.3.4.8*
>>
>> /Does this error message follow some other detailed
>> error messages? Such as .../
>> /YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP
>> error (ERROR_CODE) ERROR_MESSAGE/
>> /or /
>> /YOUR_AGREEMENT: Received error [%s] when attempting to
>> %s entry [%s]: Please correct the attribute specified in
>> the error message. Refer to the Windows Active
>> Directory docs for more information./
>> /If not, could you enable the replication log level and
>> share the error log with us?/
>>
>> *After enable replication log level:*
>> *[17/May/2016:09:13:18 -0300] - Attempting to add entry
>> cn=Benedito
>> Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp
>> to AD for local entry
>>
uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin -
>> windows sync - agmt="cn=AD - DF-GTI-DC01"
>> (gti-df-dc01:636): Received result code 32 (0000208D:
>> NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data
>> 0, best match of:
>> 'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add
>> operation *
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin -
>> windows sync - agmt="cn=AD - DF-GTI-DC01"
>> (gti-df-dc01:636): windows_process_total_add: Cannot
>> replay add operation.*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin -
>> windows sync - agmt="cn=AD - DF-GTI-DC01"
>> (gti-df-dc01:636): Beginning linger on the connection*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin -
>> windows sync - agmt="cn=AD - DF-GTI-DC01"
>> (gti-df-dc01:636): windows_tot_run: failed to obtain
>> data to send to the consumer; LDAP error - 1*
>> *
>> *
>> *Once I do not have the same OU structure on both side
>> (for testing purposes), I created
>> "**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp"
>> on AD side and started to get error in another OU that I
>> have on 389 side but not in AD.*
>> *
>> *
>> *Is that the expected behavior?*
>> *
>> *
>> *PS: In my production environment we use this strategy
>> that what we dont want to be replicated, just not create
>> the OU structure and works fine. I never found a better
>> way to do that like a "exclude list".*
>>
>>
>> /Could you also share your Windows Sync agreement? Do
>> you happen to have 2 Directory Servers -- one for 2008R2
>> and another for 2012R2, could you provide both?/
>>
>>
>> *Here's my sync agreement:*
>> *
>> *
>> *dn: cn=AD -
>> DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping
>> tree,*
>> * cn=config*
>> *objectClass: top*
>> *objectClass: nsDSWindowsReplicationAgreement*
>> *description: Sync with HOMOLOG DF-GTI-DC01*
>> *cn: AD - DF-GTI-DC01*
>> *nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
>> *nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp*
>> *nsds7NewWinUserSyncEnabled: on*
>> *nsds7NewWinGroupSyncEnabled: on*
>> *nsds7WindowsDomain: homolog.rnp*
>> *nsDS5ReplicaRoot: dc=homolog,dc=rnp*
>> *nsDS5ReplicaHost: gti-df-dc01.homolog.rnp*
>> *nsDS5ReplicaPort: 636*
>> *nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com
>> LDAP 389,OU=APLICACOES*
>> * ,DC=homolog,DC=rnp*
>> *nsDS5ReplicaTransportInfo: SSL*
>> *nsDS5ReplicaBindMethod: SIMPLE*
>> *nsDS5ReplicaCredentials:
>> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG*
>> *
RERBNEJDUXhNVEZoWmpjMVlTMDVaakkyTXpBNA0KTnkwNVl6RmxOV1UwWXkxaVpHWTBaVEkwWkFBQ*
>> *
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ0FNQytucnM5R09Pbm*
>> * IrTGc5Q1BURw==}y3eiY+wIKrDUOvz08JXugA==*
>> *nsds7DirsyncCookie::
>> TVNEUwMAAABTrjoAO7DRAQAAAAAAAAAAWAAAAMJLBQAAAAAAAAAAAAAAA*
>> *
ADCSwUAAAAAAOaoLC8LQH5DrKGkZbG6hSgBAAAAAAAAAAMAAAAAAAAAUFu8Kzif9UKPjH3e1siBWw*
>> *
A5AQAAAAAA5qgsLwtAfkOsoaRlsbqFKMNLBQAAAAAAdqnRrgBktU6JZXBssjxeIesdBQAAAAAA*
>> *nsds5replicareapactive: 0*
>> *nsds5replicaLastUpdateStart: 20160517125737Z*
>> *nsds5replicaLastUpdateEnd: 20160517125737Z*
>> *nsds5replicaChangesSentSinceStartup:*
>> *nsds5replicaLastUpdateStatus: 0 Replica acquired
>> successfully: Incremental upd*
>> * ate started*
>> *nsds5replicaUpdateInProgress: FALSE*
>> *nsds5replicaLastInitStart: 20160517124301Z*
>> *nsds5replicaLastInitEnd: 20160517125236Z*
>> *nsds5replicaLastInitStatus: 1 connection error:
>> operation failure - Total upda*
>> * te aborted*
>> *
>> *
>> *
>> *
>> *In this testing environment, I just have 2012 r2 (I
>> upgraded all DCs to 2012). Right now, I don't have any
>> 2008 r2 to test. *
>> *
>> *
>> *In my production environment I have:*
>> *389-ds-base 1.3.2.19 + Windows 2008 r2*
>>
>> On Mon, May 16, 2016 at 6:02 PM, Noriko Hosoi
>> <nhosoi(a)redhat.com <mailto:nhosoi@redhat.com>> wrote:
>>
>> On 05/16/2016 01:01 PM, Alberto Viana wrote:
>>> I'm trying to setup a new scenario with 389 and AD
>>> 2012 R2 (So far I'm using with AD 2008 R2 and
>>> everything works fine).
>> Did you use the same version of 389-ds-base against
>> AD on 2008 R2 and 2012 R2?
>>> 389-Directory/1.3.4.8 <
http://1.3.4.8> B2016.063.1654
>> Please share the output frpm this command line "rpm
>> -q 389-ds-base"?
>>>
>>> Windows 2012 R2 64bits
>> Both 2008 R2 and 2012 R2 are supported.
>>> :
>>> After configure the AD replication and Initiate a
>>> full sync, it starts to do some entries and I got
>>> the following error:
>>>
>>>
>>> [16/May/2016:16:36:47 -0300] NSMMReplicationPlugin
>>> - windows sync - agmt="cn=AD - DF-GTI-DC01"
>>> (gti-df-dc01:636): windows_process_total_add:
>>> Cannot replay add operation.
>> Does this error message follow some other detailed
>> error messages? Such as ...
>>
>> YOUR_AGREEMENT_NAMEFailed to send %s operation:
>> LDAP error (ERROR_CODE) ERROR_MESSAGE
>>
>> or
>>
>> YOUR_AGREEMENT: Received error [%s] when
>> attempting to %s entry [%s]: Please correct the
>> attribute specified in the error message. Refer
>> to the Windows Active Directory docs for more
>> information.
>>
>> If not, could you enable the replication log level
>> and share the error log with us?
>>>
>>> And after that:
>>>
>>> [16/May/2016:16:36:47 -0300] NSMMReplicationPlugin
>>> - windows sync - agmt="cn=AD - DF-GTI-DC01"
>>> (gti-df-dc01:636): Replica has no update vector. It
>>> has never been initialized.
>>> [16/May/2016:16:36:47 -0300] NSMMReplicationPlugin
>>> - windows sync - agmt="cn=AD - DF-GTI-DC01"
>>> (gti-df-dc01:636): Replica has no update vector. It
>>> has never been initialized.
>>> [16/May/2016:16:36:51 -0300] NSMMReplicationPlugin
>>> - windows sync - agmt="cn=AD - DF-GTI-DC01"
>>> (gti-df-dc01:636): Replica has no update vector. It
>>> has never been initialized.
>>>
>>>
>>> I found a really old ticket that seems to be
>>> related to same error:
>>>
>>>
https://fedorahosted.org/389/ticket/47589
>> This is a regression only affected
>> 389-ds-base-1.3.1.x. So, 1.3.4.x does not need the
>> patch.
>>>
>>> but with win2008r2 and fixed.
>>>
>>> According to this link ->
>>>
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...
>>>
>>> 2012 R2 is supported, is that true?
>> Could you also share your Windows Sync agreement?
>> Do you happen to have 2 Directory Servers -- one for
>> 2008R2 and another for 2012R2, could you provide both?
>>>
>>> Any clues?
>>>
>>>
>>>
>>>
>>> --
>>> 389-users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> <mailto:389-users@lists.fedoraproject.org>
>>>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>>
>>
>> --
>> 389-users mailing list
>> 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>>
>>
>>
>>
>>
>> --
>> 389-users mailing list
>> 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>
>
> --
> 389-users mailing list
> 389-users(a)lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>
>
>
> --
> 389-users mailing list
> 389-users(a)lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org