Bug 47377 - editing LDAP root object not possible due to structural object class change
editing LDAP root object not possible due to structural object class change
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - LDAP directory
UCS 4.3
Other All
: P5 normal (vote)
: UCS 4.4-0-errata
Assigned To: Florian Best
Ole Schwiegert
:
: 46095 (view as bug list)
Depends on: 45842
Blocks: 49018
  Show dependency treegraph
 
Reported: 2018-07-18 22:42 CEST by Moritz Bunkus
Modified: 2024-02-23 13:30 CET (History)
9 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.171
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019030621000178
Bug group (optional): Regression
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Bunkus 2018-07-18 22:42:28 CEST
Trying to edit and save the LDAP root object (e.g. in order to assign policies to the whole LDAP tree) doesn't work due to the following error message:

> The LDAP object could not be saved: LDAP Error Cannot modify object class: structural object class modification from 'domain' to 'univentionDomain' not allowed

This happens both on systems that started out prior to 4.3 and were updated to 4.3 as well as on newly installed 4.3-1 systems.

How to reproduce:

1. Set up a new domain with 4.3-1
2. Login to the UMC
3. Go to "Domain" → "LDAP directory"
4. Edit the root
5. Change something & click "save"

Note that this functionality still works in my 4.2-4 test system. It's a regression in 4.3-x.
Comment 1 Philipp Hahn univentionstaff 2018-10-09 18:14:40 CEST
Again: UCS Technical Training 2018-10-09
Comment 2 Philipp Hahn univentionstaff 2018-10-10 08:50:32 CEST
(In reply to Moritz Bunkus from comment #0)
> Note that this functionality still works in my 4.2-4 test system. It's a
> regression in 4.3-x.

This is caused by git:5a80f66392ae03cde942b054076754dcd0f41417 (Bug #45842)

Previously to that commit "univentionDomain" was added to "objectClasses" only via the _ldap_addlist(), that is when creating a new DC.
The LDAP base on the other hand is created via "ucs/management/univention-ldap/base.ldif" and does NOT contain "oc:univentionDomain"

After that commit "oc:univentionDomain" is ALWAYS added to any "container/dc" object (if it is missing). As it is missing for the LDAP base, the code now tried to add the new STRUCTURAL super class "oc:univentionDomain", which the LDAP server rejects, as is is a type change.

For new installations we should add "oc:univentionDomain" to the base.ldif
For existing installation we need to fix it once by doing a LDAP modify with the Control, which allows changing the structuralObjectClass.
Comment 3 Ingo Steuwer univentionstaff 2018-10-12 14:54:24 CEST
I noticed this in a test system while trying the define a global UCR policy. This is a typical use case in bigger environments and is not possible due to this bug. Therefore I increase the "Who will be affected...".

btw: this is reproducable on https://demo.univention.de
Comment 4 Andreas Peichert univentionstaff 2019-01-17 13:27:41 CET
reported again by a school customer.

(In reply to Philipp Hahn from comment #2)
> For existing installation we need to fix it once by doing a LDAP modify with
> the Control, which allows changing the structuralObjectClass.

Could we provide a workaround for this bug?
Comment 5 Philipp Hahn univentionstaff 2019-01-18 17:29:27 CET
(In reply to Andreas Peichert from comment #4)
> reported again by a school customer.
> 
> (In reply to Philipp Hahn from comment #2)
> > For existing installation we need to fix it once by doing a LDAP modify with
> > the Control, which allows changing the structuralObjectClass.
> 
> Could we provide a workaround for this bug?

See Bug #45842 comment 8: <https://tools.ietf.org/html/draft-zeilenga-ldap-relax-03>

# printf 'dn: %s\nchangetype: modify\nadd: objectClass\nobjectClass: univentionDomain\n-\nadd: sambaDomainName\nsambaDomainName: %s\n-\nadd: sambaSID\nsambaSID: %s\n\n' "$(ucr get ldap/base)" "$(ucr get windows/domain)" "$RANDOM" | ldapmodify -QY EXTERNAL -H ldapi:/// -e relax

# ldapsearch -QLLLo ldif-wrap=no -Y EXTERNAL -H ldapi:/// -b "$(ucr get ldap/base)" -s base objectClass structuralObjectClass
dn: dc=phahn,dc=dev
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: domain
objectClass: univentionBase
objectClass: univentionObject
objectClass: univentionDomain
structuralObjectClass: univentionDomain
Comment 6 Philipp Hahn univentionstaff 2019-01-25 12:57:25 CET
(In reply to Philipp Hahn from comment #5)

objectClass 'sambaDomain' must also be added as it is not added automatically; otherwise UDM does not recognize the option "samba" as set and tries to remove the attribute "sambaDomainName" again, but it is a MUST attribute of "univentionDomain" inherited from "sambaDomain":

cat <<__LDIF__ | ldapmodify -QY EXTERNAL -H ldapi:/// -e relax
dn: $(ucr get ldap/base)
changetype: modify
add: objectClass
objectClass: sambaDomain
objectClass: univentionDomain
-
add: sambaDomainName
sambaDomainName: $(ucr get windows/domain)
-
add: sambaSID
sambaSID: $RANDOM

__LDIF__
Comment 7 Christian Völker univentionstaff 2019-03-11 13:39:51 CET
Am I right the "$RANDOM" will not work in a @school environment? As SID is generated by LDAP instead of Samba (and therefore does not get overwritten).

Could we get the correct SID from the following?
root@master:~# udm settings/sambadomain list
DN: sambaDomainName=EXMPL,cn=samba,dc=exmpl,dc=local
  NextGroupRid: 1000
  NextRid: None
  NextUserRid: 1000
  SID: S-1-5-21-1756983335-327193046-581911268
  badLockoutAttempts: None
  disconnectTime: None
  domainPasswordComplex: 1
  domainPasswordStoreCleartext: 0
  domainPwdProperties: 1
  lockoutDuration: None
  logonToChangePW: None
  maxPasswordAge: None
  minPasswordAge: None
  name: NSTX
  passwordHistory: None
  passwordLength: 8
  refuseMachinePWChange: None
  resetCountMinutes: None
Comment 8 Andreas Peichert univentionstaff 2019-03-14 12:23:48 CET
(In reply to Christian Völker from comment #7)
> Am I right the "$RANDOM" will not work in a @school environment? As SID is
> generated by LDAP instead of Samba (and therefore does not get overwritten).

Yes, for UCS@School please initialize and use $sambaSID instead of $RANDOM (otherwise the S4 connector stops working):

sambaSID=$(udm settings/sambadomain list | awk '/SID/{print $2}')
Comment 9 Florian Best univentionstaff 2019-03-17 21:37:12 CET
Unfortionately I cannot see beyond svn r38 (git:0ae42fe630e9e234601d918a7ff922e64b902cdd) the inital cvs import.
Since then (2007) we have a ldap base without objectClass=univentionDomain and objectClass=sambaDomain.

For the objectClass=sambaDomain in every domain the object: sambaDomainName=$windows_domain,cn=samba,$ldap_base exists.

I see no reason to add a redundancy to the ldap base. It might even cause problems/regressions if there are wrong ldap filter out there.
I think the object classes at the ldap base are unnecessary (and probably unused).

I think you will agree with the following solution:

The UDM handler container/dc has been adjusted so that its "default" option uses the objectClass "univentionBase", which is present for every ldap base.
Currently the handler has no "add" operation, so one cannot create container/dc objects.

I see another reason why customers can't edit their ldap base currently: If they have a ldap base without dc= / objectClass=domain. 
The base ldif adds different object classes to the univentionBase ldap object:
'objectClass: domain'
'objectClass: organization'
'objectClass: organizationalUnit'
'objectClass: organization'
'objectClass: organizationalRole'
'objectClass: country'
At least the unmapping for the "name" property of the ldap base is broken - since more than UCS 4.3!
Opening the ldap base in UMC with such an ldap bases yields:

Request: udm/object/policies (navigation)

  File "%PY2.7%/notifier/threads.py", line 78, in _run
    tmp = self._function()
  File "%PY2.7%/notifier/__init__.py", line 104, in __call__
    return self._function( *tmp, **self._kwargs )
  File "%PY2.7%/univention/management/console/modules/udm/__init__.py", line 1182, in _thread
    policy_obj.clone(obj)
  File "%PY2.7%/univention/admin/handlers/__init__.py", line 3337, in clone
    self.copyIdentifier(referring_object)
  File "%PY2.7%/univention/admin/handlers/__init__.py", line 3325, in copyIdentifier
    self.info[key2] = from_object.info[key]
KeyError: 'name'

Another annoying thing is that every time opening the ldap base a pop up occurs which says that the DNS settings are set to the default values. This is because of a missing self.save() call after modifying values in open(). This has been adjusted as well.

So we see - strictly speaking - the name containers/dc is wrong and should better be containers/base.
(A change I would like to see but won't do now).

univention-directory-manager-modules (14.0.12-11)
beb95c8420e9 | Bug #47377: fix modifying ldap base

univention-directory-manager-modules.yaml
baf9eff8a29d | YAML Bug #47377
Comment 10 Ole Schwiegert univentionstaff 2019-03-20 08:47:17 CET
Advisory&Changelog: OK
Package installs: OK
Jenkins tests do not indicate a problem with the patch: OK
Fix works: OK
  - The ldap base can be modified again
  - No popup regarding DNS anymore

This fix solves the current problem of not being able to edit the ldap base in the UMC and thus addresses the original bug report without modifying the ldap itself. 

If there are valid points towards adding any object classes to the ldap base I would move it into a new bug report/ clone this one.
Comment 11 Florian Best univentionstaff 2019-03-22 13:11:57 CET
*** Bug 46095 has been marked as a duplicate of this bug. ***
Comment 12 Arvid Requate univentionstaff 2019-03-27 13:29:21 CET
<http://errata.software-univention.de/ucs/4.4/19.html>