From Fedora Project Wiki

< Changes

Revision as of 20:18, 31 March 2014 by Yelley (talk | contribs) (Initial version)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


SSSD GPO-Based Access Control

Summary

SSSD will add support for Group Policy Object (GPO) retrieval and processing, in order to provide centrally managed host-based access control in an Active Directory (AD) environment.

Owner

Current status

  • Targeted release: Fedora 21
  • Last updated: 2014-03-31
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

A common use case for managing computer-based access control in an AD environment is through the use of two specific GPO policy settings ("Allow Log On Locally", "Deny Log On Locally"), which essentially serve as a whitelist and blacklist of domain users/groups that are consulted to determine whether logon access to a particular domain computer should be granted. When dealing with GPOs, there is typically a management piece (used to *specify* the policy settings) and a client-side processing piece (used to *retrieve* and *enforce* the policy settings). Since the two policy settings of interest already exist in AD, administrators can continue to use existing mechanisms to specify the whitelist and blacklist (e.g. Group Policy Management Editor GUI). As such, this change is related only to the retrieval and enforcement of policy settings. This change only affects SSSD's AD provider. It has no effect on any other SSSD providers (e.g. IPA provider).The upstream design page that includes deeper technical details can be found in the SSSD Trac .

Benefit to Fedora

Fedora currently defaults to using SSSD's AD provider for access control in an AD environment. Using GPO-based access control would allow Fedora computers to be seamlessly integrated into the GPO-based host-based access control model, with which Windows administrators are already familiar. Additionally, while the current implementation allows host-based access control to be configured locally on each machine, using GPO-based access control supports the central configuration and management of access control policy. This is an important component of Fedora's robust ability to integrate with AD environments, that has not previously been addressed.

Scope

Since this functionality would only be used by SSSD's AD provider, it would be included as part of the sssd-ad package. This feature would be enabled by default, but a build switch would be provided for those who do not wish to deploy this functionality.

  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)

Upgrade/compatibility impact

No changes should be required and no existing functionality should be lost. The semantics of the whitelist are that everyone is allowed access if no whitelist is specified. As such, a previous version of Fedora (which would be unaware of GPO-based access-control policy settings) should not be affected.

N/A (not a System Wide Change)

How To Test

How to test

In order to test this functionality, you must have access to an AD server. You need to perform some setup tasks on both the test client and the AD server, and then test if the users/groups placed on the GPO whitelist are being correctly granted access, and that the users/groups placed on the GPO blacklist are being correctly denied access.

Client Setup:

  • use realmd (or some other mechanism) to join the test client to the AD domain.
  • make a note of the DN of the computer object that is created on the AD server as a result of the join step (e.g. "cn=f21-client, ou=computers, dc=foo, dc=com").
  • install the sssd package (if realmd hasn't already done so) and configure it to use "Active Directory" for all providers (e.g. id, auth, etc).

AD Server Setup:

  • create some AD domain users and groups
  • create a GPO (using GPMC); set the "Allow Logon Locally" policy setting to the users/groups for which you want access to be allowed; set the "Deny Logon Locally" policy setting to the users/groups for which you want access to be denied
  • link this GPO (using GPMC) to a specific site, domain, or OU node (under which the client test machine resides in AD). For example, if the client test machine's DN is "cn=f21-client, ou=computers, dc=foo, dc=com", then the GPO needs can be linked either to "ou=computers, dc=foo, dc=com" or to "dc=foo, dc=com".

Functionality Test

  • test that the users/groups that you specified in the "Allow Logon Locally" policy settings are able to logon to the test client (you can use ssh instead of doing a full login: e.g. ssh allowed_user@FOO.COM@localhost).
  • test that the users/groups that you specified in the "Deny Logon Locally" policy settings are not able to logon to the test client.
  • unlink previous GPO; link GPO to specific site, domain, or OU node (under which the host computer *does not* reside in AD); test that all users/groups are able to log in to host (since the GPO no longer applies to this host)

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product <-- Applicable for Changes that blocks specific product release/Fedora.next -->

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/SssdGpoBasedAccessControl&oldid=374986"