Ce contenu n'est pas disponible dans la langue sélectionnée.
13.2.13. Creating Domains: Active Directory
The Active Directory identity provider is an extension of a generic LDAP provider. All of the configuration options for an LDAP provider are available to the Active Directory provider, as well as some additional parameters related to user accounts and identity mapping between Active Directory and system users.
There are some fundamental differences between standard LDAP servers and an Active Directory server. When configuring an Active Directory provider, there are some configuration areas, then, which require specific configuration:
- Identities using a Windows security ID must be mapped to the corresponding Linux system user ID.
- Searches must account for the range retrieval extension.
- There may be performance issues with LDAP referrals.
Mapping Active Directory Securiy IDs and Linux User IDs
There are inherent structural differences between how Windows and Linux handle system users and in the user schemas used in Active Directory and standard LDAPv3 directory services. When using an Active Directory identity provider with SSSD to manage system users, it is necessary to reconcile the Active Directory-style user to the new SSSD user. There are two ways to do this:
- Using Services for Unix to insert POSIX attributes on Windows user and group entries, and then having those attributes pulled into PAM/NSS
- Using ID mapping on SSSD to create a map between Active Directory security IDs (SIDs) and the generated UIDs on Linux
ID mapping is the simplest option for most environments because it requires no additional packages or configuration on Active Directory.
The Mechanism of ID Mapping
Linux/Unix systems use a local user ID number and group ID number to identify users on the system. These UID:GID numbers are a simple integer, such as 501:501. These numbers are simple because they are always created and administered locally, even for systems which are part of a larger Linux/Unix domain.
Microsoft Windows and Active Directory use a different user ID structure to identify users, groups, and machines. Each ID is constructed of different segments that identify the security version, the issuing authority type, the machine, and the identity itself. For example:
S-1-5-21-3623811015-3361044348-30300820-1013
The third through sixth blocks are the machine identifier:
S-1-5-21-3623811015-3361044348-30300820-1013
The last block is the relative identifier (RID) which identifies the specific entity:
S-1-5-21-3623811015-3361044348-30300820-1013
A range of possible ID numbers are always assigned to SSSD. (This is a local range, so it is the same for every machine.)
|_____________________________| | | minimum ID max ID
This range is divided into 10,000 sections (by default), with each section allocated 200,000 IDs.
| slice 1 | slice 2 | ... | |_________|_________|_________| | | | | minimum ID max ID
When a new Active Directory domain is detected, the SID is hashed. Then, SSSD takes the modulus of the hash and the number of available sections to determine which ID section to assign to the Active Directory domain. This is a reliably consistent means of assigning ID sections, so the same ID range is assigned to the same Active Directory domain on most client machines.
| Active | Active | | |Directory|Directory| | |domain 1 |domain 2 | ... | | | | | | slice 1 | slice 2 | ... | |_________|_________|_________| | | | | minimum ID max ID
Note
While the method of assigning ID sections is consistent, ID mapping is based on the order that an Active Directory domain is encountered on a client machine — so it may not result in consistent ID range assignments on all Linux client machines. If consistency is required, then consider disabling ID mapping and using explicit POSIX attributes.
ID Mapping Parameters
ID mapping is enabled in two parameters, one to enable the mapping and one to load the appropriate Active Directory user schema:
ldap_id_mapping = True ldap_schema = ad
Note
When ID mapping is enabled, the
uidNumber and gidNumber attributes are ignored. This prevents any manually-assigned values. If any values must be manually assigned, then all values must be manually assigned, and ID mapping should be disabled.
Mapping Users
When an Active Directory user attempts to log into a local system service for the first time, an entry for that user is created in the SSSD cache. The remote user is set up much like a system user:
- A system UID is created for the user based on his SID and the ID range for that domain.
- A GID is created for the user, which is identical to the UID.
- A private group is created for the user.
- A home directory is created, based on the home directory format in the
sssd.conffile. - A shell is created, according to the system defaults or the setting in the
sssd.conffile. - If the user belongs to any groups in the Active Directory domain, then, using the SID, SSSD adds the user to those groups on the Linux system.
Active Directory Users and Range Retrieval Searches
Microsoft Active Directory has an attribute,
MaxValRange, which sets a limit on how many values for a multi-valued attribute will be returned. This is the range retrieval search extension. Essentially, this runs multiuple mini-searches, each returning a subset of the results within a given range, until all matches are returned.
For example, when doing a search for the
member attribute, each entry could have multiple values, and there can be multiple entries with that attribute. If there are 2000 matching results (or more), then MaxValRange limits how many are displayed at once; this is the value range. The given attribute then has an additional flag set, showing which range in the set the result is in:
attribute:range=low-high:value
For example, results 100 to 500 in a search:
member;range=99-499: cn=John Smith...
This is described in the Microsoft documentation at http://msdn.microsoft.com/en-us/library/cc223242.aspx.
SSSD supports range retrievals with Active Directory providers as part of user and group management, without any additional configuration.
However, some LDAP provider attributes which are available to configure searches — such as
ldap_user_search_base — are not performant with range retrievals. Be cautious when configuring search bases in the Active Directory provider domain and consider what searches may trigger a range retrieval.
Performance and LDAP Referrals
Referrals can negatively impact overall performance because of the time spent attempting to trace referrals. There is particularly bad performance degradation when referral chasing is used with an Active Directory identity provider. Disabling referral checking can significantly improve performance.
LDAP referrals are enabled by default, so they must be explicitly disabled in the LDAP domain configuration. For example:
ldap_referrals = false
Active Directory as Other Provider Types
Active Directory can be used as an identity provider and as an access, password, and authentication provider.
There are a number of options in the generic LDAP provider configuration which can be used to configure an Active Directory provider. Using the
ad value is a short-cut which automatically pulls in the parameters and values to configure a given provider for Active Directory. For example, using access_provider = ad to configure an Active Directory access provider expands to this configuration using the explicit LDAP provider parameters:
access_provider = ldap ldap_access_order = expire ldap_account_expire_policy = ad
Procedure 13.6. Configuring an Active Directory Identity Provider
Active Directory can work as a provider for identities, authentication, access control rules, and passwords, all of the
*_provider parameters for a domain. Additionally, it is possible to load the native Active Directory schema for user and group entries, rather than using the default RFC 2307.
- Make sure that both the Active Directory and Linux systems have a properly configured environment.
- Name resolution must be properly configured, particularly if service discovery is used with SSSD.
- The clocks on both systems must be in sync for Kerberos to work properly.
- Set up the Linux system as an Active Directory client and enroll it within the Active Directory domain. This is done by configuring the Kerberos and Samba services on the Linux system.
- Set up Kerberos to use the Active Directory Kerberos realm.
- Open the Kerberos client configuration file.
~]# vim /etc/krb5.conf
- Configure the
[logging]and[libdefaults]sections so that they connect to the Active Directory realm.[logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d rdns = false forwardable = false
If autodiscovery is not used with SSSD, then also configure the[realms]and[domain_realm]sections to explicitly define the Active Directory server.
- Configure the Samba server to connect to the Active directory server.
- Open the Samba configuration file.
~]# vim /etc/samba/smb.conf
- Set the Active Directory domain information in the
[global]section.[global] workgroup = EXAMPLE client signing = yes client use spnego = yes kerberos method = secrets and keytab log file = /var/log/samba/%m.log password server = AD.EXAMPLE.COM realm = EXAMPLE.COM security = ads
- Add the Linux machine to the Active Directory domain.
- Obtain Kerberos credentials for a Windows administrative user.
~]# kinit Administrator
- Add the machine to the domain using the
netcommand.~]# net ads join -k Joined 'server' to dns domain 'example.com'
This creates a new keytab file,/etc/krb5.keytab.List the keys for the system and check that the host principal is there.~]# klist -k
- Use
authconfigto enable SSSD for system authentication.# authconfig --update --enablesssd --enablesssdauth
- Set the Active Directory domain as an identity provider in the SSSD configuration, as shown in Example 13.7, “An Active Directory 2008 R2 Domain” and Example 13.8, “An Active Directory 2008 R2 Domain with ID Mapping”.
- Restart the SSH service to load the new PAM configuration.
~]# service sshd restart
- Restart SSSD after changing the configuration file.
~]# service sssd restart
Example 13.7. An Active Directory 2008 R2 Domain
~]# vim /etc/sssd/sssd.conf [sssd] config_file_version = 2 domains = ad.example.com services = nss, pam ... [domain/ad.example.com] id_provider = ad ad_server = ad.example.com ad_hostname = ad.example.com auth_provider = ad chpass_provider = ad access_provider = ad # defines user/group schema type ldap_schema = ad # using explicit POSIX attributes in the Windows entries ldap_id_mapping = False # caching credentials cache_credentials = true # access controls ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true # performance ldap_referrals = false
There are two parameters that are critical for ID mapping: the Active Directory schema must be loaded (
ldap_schema) and ID mapping must be explicitly enabled (ldap_id_mapping).
Example 13.8. An Active Directory 2008 R2 Domain with ID Mapping
~]# vim /etc/sssd/sssd.conf [sssd] config_file_version = 2 domains = ad.example.com services = nss, pam ... [domain/ad.example.com] id_provider = ad ad_server = ad.example.com ad_hostname = ad.example.com auth_provider = ad chpass_provider = ad access_provider = ad# defines user/group schema typeldap_schema = ad# for SID-UID mappingldap_id_mapping = True# caching credentials cache_credentials = true # access controls ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true # performance ldap_referrals = false
All of the potential configuration attributes for an Active Directory domain are listed in the
sssd-ldap(5) and sssd-ad(5) man pages.
