Bug 37101 - GPO security filter for domain computers doesn't work
GPO security filter for domain computers doesn't work
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0-2-errata
Assigned To: Felix Botner
Arvid Requate
https://bugzilla.samba.org/show_bug.c...
:
Depends on: 37136
Blocks: 37188
  Show dependency treegraph
 
Reported: 2014-11-28 13:44 CET by Tim Petersen
Modified: 2015-07-20 17:52 CEST (History)
3 users (show)

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:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Petersen univentionstaff 2014-11-28 13:44:18 CET
Ticket #2014090221000218

With UCS 4.0 and S4 you cannot use the group "Domain Computers" as a security filter - gpresult doesn't "see" the clients as members of the security group and so the gpo is not executed.
In AD Users- and Groups Tool the membership is correct, samba-tool shows it also.


With a native 2012R2 AD, the same thing works like expected. I only saw one difference: UCS 4.0 with Samba 4 uses the english names, the  AD used "Domänencomputer".
But as this is the same for every other relevent naming I don't think that this could be the part in question...


The group itself is shown correctly in S4, also the well know sid (515) is correct.
Comment 1 Arvid Requate univentionstaff 2014-12-02 11:22:06 CET
I'm assuming this is caused by Bug #37136. We'll have to check.
Comment 2 Stefan Gohmann univentionstaff 2014-12-05 08:03:11 CET
(In reply to Arvid Requate from comment #1)
> I'm assuming this is caused by Bug #37136. We'll have to check.

I don't see why that should be the problem. Is the mapping to the POSIX GID the problem? Can we see something in the Samba debug?
Comment 3 Arvid Requate univentionstaff 2014-12-08 17:35:22 CET
Since we A) don't add new Windows clients to "Domain Computers" and B) apparently not sync the group membership correctly from Samba4 to UCS (Oops, why?), the Client account is not part of the group and thus he will not be able to read the GPO files from the sysvol share when NT ACLs restrict access to that group.

I'm not saying that we shouldn't add the client to "Windows Hosts", but we somehow have to ensure that the AD/Samba group membership of Domain Computers also applies down to the filesystem ACL level. Probably we need do this in the S4-Connector. Maybe we also need to do something in UDM, in case clients are created there initially.
Comment 4 Stefan Gohmann univentionstaff 2014-12-08 20:01:00 CET
(In reply to Arvid Requate from comment #3)
> Since we A) don't add new Windows clients to "Domain Computers" and B)
> apparently not sync the group membership correctly from Samba4 to UCS (Oops,
> why?), the Client account is not part of the group and thus he will not be
> able to read the GPO files from the sysvol share when NT ACLs restrict
> access to that group.

OK, so the problem is that the group is missing on UCS side and thus permissions can't be set.
 
> I'm not saying that we shouldn't add the client to "Windows Hosts", but we
> somehow have to ensure that the AD/Samba group membership of Domain
> Computers also applies down to the filesystem ACL level. Probably we need do
> this in the S4-Connector. Maybe we also need to do something in UDM, in case
> clients are created there initially.

I would suggest that we fix it in the following way:
 1. For new installations:
   - create the group Domain Computers instead of Windows Hosts
   - make the Domain Computers group the default computer group for new windows clients
   - ensure the group is synchronized between OpenLDAP and Samba 4
 2. For existing systems:
   - create a SDB article which describes the transformation from the old behavior to the new one
Comment 5 Felix Botner univentionstaff 2015-04-07 12:41:55 CEST
"Windows Hosts" is used in many packages and created in base.ldif (as well as the univentionDefaultComputerGroup: cn=Windows Hosts,... configuration, so as long as we don't create a new dvd, all new system will have this group and univentionDefaultComputerGroup setting)

* management/univention-ldap (base.ldif, LDAP ACL's)
* management/univention-directory-manager-modules (container/dc)
* services/univention-samba4 (join and setup-s4.sh script)
* services/univention-ad-connector (group/ignorelist)
* services/univention-s4-connector (group/ignorelist)
* services/univention-samba (vampire)
* test ...

Maybe it is easier to put the "Windows Hosts" group as member in the "Domain Computers" group in the samba4 join script (this is already done for the "Authenticated Users" group)
Comment 6 Felix Botner univentionstaff 2015-06-25 14:34:20 CEST
YAML: 2015-05-27-samba.yaml

The problem is not the Domain Computers/Window Hosts membership.

GPO security filtering is based on the groups in Kerberos and with samba the primary group is missing there.

The patch 97_bug37101_primary_gid_in_pac.patch has been added (4.0-0-0-ucs/2:4.2.2-1-errata4.0-2) to fix this problem.

GPO security filtering now also works for a filter that is the primary group (create gpo, set security filter to primary group, reboot the client, and run "gpresult /R /SCOPE COMPUTER")

samba4 ucs-test is OK

The test 51_samba4/59checkPrimaryGroupInPacInfo has been added to check that the primary group is in the kerberos PAC_LOGON_INFO:GROUP_MEMBERSHIP_ARRAY.

I created a samba bug: https://bugzilla.samba.org/show_bug.cgi?id=11362
Comment 7 Arvid Requate univentionstaff 2015-07-14 19:43:00 CEST
Verified:
* Package installable and functional
* Issue is fixed
* ucs-test case works
* Advisory Ok
Comment 8 Janek Walkenhorst univentionstaff 2015-07-20 17:52:15 CEST
<http://errata.univention.de/ucs/4.0/253.html>