From Fedora Project Wiki


SSSD GPO-Based Access Control

Summary

This change will enhance SSSD, by adding support for centrally managed host-based access control in an Active Directory (AD) environment, using Group Policy Objects (GPOs).

Owner


Current status

Detailed Description

GPO policy settings are commonly used to manage host-based access control in an AD environment. The two specific GPO policy settings ("Allow Log On Locally" and "Deny Log On Locally") 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 Console, or GPMC). 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. Implementing this change would allow hosts running Fedora to be seamlessly integrated into the GPO-based access control model, with which Windows administrators are already familiar. Among other things, this model allows access control policy to be configured and managed in a centralized manner, something that SSSD's AD provider is not currently able to do. Implementing this change would enhance Fedora's ability to integrate with AD environments in a robust manner.

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.

How To Test

In order to test this functionality, you must have access to an AD server. After performing setup tasks on both the test client and the AD server, you can test this change by determining whether the users/groups placed on the GPO whitelist/blacklist are being correctly granted/denied access.

Test Client Setup:

  • if the test client is not already joined to an AD domain, execute the "realm join --user=Administrator <ad-domain-name>" command
  • make a note of the DN of the computer object created by "realm join" (which represents the test client).
    • In order for a GPO to be applicable to the test client, it must be linked to an ou parent or dc parent of the test client's DN (or to the site associated with the test client).

AD Server Setup:

  • create some AD domain users and AD domain groups; a user can be managed directly (by being listed) or indirectly (by being a member of a listed group) on a whitelist or blacklist
  • 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 can be linked either to "ou=computers, dc=foo, dc=com" or to "dc=foo, dc=com".

Actual 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.
  • if a user is both allowed and denied, make sure that deny takes precedence
  • unlink GPO from node and test that all users/groups are able to login to host (since the GPO no longer applies to this host)
  • create and link multiple gpos (with conflicting whitelists and blacklists) to various nodes in the hierarchy; OU-linked GPOs should override domain-linked GPOs, which should override site-linked GPOs

User Experience

N/A (not a System Wide Change)

Dependencies

This change depends on a new version of libini_config to be released, which should include functionality (already mostly implemented) needed for parsing policy settings data retrieved in the INI/INF format.

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

https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration

N/A (not a System Wide Change)

Release Notes

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