Hi Guys, 389-Directory/1.4.3.2
The password sync from 389 to windows(2012) is not working:
# 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)
Don't know what else to look
Thanks.
Hey Guys,
Really lost here, don't know what else look or test, it's not working at all :/
Any help is appreciated
Thanks
On Tue, Jan 28, 2020 at 3:48 PM Alberto Viana albertocrj@gmail.com wrote:
Hi Guys, 389-Directory/1.4.3.2
The password sync from 389 to windows(2012) is not working:
# 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)
Don't know what else to look
Thanks.
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
WIlliam,
Thanks, I put in my company's roadmap to think about pay for support, I found the problem, it's about aci (the user manager replication permission)
After add permission to read the userpassword field, starts to works.
Again, Thanks!!!
On Tue, Jan 28, 2020 at 8:58 PM William Brown wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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....
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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.
When you say "I think that perhaps we need to exclude objectClass=* from notes=U."
Where should I do that? Do you need further information?
Thanks
Alberto Viana
On Tue, Jan 28, 2020 at 9:09 PM William Brown wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 <albertocrj@gmail.com mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > On 29 Jan 2020, at 10:15, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > On 29 Jan 2020, at 10:01, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: > > > Hi Guys, > > > 389-Directory/1.4.3.2 <http://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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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-leave@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....
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.
Thanks
On Wed, Jan 29, 2020 at 12:35 PM Mark Reynolds mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
--
389 Directory Server Development Team
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 <mreynolds@redhat.com mailto:mreynolds@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > On 29 Jan 2020, at 10:15, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > On 29 Jan 2020, at 10:01, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: > > > Hi Guys, > > > 389-Directory/1.4.3.2 <http://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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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
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 nsds7DirectoryReplicaSubtree: dc=my,dc=domain nsds7owsDomain: RNP 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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
--
389 Directory Server Development Team
--
389 Directory Server Development Team
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 <mreynolds@redhat.com mailto:mreynolds@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 <mreynolds@redhat.com <mailto:mreynolds@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > On 29 Jan 2020, at 10:15, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > On 29 Jan 2020, at 10:01, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: > > > Hi Guys, > > > 389-Directory/1.4.3.2 <http://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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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-leave@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....
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)
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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
> > — > 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-leave@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....
> _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
> On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
> > — > 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-leave@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....
> _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de
wrote:
> On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
> > > > — > > 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-leave@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....
> > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to
389-users-leave@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....
> > — > 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-leave@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....
> _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
> On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote: > > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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.... > > — > 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-leave@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.... > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de
wrote:
> On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 <
albertocrj@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-leave@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....
> > > > — > > 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-leave@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....
> > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to
389-users-leave@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....
> > — > 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-leave@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....
> _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
I'll let Mark answer that, he's more knowledgeable in this area than I am. 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 albertocrj@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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 albertocrj@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:
- ldapmodify
- An application that we have here (password selfservice)
- 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 wbrown@suse.de wrote:
> On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote: > > > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote: > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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.... > > > > — > > 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-leave@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.... > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave@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.... > > — > 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-leave@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.... > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 albertocrj@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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht...
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 albertocrj@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 wbrown@suse.de wrote: > > >> On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >> >> >>> On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >>> >>> >>>> On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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.... >>> — >>> 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-leave@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.... >>> _______________________________________________ >>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave@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.... >> — >> 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-leave@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.... >> _______________________________________________ >> 389-users mailing list -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave@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.... > — > 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-leave@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.... > > > _______________________________________________ > 389-users mailing list -- > 389-users@lists.fedoraproject.org > > To unsubscribe send an email to > 389-users-leave@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....
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
On 25 Feb 2020, at 00:02, Mark Reynolds mreynolds@redhat.com wrote:
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
Twice more than I've done it :)
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.
If I get this current block of work I'm doing done soon, maybe I'll set it up also.
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 albertocrj@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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht... > > 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 albertocrj@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 wbrown@suse.de wrote: >> >> >>> On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >>> >>> >>>> On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >>>> >>>> >>>>> On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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.... >>>> — >>>> 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-leave@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.... >>>> _______________________________________________ >>>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>>> To unsubscribe send an email to 389-users-leave@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.... >>> — >>> 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-leave@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.... >>> _______________________________________________ >>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave@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.... >> — >> 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-leave@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.... >> >> >> _______________________________________________ >> 389-users mailing list -- >> 389-users@lists.fedoraproject.org >> >> To unsubscribe send an email to >> 389-users-leave@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.... > -- > > 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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
--
389 Directory Server Development Team
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Alberto,
We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to "on" in cn=config and see if it solves the problem?
Thanks,
Mark
On 2/19/20 8:01 AM, Alberto Viana 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 <wbrown@suse.de mailto:wbrown@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 <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > On 30 Jan 2020, at 08:04, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <mreynolds@redhat.com <mailto:mreynolds@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 <mreynolds@redhat.com <mailto:mreynolds@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 <mreynolds@redhat.com <mailto:mreynolds@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > >>>> > >>>> > On 29 Jan 2020, at 10:15, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > > >>>> > > >>>> > > On 29 Jan 2020, at 10:01, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > > > >>>> > > > >>>> > > > On 29 Jan 2020, at 09:24, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: > >>>> > > > Hi Guys, > >>>> > > > 389-Directory/1.4.3.2 <http://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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > >>>> To unsubscribe send an email to > >>>> 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >> > >> To unsubscribe send an email to > >> 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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-leave@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....
Hi Mark,
Yes, I will try and let you know.
Thanks
On Fri, Feb 28, 2020, 12:39 Mark Reynolds mreynolds@redhat.com wrote:
Alberto,
We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to "on" in cn=config and see if it solves the problem?
Thanks,
Mark On 2/19/20 8:01 AM, Alberto Viana 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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 <
mreynolds@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/ht...
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 <
albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana <
albertocrj@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 <
albertocrj@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-leave@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....
> > > > > > — > > > 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-leave@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....
> > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > > To unsubscribe send an email to
389-users-leave@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....
> > > > — > > 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-leave@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....
> > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to
389-users-leave@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....
> > — > 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-leave@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....
> > > _______________________________________________ > 389-users mailing list -- > 389-users@lists.fedoraproject.org > > To unsubscribe send an email to > 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
--
389 Directory Server Development Team
Mark,
Yes, it solves the problem!!!!!!!!. Can you explain what exactly that config does? It's suppose to be on? Found some old CVE about it and just want to be sure about what I'm doing.
Thanks
Alberto Viana
On Fri, Feb 28, 2020 at 12:39 PM Mark Reynolds mreynolds@redhat.com wrote:
Alberto,
We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to "on" in cn=config and see if it solves the problem?
Thanks,
Mark On 2/19/20 8:01 AM, Alberto Viana 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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 <
mreynolds@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/ht...
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 <
albertocrj@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 wbrown@suse.de
wrote:
> > > > On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de
wrote:
> > > > > > > > > > On 29 Jan 2020, at 09:24, Alberto Viana <
albertocrj@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 <
albertocrj@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-leave@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....
> > > > > > — > > > 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-leave@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....
> > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > > To unsubscribe send an email to
389-users-leave@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....
> > > > — > > 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-leave@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....
> > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to
389-users-leave@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....
> > — > 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-leave@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....
> > > _______________________________________________ > 389-users mailing list -- > 389-users@lists.fedoraproject.org > > To unsubscribe send an email to > 389-users-leave@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....
--
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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
--
389 Directory Server Development Team
On 2/28/20 1:15 PM, Alberto Viana wrote:
Mark,
Yes, it solves the problem!!!!!!!!. Can you explain what exactly that config does? It's suppose to be on? Found some old CVE about it and just want to be sure about what I'm doing.
Well we used to keep this set to "on" but changed the default to "off", because when it's "on" it writes the clear text password in the replication changelog and retro changelog (if enabled). It was considered a security risk to do this by default. The problem here was that it is not documented anywhere that you need to turn it back "on" for winsync to send DS passwords to AD.
We missed this, and I will make sure it gets documented right away in the Admin guide.
Regards,
Mark
Thanks
Alberto Viana
On Fri, Feb 28, 2020 at 12:39 PM Mark Reynolds <mreynolds@redhat.com mailto:mreynolds@redhat.com> wrote:
Alberto, We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to "on" in cn=config and see if it solves the problem? Thanks, Mark On 2/19/20 8:01 AM, Alberto Viana 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 <wbrown@suse.de <mailto:wbrown@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 <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > > > > On 30 Jan 2020, at 08:04, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <mreynolds@redhat.com <mailto:mreynolds@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 <mreynolds@redhat.com <mailto:mreynolds@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 <mreynolds@redhat.com <mailto:mreynolds@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 <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > >>>> > >>>> > On 29 Jan 2020, at 10:15, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > > >>>> > > >>>> > > On 29 Jan 2020, at 10:01, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <wbrown@suse.de <mailto:wbrown@suse.de>> wrote: > >>>> > > > >>>> > > > >>>> > > > On 29 Jan 2020, at 09:24, Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@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 <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: > >>>> > > > Hi Guys, > >>>> > > > 389-Directory/1.4.3.2 <http://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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >>>> > >>>> To unsubscribe send an email to > >>>> 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > >> > >> To unsubscribe send an email to > >> 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@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
On 29 Feb 2020, at 05:45, Mark Reynolds mreynolds@redhat.com wrote:
On 2/28/20 1:15 PM, Alberto Viana wrote:
Mark,
Yes, it solves the problem!!!!!!!!. Can you explain what exactly that config does? It's suppose to be on? Found some old CVE about it and just want to be sure about what I'm doing.
Well we used to keep this set to "on" but changed the default to "off", because when it's "on" it writes the clear text password in the replication changelog and retro changelog (if enabled). It was considered a security risk to do this by default. The problem here was that it is not documented anywhere that you need to turn it back "on" for winsync to send DS passwords to AD.
We missed this, and I will make sure it gets documented right away in the Admin guide.
You're a wizard Mark.
Regards,
Mark
Thanks
Alberto Viana
On Fri, Feb 28, 2020 at 12:39 PM Mark Reynolds mreynolds@redhat.com wrote: Alberto,
We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to "on" in cn=config and see if it solves the problem?
Thanks,
Mark
On 2/19/20 8:01 AM, Alberto Viana 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 wbrown@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 albertocrj@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 albertocrj@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 wbrown@suse.de wrote:
On 30 Jan 2020, at 08:04, Alberto Viana albertocrj@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:
- ldapmodify
- password Selfservice (application that we have here)
- 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 mreynolds@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 mreynolds@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 mreynolds@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/ht... > > 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 albertocrj@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 wbrown@suse.de wrote: >> >> >> > On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >> > >> > >> > > On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote: >> > > >> > > >> > > > On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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.... >> > > >> > > — >> > > 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-leave@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.... >> > > _______________________________________________ >> > > 389-users mailing list -- 389-users@lists.fedoraproject.org >> > > To unsubscribe send an email to 389-users-leave@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.... >> > >> > — >> > 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-leave@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.... >> > _______________________________________________ >> > 389-users mailing list -- 389-users@lists.fedoraproject.org >> > To unsubscribe send an email to 389-users-leave@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.... >> >> — >> 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-leave@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.... >> >> >> _______________________________________________ >> 389-users mailing list -- >> 389-users@lists.fedoraproject.org >> >> To unsubscribe send an email to >> 389-users-leave@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.... > -- > > 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-leave@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....
--
389 Directory Server Development Team
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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....
--
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-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:15, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 10:01, Alberto Viana albertocrj@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 wbrown@suse.de wrote:
On 29 Jan 2020, at 09:24, Alberto Viana albertocrj@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 albertocrj@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-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@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....
— 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-leave@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....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....
— 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-leave@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....
389-users@lists.fedoraproject.org