On 2/19/20 10:45 PM, William Brown wrote:
I'll let Mark answer that, he's more knowledgeable in this area than I am.

I wouldn't say that.  I've only set it up twice :-p  But it always just worked, and a lot of people use it without issue.  So I have no idea what's going on here or how to troubleshoot your env (I'm not a windows guy).   I'll request some lab machines later this week and see if it still works for me.  If it does work then I'll see what the debug logging shows and maybe that will provide some insight into your situation and how we can investigate it further.

Mark

If I find time in the next two weeks I can have a look but no promises about a 
resolution. :)

Thoughts Mark?

On 19 Feb 2020, at 23:01, Alberto Viana <alberto...@gmail.com> wrote:

WIlliam,

Would be helpful if I provide to you guys a test environment? It's not hard for 
me to do that.

I'm really interesting in find out what is going on and some other projects 
over here are depending on my 389 upgrade.

Thanks

Alberto Viana

On Mon, Feb 17, 2020 at 7:21 PM William Brown <wbr...@suse.de> wrote:
Mark, any ideas what to look at next :S

Besides actually trying to setup and reproduce it which I think would be the 
next step ....

On 18 Feb 2020, at 05:45, Alberto Viana <alberto...@gmail.com> wrote:

Hi Guys,

Setup another environment 389 1.4.1.14 + windows 2016, still not working, 
exactly the same behavior.

:/

Cheers,

Alberto Viana

On Wed, Jan 29, 2020 at 8:19 PM Alberto Viana <alberto...@gmail.com> wrote:
William,

Yes, *other* attributes are replicated to AD normally (in all versions that I 
tested).

Thanks.




On Wed, Jan 29, 2020 at 8:16 PM William Brown <wbr...@suse.de> wrote:


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
_______________________________________________
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 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

Reply via email to