> On 30 Jan 2020, at 08:04, Alberto Viana <alberto...@gmail.com> wrote:
>
> Mark
>
> Again (my bad on copy and paste):
>
> dn: cn=AD-DF-DC01,cn=replica,cn=dc\3Dmy\2Cdc\3Ddomain,cn=mapping
> tree,cn=config
> objectClass: top
> objectClass: nsDSWindowsReplicationAgreement
> cn: AD-DF-DC01
> nsDS5ReplicaRoot: dc=my,dc=domain
> description: AD-DF-DC01
> nsDS5ReplicaHost: gti-df-dc01.domain.local
> nsDS5ReplicaPort: 636
> nsDS5ReplicaTransportInfo: LDAPS
> nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP
> 389,OU=APLICACOES,dc=my,dc=domain
> nsds7WindowsReplicaSubtree: dc=my,dc=domain
> nsds7DirectoryReplicaSubtree: dc=my,dc=domain
> nsds7WindowsDomain: RNP
> nsds7NewWinUserSyncEnabled: on
> nsds7NewWinGroupSyncEnabled: on
> nsDS5ReplicaCredentials:
> {AES-RERBNEJDUTBPV1psTXpoak15MDNPRFZrTXpZMg0KTnkxaE56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
> RERBNEJDUTBPV1psTXpoak15MDNPRFZrTXpZMg0KTnkxaE56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQTJRME5QSmRXNWVLQW
> NFaXczVmFXWQ==}F/Jp/zDrXdzGs4/tMIPZZw==
> internalCreatorsName: cn=directory manager
> internalModifiersName: cn=directory manager
> creatorsName: cn=directory manager
> modifiersName: cn=directory manager
> createTimestamp: 20200129214430Z
> modifyTimestamp: 20200129214431Z
> nsds5BeginReplicaRefresh: start
>
>
> How are you changing the password in DS?
> Tried 3 different ways:
> 1. ldapmodify
> 2. password Selfservice (application that we have here)
> 3. Apache directory (LDAP client)
I can't remember if I asked this, but do *other* non-password attributes
replicate correctly from 389 to AD?
>
> Question, the The AD machine (gti-df-dc01.my.domain) is the Domain
> Controller, right?
> The entry looks off, but it might be because you did some find/replace on
> some text. See comments below...
>
> Yes, this is my domain controller(AD). I have 6 domain controllers (2012 R2)
> over here, tried at least in 4.
>
> Another info is that I reconfigured my old server(1.3.7.4) and everything
> works as expect.
>
> So far, I have no idea where the problem is, so I decided that tomorrow I
> will bring up again my old server, (and after that, rebuild my lab
> environment e try to figure it out).
>
> Right now, I'm testing with 3 different versions:
> 1.4.1.14
> 1.4.3.2
> 1.4.2.5 => This one with Fedora packages (not compiled by myself)
>
> None of them is working with same behavior, just the password is not sent
> from 389 to AD. In all versions, attributes are replicated(except password)
> from 389 to AD, and everything is working fine from AD to 389.
>
> Please let me know if need some more info.
>
> Thanks
>
> Alberto Viana
>
> On Wed, Jan 29, 2020 at 5:24 PM Mark Reynolds <mreyno...@redhat.com> wrote:
> How are you changing the password in DS?
>
> Question, the The AD machine (gti-df-dc01.my.domain) is the Domain
> Controller, right?
>
> The entry looks off, but it might be because you did some find/replace on
> some text. See comments below...
>
> On 1/29/20 1:26 PM, Alberto Viana wrote:
>> Mark,
>>
>> here's:
>>
>> dn: cn=AD-DF-DC01,cn=replica,cn=dc\3Drnp\2Cdc\3Dlocal,cn=mapping
>> tree,cn=config
>> objectClass: top
>> objectClass: nsDSowsReplicationAgreement
>> cn: AD-DF-DC01
>> nsDS5ReplicaRoot: dc=rnp,dc=local
>> description: AD-DF-DC01
>> nsDS5ReplicaHost: gti-df-dc01.my.domain
>> nsDS5ReplicaPort: 636
>> nsDS5ReplicaTransportInfo: LDAPS
>> nsDS5ReplicaBindDN: CN=my user on AD,OU=APLICACOES,DC=my,DC=domain
>> nsds7owsReplicaSubtree: dc=my,dc=domain
> This is the wrong attribute, it should be: nsds7WindowsReplicaSubtree
>> nsds7DirectoryReplicaSubtree: dc=my,dc=domain
>> nsds7owsDomain: RNP
> Same here, it should be: nsds7WindowsDomain.
>
> Mark
>
>> nsds7NewWinUserSyncEnabled: on
>> nsds7NewWinGroupSyncEnabled: on
>> nsDS5ReplicaCredentials: {AES-E56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
>>
>> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRFl0ZGNTUGZoV2xEZE
>> 5rMUZNZWp4Rw==}UxxEid4L9eUthSplmxIoy4woEEB4YoihY1++Vv60ibM=
>> internalCreatorsName: cn=directory manager
>> internalModifiersName: cn=directory manager
>>
>> Thanks
>>
>> On Wed, Jan 29, 2020 at 2:27 PM Mark Reynolds <mreyno...@redhat.com> wrote:
>>
>>
>> On 1/29/20 12:17 PM, Alberto Viana wrote:
>>> Mark,
>>>
>>> Already did that twice hehehehe
>>>
>>> Do you think that's about config once all attributes except password are
>>> sync'ed to AD? If it's about config, the log does not suppose to show
>>> something?
>>>
>>> 389 -> AD (all attributes except password)
>>> AD -> 389 (everthing works, including password)
>>>
>>> Tried almost everything over here, without success.
>>>
>>> There's another way to trace it? replication log does not shows me anything
>>> related to it.
>> Replication logging is the only option on the DS side.
>>
>> Can you share your replication agreement from dse.ldif? From what I saw
>> from the command line you set everything correctly, but maybe it didn't
>> write it correctly to the entry. You have to use LDAPS for passwords to
>> sync to AD, and you specified that, but lets confirm what is actually in the
>> agreement.
>>
>> Thanks,
>>
>> Mark
>>
>>>
>>> Thanks
>>>
>>> On Wed, Jan 29, 2020 at 12:35 PM Mark Reynolds <mreyno...@redhat.com> wrote:
>>> Alberto,
>>>
>>> Sorry I'm not sure what is wrong. Please review the documentation and make
>>> sure you have everything setup correctly:
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_the_password_policy-synchronizing_passwords
>>>
>>> HTH,
>>>
>>> Mark
>>>
>>> On 1/29/20 10:22 AM, Alberto Viana wrote:
>>>> Hi Guys,
>>>>
>>>> My messages to list are being moderated (no sure why), trying again
>>>>
>>>> William,
>>>>
>>>> Right, so if you change a password on AD, does it properly change the
>>>> password to 389?
>>>>
>>>> Yes.
>>>>
>>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to change
>>>> the password? What's the exact command you run against 389 to change the
>>>> password?
>>>>
>>>> Tried 3 different ways:
>>>> 1. ldapmodify
>>>> 2. An application that we have here (password selfservice)
>>>> 3. Apache directory studio
>>>>
>>>> The password is always updated locally in 389 but never sent to AD.
>>>>
>>>> And it's seems that not even trying, I'm tracking on event viewer. Another
>>>> thing that when I used to change the password, the passync always
>>>> intercepts the change and tries to send back the (same) password and it's
>>>> not happening.
>>>>
>>>> Please let me know if you anything else.
>>>>
>>>>
>>>>
>>>> On Tue, Jan 28, 2020 at 9:40 PM Alberto Viana <alberto...@gmail.com> wrote:
>>>> William,
>>>>
>>>> Right, so if you change a password on AD, does it properly change the
>>>> password to 389?
>>>>
>>>> Yes.
>>>>
>>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to change
>>>> the password? What's the exact command you run against 389 to change the
>>>> password?
>>>>
>>>> Tried 3 different ways:
>>>> 1. ldapmodify
>>>> 2. An application that we have here (password selfservice)
>>>> 3. Apache directory studio
>>>>
>>>> The password is always updated locally in 389 but never sent to AD.
>>>>
>>>> And it's seems that not even trying, I'm tracking on event viewer. Another
>>>> thing that when I used to change the password, the passync always
>>>> intercepts the change and tries to send back the (same) password and it's
>>>> not happening.
>>>>
>>>> Please let me know if you anything else.
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> On Tue, Jan 28, 2020 at 9:31 PM William Brown <wbr...@suse.de> wrote:
>>>>
>>>>
>>>> > On 29 Jan 2020, at 10:15, Alberto Viana <alberto...@gmail.com> wrote:
>>>> >
>>>> > William,
>>>> >
>>>> > Sorry, my bad, it's not working
>>>> >
>>>> >
>>>> > The problem is the password is never sent to AD and it's just about
>>>> > password, any other replicated attribute that I modify sends the
>>>> > modification to AD normally.
>>>>
>>>>
>>>> Right, so if you change a password on AD, does it properly change the
>>>> password to 389?
>>>>
>>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to change
>>>> the password? What's the exact command you run against 389 to change the
>>>> password?
>>>>
>>>> >
>>>> > When you say "I think that perhaps we need to exclude objectClass=* from
>>>> > notes=U."
>>>>
>>>> No, this is something for the team and I to do, not you :)
>>>>
>>>> >
>>>> > Where should I do that? Do you need further information?
>>>> >
>>>> >
>>>> > Thanks
>>>> >
>>>> > Alberto Viana
>>>> >
>>>> >
>>>> > On Tue, Jan 28, 2020 at 9:09 PM William Brown <wbr...@suse.de> wrote:
>>>> >
>>>> >
>>>> > > On 29 Jan 2020, at 10:01, Alberto Viana <alberto...@gmail.com> wrote:
>>>> > >
>>>> > > WIlliam,
>>>> > >
>>>> > > Thanks, I put in my company's roadmap to think about pay for support,
>>>> >
>>>> > Great!
>>>> >
>>>> > > I found the problem, it's about aci (the user manager replication
>>>> > > permission)
>>>> >
>>>> > Can you please describe the problem and solution more? That way I and
>>>> > others can learn from what you just solved :) It will help many others.
>>>> > Thank you!
>>>> >
>>>> > >
>>>> > > After add permission to read the userpassword field, starts to works.
>>>> > >
>>>> > > Again, Thanks!!!
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Tue, Jan 28, 2020 at 8:58 PM William Brown <wbr...@suse.de> wrote:
>>>> > >
>>>> > >
>>>> > > > On 29 Jan 2020, at 09:24, Alberto Viana <alberto...@gmail.com> wrote:
>>>> > > >
>>>> > > > Hey Guys,
>>>> > > >
>>>> > > > Really lost here, don't know what else look or test, it's not
>>>> > > > working at all :/
>>>> > >
>>>> > > Hey there,
>>>> > >
>>>> > > Remember, the team is distributed around the world - I'm Australian
>>>> > > for example, so sometimes mailing list questions can take 24 hours.
>>>> > > Sometimes personal things go wrong. It's just the annoying nature,
>>>> > > that we will potentially take time to respond :(
>>>> > >
>>>> > > If you do want an SLA, and it's super important to have things fixed,
>>>> > > do consider convincing your business to take a SUSE (SLE) or Red Hat
>>>> > > (RHDS) contract, as there are support teams that can assist, and there
>>>> > > are going to be better response times rather than just us developers
>>>> > > :)
>>>> > >
>>>> > > >
>>>> > > > Any help is appreciated
>>>> > > >
>>>> > > > Thanks
>>>> > > >
>>>> > > > On Tue, Jan 28, 2020 at 3:48 PM Alberto Viana <alberto...@gmail.com>
>>>> > > > wrote:
>>>> > > > Hi Guys,
>>>> > > > 389-Directory/1.4.3.2
>>>> > > >
>>>> > > >
>>>> > > > The password sync from 389 to windows(2012) is not working:
>>>> > >
>>>> > > One of these days I really need to setup winsync at home to really
>>>> > > learn more about it ...
>>>> > >
>>>> > > >
>>>> > > > # dsconf RNP repl-winsync-agmt create --suffix=dc=rnp,dc=local
>>>> > > > --host=gti-df-dc01 --port=636 --conn-protocol=LDAPS
>>>> > > > --bind-dn="CN=my_win_account" --bind-passwd=password
>>>> > > > --win-subtree=dc=my,dc=domain --ds-subtree=dc=my,dc=domain
>>>> > > > --win-domain=RNP --sync-users=on --sync-groups=on --init AD-DF-DC01
>>>> > > >
>>>> > > >
>>>> > > > Double checked everything including the user permissions on windows
>>>> > > > AD side , also checked the windows log and passync log, could not
>>>> > > > found anything related (at least the 389 trying to update my user's
>>>> > > > password or any error)
>>>> > > >
>>>> > > > From windows to 389 works fine.
>>>> > > >
>>>> > > > Attaching the log (in replication debug mode)
>>>> > >
>>>> > > Looking at the log I can see changes happening.
>>>> > >
>>>> > >
>>>> > > This error seems surprising, but shouldn't really cause a problem.
>>>> > >
>>>> > > [28/Jan/2020:15:14:05.423481115 -0300] - ERR - log_result - Internal
>>>> > > unindexed search: source (cn=Multimaster Replication
>>>> > > Plugin,cn=plugins,cn=config) search base="dc=my,dc=domain"
>>>> > > filter="(&(|(objectclass=*)(objectclass=ldapsubentry))(nsUniqueid=0c57800e-050011e8-b998ed08-97c36f4f))"
>>>> > > etime=0.000798288 nentries=1 notes=U details="Partially Unindexed
>>>> > > Filter
>>>> > >
>>>> > > I think that perhaps we need to exclude objectClass=* from notes=U.
>>>> > >
>>>> > >
>>>> > > Anyway, you say it's "not working". I'm going to ask you to describe
>>>> > > what "not working means". Did you change a group on AD and the changes
>>>> > > aren't appearing in 389? Or the other way? Can you be more specific
>>>> > > about what's not working?
>>>> > >
>>>> > > Thanks,
>>>> > >
>>>> > > >
>>>> > > > Don't know what else to look
>>>> > > >
>>>> > > > Thanks.
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> > > > To unsubscribe send an email to
>>>> > > > 389-users-le...@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.fedoraproject.org
>>>> > >
>>>> > > —
>>>> > > Sincerely,
>>>> > >
>>>> > > William Brown
>>>> > >
>>>> > > Senior Software Engineer, 389 Directory Server
>>>> > > SUSE Labs
>>>> > > _______________________________________________
>>>> > > 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> > > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
>>>> > > _______________________________________________
>>>> > > 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> > > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
>>>> >
>>>> > —
>>>> > Sincerely,
>>>> >
>>>> > William Brown
>>>> >
>>>> > Senior Software Engineer, 389 Directory Server
>>>> > SUSE Labs
>>>> > _______________________________________________
>>>> > 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
>>>> > _______________________________________________
>>>> > 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
>>>>
>>>> —
>>>> Sincerely,
>>>>
>>>> William Brown
>>>>
>>>> Senior Software Engineer, 389 Directory Server
>>>> SUSE Labs
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
>>>>
>>>>
>>>> _______________________________________________
>>>> 389-users mailing list --
>>>> 389-users@lists.fedoraproject.org
>>>>
>>>> To unsubscribe send an email to
>>>> 389-users-le...@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.fedoraproject.org
>>> --
>>>
>>> 389 Directory Server Development Team
>>>
>> --
>>
>> 389 Directory Server Development Team
>>
>>
>>
>> _______________________________________________
>> 389-users mailing list --
>> 389-users@lists.fedoraproject.org
>>
>> To unsubscribe send an email to
>> 389-users-le...@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.fedoraproject.org
> --
>
> 389 Directory Server Development Team
>
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
