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.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-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