Univention Bugzilla – Bug 56929
No changes in AD created groups are possible anymore
Last modified: 2024-02-28 13:17:24 CET
If an app like kopano is installed in an ad membermode domain, it was possible in UCS 4.4-9 to make a group created in AD to a kopano group and enable it via UMC. This is not possible anymore with UCS5. Saving the group you will receive this error message and the group cannot be made to a kopano group. Notification The LDAP object could not be saved: Value may not change: key=mailAddress old=None new=.
*** Bug 56788 has been marked as a duplicate of this bug. ***
Reproducer: # /usr/lib/python3/dist-packages/univention/admincli/admin.py groups/group modify --dn "cn=kopano_test,cn=users,dc=example-ad,dc=org" --set description=foo Traceback (most recent call last): File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 366, in main _doit(arglist, stdout=stdout, stderr=stderr) File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 617, in _doit cli.modify(input, append, remove, parsed_append_options, parsed_remove_options, parsed_options, policy_reference, policy_dereference, ignore_not_exists=ignore_not_exists) File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 646, in modify return self._modify(self.module_name, self.module, self.dn, self.lo, self.position, self.superordinate, *args, **kwargs) File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 802, in _modify dn = object.modify() File "/usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py", line 650, in modify dn = self._modify(modify_childs, ignore_license=ignore_license, response=response, serverctrls=serverctrls) File "/usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py", line 1346, in _modify self.__prevent_ad_property_change() File "/usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py", line 1749, in __prevent_ad_property_change raise univention.admin.uexceptions.valueMayNotChange(_('key=%(key)s old=%(old)s new=%(new)s') % {'key': key, 'old': oldval, 'new': value}, property=key) univention.admin.uexceptions.valueMayNotChange: Value may not change: key=description old=None new=foo. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 964, in <module> main(sys.argv, sys.stdout, sys.stderr) File "/usr/lib/python3/dist-packages/univention/admincli/admin.py", line 372, in main raise OperationFailed(msg) __main__.OperationFailed: Value may not change: key=description old=None new=foo.
It's a regression from git:ae47c0e6c1ecf13c98e32046471573cb17c4d858 Bug #53453. (In reply to Florian Best from comment #2) > Reproducer: > > # /usr/lib/python3/dist-packages/univention/admincli/admin.py groups/group > modify --dn "cn=kopano_test,cn=users,dc=example-ad,dc=org" --set > description=foo Err, I meant: --set kopano-group=1 > univention.admin.uexceptions.valueMayNotChange: Value may not change: > key=description old=None new=foo. Then it becomes: univention.admin.uexceptions.valueMayNotChange: Value may not change: key=mailAddress old=None new=. (Pdb) oldval (Pdb) key 'mailAddress' (Pdb) value '' The problem lies in Bug #44944 - which causes that obj['mailAddress'] sets the default value '', which is different to the old state of `None`. A potential fix is: diff --git management/univention-directory-manager-modules/modules/univention/admin/handlers/groups/group.py management/univention-directory-manager-modules/modules/univention/admin/handlers/groups/group.py index 002e3d1baf..0e14ac6149 100644 --- management/univention-directory-manager-modules/modules/univention/admin/handlers/groups/group.py +++ management/univention-directory-manager-modules/modules/univention/admin/handlers/groups/group.py @@ -462,7 +462,7 @@ class object(univention.admin.handlers.simpleLdap): raise univention.admin.uexceptions.groupNameAlreadyUsed(self['name']) # get lock for mailPrimaryAddress - if self['mailAddress'] and (not self.exists() or self.hasChanged('mailAddress') and self['mailAddress'].lower() != self.oldinfo.get('mailAddress', '').lower()): + if self.get('mailAddress') and (not self.exists() or self.hasChanged('mailAddress') and self['mailAddress'].lower() != self.oldinfo.get('mailAddress', '').lower()): try: self.request_lock('mailPrimaryAddress', self['mailAddress']) except univention.admin.uexceptions.noLock: Maybe we should do this at mulitple places, in users/user is the same case for mailPrimaryAddress. Maybe we can relax the restriction to: diff --git management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py index e15ab5b163..f210194720 100644 --- management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py +++ management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py @@ -1726,6 +1726,8 @@ class simpleLdap(object): if self.descriptions[key].readonly_when_synced: value = self.info.get(key) oldval = self.oldinfo.get(key) + if not oldval and not value: # '' != None != [] + continue if oldval != value: raise univention.admin.uexceptions.valueMayNotChange(_('key=%(key)s old=%(old)s new=%(new)s') % {'key': key, 'old': oldval, 'new': value}, property=key)
The first patch is applied in the customer environment and it works now.
univention-directory-manager-modules.yaml e6d0329f5834 | Bug #56929: Fix groups changes are not sync to AD univention-directory-manager-modules (15.0.25-9) e6d0329f5834 | Bug #56929: Fix groups changes are not sync to AD
Package: univention-directory-manager-modules Version: 15.0.25-9 Branch: ucs_5.0-0 Scope: errata5.0-6
Bug #53453 for UCS 5.0-0-errata groups/group and other modules are checking whether properties are locked. Access to those properties, like `mailAddress` is done via `self[property]`, which sets the default value of that property (due to Bug #44944). We now ignore null-equal values when checking if a property change is blocked for AD. This regression caused the modification operation to fail when an attribute that should not be synchronized with AD had no value assigned in AD and the default value in UCS was different, e.g. string vs. Nonetype.
OK: comparison for null-like values is done when checking if a property might be changed on a AD-synced object OK: code review OK: Jenkins-Tests OK: advisory
<https://errata.software-univention.de/#/?erratum=5.0x974>