Univention Bugzilla – Bug 32767
Adjust UCS and AD groups
Last modified: 2016-06-02 11:58:39 CEST
We should be able to create and modify the different group types: - security groups - distribution groups http://technet.microsoft.com/en-us/library/cc781446%28v=ws.10%29.aspx We should also be able to modify the group scope: - universal groups - global groups - domain local groups And the special ones - local groups - builtin groups - pseudo groups http://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx http://technet.microsoft.com/en-us/library/cc778060%28v=ws.10%29.aspx http://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/
Currently we use sambaGroupType for some values: - samnbaGroupType 2: Domain Group - samnbaGroupType 3: Local Group - samnbaGroupType 5: Well-Known Group I think we should add a new attribute groupType and sync it directly with the AD attribute, see http://msdn.microsoft.com/en-us/library/cc223142.aspx: GROUP_TYPE_BUILTIN_LOCAL_GROUP: 0x00000001 (local) GROUP_TYPE_ACCOUNT_GROUP: 0x00000002 (global) GROUP_TYPE_RESOURCE_GROUP: 0x00000004 (domain local) GROUP_TYPE_UNIVERSAL_GROUP: 0x00000008 (universal) GROUP_TYPE_APP_BASIC_GROUP: 0x00000010 (not used in AD) GROUP_TYPE_APP_QUERY_GROUP: 0x00000020 (not used in AD) GROUP_TYPE_SECURITY_ENABLED: 0x80000000 (pseudo) Search for all local / builtin groups: '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=1))' Search for all global groups: '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2))' Search for all domain local groups: '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4))' Search for universal groups: '(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8))' If we use that new attribute we should set the sambaGroupType in background.
(In reply to Stefan Gohmann from comment #1) > GROUP_TYPE_SECURITY_ENABLED: 0x80000000 (pseudo) That is wrong. We currently do not have a flag for the pseudo types. In Samba 4 these are different objects (objectClass: foreignSecurityPrincipal), for example: # record 3 dn: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=deadlock19,DC=local objectClass: top objectClass: foreignSecurityPrincipal cn: S-1-5-11 instanceType: 4 whenCreated: 20131001041614.0Z whenChanged: 20131001041614.0Z uSNCreated: 3562 uSNChanged: 3562 showInAdvancedViewOnly: TRUE name: S-1-5-11 objectGUID: 4ff29ed0-70d5-4492-8324-6461d10da69a objectSid: S-1-5-11 objectCategory: CN=Foreign-Security-Principal,CN=Schema,CN=Configuration,DC=de adlock19,DC=local memberOf: CN=Pre-Windows 2000 Compatible Access,CN=Builtin,DC=deadlock19,DC=lo cal memberOf: CN=Users,CN=Builtin,DC=deadlock19,DC=local distinguishedName: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=deadlock19,DC=l ocal
(In reply to Stefan Gohmann from comment #2) > (In reply to Stefan Gohmann from comment #1) > > GROUP_TYPE_SECURITY_ENABLED: 0x80000000 (pseudo) > > That is wrong. We currently do not have a flag for the pseudo types. In > Samba 4 these are different objects (objectClass: foreignSecurityPrincipal), > for example: It could make sense to implement them as a separate group subtype: groups/securityprincipal. In S4 we do have these four objects:: CN=S-1-5-4,CN=ForeignSecurityPrincipals,$base Interactive CN=S-1-5-11,CN=ForeignSecurityPrincipals,$base Authenticated Users CN=S-1-5-9,CN=ForeignSecurityPrincipals,$base Enterprise Domain Controllers CN=S-1-5-17,CN=ForeignSecurityPrincipals,$base This Organization See http://support.microsoft.com/kb/243330 In OpenLDAP we create these five objects to get a gidNumber: - S-1-5-11 Authenticated Users - S-1-1 World Authority - S-1-1-0 Everyone - S-1-0 Null Authority - S-1-0-0 Nobody If we synchronize these objects we should blacklist all objects which are not created by default in S4.
management/univention-ldap: added univentionGroupType r44727
Some more issues: - The UCS@school Slave PDCs don't have the credentials to create the groups. If Samba 4 already runs on the DC Master the groups do exist otherwise the groups must be created in the Slave PDC join script. - The domain local groups can be created in Samba 4 only with the relax control. - The SID handling gets a little bit more complicated. Currently Samba 4 must generate the domain SIDs. But if I add a domain local group without a SID, Samba 4 generates a domain sid and that is incorrect. So the UDM must generate the SID for the domain local group and the connector must use this generated SID. As an alternative we don't allow the generation of domain local groups in UCS.
(In reply to Stefan Gohmann from comment #5) > - The domain local groups can be created in Samba 4 only with the relax > control. > > - The SID handling gets a little bit more complicated. Currently Samba 4 > must generate the domain SIDs. But if I add a domain local group without a > SID, Samba 4 generates a domain sid and that is incorrect. So the UDM must > generate the SID for the domain local group and the connector must use this > generated SID. As an alternative we don't allow the generation of domain > local groups in UCS. These issues have been fixed with r45012.
We don't create pseudo groups because they would break our group handling and we can not synchronize these groups to S4. So we create these pseudo groups still as normal groups in UCS and the S4 connector ignores these pseudo groups.
(In reply to Stefan Gohmann from comment #7) > We don't create pseudo groups because they would break our group handling > and we can not synchronize these groups to S4. So we create these pseudo > groups still as normal groups in UCS and the S4 connector ignores these > pseudo groups. Bug against the UCS manual: Bug #32864
(In reply to Stefan Gohmann from comment #5) > Some more issues: > > - The UCS@school Slave PDCs don't have the credentials to create the groups. > If Samba 4 already runs on the DC Master the groups do exist otherwise the > groups must be created in the Slave PDC join script. Bug #32894
Test cases: - 62_udm-groups/21_group_grouptype - 62_udm-groups/23_group_modify_grouptype
Created attachment 5532 [details] adGroupTypeConversionChecks.patch I think two of the type conversion checks are twisted, as far as I get the information about "Group scope can be converted to…" from http://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx See the (untested) patch proposal attached.
(In reply to Arvid Requate from comment #11) > Created attachment 5532 [details] > adGroupTypeConversionChecks.patch > > I think two of the type conversion checks are twisted, as far as I get the > information about "Group scope can be converted to…" from > http://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx > See the (untested) patch proposal attached. Yes you are right. These are the limitations: 1. Global to universal. This conversion is allowed only if the group that you want to change is not a member of another global scope group. 2. Domain local to universal. This conversion is allowed only if the group that you want to change does not have another domain local group as a member. 3. Universal to global. This conversion is allowed only if the group that you want to change does not have another universal group as a member. 2 and 3 have been implemented in the wrong way. Fixed with a patch similar to yours.
I adjusted the german translation of "univeral group" to "Universelle Gruppe", following the faq-o-matic tutorial cited above. Test Cases: Ok Changelog: Ok
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".