From 2596a8a48d2fef714ddf5dfa9ed1dfa3bac3b7ad Mon Sep 17 00:00:00 2001 From: Douglas Silas Date: May 12 2010 15:39:44 +0000 Subject: Merge branch 'master' of git+ssh://git.engineering.redhat.com/srv/git/users/dhensley/Deployment_Guide --- diff --git a/en-US/SSSD.xml b/en-US/SSSD.xml index 9b8e995..79703af 100644 --- a/en-US/SSSD.xml +++ b/en-US/SSSD.xml @@ -184,7 +184,8 @@ key10 = val10,val11 class="option">-c (or --config) parameter on the command line to specify a different configuration file for SSSD. - Refer to the sssd.conf(5) manual page for more information on configuring SSSD. + Refer to the sssd.conf(5) manual page for more information on global SSSD configuration options. +
Configuring NSS @@ -252,6 +253,68 @@ session optional pam_console.so
+
Configuring Access Control + + Access Control + configuring in SSSD + + + SSSD provides a rudimentary access control mechanism based on the implementation of access or deny lists of usernames. This mechanism is known as the Simple Access Provider, and is configured in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file. To enable the Simple Access Provider, you need to set the access_provider parameter to simple, and then add usernames as a comma-separated list to either the simple_allow_users or simple_deny_users parameters. + + Using the Simple Access Provider + By using the Simple Access Provider, you can continue to support a number of network logins to maintain common network accounts on company or department laptops, but you might want to restrict the use of a particular laptop to one or two users. This means that even if a different user authenticated successfully against the same authentication provider, the Simple Access Provider would prevent that user from gaining access. + + + The following example demonstrates the use of the Simple Access Provider to grant access to two users. This example assumes that SSSD is correctly configured and example.com is one of the domains specified in the [sssd] section, and only shows the Simple Access Provider-specific options. + +[domain/example.com] +access_provider = simple +simple_allow_users = user1, user2 + + Access Control Rules + The Simple Access Provider adheres to three simple rules to determine which users should or should not be granted access, as follows: + + If both lists are empty, access is granted + If simple_allow_users is set, only users from this list are allowed access. This setting supersedes the simple_deny_users list (which would be redundant). + If the simple_allow_users list is empty, users are allowed access unless they appear in the simple_deny_users list. + + It is a configuration error if both simple_allow_users and simple_deny_users are defined. + + +
+ +
+ Configuring Failover + The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers. + + For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values: + ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org + + In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that is unavailable, it then attempts to connect to ldap2.mydomain.org. If the primary server is restored, the failover mechanism automatically restores operations to use that server instead of any failover servers. + + Do not use multiple ldap_uri parameters to specify your failover servers. The failover servers must be entered as a comma-separated list of values for a single ldap_uri parameter. If you enter multiple ldap_uri parameters, SSSD only recognizes the last entry. + +
+ Using SRV Records with Failover + SSSD also supports the use of SRV records in its failover configuration. This means that you can specify a server that is later resolved into a list of specific servers using SRV requests. The priority and weight attributes of SRV records provide further opportunity for specifying which servers should be contacted first in the event that the primary server fails. + + For every service with which you want to use service discovery, you need to add a special DNS record to your DNS server using the following form: + _service._protocol._domain TTL priority weight port hostname + + A typical configuration would contain multiple such records, each with a different priority (for failover) and different weights (for load balancing). + + The client then makes an SRV DNS query to retrieve a list of host names, their priorities, and weights. These queries are of the form _service._protocol._domain, for example, _ldap._tcp._redhat.com. The client then sorts this list according to the priorities and weights, and connects to the first server in this sorted list.
+ +
+ How the Failover Mechanism Works + The failover mechanism distinguishes between machines and services. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this machine for any other service. If the resolution attempt succeeds, the back end tries to connect to a service on this machine. If the service connection attempt fails, then only this particular service is considered offline and the back end automatically switches over to the next service. The machine is still considered online and might still be tried for another service. + + Further connection attempts are made to machines or services marked as offline after a specified period of time; this is currently hard coded to 30 seconds. If there are no more machines to try, the back end as a whole switches to offline mode, and then attempts to reconnect every 30 seconds.
+ +
+ + @@ -373,6 +436,7 @@ session optional pam_console.so +
Configuring Domains @@ -406,41 +470,11 @@ auth_provider = krb5 krb5_kdcip = 192.168.1.1 krb5_realm = EXAMPLE.COM -
- Configuring Failover - The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the "[domain/NAME]" sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers. - - For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values: -ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org - - In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1, and if that is unavailable, it then attempts to connect to ldap2. If the primary server is restored, the failover mechanism automatically restores operations to use that server instead of any failover servers. - - - Using SRV Records with Failover - SSSD also supports the use of SRV records in its failover configuration. This means that you can specify a server that is later resolved into a list of specific servers using SRV requests. The priority and weight attributes of SRV records provide further opportunity for specifying which servers should be contacted first in the event that the primary server fails. - - - For every service that you want to use service discovery with, you need to add a special DNS record to your DNS server using the following form: -_service._protocol._domain TTL priority weight port hostname - - A typical configuration would contain multiple records like this, each with a different priority (for failover) and different weights (for load balancing). - - The client then makes a SRV DNS query to retrieve a list of host names, their priorities, and weights. These queries are of the form "_service._protocol._domain", for example, "_ldap._tcp._redhat.com". The client then sorts this list according to the priorities and weights, and connects to the first server in this sorted list. - - - How the Failover Mechanism Works - The failover mechanism distinguishes between machines and services. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this machine for any other service. If the resolution attempt succeeds, the back end tries to connect to a service on this machine. If the service connection attempt fails, then only this particular service is considered offline and the back end automatically switches over to the next service. The machine is still considered online and might still be tried for another service. - - - Further connection attempts are made to machines or services marked as offline after a specified period of time; this is currently hard coded to 30 seconds. If there are no more machines to try, the back end as a whole switches to offline mode, and then attempts to reconnect every 30 seconds. - -
Domain Configuration Options - You can add new domain configurations to the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and then add the list of domains to the domains attribute of the [sssd] section, in the order you want them to be queried. + You can add new domain configurations to the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and then add the list of domains to the domains attribute of the [sssd] section, in the order you want them to be queried.