Univention Bugzilla – Bug 47377
editing LDAP root object not possible due to structural object class change
Last modified: 2024-02-23 13:30:31 CET
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.
Again: UCS Technical Training 2018-10-09
(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.
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
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?
(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
(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__
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
(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}')
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
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.
*** Bug 46095 has been marked as a duplicate of this bug. ***
<http://errata.software-univention.de/ucs/4.4/19.html>