UCS <-> AD sync

UCS - Univention Corporate Server
#1

Hello all,

I noticed appearance of errors in synchronization process between UCS and AD.
It happens in few cases:

  1. If the user account is locked

    Unable to sync CN=Test,CN=employees,CN=Users,DC=example,DC=com (GUID: aeef58c0-807e-42a3-9621-8f7161e1f6b0). The object is currently locked.

  2. If user account has some value in ‘Account expiry date’ field.

  3. If primary group of user account is changed and is removed from the list of additional ones, this will break entry in Samba4. This issue can be fixed then by the following steps:

    1. Set back the change of primary group
    2. Save account changes
    3. Change primary group to required one without removing it from the list of additional groups.
    4. Save account changes
    5. Remove old primary group from the ‘Additional groups’ list.
    6. Save account changes

    In this case, ‘System Diagnostic’ tool is able to check Samba4 database and fix all incorrect entries.

I don’t know whether it is bug or just a feature that must be memorized, but the behavior is weird by my opinion.

I will appreciate if someone takes a look and tells me if I am wrong and this situation is a sign of some troubles with my installation of UCS.

Thanks in advance.

#2

Hi,

ad1: object is currently locked.

ad2: This is quiet a very complicated topic, indeed. For some insight you might have a look here.

ad3: For AD you should not change the default primary group to anything else than “domain users”. Loads of links tell this, even though I did not find a MS document telling this. In short: do not change primary group. It will break things!

So far I would guess you installation is fine.

/CV

#3

Hello Christian,

Thank you for your reply!
And thank you for providing the links on useful information. It is really interesting for reading.

However, I still have some questions:

  1. This worked. Thanks again!

  2. In this item I meant the following parameter:
    %D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

As far as I understand, it is not related with password expiry date somehow. If I am wrong, please tell me.
If there is some value in this parameter, the synchronization between UCS and Samba4 goes permanently.

17.10.2018 07:34:31,114 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:34:37,178 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:34:38,273 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:34:44,331 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:34:45,376 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:34:51,433 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:34:52,483 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:34:58,545 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:34:59,591 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:35:05,650 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:35:06,701 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:35:12,763 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:35:13,808 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:35:19,867 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com
17.10.2018 07:35:20,912 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=test,cn=employees,cn=users,dc=example,dc=com
17.10.2018 07:35:26,972 LDAP        (PROCESS): sync from ucs: [          user] [    modify] cn=test,cn=employees,cn=users,DC=example,DC=com

As soon as I clean the value, sync actions complete successfully.

  1. Thank you for the info, but I cannot agree with you. There is a ton of links describing how to change primary group of users in AD. For example, there is an excerpt from book Active Directory Cookbook by Robbie Allen describing instruction how to do that. I don’t think that publishing house O’Reilly released the book with instruction how to harm own infrastructure. If it is not difficult, could you point me to the links mentioning bad circumstances of changing primary group of users? I really want to understand why this action should be avoided. Because, for instance, in our case we create accounts for our clients and don’t want to grant them permissions for access to internal resources as ordinary Domain Users.

Thanks again for your cooperation!

Mastodon