On 11 Apr 2022, at 17:41, Tornóci László
<torlasz(a)xenia.sote.hu> wrote:
Hi William,
On 4/11/22 03:37, William Brown wrote:
> No problem mate, happy to help :)
Thanks a lot. I happen to have another question. The LDAP structure that we need to sync
from AD to DS is "bushy", with multilevel, hierarchical OUs. However, according
to the the docs, the AD-DS sync creates and syncs only users or groups and won't
create the OUs. I wonder:
1. Why has been designed the sync program this way?
2. What is the suggested way to solve this problem?
I'm not sure what the historical choices were around not implementing structure
preservation. So long as you create the OUs in DS, they'll be populated from AD. There
is now a setting though to "flatten" the structure to a single level in DS
instead. But the OU creation should be a once-off I'd hope.
Should I simply write a program that syncs the OUs? But then the original AD-DS sync
could do that as well...
Yeah, it wouldn't be that hard. In the future though AD-DS sync will be getting a
major cut back though, it will be from AD to DS only, and much more limited. so keepy that
in mind.
Yours: Laszlo
>> On 8 Apr 2022, at 19:35, Tornóci László <torlasz(a)xenia.sote.hu> wrote:
>>
>> Hi William,
>>
>> On 4/8/22 02:27, William Brown wrote:
>>> I think the best step for you to help diagnose this is to turn up replication
logging.
>>> dsconf localhost config replace nsslapd-errorlog-level=24576
>>
>> thank you, that helped. The problem was that we were missing a subtree-pair
definition.
>>
>> Yours: Laszlo
>>
>>> That will give you more information as a starting place.
>>>> On 5 Apr 2022, at 19:44, Tornóci László <torlasz(a)xenia.sote.hu>
wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>> we have tried to set up a synchronization from AD to our directory
server, but we have a problem. We have RHEL 8.5, 389-ds-base-1.4.3.23-14
>>>>
>>>> We have followed the docs here:
>>>>
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>>>>
>>>>
>>>> We have created this agreement:
>>>>
>>>> dsconf dirsrv_inst repl-winsync-agmt create
--suffix="dc=example,dc=hu" --host="our.ad.server.hu" --port=636
--conn-protocol="LDAPS" --bind-dn="CN=_sync_user,DC=exmaple,DC=local"
--bind-passwd="passwd"
--win-subtree="OU=Felhasználók,DC=example,DC=local"
--ds-subtree="ou=People1,dc=example,dc=hu" --win-domain=example
--one-way-sync=fromWindows --init users-sync
>>>>
>>>> (some data have been masked). The agreement gets accepted, init status is
okay. However, no users get created on the directory server, even after setting the
--sync-users option to "on" in the replication agreement as suggested by the
docs.
>>>>
>>>>
>>>> In AD, there are test users, for example this:
>>>>
>>>>
>>>> dn::
Q049VGVzenQgVXNlciAxLE9VPUZlbGhhc3puw6Fsw7NrLERDPWV4YW1wbGUsREM9bG9jYWw=
>>>> objectClass: top
>>>> objectClass: person
>>>> objectClass: organizationalPerson
>>>> objectClass: user
>>>> cn:: VGVzenQgVXNlciAx
>>>> sn:: UG9ydMOhbA==
>>>> title:: VGVzenRlbMWR
>>>> telephoneNumber: +3612345679
>>>> givenName: User
>>>> distinguishedName::
Q049VGVzenQgVXNlciAxLE9VPUZlbGhhc3puw6Fsw7NrLERDPWV4YW1wbGUsREM9bG9jYWw=
>>>> instanceType: 4
>>>> whenCreated: 20220324073810.0Z
>>>> whenChanged: 20220405072514.0Z
>>>> displayName:: VGVzenQgVXNlciAx
>>>> uSNCreated: 654581
>>>> uSNChanged: 731702
>>>> department: Development
>>>> name:: VGVzenQgVXNlciAx
>>>> objectGUID:: ZYcqiTPzVkCifL7rP8qGlg==
>>>> userAccountControl: 512
>>>> codePage: 0
>>>> countryCode: 0
>>>> pwdLastSet: 132935477968356837
>>>> primaryGroupID: 513
>>>> objectSid:: AQUAAAAAAAUVAAAAGOXkLRHqLIUsJtYXDBAAAA==
>>>> accountExpires: 9223372036854775807
>>>> sAMAccountName: portal.user2
>>>> sAMAccountType: 805306368
>>>> userPrincipalName: portal.user2(a)example.local
>>>> objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
>>>> dSCorePropagationData: 20220405072514.0Z
>>>> dSCorePropagationData: 20220401092451.0Z
>>>> dSCorePropagationData: 20220401092431.0Z
>>>> dSCorePropagationData: 20220401092408.0Z
>>>> dSCorePropagationData: 16010101000417.0Z
>>>> lastLogonTimestamp: 132925820675992048
>>>> mail: portaluser2(a)example.hu
>>>> homePhone: +3687654321
>>>>
>>>> In the error log we get these lines about the replication of this
particular test user:
>>>>
>>>>
>>>> Received entry from dirsync: CN=Teszt User
1,OU=Felhaszn<C3><A1>l<C3><B3>k,OU=Example>
>>>> (test2:637) - Looking for local entry matching AD entry [CN=Teszt
User>
>>>> (test2:637) - Looking for local entry by guid
[65872a8933f35640a27cbeeb3fca8696]
>>>> (test2:637) - Problem looking for guid: -1
>>>> (test2:637) - Looking for local entry by uid [portal.user2]
>>>> (test2:637) - problem looking for username: -1
>>>>
>>>> What could be the problem?
>>>>
>>>> Yours: Laszlo
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>>>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
>>> --
>>> Sincerely,
>>> William Brown
>>> Senior Software Engineer,
>>> Identity and Access Management
>>> SUSE Labs, Australia
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> --
> Sincerely,
> William Brown
> Senior Software Engineer,
> Identity and Access Management
> SUSE Labs, Australia
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia