Bug 32767 - Adjust UCS and AD groups
Adjust UCS and AD groups
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Groups
UCS 3.1
Other Linux
: P5 enhancement (vote)
: UCS 3.2
Assigned To: Stefan Gohmann
Arvid Requate
: interim-3
Depends on:
Blocks: 41417
  Show dependency treegraph
 
Reported: 2013-10-01 08:32 CEST by Stefan Gohmann
Modified: 2016-06-02 11:58 CEST (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
adGroupTypeConversionChecks.patch (5.18 KB, patch)
2013-10-24 18:22 CEST, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2013-10-01 08:32:26 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/
Comment 1 Stefan Gohmann univentionstaff 2013-10-01 09:09:01 CEST
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.
Comment 2 Stefan Gohmann univentionstaff 2013-10-01 10:56:49 CEST
(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
Comment 3 Stefan Gohmann univentionstaff 2013-10-01 11:45:22 CEST
(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.
Comment 4 Stefan Gohmann univentionstaff 2013-10-04 11:36:37 CEST
management/univention-ldap: added univentionGroupType r44727
Comment 5 Stefan Gohmann univentionstaff 2013-10-05 21:31:02 CEST
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.
Comment 6 Stefan Gohmann univentionstaff 2013-10-12 22:07:26 CEST
(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.
Comment 7 Stefan Gohmann univentionstaff 2013-10-14 22:01:28 CEST
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.
Comment 8 Stefan Gohmann univentionstaff 2013-10-14 22:32:36 CEST
(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
Comment 9 Stefan Gohmann univentionstaff 2013-10-17 23:56:29 CEST
(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
Comment 10 Stefan Gohmann univentionstaff 2013-10-18 00:03:15 CEST
Test cases: 
 - 62_udm-groups/21_group_grouptype
 - 62_udm-groups/23_group_modify_grouptype
Comment 11 Arvid Requate univentionstaff 2013-10-24 18:22:39 CEST
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.
Comment 12 Stefan Gohmann univentionstaff 2013-10-24 22:05:34 CEST
(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.
Comment 13 Arvid Requate univentionstaff 2013-10-28 19:48:30 CET
I adjusted the german translation of "univeral group" to "Universelle Gruppe", following the faq-o-matic tutorial cited above.

Test Cases: Ok
Changelog: Ok
Comment 14 Stefan Gohmann univentionstaff 2013-11-19 06:44:25 CET
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".