From Fedora Project Wiki
< Changes
(Initial version) |
No edit summary |
||
| Line 24: | Line 24: | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
SSSD | 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 == | == Owner == | ||
| Line 58: | Line 58: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
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 [http://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration SSSD Trac ]. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
Fedora currently defaults to using SSSD's AD provider for access control in an AD environment. | 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 == | == Scope == | ||
| Line 80: | Line 80: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
No changes should be required and no existing functionality should be lost. | No changes should be required and no existing functionality should be lost. | ||
== How To Test == | == How To Test == | ||
| Line 100: | Line 97: | ||
--> | --> | ||
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. | |||
In order to test this functionality, you must have access to an AD server. | |||
Client Setup: | '''Test Client Setup: | ||
* use realmd (or some other mechanism) to join the test client to the AD domain. | * 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"). | * 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"). 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). | ||
* install the sssd package | * install the sssd package and configure it to use "ad" for all providers (e.g. id, auth, access, etc). | ||
AD Server Setup: | '''AD Server Setup: | ||
* create some AD domain users and groups | * 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 | * 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 | * 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 == | == User Experience == | ||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
| Line 129: | Line 122: | ||
== Dependencies == | == Dependencies == | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
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 Plan == | ||
| Line 144: | Line 135: | ||
== Documentation == | == Documentation == | ||
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | ||
https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration | |||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 21:25, 31 March 2014
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
- Name: Yassir Elley
- Email: yelley@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 21
- Last updated: 2014-03-31
- Tracker bug: <will be assigned by the Wrangler>
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:
- 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"). 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).
- install the sssd package and configure it to use "ad" for all providers (e.g. id, auth, access, etc).
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)