Comment 1 Christina Scheinig 2019-06-18 08:50:02 CEST

If a user created in users is moved to the OU, this will result in the following failed.ldif
---------------------------------------
dn: uid=lcraft,ou=Admin_OU,dc=schein,dc=me
changetype: modify
replace: modifyTimestamp
modifyTimestamp: 20190607213240Z
-
replace: entryCSN
entryCSN: 20190607213240.784445Z#000000#000#000000
-
replace: modifiersName
modifiersName: uid=Administrator,cn=users,dc=schein,dc=me
-
delete: sambaPasswordHistory
-
delete: userPassword
-
delete: krb5Key
-
delete: krb5KDCFlags
-
delete: sambaPwdLastSet
-
delete: sambaNTPassword
-
delete: krb5KeyVersionNumber
-
delete: pwhistory
-

Comment 2 Christina Scheinig 2019-06-18 09:10:28 CEST

And the same happens, if you use an container (CN) instead of an OU
-----------------------------------
07.06.19 23:54:34.470  LDAP        ( PROCESS ) : connecting to ldap://master.schein.me:7389
07.06.19 23:54:34.511  LISTENER    ( PROCESS ) : updating 'cn=ppaul,cn=uid,cn=temporary,cn=univention,dc=schein,dc=me' command a
07.06.19 23:54:34.519  LDAP        ( PROCESS ) : connecting to ldap://localhost:7389
07.06.19 23:54:34.532  LISTENER    ( WARN    ) : replication: Can't contact LDAP server: retrying
07.06.19 23:54:34.532  LISTENER    ( WARN    ) :        machted dn: cn=univention,dc=schein,dc=me
07.06.19 23:54:34.542  LISTENER    ( PROCESS ) : updating 'cn=26622,cn=uidNumber,cn=temporary,cn=univention,dc=schein,dc=me' command a
07.06.19 23:54:34.582  LISTENER    ( PROCESS ) : updating 'cn=26622,cn=gidNumber,cn=temporary,cn=univention,dc=schein,dc=me' command a
07.06.19 23:54:34.586  LISTENER    ( PROCESS ) : updating 'cn=26622,cn=gidNumber,cn=temporary,cn=univention,dc=schein,dc=me' command d
07.06.19 23:54:34.594  LISTENER    ( PROCESS ) : updating 'cn=S-1-5-21-1965273560-2518893881-2166918580-54244,cn=sid,cn=temporary,cn=univention,dc=schein,dc=me' command a
07.06.19 23:54:34.618  LISTENER    ( PROCESS ) : updating 'uid=ppaul,cn=Admin_CN,dc=schein,dc=me' command a
07.06.19 23:54:34.654  LISTENER    ( ERROR   ) : replication: Object class violation; dn="uid=ppaul,cn=Admin_CN,dc=schein,dc=me": object class violation while adding
07.06.19 23:54:34.654  LISTENER    ( ERROR   ) :        additional info: object class 'krb5KDCEntry' requires attribute 'krb5KeyVersionNumber'
07.06.19 23:54:35.219  LISTENER    ( PROCESS ) : samba4-idmap: added entry for S-1-5-21-1965273560-2518893881-2166918580-54244
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=slave.schein.me port=7389 base=dc=schein,dc=me
UNIVENTION_DEBUG_END    : uldap.__open host=slave.schein.me port=7389 base=dc=schein,dc=me
07.06.19 23:54:35.260  LISTENER    ( PROCESS ) : updating 'cn=uidNumber,cn=temporary,cn=univention,dc=schein,dc=me' command m
07.06.19 23:54:35.278  LISTENER    ( PROCESS ) : updating 'cn=26622,cn=uidNumber,cn=temporary,cn=univention,dc=schein,dc=me' command d
07.06.19 23:54:35.283  LISTENER    ( PROCESS ) : updating 'cn=ppaul,cn=uid,cn=temporary,cn=univention,dc=schein,dc=me' command d
07.06.19 23:54:35.289  LISTENER    ( PROCESS ) : updating 'uid=ppaul,cn=Admin_CN,dc=schein,dc=me' command m
07.06.19 23:54:35.300  LISTENER    ( ERROR   ) : replication: Object class violation; dn="uid=ppaul,cn=Admin_CN,dc=schein,dc=me": object class violation while adding
07.06.19 23:54:35.300  LISTENER    ( ERROR   ) :        additional info: object class 'krb5KDCEntry' requires attribute 'krb5KeyVersionNumber'
07.06.19 23:54:35.304  LISTENER    ( PROCESS ) : updating 'uid=ppaul,cn=Admin_CN,dc=schein,dc=me' command m
07.06.19 23:54:35.315  LISTENER    ( ERROR   ) : replication: Object class violation; dn="uid=ppaul,cn=Admin_CN,dc=schein,dc=me": object class violation while adding
07.06.19 23:54:35.315  LISTENER    ( ERROR   ) :        additional info: object class 'krb5KDCEntry' requires attribute 'krb5KeyVersionNumber'
07.06.19 23:54:35.317  LISTENER    ( PROCESS ) : updating 'cn=Domain Users,cn=groups,dc=schein,dc=me' command m

