Univention Bugzilla – Bug 49903
Enterprise Admins groupType should not be attempted to modify
Last modified: 2019-07-29 21:04:49 CEST
Hi The Group "Enterprise Admins" is a special Group in Active Directory where its Group Type cannot be modified at all. A freshly installed UCS 4.4 will initialize its "Enterprise Admins" Group with univentionGroupType: -2147483640 (Universal Security Group) which is, identical to the valuet of the groupType Attribute in Active Directory. univentionGroupAttribute is used by the UCS AD connector to set the Group Type on the AD side (groupType attribute). If one configures a UCS AD connector between such 2 directories there will be no rejections as they will be identical on both sides. There are however 2 scenarios where this will cause rejected objects: - Old UCS setups that have been upgraded and are lacking modern defaults and where univentionGroupType might be lacking (like in this case) - When users modify the type on the side of UCS (which is actually possible to do) In my case this came up on a UCS domain that is already pretty old and therefore lacks some of the modern things that fresh setups lack, such as a defined univentionGroupAttributes. An absence of the Attribute on the UCS side will also render a rejected object. Suggestions: Make univentionGroupType unchangeable on the UCS side OR do not attempt to modify groupType of this Group in case UCS and AD differ. Environment information: * UCS Environment: UCS 4.4.0 Errata 175, upgraded certainly 3.2 or even older, possibly going back until 2.4 * Windows Environment: Windows Server 2019, Domain/Forest Level: Server 2016 (there is no 2019 function levels)
Is the affected UCS domain running Samba/AD DCs ? If so, we recommend following the migration procedure documented in this article to allow the S4-Connector to actually sync the group objects as this may be relevant von GPO evaluation: https://help.univention.com/t/activation-of-the-synchronisation-of-the-grouptype-attribute-with-the-s4-connector/6451
Hi, and thanks for your answer. > Is the affected UCS domain running Samba/AD DCs ? Depends on the perspective. The UCS master running the AD connector does not. There is however a "downstream" UCS@School member server that runs the S4 connector and is a member server. On that system connector/s4/mapping/group/grouptype is in fact set to false from the olden days. The AD connector was purposely installed on the master as it contains all objects whereas the education (previously) only replicated the data in the OU of the specific school whereas some users would not have been replicated if not in that school OU. (Sadly I don't know the details as to why that is, as it is now) The UCR option was likely (and IMO easily overlooked) when the environment was upgraded to 3.2 as it is in the fine print of the S4 connector changes: "The S4 connector can now synchronises the different group types [...] if the Univention Configuration Registry variable connector/s4/mapping/group/grouptype is set to true. By default this is activated for new UCS 3.2 installations only. All other systems have to be migrated manually [...]" (https://docs.software-univention.de/release-notes-3.2-en.html#idp7740384) IMO linking on how to migrate it properly from the release notes to that guid you mention, would be appreciated. (I know UCS 3.2 is old and EoL for quite some time, nonetheless). Also the formatting of the article on help.univention.com was partially messed up when the original SDB was migrated to the new help site. However if you have only an AD connector without S4 the problem likely remains: Modifying the group Type via UDM Web or CLI remains possible and will cause replication issues with the AD connector as it is. AD doesn't permit modification of said attribute on at least this Group. There are other special groups that are also protected but have other limitations. What about is your stance? Ignore the attribute in the AD connector or make it unchangeable at UDM Web/CLI level like with an OpenLDAP ACLs? -- Mathieu
Thanks for your feedback. > AD doesn't permit modification of said attribute on at least this Group AD has certain rules about the allowed modifications and the nesting of group types. We have implemented these restrictions in UDM: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755692(v=ws.10) I think it would be good to adjust the AD-Connector to not attempt to remove the group type attribute in AD.