Comment 3 Christina Scheinig 2019-06-18 09:16:31 CEST

Created attachment 10068 [details]
connector-s4.log with the impact

Comment 4 Christina Scheinig 2019-06-18 09:21:07 CEST

I just added the tracebacks from the connector-s4.log to find this issue in Bugzilla
--------------------------------------------------
08.06.2019 00:03:52,218 LDAP        (PROCESS): sync from ucs: [          user] [       add] cn=lcraft,cn=users,DC=schein,DC=me
08.06.2019 00:03:52,228 LDAP        (ERROR  ): sync_from_ucs: traceback during add object: cn=lcraft,cn=users,DC=schein,DC=me
08.06.2019 00:03:52,229 LDAP        (ERROR  ): sync_from_ucs: traceback due to addlist: [('objectClass', ['top', 'user', 'person', 'organizationalPerson']), ('objectSid',
 ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00\xd8\xb1#u9E#\x96\xb4\x8d(\x81\xe2\xd3\x00\x00']), ('sAMAccountName', [u'lcraft']), (u'displayName', [u'lara craft']), 
(u'sn', [u'craft']), (u'givenName', [u'lara'])]
08.06.2019 00:03:52,232 LDAP        (WARNING): sync failed, saved as rejected
        /var/lib/univention-connector/s4/1559943600.247823
08.06.2019 00:03:52,232 LDAP        (WARNING): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 910, in __sync_file_from_ucs
    if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mappe
d_object, pre_mapped_ucs_dn, old_dn, old, new))):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2559, in sync_from_ucs
    self.lo_s4.lo.add_ext_s(compatible_modstring(object['dn']), compatible_addlist(addlist), serverctrls=ctrls)  # FIXME encoding
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 195, in add_ext_s
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 514, in result3
    resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 521, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call
    result = func(*args,**kwargs)
CONSTRAINT_VIOLATION: {'info': '0000202F: ../../ldb_key_value/ldb_kv_index.c:2506: Failed to re-index objectSid in CN=lcraft,CN=Users,DC=schein,DC=me - ../../ldb_key_valu
e/ldb_kv_index.c:2351: unique index violation on objectSid in CN=lcraft,CN=Users,DC=schein,DC=me', 'desc': 'Constraint violation'}

-------------------------------------------------------------------
08.06.2019 00:03:52,386 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=scheinC,CN=Users,DC=schein,DC=me
08.06.2019 00:03:52,392 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=scheinc,cn=users,dc=schein,dc=me
08.06.2019 00:03:52,393 LDAP        (PROCESS): Unable to sync uid=scheinC,cn=users,dc=schein,dc=me (UUID: 88ab1e74-1db5-1039-8ae7-3b610f60339b). The object is currently l
ocked.
08.06.2019 00:03:52,393 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=ppaul,CN=Admin_CN,DC=schein,DC=me
08.06.2019 00:03:52,397 LDAP        (PROCESS): sync to ucs:   [          user] [       add] uid=ppaul,CN=Admin_CN,dc=schein,dc=me
08.06.2019 00:03:52,697 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
08.06.2019 00:03:52,698 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1547, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1295, in add_in_ucs
    res = ucs_object.create(serverctrls=serverctrls, response=response)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 539, in create
    self._ldap_pre_ready()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/users/user.py", line 1890, in _ldap_pre_ready
    self.alloc.append(('uid', univention.admin.allocators.request(self.lo, self.position, 'uid', value=self['username'])))
  File "/usr/lib/pymodules/python2.7/univention/admin/allocators.py", line 196, in request
    return acquireUnique(lo, position, type, value, _type2attr[type], scope=_type2scope[type])
  File "/usr/lib/pymodules/python2.7/univention/admin/allocators.py", line 174, in acquireUnique
    univention.admin.locking.lock(lo, position, type, value, scope=scope)
  File "/usr/lib/pymodules/python2.7/univention/admin/locking.py", line 78, in lock
    raise univention.admin.uexceptions.permissionDenied(_('Can not modify lock time of %r.') % (dn,))
permissionDenied: Can not modify lock time of u'cn=ppaul,cn=uid,cn=temporary,cn=univention,dc=schein,dc=me'.

Comment 5 Arvid Requate 2019-06-18 09:58:00 CEST

What is the expectation here?

A) The OU should not be replicated to school OUs

B) The OU should be replicated to school OUs

When addressing this, we may need a usable option to select this?

Comment 6 Christina Scheinig 2019-06-18 10:20:22 CEST

(In reply to Arvid Requate from comment #5)
> What is the expectation here?
> 
> A) The OU should not be replicated to school OUs
> 
> B) The OU should be replicated to school OUs
> 
> When addressing this, we may need a usable option to select this?

-----------------------------------------------------

The customer expected the members in that OU to be replicated to all slaves.

I called the customer to better understand the need. 
Here is my summary:
- As an organization I want each administrator to have an individual admin account so that the default "administrator" does not have to be used/shared.
- As an organization I would like to give the different administrators different rights according to their roles (e.g. domain admin, school admin, OPSI admin, ...) so that they can only perform tasks for which they are authorized.
- As organization I want the administrators to be automatically synchronized to all school servers so that they can log in there.
- As organization I would like to maintain the administrators in an extra container or organizational unit to keep the overview.
- As an organization I would like to link group policies to the administrators in order to store my own Windows settings. (low prio)

Comment 8 Arvid Requate 2019-06-27 16:54:22 CEST

Created attachment 10092 [details]
Allow-replication-of-objects-below-non-school-OUs-to-school-slaves.patch

Looks like user accounts below a Non-School-OU can only be read partly by a School-PDC and e.g. krb5KeyVersionNumber is one of the attibutes that cannot be read.

The attached patch adds a new ACL-Entry to ucs-school-ldap-acls-master/65ucsschool which grants Read access to objects below Non-School-OUs by School-PDCs.  This can be tested with the following command:

Without the patch:

schoolmaster:~# slapacl \
   -D 'cn=ucs-sc1,cn=dc,cn=server,cn=computers,ou=school1,dc=straeger,dc=loc'
   -b 'uid=admin1,ou=Admin_OU,dc=straeger,dc=loc' krb5KeyVersionNumber/read
read access to krb5KeyVersionNumber: DENIED

with the patch:

read access to krb5KeyVersionNumber: ALLOWED

We should carefully check that this new rule doesn't break the strict separation of schools.

Comment 9 Sönke Schwardt-Krummrich 2019-06-27 17:08:17 CEST

Untested idea for a workaround:
create the group "OUAdmin_OU-DC-Edukativnetz" and add all school slave objects to it.

Comment 10 Christina Scheinig 2019-06-28 13:30:01 CEST

(In reply to Sönke Schwardt-Krummrich from comment #9)
> Untested idea for a workaround:
> create the group "OUAdmin_OU-DC-Edukativnetz" and add all school slave
> objects to it.

I am not sure we just need a workaround. There are two customers who really get in trouble with this. The now use an other way. And there maybe some more customers, who would like to use other OUs despite the school OUs.

The worst part is, that this causes a failed.ldif and the replication to stop.

Comment 11 Arvid Requate 2019-06-28 14:07:59 CEST

Beware: My patch proposal from Comment 8 seems to be wrong. @Florian: Can you comment?

Comment 12 Florian Best 2019-06-28 14:15:01 CEST

(In reply to Arvid Requate from comment #11)
> Beware: My patch proposal from Comment 8 seems to be wrong. @Florian: Can
> you comment?
Yes, sir.

The problem is that filter="(!(objectClass=ucsschoolOrganizationalUnit))" doesn't match on the OU but on the actual objects underneath of the OU.
We need to find a different, more complex ACL :-(

Comment 13 Sönke Schwardt-Krummrich 2019-06-28 14:52:13 CEST

(In reply to Christina Scheinig from comment #10)
> (In reply to Sönke Schwardt-Krummrich from comment #9)
> > Untested idea for a workaround:
> > create the group "OUAdmin_OU-DC-Edukativnetz" and add all school slave
> > objects to it.
> 
> I am not sure we just need a workaround. There are two customers who really
> get in trouble with this. The now use an other way. And there maybe some
> more customers, who would like to use other OUs despite the school OUs.

"Workaround" may not be the right word for it. The group defines in UCS@school which slave is allowed to replicate the contents of the OU. This means that this is exactly what this customer wants without having to interfere with the product via complex ACLs. And it's easy to test: create a group and add all school slaves to it.

The only drawback is that I haven't tried out this "workaround" in such a scenario yet, so minor side effects cannot be ruled out.

> The worst part is, that this causes a failed.ldif and the replication to
> stop.

That's why I'm suggesting this solution, because it's easy to implement and to revert. IMHO the final solution within the product would be similar/identical to the one above.

For me, this is not a discussion about a workaround. The customers already know possible workarounds and are satisfied with them (at least for the time being).
I think it should be a discussion about the solution how we enable customers to create OUs below the root that are not school OUs and automatically replicate them to schools with all subobjects. In two cases this was the expectation of the customers.
Or we prevent this in some way.

Comment 15 Ingo Steuwer 2020-04-17 14:19:28 CEST

I'd suggest to tag this as Feature Request, not a Bug?

Comment 16 Ingo Steuwer 2020-05-25 21:44:03 CEST

(In reply to Ingo Steuwer from comment #15)
> I'd suggest to tag this as Feature Request, not a Bug?

changed it.

Comment 17 Christina Scheinig 2020-05-26 09:08:42 CEST

I don't understand why this is now a feature request? I think a customer should always be able to add an OU, especially if he wants to use GPOs you need an OU instead of a Container.

Now in School it is documented having additional OUs on a server. So we could consider if this is still an impact?

So I change it back to Bug report.

Comment 18 Ingo Steuwer 2020-05-27 14:47:52 CEST

(In reply to Christina Scheinig from comment #17)
> I don't understand why this is now a feature request? I think a customer
> should always be able to add an OU, especially if he wants to use GPOs you
> need an OU instead of a Container.
> 
> Now in School it is documented having additional OUs on a server. So we
> could consider if this is still an impact?

mhm, the documentation ov UCS@school explicitly describes that additional OUs for GPOs are only possible below school OUs.

from https://docs.software-univention.de/ucsschool-handbuch-4.4.html#school:exam:gpo:general

"Grundsätzlich können Gruppenrichtlinien im Samba-Verzeichnisdienst mit Organisationseinheiten (OU) und der LDAP-Basis verknüpft werden. Im UCS@school-Kontext werden jedoch nur Verknüpfungen unterhalb der Schul-OU auch automatisch in das OpenLDAP-Verzeichnis synchronisiert."

Comment 19 Christina Scheinig 2020-05-27 14:50:34 CEST

(In reply to Christina Scheinig from comment #1)
> If a user created in users is moved to the OU, this will result in the
> following failed.ldif
> ---------------------------------------
> dn: uid=lcraft,ou=Admin_OU,dc=schein,dc=me
> changetype: modify
> replace: modifyTimestamp
> modifyTimestamp: 20190607213240Z
> -
> replace: entryCSN
> entryCSN: 20190607213240.784445Z#000000#000#000000
> -
> replace: modifiersName
> modifiersName: uid=Administrator,cn=users,dc=schein,dc=me
> -
> delete: sambaPasswordHistory
> -
> delete: userPassword
> -
> delete: krb5Key
> -
> delete: krb5KDCFlags
> -
> delete: sambaPwdLastSet
> -
> delete: sambaNTPassword
> -
> delete: krb5KeyVersionNumber
> -
> delete: pwhistory
> -

But, I think if there is a possibility, that an failed.ldif is created because of this, this is in my opinion NOT a feature request.
Changed again

Comment 20 Ingo Steuwer 2020-05-27 14:57:17 CEST

(In reply to Christina Scheinig from comment #19)
> But, I think if there is a possibility, that an failed.ldif is created
> because of this, this is in my opinion NOT a feature request.
> Changed again

OK, that's a bug. I changed the summary to make clear what we want to fix here. We should simply / consequently block replicating these OUs.

To be clear: the initial request was to allow replicating users that way. That would be a feature request and should be handled in a separate Bugzilla entry.

Comment 22 Nico Gulden 2020-12-01 12:47:28 CET

There has not been any recent activity on this bug. Has the problem been seen somewhere else as well in the meantime or has its assessment changed?

Comment 23 Christina Scheinig 2020-12-01 13:09:50 CET

(In reply to Nico Gulden from comment #22)
> There has not been any recent activity on this bug. Has the problem been
> seen somewhere else as well in the meantime or has its assessment changed?

I have not added the new ticket, because I had to be sure. Yes  I had this case about tree days ago. 
So this is still an issue, and this was a lot of work to undo all the changes.

Comment 24 Christina Scheinig 2021-02-02 15:47:06 CET

Next customer runs in this issue, and had a failed.ldif on his school slaves. A rejoin of all slaves may solve the problem, but just temporary, till the next modification of a user. 
So still relevant.

Comment 26 Siavash Sefid Rodi 2022-03-18 10:34:41 CET

*** This bug has been marked as a duplicate of bug 51279 ***