Windows Integration Guide
Integrating Linux systems with Active Directory environments
Abstract
The Linux Domain Identity, Authentication, and Policy Guide documents Red Hat Identity Management, a solution that provides a centralized and unified way to manage identity stores as well as authentication and authorization policies in a Linux-based domain.
The System-Level Authentication Guide documents different applications and services available to configure authentication on local systems, including the authconfig
utility, the System Security Services Daemon (SSSD) service, the Pluggable Authentication Module (PAM) framework, Kerberos, the certmonger
utility, and single sign-on (SSO) for applications.
Chapter 1. Ways to Integrate Active Directory and Linux Environments
1.1. Defining Windows Integration
User Identities and Authentication
- Where are user accounts located; in a central authentication system running on Windows (AD domain) or in a central identity and authentication server running on Linux?
- How are users authenticated on a Linux system; through a local Linux authentication system or a central authentication system running on Windows?
- How is group membership configured for users? How is that group membership determined?
- Will users authenticate using a user name/password pair, Kerberos tickets, certificates, or a combination of methods?
- POSIX attributes are required to access services on Linux machines. How are these attributes stored: are they set in the Windows domain, configured locally on the Linux system, or dynamically mapped (for UID/GID numbers and Windows SIDs)?
- What users will be accessing what resources? Will Windows-defined users access Linux resources? Will Linux-defined users access Windows resources?
Host and Service Principals
- What resources will be accessed?
- What authentication protocols are required?
- How will Kerberos tickets be obtained? How will SSL certificates be requested or verified?
- Will users need access to a single domain or to both Linux and Windows domains?
DNS Domains, Queries, and Name Resolution
- What will be the DNS configuration?
- Is there a single DNS domain? Are there subdomains?
- How will system host names be resolved?
- How will service discovery be configured?
Security Policies
- Where are access control instructions set?
- Which administrators are configured for each domain?
Change Management
- How frequently are systems added to the domain?
- If the underlying configuration for something related to Windows integration is changed, for example the DNS service, how are those changes propagated?
- Is configuration maintained through domain-related tools or a provisioning system?
- Does the integration path require additional applications or configuration on the Windows server?
1.2. Direct Integration
- Native LDAP and Kerberos PAM and NSS modules
- Among these modules are
nss_ldap
,pam_ldap
, andpam_krb5
. As PAM and NSS modules are loaded into every application process, they directly affect the execution environment. With no caching, offline support, or sufficient protection of access credentials, use of the basic LDAP and Kerberos modules for NSS and PAM is discouraged due to their limited functionality. - Samba Winbind
- Samba Winbind had been a traditional way of connecting Linux systems to AD. Winbind emulates a Windows client on a Linux system and is able to communicate to AD servers.Note that:
- The Winbind service must be running if you configured Samba as a domain member.
- Direct integration with Winbind in a multi-forest AD setup requires bidirectional trusts.
- Remote forests must trust the local forest to ensure that the
idmap_ad
plug-in handles remote forest users correctly.
- System Security Services Daemon (SSSD)
- The primary function of SSSD is to access a remote identity and authentication resource through a common framework that provides caching and offline support to the system. SSSD is highly configurable; it provides PAM and NSS integration and a database to store local users, as well as core and extended user data retrieved from a central server. SSSD is the recommended component to connect a Linux system with an identity server of your choice, be it Active Directory, Identity Management (IdM) in Red Hat Enterprise Linux, or any generic LDAP or Kerberos server.Note that:
- Direct integration with SSSD works only within a single AD forest by default.
- Remote forests must trust the local forest to ensure that the
idmap_ad
plug-in handles remote forest users correctly.
realmd
service. It allows callers to configure network authentication and domain membership in a standard way. The realmd
service automatically discovers information about accessible domains and realms and does not require advanced configuration to join a domain or realm.
1.2.1. Supported Windows Platforms for direct integration
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
1.3. Indirect Integration
- Trust-based solution
- The recommended approach is to leverage Identity Management (IdM) in Red Hat Enterprise Linux as the central server to control Linux systems and then establish cross-realm Kerberos trust with AD, enabling users from AD to log on to and to use single sign-on to access Linux systems and resources. This solution uses the Kerberos capability to establish trusts between different identity sources. IdM presents itself to AD as a separate forest and takes advantage of the forest-level trusts supported by AD.In complex environments, a single IdM forest can be connected to multiple AD forests. This setup enables better separation of duties for different functions in the organization. AD administrators can focus on users and policies related to users while Linux administrators have full control over the Linux infrastructure. In such a case, the Linux realm controlled by IdM is analogous to an AD resource domain or realm but with Linux systems in it.
Note
In Windows, every domain is a Kerberos realm and a DNS domain at the same time. Every domain managed by the domain controller needs to have its own dedicated DNS zone. The same applies when IdM is trusted by AD as a forest. AD expects IdM to have its own DNS domain. For the trust setup to work, the DNS domain needs to be dedicated to the Linux environment.Note that in trust environments, IdM enables you to use ID views to configure POSIX attributes for AD users on the IdM server. For details, see:- SSSD Client-side Views in the System-Level Authentication Guide
- Synchronization-based solution
- An alternative to a trust-based solution is to leverage user synchronization capability, also available in IdM or Red Hat Directory Server (RHDS), allowing user accounts (and with RHDS also group accounts) to be synchronized from AD to IdM or RHDS, but not in the opposite direction. User synchronization has certain limitations, including:
- duplication of users
- the need to synchronize passwords, which requires a special component on all domain controllers in an AD domain
- to be able to capture passwords, all users must first manually change them
- synchronization supports only a single domain
- only one domain controller in AD can be used to synchronize data to one instance of IdM or RHDS
Part I. Adding a Single Linux System to an Active Directory Domain
SSSD
) works with an Active Directory (AD
) domain, how to use the realmd
system to achieve direct domain integration, and finally, how to use Samba
for AD
integration.
Chapter 2. Using Active Directory as an Identity Provider for SSSD
2.1. How the AD Provider Handles Trusted Domains
id_provider = ad
in the /etc/sssd/sssd.conf
file.
- SSSD only supports domains in a single Active Directory forest. If SSSD requires access to multiple domains from multiple forests, consider using IdM with trusts (preferred) or the
winbindd
service instead of SSSD. - By default, SSSD discovers all domains in the forest and, if a request for an object in a trusted domain arrives, SSSD tries to resolve it.If the trusted domains are not reachable or geographically distant, which makes them slow, you can set the
ad_enabled_domains
parameter in/etc/sssd/sssd.conf
to limit from which trusted domains SSSD resolves objects. - By default, you must use fully-qualified user names to resolve users from trusted domains.
2.2. Configuring an AD Provider for SSSD
2.2.1. Overview of the Integration Options
- Linux uses user IDs (UID) and group IDs (GID). See Managing Users and Groups in the System Administrator's Guide. Linux UIDs and GIDs are compliant with the POSIX standard.
- Windows use security IDs (SID).
Important
- Automatically generate new UIDs and GIDs for AD users
- SSSD can use the SID of an AD user to algorithmically generate POSIX IDs in a process called ID mapping. ID mapping creates a map between SIDs in AD and IDs on Linux.
- When SSSD detects a new AD domain, it assigns a range of available IDs to the new domain. Therefore, each AD domain has the same ID range on every SSSD client machine.
- When an AD user logs in to an SSSD client machine for the first time, SSSD creates an entry for the user in the SSSD cache, including a UID based on the user's SID and the ID range for that domain.
- Because the IDs for an AD user are generated in a consistent way from the same SID, the user has the same UID and GID when logging in to any Red Hat Enterprise Linux system.
Note
When all client systems use SSSD to map SIDs to Linux IDs, the mapping is consistent. If some clients use different software, choose one of the following:- Ensure that the same mapping algorithm is used on all clients.
- Use explicit POSIX attributes, as described in Use POSIX attributes defined in AD.
- Use POSIX attributes defined in AD
- AD can create and store POSIX attributes, such as
uidNumber
,gidNumber
,unixHomeDirectory
, orloginShell
.When using ID mapping described in Automatically generate new UIDs and GIDs for AD users, SSSD creates new UIDs and GIDs, which overrides the values defined in AD. To keep the AD-defined values, you must disable ID mapping in SSSD.
2.2.2. Configuring an AD Domain with ID Mapping as a Provider for SSSD
Prerequisites
- Verify the configuration for name resolution. In particular, verify the DNS SRV records. For example, for a domain named
ad.example.com
:- To verify the DNS SRV LDAP records:
# dig -t SRV _ldap._tcp.ad.example.com
- To verify AD records:
# dig -t SRV _ldap._tcp.dc._msdcs.ad.example.com
If you later connect SSSD to a particular AD domain controller, it is not necessary to verify the DNS SRV records. - Verify that system time on both systems is synchronized. This ensures that Kerberos is able to work properly.
- Ensure that the following ports on the AD domain controllers are open and accessible to the RHEL host.
Table 2.1. Ports Required for Direct Integration of Linux Systems into AD Using SSSD Service Port Protocol Notes DNS 53 UDP and TCP LDAP 389 UDP and TCP Kerberos 88 UDP and TCP Kerberos 464 UDP and TCP Used by kadmin for setting and changing a password LDAP Global Catalog 3268 TCP If the id_provider = ad
option is being usedNTP 123 UDP Optional Samba 445 UDP and TCP For AD Group Policy Objects (GPOs)
Configure the Local System
realm join
command to configure the system. See Chapter 3, Using realmd
to Connect to an Active Directory Domain. The realmd
suite edits all required configuration files automatically. For example:
# realm join ad.example.com
realmd
, you can configure the system manually. See Manually Connecting an SSSD Client to an Active Directory Domain in the Red Hat Knowledgebase.
Optional: Configure User Home Directories and Shells
pam_oddjob_mkhomedir.so
library automatically creates home directories when users first log in to the Linux system. By default, SSSD retrieves the format of the home directory from the AD identity provider. To customize the directory format on Linux clients:
- Open the
/etc/sssd/sssd.conf
file. - In the
[domain]
section, use one of these options:fallback_homedir
sets a fallback home directory format, which is used only if a home directory is not defined in ADoverride_homedir
sets a home directory template, which always overrides the home directory defined in AD
For example, to always use the format/home/domain_name/user_name
:[domain/EXAMPLE] [... file truncated ...]
override_homedir = /home/%d/%u
For details, see the sssd.conf(5) man page.
loginShell
parameter configured in AD. To customize the user shell settings on Linux clients:
- Open the
/etc/sssd/sssd.conf
file. - Define the required user shell settings using these options:
shell_fallback
sets a fallback value, which is used only if no shells are defined in ADoverride_shell
sets a value that always overrides the shell defined in ADdefault_shell
sets a default shell valueallowed_shells
andvetoed_shells
set lists of allowed or blacklisted shells
For details, see the sssd.conf(5) man page.
Load the New Configuration
- Restart SSSD after changing the configuration file.
# systemctl restart sssd.service
Additional Resources
- See the sssd-ldap(5) and sssd-krb5(5) man pages for other configuration options for LDAP and Kerberos providers.
- See the sssd-ad(5) man page for other configuration options for AD providers.
2.2.3. Configuring SSSD to Use POSIX Attributes Defined in AD
Note
Recommendations
Join the Linux System to the AD Domain
Disable ID Mapping in SSSD
- Open the
/etc/sssd/sssd.conf
file. - In the AD domain section, add the
ldap_id_mapping = false
setting.Note
If you used therealm
utility to join the domain and added the--automatic-id-mapping=no
switch, therealm
utility already set up SSSD withldap_id_mapping = false
. - If you previously requested any users with the default ID mapping configuration, remove the SSSD caches:
rm -f /var/lib/sss/db/*
Additional Resources
ldap_id_mapping
parameter, see the sssd-ldap(8) man page.
2.3. Automatic Kerberos Host Keytab Renewal
- Add the following parameter to the AD provider in your
/etc/sssd/sssd.conf
file:ad_maximum_machine_account_password_age = value_in_days
- Restart SSSD:
# systemctl restart sssd
ad_maximum_machine_account_password_age = 0
.
2.4. Enabling Dynamic DNS Updates
- when the identity provider comes online (always)
- when the Linux system reboots (always)
- at a specified interval (optional configuration); by default, the AD provider updates the DNS record every 24 hoursYou can set this behavior to the same interval as the DHCP lease. In this case, the Linux client is renewed after the lease is renewed.
[domain/ad.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = addyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
2.5. Using Range Retrieval Searches with SSSD
Important
2.6. Group Policy Object Access Control
2.6.1. How SSSD Works with GPO Access Control
Important
2.6.2. GPO Settings Supported by SSSD
GPO option [a] | Corresponding sssd.conf option [b] |
---|---|
Allow log on locally
Deny log on locally
| ad_gpo_map_interactive |
Allow log on through Remote Desktop Services
Deny log on through Remote Desktop Services
| ad_gpo_map_remote_interactive |
Access this computer from the network
Deny access to this computer from the network
| ad_gpo_map_network |
Allow log on as a batch job
Deny log on as a batch job
| ad_gpo_map_batch |
Allow log on as a service
Deny log on as a service
| ad_gpo_map_service |
[a]
As named in the Group Policy Management Editor on Windows.
[b]
See the sssd-ad(5) man page for details about these options and for lists of pluggable authentication module (PAM) services to which the GPO options are mapped by default.
|
2.6.3. Configuring GPO-based Access Control for SSSD
/etc/sssd/sssd.conf
file. The ad_gpo_access_control
option specifies the mode in which the GPO-based access control runs. It can be set to the following values:
ad_gpo_access_control = permissive
- The
permissive
value specifies that GPO-based access control is evaluated but not enforced; asyslog
message is recorded every time access would be denied. This is the default setting. ad_gpo_access_control = enforcing
- The
enforcing
value specifies that GPO-based access control is evaluated and enforced. ad_gpo_access_control = disabled
- The
disabled
value specifies that GPO-based access control is neither evaluated nor enforced.
Important
ad_gpo_access_control
to enforcing mode, it is recommended to ensure that ad_gpo_access_control
is set to permissive mode and examine the logs. By reviewing the syslog
messages, you can test and adjust the current GPO settings as necessary before finally setting the enforcing mode.
sssd.conf
file:
- The
ad_gpo_map_*
options and thead_gpo_default_right
option configure which PAM services are mapped to specific Windows logon rights.To add a PAM service to the default list of PAM services mapped to a specific GPO setting, or to remove the service from the list, use thead_gpo_map_*
options. For example, to remove thesu
service from the list of PAM services mapped to interactive login (GPO settings Allow log on locally and Deny log on locally):ad_gpo_map_interactive = -su
- The
ad_gpo_cache_timeout
option specifies the interval during which subsequent access control requests can reuse the files stored in the cache, instead of retrieving them from the DC anew.
2.6.4. Additional Resources
- For more details on configuring SSSD to work with GPOs, see Configure SSSD to respect Active Directory SSH or Console/GUI GPOs in Red Hat Knowledgebase.
2.7. Creating User Private Groups Automatically Using SSSD
2.7.1. Activating the Automatic Creation of User Private Groups for AD users
- Edit the
/etc/sssd/sssd.conf
file, adding in the[domain/LDAP]
section:auto_private_groups = true
- Restart the sssd service, removing the sssd database:
# service sssd stop ; rm -rf /var/lib/sss/db/* ; service sssd start
# id ad_user1 uid=121298(ad_user1) gid=121298(ad_user1) groups=121298(ad_user1),10000(Group1) # id ad_user2 uid=121299(ad_user2) gid=121299(ad_user2) groups=121299(ad_user2),10000(Group1)
2.7.2. Deactivating the Automatic Creation of User Private Groups for AD users
- Edit the
/etc/sssd/sssd.conf
file, adding in the[domain/LDAP]
section:auto_private_groups = false
- Restart the sssd service, removing the sssd database:
# service sssd stop ; rm -rf /var/lib/sss/db/* ; service sssd start
# id ad_user1 uid=121298(ad_user1) gid=10000(group1) groups=10000(Group1) # id ad_user2 uid=121299(ad_user2) gid=10000(group1) groups=10000(Group1)
2.8. SSSD Clients and Active Directory DNS Site Autodiscovery
- SSSD queries SRV records from the DNS server in the AD forest. The returned records contain the names of DCs in the forest.
- SSSD sends an LDAP ping to each of these DCs. If a DC does not respond within a configured interval, the request times out and SSSD sends the LDAP ping to the next one. If the connection succeeds, the response contains information about the AD site the SSSD client belongs to.
- SSSD then queries SRV records from the DNS server to locate DCs within the site it belongs to, and connects to one of them.
Note
ad_site
option in the [domain] section of the /etc/sssd/sssd.conf
file.
Additional Resources
- See the sssd-ad(5) man page for details on
ad_site
. - For environments with a trust between Identity Management and Active Directory, see Section 5.6, “Restricting Identity Management or SSSD to Selected Active Directory Servers or Sites in a Trusted Active Directory Domain”.
2.9. Troubleshooting SSSD
Chapter 3. Using realmd
to Connect to an Active Directory Domain
realmd
system provides a clear and simple way to discover and join identity domains to achieve direct domain integration. It configures underlying Linux system services, such as SSSD or Winbind, to connect to the domain.
realmd
system simplifies that configuration. It can run a discovery search to identify available AD and Identity Management domains and then join the system to the domain, as well as set up the required client services used to connect to the given identity domain and manage user access. Additionally, because SSSD as an underlying service supports multiple domains, realmd
can discover and support multiple domains as well.
3.1. Supported Domain Types and Clients
realmd
system supports the following domain types:
- Microsoft Active Directory
- Red Hat Enterprise Linux Identity Management
realmd
:
- SSSD for both Red Hat Enterprise Linux Identity Management and Microsoft Active Directory
- Winbind for Microsoft Active Directory
3.2. Prerequisites for Using realmd
realmd
system, install the realmd package.
# yum install realmd
realmd
.
Note
realmd
to find out which packages to install.
3.3. realmd
Commands
realmd
system has two major task areas:
- managing system enrollment in a domain
- setting which domain users are allowed to access the local system resources
realmd
is called realm
. Most realm
commands require the user to specify the action that the utility should perform, and the entity, such as a domain or user account, for which to perform the action:
realm command arguments
realm join ad.example.com realm permit user_name
Command | Description |
---|---|
Realm Commands | |
discover | Run a discovery scan for domains on the network. |
join | Add the system to the specified domain. |
leave | Remove the system from the specified domain. |
list | List all configured domains for the system or all discovered and configured domains. |
Login Commands | |
permit | Enable access for specified users or for all users within a configured domain to access the local system. |
deny | Restrict access for specified users or for all users within a configured domain to access the local system. |
realm
commands, see the realm(8) man page.
3.4. Discovering and Joining Identity Domains
realm discover
command returns complete domain configuration and a list of packages that must be installed for the system to be enrolled in the domain.
realm join
command then sets up the local machine for use with a specified domain by configuring both the local system services and the entries in the identity domain. The process run by realm join
follows these steps:
- Running a discovery scan for the specified domain.
- Automatic installation of the packages required to join the system to the domain.This includes SSSD and the PAM home directory job packages. Note that the automatic installation of packages requires the
PackageKit
suite to be running.Note
IfPackageKit
is disabled, the system prompts you for the missing packages, and you will be required to install them manually using theyum
utility. - Joining the domain by creating an account entry for the system in the directory.
- Creating the
/etc/krb5.keytab
host keytab file. - Configuring the domain in SSSD and restarting the service.
- Enabling domain users for the system services in PAM configuration and the
/etc/nsswitch.conf
file.
Discovering Domains
realm discover
command displays information about the default DNS domain, which is the domain assigned through the Dynamic Host Configuration Protocol (DHCP):
# realm discover ad.example.com type: kerberos realm-name: AD.EXAMPLE.COM domain-name: ad.example.com configured: no server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common
realm discover
and add the name of the domain you want to discover:
# realm discover ad.example.com
realmd
system will then use DNS SRV lookups to find the domain controllers in this domain automatically.
Note
realm discover
command requires NetworkManager to be running; in particular, it depends on the D-Bus interface of NetworkManager. If your system does not use NetworkManager, always specify the domain name in the realm discover
command.
realmd
system can discover both Active Directory and Identity Management domains. If both domains exist in your environment, you can limit the discovery results to a specific type of server using the --server-software
option. For example:
# realm discover --server-software=active-directory
login-policy
, which shows if domain users are allowed to log in as soon as the join is complete. If logins are not allowed by default, you can allow them manually by using the realm permit
command. For details, see Section 3.7, “Managing Login Permissions for Domain Users”.
realm discover
command, see the realm(8) man page.
Joining a Domain
Important
realm join
command and specify the domain name:
# realm join ad.example.com realm: Joined ad.example.com domain
Administrator
; for IdM, it is called admin
. To connect as a different user, use the -U
option:
# realm join ad.example.com -U user
-U
option.
# kinit user # realm join ad.example.com -U user
realm join
command accepts several other configuration options. For more information about the realm join
command, see the realm(8) man page.
Example 3.1. Example Procedure for Enrolling a System into a Domain
- Run the
realm discover
command to display information about the domain.# realm discover ad.example.com ad.example.com type: kerberos realm-name: AD.EXAMPLE.COM domain-name: ad.example.com configured: no server-software: active-directory client-software: sssd
- Run the
realm join
command and pass the domain name to the command. Provide the administrator password if the system prompts for it.# realm join ad.example.com Password for Administrator: password
realmd
checks for the DNS SRV record:
_ldap._tcp.domain.example.com.
for Identity Management records_ldap._tcp.dc._msdcs.domain.example.com.
for Active Directory records
Testing the System Configuration after Joining a Domain
- Run the
id user@domain_name
command to display information about a user from the domain.# id user@ad.example.com uid=1348601103(user@ad.example.com) gid=1348600513(domain group@ad.example.com) groups=1348600513(domain group@ad.example.com)
- Using the
ssh
utility, log in as the same user.# ssh -l user@ad.example.com linux-client.ad.example.com user@ad.example.com@linux-client.ad.example.com's password: Creating home directory for user@ad.example.com.
- Verify that the
pwd
utility prints the user's home directory.$ pwd /home/ad.example.com/user
- Verify that the
id
utility prints the same information as theid user@domain_name
command from the first step.$ id uid=1348601103(user@ad.example.com) gid=1348600513(domain group@ad.example.com) groups=1348600513(domain group@ad.example.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
kinit
utility is also useful when testing whether the domain join was successful. Note that to use the utility, the krb5-workstation package must be installed.
3.5. Removing a System from an Identity Domain
realm leave
command. The command removes the domain configuration from SSSD and the local system.
# realm leave ad.example.com
Administrator
; for IdM, it is called admin
. If a different user was used to join to the domain, it might be required to perform the removal as that user. To specify a different user, use the -U
option:
# realm leave ad.example.com -U 'AD.EXAMPLE.COM\user'
--remove
option specified.
realm leave
command, see the realm(8) man page.
3.6. Listing Domains
realm list
command lists every configured domain for the system, as well as the full details and default configuration for that domain. This is the same information as is returned by the realm discovery
command, only for a domain that is already in the system configuration.
# realm list --all --name-only ad.example.com
realm list
are:
--all
- The
--all
option lists all discovered domains, both configured and unconfigured. --name-only
- The
--name-only
option limits the results to the domain names and does not display the domain configuration details.
realm list
command, see the realm(8) man page.
3.7. Managing Login Permissions for Domain Users
realmd
system to configure basic allow or deny access rules for users from that domain. Note that these access rules either allow or deny access to all services on the system. More specific access rules must be set on a specific system resource or in the domain.
realm deny
- The
realm deny
command simply denies access to all users within the domain. Use this command with the--all
option. realm permit
- The
realm permit
command can be used to:- grant access to all users by using the
--all
option, for example:$ realm permit --all
- grant access to specified users, for example:
$ realm permit user@example.com $ realm permit 'AD.EXAMPLE.COM\user'
- deny access to specified users by using the
-x
option, for example:$ realm permit -x 'AD.EXAMPLE.COM\user'
realmd
with information about available child domains.
Important
realm permit -x
. Instead, Red Hat recommends to maintain a default no access policy for all users and only grant access to selected users using realm permit
.
realm deny
and realm permit
commands, see the realm(8) man page.
3.8. Changing Default User Configuration
realmd
system supports modifying the default user home directory and shell POSIX attributes. For example, this might be required when some POSIX attributes are not set in the Windows user accounts or when these attributes are different from POSIX attributes of other users on the local system.
Important
realm join
command has not been run yet. If a system is already joined, change the default home directory and shell in the /etc/sssd/sssd.conf
file, as described in the section called “Optional: Configure User Home Directories and Shells”.
[users]
section in the /etc/realmd.conf
file:
default-home
- The
default-home
option sets a template for creating a home directory for accounts that have no home directory explicitly set. A common format is/home/%d/%u
, where%d
is the domain name and%u
is the user name. default-shell
- The
default-shell
option defines the default user shell. It accepts any supported system shell.
[users] default-home = /home/%u default-shell = /bin/bash
3.9. Additional Configuration for the Active Directory Domain Entry
/etc/realmd.conf
file. Each domain can have its own configuration section; the name of the section must match the domain name. For example:
[ad.example.com] attribute = value attribute = value
Important
realm join
command has not been run yet. If a system is already joined, changing these settings does not have any effect. In such situations, you must leave the domain, as described in Section 3.5, “Removing a System from an Identity Domain”, and then join again, as described in the section called “Joining a Domain”. Note that joining requires the domain administrator's credentials.
/etc/realmd.conf
. The following example disables ID mapping for the ad.example.com
domain, sets the host principal, and adds the system to the specified subtree:
[ad.example.com] computer-ou = ou=Linux Computers,DC=domain,DC=example,DC=com user-principal = host/linux-client@AD.EXAMPLE.COM automatic-id-mapping = no
realm join
command, described in the section called “Joining a Domain”:
# realm join --computer-ou="ou=Linux Computers,dc=domain,dc=com" --automatic-id-mapping=no --user-principal=host/linux-client@AD.EXAMPLE.COM
/etc/realmd.conf
. For complete information about the available configuration options, see the realmd.conf(5) man page.
Option | Description |
---|---|
computer-ou | Sets the directory location for adding computer accounts to the domain. This can be the full DN or an RDN, relative to the root entry. The subtree must already exist. |
user-principal | Sets the userPrincipalName attribute value of the computer account to the provided Kerberos principal. |
automatic-id-mapping | Sets whether to enable dynamic ID mapping or disable the mapping and use POSIX attributes configured in Active Directory. |
Chapter 4. Using Samba for Active Directory Integration
4.1. Using winbindd
to Authenticate Domain Users
winbindd
service provides an interface for the Name Service Switch (NSS) and enables domain users to authenticate to AD when logging into the local system.
winbindd
provides the benefit that you can enhance the configuration to share directories and printers without installing additional software. For further detail, see the section about Samba in the Red Hat System Administrator's Guide.
4.1.1. Joining an AD Domain
Winbind
service, use the realm join --client-software=winbind domain_name
command. The realm
utility automatically updates the configuration files, such as those for Samba, Kerberos, and PAM.
4.2. Using SMB shares with SSSD and Winbind
Important
4.2.1. How SSSD Works with SMB
4.2.2. Switching Between SSSD and Winbind for SMB Share Access
$ rpm -q cifs-utils
- Optional. Find out whether you are currently using SSSD or Winbind to access SMB shares from the SSSD client:
# alternatives --display cifs-idmap-plugin
cifs-idmap-plugin - status is auto. link currently points to /usr/lib64/cifs-utils/cifs_idmap_sss.so /usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20 /usr/lib64/cifs-utils/idmapwb.so - priority 10 Current `best' version is /usr/lib64/cifs-utils/cifs_idmap_sss.so.If the SSSD plug-in (cifs_idmap_sss.so
) is installed, it has a higher priority than the Winbind plug-in (idmapwb.so
) by default. - Before switching to the Winbind plug-in, make sure Winbind is running on the system:
# systemctl is-active winbind.service
activeBefore switching to the SSSD plug-in, make sure SSSD is running on the system:# systemctl is-active sssd.service
active - To switch to a different plug-in, use the
alternatives --set cifs-idmap-plugin
command, and specify the path to the required plug-in. For example, to switch to Winbind:# alternatives --set cifs-idmap-plugin /usr/lib64/cifs-utils/idmapwb.so
Note
/usr/lib/cifs-utils/
directory instead of /usr/lib64/cifs-utils/
.
4.3. Additional Resources
Part II. Integrating a Linux Domain with an Active Directory Domain: Cross-forest Trust
Linux Domain
with an Active Directory
domain by creating, configuring, and managing a cross-forest trust environment.
Chapter 5. Creating Cross-forest Trusts with Active Directory and Identity Management
5.1. Introduction to Cross-forest Trusts
5.1.1. The Architecture of a Trust Relationship
Active Directory Trusts, Forests, and Cross-forest Trusts
Trust Flow and One-way Trusts
Figure 5.1. One-way Trust
Transitive and Non-transitive Trusts
Figure 5.2. Transitive Trusts
Cross-forest Trust in Active Directory and Identity Management
Figure 5.3. Trust Direction
5.1.2. Active Directory Security Objects and Trust
Active Directory Global Catalog
Global Catalog and POSIX Attributes
5.1.3. Trust Architecture in IdM
- SSSD, to perform identity lookups on Active Directory and to retrieve user and group security identifiers (SIDs) for authorization. SSSD also caches user, group, and ticket information for users and maps Kerberos and DNS domains,
- Identity Management (Linux domain management), to associate the Active Directory user with an IdM group for IdM policies and access.
Note
Access control rules and policies for Linux domain administration, such as SELinux, sudo, and host-based access controls, are defined and applied through Identity Management. Any access control rules set on the Active Directory side are not evaluated or used by IdM; the only Active Directory configuration which is relevant is group membership.
Trusts with Different Active Directory Forests
5.1.3.1. Active Directory PACs and IdM Tickets
- The request for a service contains the PAC of the user. The IdM Kerberos Distribution Centre (KDC) analyzes the PAC by comparing the list of Active Directory groups to memberships in IdM groups.
- For SIDs of the Kerberos principal defined in the MS-PAC, the IdM KDC evaluates external group memberships defined in the IdM LDAP. If additional mappings are available for an SID, the MS-PAC record is extended with other SIDs of the IdM groups to which the SID belongs. The resulting MS-PAC is signed by the IdM KDC.
- The service ticket is returned to the user with the updated PAC signed by the IdM KDC. Users belonging to AD groups known to the IdM domain can now be recognized by SSSD running on the IdM clients based on the MS-PAC content of the service ticket. This allows to reduce identity traffic to discover group memberships by the IdM clients.
- The Kerberos client libraries used in the evaluation process send the PAC data to the SSSD PAC responder.
- The PAC responder verifies the group SIDs in the PAC and adds the user to the corresponding groups in the SSSD cache. SSSD stores multiple TGTs and tickets for each user as new services are accessed.
- Users belonging to the verified groups can now access the required services on the IdM side.
5.1.3.2. Active Directory Users and Identity Management Groups
Non-POSIX External Groups and SID Mapping
ID Ranges
Note
ipa trust-add
command:
- ipa-ad-trust
- This range option is used for IDs algorithmically generated by IdM based on the SID.If IdM generates the SIDs using SID-to-POSIX ID mapping, the ID ranges for AD and IdM users and groups must have unique, non-overlapping ID ranges available.
- ipa-ad-trust-posix
- This range option is used for IDs defined in POSIX attributes in the AD entry.IdM obtains the POSIX attributes, including
uidNumber
andgidNumber
, from the global catalog in AD or from the directory controller. If the AD domain is managed correctly and without ID conflicts, the ID numbers generated in this way are unique. In this case, no ID validation or ID range is required.
[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix
Recreating a trust with the other ID range
--range-type
option:
- View all the ID ranges that are currently in use:
[root@ipaserver ~]# ipa idrange-find
In the list, identify the name of the ID range that was created by theipa trust-add
command. The first part of the name of the ID range is the name of the trust: name_of_the_trust_id_range, for example ad.example.com. - (Optional) If you do not know which
--range-type
option,ipa-ad-trust
oripa-ad-trust-posix
, was used when the trust was created, identify the option:[root@ipaserver ~]# ipa idrange-show name_of_the_trust_id_range
Make note of the type so that you choose the opposite type for the new trust in Step 5. - Remove the range that was created by the
ipa trust-add
command:[root@ipaserver ~]# ipa idrange-del name_of_the_trust_id_range
- Remove the trust:
[root@ipaserver ~]# ipa trust-del name_of_the_trust
- Create a new trust with the correct
--range-type
option. For example:[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust
5.1.3.3. Active Directory Users and IdM Policies and Configuration
Figure 5.4. Active Directory Users and IdM Groups and Policies
5.1.4. One-Way and Two-Way Trusts
- One-way trust
- One-way trust enables AD users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain.One-way trust is the default mode for creating a trust.
- Two-way trust
- Two-way trust enables AD users and groups to access resources in IdM. You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the S4U2Self and S4U2Proxy Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might request S4U2Self or S4U2Proxy information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature.Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD.
ipa trust-add
command again; by doing this, you can delete the existing trust and establish a new one.
5.1.5. External Trusts to Active Directory
5.1.6. Trust Controllers and Trust Agents
- Trust controllers
- IdM servers that can control the trust and perform identity lookups against Active Directory domain controllers (DC). Active Directory domain controllers contact trust controllers when establishing and verifying the trust to Active Directory. The first trust controller is created when you configure the trust.For details about configuring an IdM server as a trust controller, see Section 5.2.2, “Creating Trusts”.Trust controllers run an increased amount of network-facing services compared to trust agents, and thus present a greater attack surface for potential intruders.
- Trust agents
- IdM servers that can perform identity lookups against Active Directory domain controllers.For details about configuring an IdM server as a trust agent, see Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
Capability | Trust controllers | Trust agents |
---|---|---|
Resolve Active Directory users and groups | Yes | Yes |
Enroll IdM clients that run services accessible by users from trusted Active Directory forests | Yes | Yes |
Manage the trust (for example, add trust agreements) | Yes | No |
- Configure at least two trust controllers per Identity Management deployment.
- Configure at least two trust controllers in each data center.
ipa-adtrust-install
utility on the IdM server as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
Important
5.2. Creating Cross-forest Trusts
5.2.1. Environment and Machine Requirements
5.2.1.1. Supported Windows Platforms
- Forest functional level range: Windows Server 2008 - Windows Server 2016
- Domain functional level range: Windows Server 2008 - Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2016
5.2.1.2. DNS and Realm Settings
- Unique primary DNS domains
- Each system must have its own unique primary DNS domain configured. For example:
ad.example.com
for AD andidm.example.com
for IdMexample.com
for AD andidm.example.com
for IdMad.example.com
for AD andexample.com
for IdMImportant
If the IdM domain is the parent domain of the AD domain, the IdM servers must run on Red Hat Enterprise Linux 7.5 or later.
The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but it is possible to use any other standard-compliant DNS server as well.It is not possible for AD or IdM to share the primary DNS domain with another system for identity management. For more information, see documentation for host name and DNS configuration requirements in the Linux Domain Identity, Authentication, and Policy Guide. - Kerberos realm names as upper-case versions of primary DNS domain names
- Kerberos realm names must be the same as the primary DNS domain names, with all letters uppercase. For example, if the domain names are
ad.example.com
for AD andidm.example.com
for IdM, the Kerberos realm names are required to beAD.EXAMPLE.COM
andIDM.EXAMPLE.COM
. - DNS records resolvable from all DNS domains in the trust
- All machines must be able to resolve DNS records from all DNS domains involved in the trust relationship:
- When configuring IdM DNS, follow the instructions described in the section on configuring DNS services within the IdM domain and section on managing DNS forwarding in the Linux Domain Identity, Authentication, and Policy Guide.
- If you are using IdM without integrated DNS, follow the instructions described in the section describing the server installation without integrated DNS in the Linux Domain Identity, Authentication, and Policy Guide.
- No overlap between IdM and AD DNS domains
- Systems joined to IdM can be distributed over multiple DNS domains. DNS domains containing IdM clients must not overlap with DNS domains containing machines joined to AD. The primary IdM DNS domain must have proper SRV records to support AD trusts.
Note
In some environments with trusts between IdM and Active Directory, you can install an IdM client on a host that is part of the Active Directory DNS domain. The host can then benefit from the Linux-focused features of IdM. This is not a recommended configuration and has some limitations. Red Hat recommends to always deploy IdM clients in a DNS zone different from the ones owned by Active Directory and access IdM clients through their IdM host names.You can acquire a list of the required SRV records specific to your system setup by running the$ ipa dns-update-system-records --dry-run
command.The generated list can look for example like this:$ ipa dns-update-system-records --dry-run IPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos.example.com. 86400 IN TXT "EXAMPLE.COM" _kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com. _kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com. _ntp._udp.example.com. 86400 IN SRV 0 100 123 server.example.com.
For other DNS domains that are part of the same IdM realm, it is not required for the SRV records to be configured when the trust to AD is configured. The reason is that AD domain controllers do not use SRV records to discover KDCs but rather base the KDC discovery on name suffix routing information for the trust.
Verifying the DNS Configuration
ipconfig /flushdns
command.
- Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust
- Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
The commands are expected to list all IdM servers. - Run a DNS query for the TXT record with the IdM Kerberos realm name. The obtained value is expected to match the Kerberos realm that you specified when installing IdM.
[root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com. IPA.EXAMPLE.COM
- After you execute the
ipa-adtrust-install
utility, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”, run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
The commands are expected to list all IdM servers on whichipa-adtrust-install
has been executed. Note that the output is empty ifipa-adtrust-install
has not been executed on any IdM server, which is typically before establishing the very first trust relationship.
- Verify that IdM is able to resolve service records for AD
- Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
These commands are expected to return the names of AD domain controllers. - Verify that the IdM-hosted services are resolvable from the AD server
- On the AD server, set the
nslookup.exe
utility to look up service records.C:\>nslookup.exe > set type=SRV
- Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
> _kerberos._udp.ipa.example.com. _kerberos._udp.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.ipa.example.com _ldap._tcp.ipa.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com
The expected output contains the same set of IdM servers as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust. - Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name.
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"
The output is expected to contain the same value as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust. - After you execute the
ipa-adtrust-install
utility, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”, run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.ipa.example.com. _kerberos._udp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.dc._msdcs.ipa.example.com. _ldap._tcp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com
The command is expected to list all IdM servers on which theipa-adtrust-install
utility has been executed. Note that the output is empty ifipa-adtrust-install
has not been executed on any IdM server, which is typically before establishing the very first trust relationship.
- Verify that AD services are resolvable from the AD server
- On the AD server, set the
nslookup.exe
utility to look up service records.C:\>nslookup.exe > set type=SRV
- Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
> _kerberos._udp.dc._msdcs.ad.example.com. _kerberos._udp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = addc1.ad.example.com > _ldap._tcp.dc._msdcs.ad.example.com. _ldap._tcp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = addc1.ad.example.com
The expected output contains the same set of AD servers as displayed in Verify that IdM is able to resolve service records for AD.
5.2.1.3. NetBIOS Names
ad.example.com
, the NetBIOS name is typically AD
.
Note
5.2.1.4. Firewalls and Ports
- Open ports required for an AD trust and ports required by an IdM server in an AD trust on IdM servers and all AD domain controllers in both directions: from the IdM servers to the AD domain controllers and back.
- Open the port required by an IdM client in an AD trust on all AD domain controllers of the trusted AD forest. On the IdM clients, make sure the port is open in the outgoing direction (see Prerequisites for Installing a Client in the Linux Domain Identity, Authentication, and Policy Guide).
Service | Port | Protocol |
---|---|---|
Endpoint resolution portmapper | 135 | TCP |
NetBIOS-DGM | 138 | TCP and UDP |
NetBIOS-SSN | 139 | TCP and UDP |
Microsoft-DS | 445 | TCP and UDP |
Endpoint mapper listener range | 1024-1300 | TCP |
AD Global Catalog | 3268 | TCP |
LDAP | 389 | TCP [a] and UDP |
[a]
The TCP port 389 is not required to be open on IdM servers for trust, but it is necessary for clients communicating with the IdM server.
|
Service | Port | Protocol |
---|---|---|
Kerberos | See Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide. | |
LDAP | ||
DNS |
Service | Port | Protocol | Notes |
---|---|---|---|
Kerberos | 88 | UDP and TCP |
The
libkrb5 library uses UDP and falls-back to the TCP protocol if the data sent from the Kerberos Distribution Center (KDC) is too large. Active Directory attaches a Privilege Attribute Certificate (PAC) to the Kerberos ticket, which increases the size and requires in most cases to use the TCP protocol. To avoid the fall-back and resending the request, by default, SSSD in Red Hat Enterprise Linux 7.4 and later uses TCP for user authentication. To configure the size before libkrb5 uses TCP, set the udp_preference_limit in the /etc/krb.5.conf file. For details, see the krb5.conf(5) man page.
|
Additional Resources
- For advice on how to open the required ports, see Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide.
5.2.1.5. IPv6 Settings
5.2.1.6. Clock Settings
5.2.1.7. Creating a Conditional Forwarder for the IdM Domain in AD
- On a Windows AD domain controller, open the Active Directory (AD)
DNS
console. - Right-click New Conditional Forwarder., select
- Enter the IdM DNS domain name and the IP address of the IdM DNS server
- Select Store this conditional forwarder in Active Directory, and replicate it as follows, and select the replication setting that matches your environment.
- Click.
- To verify that the AD domain controller (DC) can resolve DNS entries from the IdM domain, open a command prompt and enter:
C:\> nslookup server.idm.example.com
If the command returns the IP address of the IdM server, the conditional forwarder is working correctly.
5.2.1.8. Creating a Forward Zone for the AD Domain in IdM
- On the IdM server, create a forward zone entry for the AD DNS domain. For further details about creating a DNS forward zone in IdM see the Configuring Forward Zones section in the Linux Domain Identity, Authentication, and Policy Guide.
- If the AD DNS server does not support DNSSEC, disable DNSSEC validation on the IdM server:
- Edit the
/etc/named.conf
file and set thednssec-validation
parameter tono
:dnssec-validation no;
- Restart the
named-pkcs11
service:# systemctl restart named-pkcs11
- To verify that the IdM server can resolve DNS entries from the AD domain, enter:
# host server.ad.example.com
If the command returns the IP address of the AD DC, the forward zone is working correctly.
5.2.1.9. Supported User Name Formats
user_name@domain
. Active Directory supports several different kinds of name formats: user_name
, user_name@DOMAIN_NAME
, and DOMAIN_NAME\user_name
.
user_name
) or their fully-qualified user name (user_name@domain_name
), for example, to authenticate to the system.
Warning
/etc/sssd/sssd.conf
file and in trusted domains. If you configured a domain resolution order as described in Section 8.5.3, “Configuring the Domain Resolution Order on an IdM Client”, SSSD searches for the user in the defined order. In any case, SSSD uses the first entry found. This can lead to problems or confusion if the same user name exists in multiple domains and the first entry found is not the expected one.
re_expression
option. The regular expression is used for IdM back ends or AD back ends and supports all the mentioned formats:
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
5.2.2. Creating Trusts
Note
5.2.2.1. Creating a Trust from the Command Line
- Preparing the IdM server for the trust, described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”
- Creating a trust agreement, described in Section 5.2.2.1.2, “Creating a Trust Agreement”
- Verifying the Kerberos configuration, described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”
5.2.2.1.1. Preparing the IdM Server for Trust
- Install the required IdM, trust, and Samba packages:
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
- Configure the IdM server to enable trust services. You can skip this step if you installed the server with the
ipa-replica-install --setup-adtrust
command.- Run the
ipa-adtrust-install
utility:[root@ipaserver ]# ipa-adtrust-install
The utility adds DNS service records required for AD trusts. These records are created automatically if IdM was installed with an integrated DNS server.If IdM was installed without an integrated DNS server,ipa-adtrust-install
prints a list of service records that you must manually add to the DNS before you can continue.Important
Red Hat strongly recommends to verify the DNS configuration as described in the section called “Verifying the DNS Configuration” every time after runningipa-adtrust-install
, especially if IdM or AD do not use integrated DNS servers. - The script prompts to configure the
slapi-nis
plug-in, a compatibility plug-in that allows older Linux clients to work with trusted users.Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]: y
- At least one user (the IdM administrator) exists when the directory is first installed. The SID generation task can create a SID for any existing users to support the trust environment. This is a resource-intensive task; for a high number of users, this can be run separately.
Do you want to run the ipa-sidgen task? [no]: yes
- Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
- Start the
smb
service:[root@ipaserver ~]# systemctl start smb
- Optionally, configure that the
smb
service starts automatically when the system boots:[root@ipaserver ~]# systemctl enable smb
- Optionally, use the
smbclient
utility to verify that Samba responds to Kerberos authentication from the IdM side.[root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.9.1) Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- -------
5.2.2.1.2. Creating a Trust Agreement
ipa trust-add
command:
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
ipa trust-add
command sets up a one-way trust by default. It is not possible to establish a two-way trust in RHEL 7.
--external=true
option to the ipa trust-add
command. See Section 5.1.5, “External Trusts to Active Directory” for details.
Note
ipa trust-add
command configures the server as a trust controller by default. See Section 5.1.6, “Trust Controllers and Trust Agents” for details.
--two-way=true
option:
[root@ipaserver ~]# ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true Active Directory domain administrator's password: ------------------------------------------------------- Added Active Directory trust for realm "ad.example.com" ------------------------------------------------------- Realm-Name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified
5.2.2.1.3. Verifying the Kerberos Configuration
- Request a ticket for an IdM user:
[root@ipaserver ~]# kinit user
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.example.com
- Request service tickets for a service within the AD domain:
[root@ipaserver ~]# kvno -S cifs adserver.example.com
If the AD service ticket is successfully granted, there is a cross-realm ticket-granting ticket (TGT) listed with all of the other requested tickets. The TGT is namedkrbtgt/AD.DOMAIN@IPA.DOMAIN
.[root@ipaserver ]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@IPA.DOMAIN Valid starting Expires Service principal 06/15/12 12:13:04 06/16/12 12:12:55 krbtgt/IPA.DOMAIN@IPA.DOMAIN 06/15/12 12:13:13 06/16/12 12:12:55 host/ipaserver.ipa.example.com@IPA.DOMAIN 06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/AD.DOMAIN@IPA.DOMAIN 06/15/12 12:14:58 06/15/12 22:14:58 cifs/adserver.ad.example.com@AD.DOMAIN
- Request a ticket for an Active Directory user:
[root@ipaserver ~]# kinit user@AD.DOMAIN
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.example.com
If the AD service ticket is successfully granted, there is a cross-realm ticket-granting ticket (TGT) listed with all of the other requested tickets. The TGT is namedkrbtgt/IPA.DOMAIN@AD.DOMAIN
.[root@ipaserver ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.DOMAIN Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/ipaserver.ipa.example.com@IPA.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IPA.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00
localauth
plug-in maps Kerberos principals to local SSSD user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly.
Note
5.2.2.3. Verifying the ID Mapping
- Run the following command on a Windows Active Directory domain controller (DC) to list the highest ID:
C:\> dcdiag /v /test:ridmanager /s:ad.example.com ... Available RID Pool for the Domain is 1600 to 1073741823 ...
- List the ID ranges on an IdM server:
[root@ipaserver ~]# ipa idrange-find ---------------- 1 range matched ---------------- Range name: AD.EXAMPLE.COM_id_range First Posix ID of the range: 610600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912 Range type: Active Directory domain range ---------------------------- Number of entries returned 1 ----------------------------
You require the first POSIX ID value in a later step. - On the Active Directory DC, display the security identifier (SID) or a user. For example, to display the SID of
administrator
:C:\> wmic useraccount where name="administrator" get sid S-1-5-21-796215754-1239681026-23416912-500
The last part of the SID is the relative identifier (RID). You require the user's RID in the next step.Note
If the RID is higher than the default ID range (200000), use theipa idrange-mod
command to extend the range. For example:# ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
- Display the user ID of the same user on the IdM server:
[root@ipaserver ~]# id ad\\administrator uid=610600500(administrator@ad.example.com)...
- If you add the first POSIX ID value (610600000) to the RID (500), it must match the user ID displayed on the IdM server (610600500).
5.2.2.4. Creating a Trust on an Existing IdM Instance
- Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, “Preparing the IdM Server for Trust”.
- Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.
- Generate SIDs for each IdM user.
Note
Do not perform this step if the SIDs were generated when theipa-adtrust-install
utility was used to establish the trust.- Add a new
ipaNTSecurityIdentifier
attribute, containing a SID, automatically for each entry by running theipa-sidgen-task
operation on the back-end LDAP directory.[root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipa.example.com:389 -D "cn=directory manager" -w password dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: sidgen nsslapd-basedn: dc=ipadomain,dc=com delay: 0 adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
- After the task completes successfully, a message is recorded in the error logs that the SID generation task (
Sidgen task
) finished with a status of zero (0).[root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ... [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
- Verify the Kerberos configuration, as described in Section 5.2.2.1.3, “Verifying the Kerberos Configuration”.
5.2.2.5. Adding a Second Trust
- Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
- Create a trust agreement, as described in Section 5.2.2.1.2, “Creating a Trust Agreement”.
5.2.2.6. Creating a Trust in the Web UI
- Open the IdM web UI:
https://ipaserver.example.com
- Open the IPA Server main tab, and select the Trusts subtab.
- In the Trusts subtab, click Add to open the new trust configuration window.
- Fill in the required information about the trust:
- Provide the AD domain name in the Domain field.
- To set up the trust as two-way, select the Two-way trust check box. To set up the trust as one-way, leave Two-way trust unselected.For more information about one-way and two-way trusts, see Section 5.1.4, “One-Way and Two-Way Trusts”.
- To establish an external trust to a domain in another forest, select the External Trust check box.For more information, see Section 5.1.5, “External Trusts to Active Directory”.
- The Establish using section defines how the trust is to be established:
- To establish the trust using the AD administrator's user name and password, select Administrative account and provide the required credentials.
- Alternatively, to establish the trust with a shared password, select Pre-shared password and provide the trust password.
- Define the ID configuration for the trust:
- The Range type option allows you to choose the ID range type. If you want IdM to automatically detect what kind of ID range to use, select Detect.
- To define the starting ID of the ID range, use the Base ID field. To define the size of the ID range, use the Range size field. If you want IdM to use default values for the ID range, do not specify these options.
For more information about ID ranges, see the section called “ID Ranges”.
Figure 5.5. Adding a Trust in the Web UI
- Clickto save the new trust.
5.2.3. Post-installation Considerations for Cross-forest Trusts
5.2.3.1. Potential Behavior Issues with Active Directory Trust
5.2.3.1.1. Active Directory Users and IdM Administration
5.2.3.1.2. Authenticating Deleted Active Directory Users
5.2.3.1.3. Credential Cache Collections and Selecting Active Directory Principals
- service name
- host name
- realm name
kinit
utility and then uses SSH to connect to an IdM resource, the principal is not selected for the resource ticket. an IdM principal is used because the IdM principal matches the realm name of the resource.
Administrator
and the domain is ADEXAMPLE.ADREALM
, the principal is Administrator@ADEXAMPLE.ADREALM
.
[root@server ~]# kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: [root@server ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16
admin
), then there is a separate IdM credentials cache, with an IdM default principal. That IdM default principal is selected for a host ticket if the Active Directory user uses SSH to connect to a resource.
[root@vm-197 ~]# ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: [root@vm-197 ~]# klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0Default principal: admin@EXAMPLE.COM
>>>>> IdM user Valid starting Expires Service principal 27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM
>>>>> host principal
5.2.3.1.4. Resolving Group SIDs
Losing Kerberos Tickets
net getlocalsid
or net getdomainsid
, removes any existing admin ticket from the Kerberos cache.
Note
net getlocalsid
or net getdomainsid
in order to use Active Directory trusts.
Cannot Verify Group Membership for Users
Cannot Display Remote Active Directory Group Memberships for an Active Directory User
Important
id
utility can be used to display local group associations for Linux system users. However, id
does not display Active Directory group memberships for Active Directory users, even though Samba tools do display them.
ssh
utility to log into an IdM client machine as the given AD user. After the AD user logs in successfully for the first time, the id
search detects and displays the AD group memberships:
[root@ipaserver ~]# id ADDOMAIN\user uid=1921801107(user@ad.example.com) gid=1921801107(user@ad.example.com) groups=1921801107(user@ad.example.com),129600004(ad_users),1921800513(domain users@ad.example.com)
5.2.3.2. Configuring Trust Agents
AD trust agent
role installed. To configure the replica as a trust agent:
- On an existing trust controller, run the
ipa-adtrust-install --add-agents
command:[root@existing_trust_controller]# ipa-adtrust-install --add-agents
The command starts an interactive configuration session and prompts you for the information required to set up the agent.For further information about the--add-agents
option, see the ipa-adtrust-install(1) man page. - On the new replica:
- Restart the IdM service:
[root@new_trust_controller]# ipactl restart
- Remove all entries from the SSSD cache:
[root@new_trust_controller]# sssctl cache-remove
Note
To use thesssctl
command, the sssd-tools package must be installed. - Optionally, verify that the replica has the
AD trust agent
role installed:[root@new_trust_controller]# ipa server-show new_replica.idm.example.com ... Enabled server roles: CA server, NTP server, AD trust agent
5.3. Managing and Configuring a Cross-forest Trust Environment
5.3.1. User Principal Names in a Trusted Domains Environment
username@KERBEROS-REALM
. In an Active Directory forest it is possible to configure additional UPN suffixes. These enterprise principal names are used to provide alternative logins to the default UPN.
AD.EXAMPLE.COM
, the default UPN for a user is user@ad.example.com
. However often a company want instead their users to be able to log in using their email addresses, like user@example.com
. In this case the administrator adds an additional UPN suffix example.com
to the Active Directory forest and sets the new suffix in the user's account properties.
Active Directory Domain and Trust
utility or the PowerShell
command line tool.
Note
Active Directory Domain and Trust
utility.
ldapmodify
commands to set the userPrincipalName
attribute for users, because Active Directory does not validate those operations.
[root@ipaserver ~]# ipa trust-fetch-domains Realm-Name: ad.example.com ------------------------------- No new trust domains were found ------------------------------- ---------------------------- Number of entries returned 0 ----------------------------
[root@ipaserver ~]# ipa trust-show
Realm-Name: ad.example.com
Realm-Name: ad.example.com
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
Trust direction: Two-way trust
Trust type: Active Directory domain
UPN suffixes: example.com
ipaNTAdditionalSuffixes
in the cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com
subtree.
5.3.2. IdM Clients in an Active Directory DNS Domain
Important
5.3.2.1. Kerberos Single Sign-on to the IdM Client is not Required
- To ensure that the System Security Service Daemon (SSSD) on the client can communicate with the IdM servers, install the IdM client with the
--domain=IPA_DNS_Domain
option:[root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com
This option disables the SRV record auto-detection for the Active Directory DNS domain. - Locate the existing mapping for the Active Directory domain in the
[domain_realm]
section of the/etc/krb5.conf
configuration file:.ad.example.com = IDM.EXAMPLE.COM ad.example.com = IDM.EXAMPLE.COM
Replace both lines with a mapping entry for the Linux clients fully qualified domain name (FQDN) in the Active Directory DNS zone to the IdM realm:idm-client.ad.example.com = IDM.EXAMPLE.COM
Replacing the default mapping prevents Kerberos from sending its requests for the Active Directory domain to the IdM Kerberos Distribution Center (KDC). Instead Kerberos uses auto-discovery through SRV DNS records to locate the KDC. Only for the added hostidm-client.ad.example.com
the IdM KDC is set.
Note
Handling of SSL certificates
certmonger
can request a certificate for this name:
[root@idm-client.ad.example.com ~]# ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=ipa-client.ad.example.com \ -D ipa-client.ad.example.com \ -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \ -U id-kp-serverAuth
certmonger
service uses the default host key stored in the /etc/krb5.keytab
file to authenticate to the IdM Certificate Authority (CA).
5.3.2.2. Kerberos Single Sign-on to the IdM Client is Required
idm-client.idm.example.com
. You must create a CNAME record idm-client.ad.example.com
in the Active Directory DNS domain pointing to the A/AAAA record of the IdM client.
[libdefaults]
section of the /etc/krb5.conf
configuration file:
ignore_acceptor_hostname = true
Handling of SSL certificates
certmonger
can request a certificate for this name:
- Create a new host object:
[root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
Use the--force
option, because the host name is a CNAME and not an A/AAAA record. - Allow the IdM DNS host name to manage the Active Directory host entry in the IdM database:
[root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \ --hosts=idm-client.idm.example.com
[root@idm-client.idm.example.com ~]# ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=`hostname --fqdn` \ -D `hostname --fqdn` \ -D idm-client.ad.example.com \ -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \ -U id-kp-serverAuth
5.3.3. Creating IdM Groups for Active Directory Users
Note
- Optional. Create or select the group in the AD domain to use to manage AD users in the IdM realm. Multiple groups can be used and added to different groups on the IdM side.
- Create an external group in the IdM domain for the Active Directory users by adding the
--external
option to theipa group-add
command. The--external
option indicates that this group is intended to contain members from outside the IdM domain. For example:[root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external ------------------------------- Added group "ad_users_external" ------------------------------- Group name: ad_users_external Description: AD users external map
Note
The external group must be linked to a additional group of a user and not to the user's primary group. Active Directory stores group members inmember
attributes of a group, and IdM uses this attribute to resolve the members. However, Active Directory stores the primary group of users in theprimaryGroupID
attribute in the user's entry, which is not resolved. - Create a new IdM POSIX group or select an existing one for administering the IdM policies. For example, to create a new group:
[root@ipaserver ~]# ipa group-add --desc='AD users' ad_users ---------------------- Added group "ad_users" ---------------------- Group name: ad_users Description: AD users GID: 129600004
- Add the AD users or groups to the IdM external group as an external member. The AD member is identified by its fully-qualified name, such as
DOMAIN\group_name
orDOMAIN\username
. The AD identity is then mapped to the Active Directory SID for the user or group.For example, for an AD group:[root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users" [member user]: [member group]: Group name: ad_users_external Description: AD users external map External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2) ------------------------- Number of members added 1 -------------------------
- Add the external IdM group to the POSIX IdM group as a member. For example:
[root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external Group name: ad_users Description: AD users GID: 129600004 Member groups: ad_users_external ------------------------- Number of members added 1 -------------------------
5.3.4. Maintaining Trusts
5.3.4.1. Editing the Global Trust Configuration
ipa-adtrust-install
utility automatically automatically configures background information for the IdM domain which is required to create a trust with the Active Directory domain.
- A Windows-style security ID (SID); this attribute is autogenerated and cannot be modified
- A domain GUID; this attribute is autogenerated and cannot be modified
- A Kerberos domain name; this attribute comes from the IdM configuration and cannot be modified
- The default group to which to add IdM users; this attribute can be modified
- The NetBIOS name; it is not recommended to modify this attribute
cn=domain,cn=ad,cn=etc,dc=example,dc=com
subtree.
5.3.4.1.1. Changing the NetBIOS Name
Important
ipa-adtrust-install
utility. To change it later, run ipa-adtrust-install
again and specify the new NetBIOS name using the --netbios-name
option:
[root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME
5.3.4.1.2. Changing the Default Group for Windows Users
ipa-adtrust-install
utility. The default group cannot be deleted, but you can use the global trust configuration to specify another IdM group to be used as a fallback for the primary group of the IdM users.
ipa trustconfig-mod
command:
[root@server ~]# kinit admin [root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"
- Open the IdM web UI.
https://ipaserver.example.com
- Under the IPA Server main tab, select the Trusts subtab, and then open the Global Configuration section.
- Select a new group from all of the IdM groups in thedrop-down list.
Figure 5.6. Configuring the Default Group for Windows Users
- Clickto save the new configuration.
5.3.4.2. Discovering, Enabling, and Disabling Trust Domains
cn=subdomain,cn=trust_name,cn=ad,cn=trusts,dc=example,dc=com
in the trusts subtree.
trust-fetch-domains
command:
[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa trust-fetch-domains ad.example.com -------------------------------------------- List of trust domains successfully refreshed -------------------------------------------- Realm name: test.ad.example.com Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-87535643-5658642561-5780864324 Realm name: users.ad.example.com Domain NetBIOS name: USERS Domain Security Identifier: S-1-5-21-91314187-2404433721-1858927112 Realm name: prod.ad.example.com Domain NetBIOS name: PROD Domain Security Identifier: S-1-5-21-46580863-3346886432-4578854233 ---------------------------- Number of entries returned 3 ----------------------------
Note
ipa trust-add ad.domain --trust-secret
command, validate incoming trust at AD side using forest trust properties in the AD Domains and Trusts tool. Then, run the ipa trust-fetch-domains ad.domain
command. IdM will receive information about the trust, which will then be usable.
[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com ------------------------------------------ Disabled trust domain "test.ad.example.com" ------------------------------------------
trustdomain-enable
command.
[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa trustdomain-del prod.ad.example.com ------------------------------------------------------------------- Removed information about the trusted domain " "prod.ad.example.com" -------------------------------------------------------------------
5.3.4.3. Viewing and managing domains associated with IdM Kerberos realm
cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com
subtree in the IdM directory. The list of domains is used by IdM when it establishes a trust with Active Directory. Knowing the full list of domains managed by IdM allows the AD domain controller to know which authentication requests to route to the IdM KDC. The list of configured domains associated with IdM realm can be displayed using the realmdomains-show
command:
[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa realmdomains-show Domain: ipa.example.org, ipa.example.com, example.com
- A domain is automatically added to the domains list after a new DNS zone is added to IdM using the
ipa dnszone-add
command. Runningipa realmdomains-show
shows the new domain in the list of domains controlled by the IdM KDC:# kinit admin # ipa dnszone-add ipa2.example.com # ipa realmdomains-show Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
Deletion and other types of modification of domains associated with the IdM Kerberos realm are also taken care of automatically.
- If a DNS zone has been added that is part of the IdM Kerberos realm, the new domain has to be added manually to the IdM list of domains under the control of the IdM KDC. Add the new domain using the
ipa realmdomains-mod
command with the--add-domain
option:[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa realmdomains-mod --add-domain=ipa2.example.com Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
If a DNS zone has been deleted, you need to delete the domain associated with the IdM Kerberos realm manually, too:[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa realmdomains-mod --del-domain=ipa2.example.com Domain: ipa.example.org, ipa.example.com, example.com
If there are multiple changes to be made to the list of domains, the list itself can be modified and replaced using the--domain
option.[root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ipa2.example.com}
5.3.4.4. Adding Ranges for UID and GID Numbers in a Transitive Trust
ipa idrange-add
command with the following options:
- the
--base-id
option sets the base ID for the POSIX range, which is the starting number - The
--range-size
option sets the size of the POSIX ID range IdM uses. IdM maps the RID of users and groups in a trusted AD domain to POSIX IDs. The--range-size
option defines the maximum number of IDs IdM creates. AD uses a new RID for each user and group you create. If you delete a user or group, AD will not re-use the RID for future AD entries. Therefore, the range must be large enough for IdM to assign an ID to each existing AD user and group as well as the ones you create in the future. For example, if an administrator deletes 20000 of 50000 AD users and will, during the time, create 10000 new accounts, the range must be at least set to 60000. However, it is important that the range also contains enough reserves. In large environments, in which you expect that the default (200000) range size is not sufficient, set--range-size
to a higher value. - the
--rid-base
option sets the starting number of the RID, which is the far-right number in the SID; the value represents the range to add to the base ID to prevent conflicts - the
--dom-sid
option sets the domain SID, because there can be multiple domains configured for trusts
[root@server ~]$ kinit admin [root@server ~]$ ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range
Important
5.3.4.5. Adjusting DNA ID ranges manually
ipa idrange-find
command. If the newly adjusted range is not included in the IdM ID range, the command fails.
ipa-replica-manage dnarange-show
command to see currently assigned DNA ranges. To see the currently assigned on-deck DNA ranges, use the ipa-replica-manage dnanextrange-show
command.
Important
ipa-replica-manage dnarange-set
command:
# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
ipa-replica-manage dnanextrange-set
command:
# ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000
5.3.4.6. Kerberos Flags for Services and Hosts
OK_AS_DELEGATE
is required.
5.3.5. Setting PAC Types for Services
5.3.5.1. Setting Default PAC Types
- Open the IPA Server tab.
- Select the Configuration subtab.
- Scroll to the Service Options area.
Figure 5.7. The Service Options Area
- To use PAC, select the MS-PAC check box, which adds a certificate that can be used by AD services. If no check box is selected, then no PAC is added to Kerberos tickets.If you select the nfs:NONE check box, the MS-PAC record will not be added to the service tickets issued against NFS servers.
Note
You can ignore the PAD check box. This functionality is not yet available in IdM. - Click the Update link at the top of the page to save the changes.
5.3.5.2. Setting PAC Types for a Service
ipa service-mod
command with the --pac-type
option. For information on how to use the command, run it with the --help
option added:
$ ipa service-mod --help Usage: ipa [global-options] service-mod PRINCIPAL [options] Modify an existing IPA service. Options: -h, --help show this help message and exit ...
- Open the Identity tab, and select the Services subtab.
- Click the name of the service to edit.
- In the Service Settings area, check the Override inherited settings option and then select the MS-PAC check box to add a certificate that can be used by AD services.
Figure 5.8. The Service Settings Area
If no check box is selected, then no PACs are added to Kerberos tickets.Note
You can ignore the PAD check box. This functionality is not yet available in IdM. - Click the Update link at the top of the page to save the changes.
5.3.6. Using POSIX Attributes Defined in Active Directory
5.3.6.1. Defining UID and GID Attributes for Active Directory Users
5.3.6.2. Transferring Login Shell and Home Directory Attributes
Important
- the
loginShell
attribute, which specifies the AD user's shell - the
unixHomeDirectory
attribute, which specifies the AD user's home directory
subdomain_homedir
option in the [domain]
section of the /etc/sssd/sssd.conf
file on the IdM server must be set to %o
. The %o
value represents the home directory retrieved from the identity provider. For example:
[domain/example.com] subdomain_homedir = %o
loginShell
or unixHomeDirectory
on the AD side, the change is automatically reflected on the IdM side as well. If the attributes are not defined on the AD server, SSSD uses a template default value. This default value is then displayed to the IdM client.
5.3.7. Using SSH from Active Directory Machines for IdM Resources
5.3.7.1. Caching Considerations
- The entry has expired automatically.
- You manually expire the entry of the user in the cache using the
sss_cache
utility:# sss_cache --user user_name
- The user authenticates to an IdM server using the
kinit
utility or the web UI.
5.3.7.2. Using SSH Without Passwords
localauth
Kerberos plug-in for local authorization ensures that Kerberos principals are automatically mapped to local SSSD user names. With localauth
, Windows users from a trusted AD domain are not prompted for a password when logging in using Kerberos and can therefore use SSH without passwords.
sssd
connects to the Kerberos library to map the principal to a local POSIX identity, the SSSD plug-in maps them according to the trust agreements defined in IdM.
OK_AS_DELEGATE
Kerberos flag to the bastions host principal:
# ipa host-mod bastion_host.idm.example.com --ok-as-delegate=true
Kerberos Authentication for AD Users on Red Hat Enterprise Linux 7.1 and newer Systems
localauth
Kerberos plug-in.
user@AD.DOMAIN
, ad.domain\user
and AD\user
.
Note
localauth
, it is not required to set the auth_to_local
option in the /etc/krb5.conf
file or list Kerberos principals in the .k5login
file. The localauth
plug-in makes this previously used configuration for logins without passwords obsolete.
Manual Configuration of Kerberos Authentication for AD Users
localauth
plug-in is not present, SSH prompts for a user password for Active Directory domain users even if the user obtains a proper Kerberos ticket.
auth_to_local
option in the /etc/krb5.conf
file or list the user Kerberos principals in the .k5login
file in the home directory of the user.
- Configuring
/etc/krb5.conf
- The following procedure describes how to configure realm mapping in the Kerberos configuration.
- Open the
/etc/krb5.conf
file. - In the
[realms]
section, identify the IdM realm by name, and then add twoauth_to_local
lines to define the Kerberos principal name mapping:- In one rule, include a rule to map different Active Directory user name formats and the specific Active Directory domain.
- In the other rule, set the value of
DEFAULT
, for standard Unix user names.
For example:[realms] IDM = { .... auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/ auth_to_local = DEFAULT }
- Restart the KDC service.
[root@server ~]# systemctl restart krb5kdc.service
Note that if you configure Kerberos authentication using theauth_to_local
option, the user name used for SSH access must meet the following criteria:- The user name must have the format
ad_user@ad_domain
. - The domain name must be lowercase.
- The case of the user name must match the case of the user name in Active Directory. For example,
user
andUser
are considered different users because of the different cases.
For more information about settingauth_to_local
, see the krb5.conf(5) man page. - Configuring
.k5login
- The following procedure configures the system to find the Kerberos principal name for a local user name.
- Create the
.k5login
file in the user's home directory. - List the Kerberos principals used by the user in the file.
If the authenticating user matches the principal in an existing Kerberos ticket, the user is allowed to log in using the ticket and is not prompted for a password.Note that if you configure Kerberos authentication using the.k5login
configuration, the user name used for SSH access must have the formatad_user@ad_domain
.For more information about configuring the.k5login
file, see the .k5login(5) man page.
5.3.8. Using a Trust with Kerberos-enabled Web Applications
Note
[root@ipaserver ~]# systemctl restart httpd.service
KrbAuthRealms
- The
KrbAuthRealms
option gives the application location to the name of the IdM domain. This is required. Krb5Keytab
- The
Krb5Keytab
option gives the location for the IdM server keytab. This is required. KrbServiceName
- The
KrbServiceName
option sets the Kerberos service name used for the keytab (HTTP). This is recommended. KrbMethodK5Passwd
andKrbMethodNegotiate
- The
KrbMethodK5Passwd
Kerberos method option enables password-based authentication for valid users. TheKrbMethodNegotiate
option enables single sign-on (SSO) if a valid Kerberos ticket is available.These options are recommended for ease of use for many users. KrbLocalUserMapping
- The
KrbLocalUserMapping
option enables normal web logins (which are usually the UID or common name of the account) to be mapped to the fully-qualified user name (which has a format of user@REALM.COM).This option is strongly recommended. Without the domain name/login name mapping, the web login appears to be a different user account than the domain user. This means that users cannot see their expected data.For information on supported user name formats, see Section 5.2.1.9, “Supported User Name Formats”.
Example 5.1. Kerberos Configuration in an Apache Web Application
<Location "/mywebapp"> AuthType Kerberos AuthName "IPA Kerberos authentication" KrbMethodNegotiate on KrbMethodK5Passwd on KrbServiceName HTTPKrbAuthRealms IDM_DOMAIN
Krb5Keytab /etc/httpd/conf/ipa.keytab
KrbLocalUserMapping on
KrbSaveCredentials off Require valid-user </Location>
5.3.9. Configuring an IdM server as a Kerberos Distribution Center Proxy for Active Directory Kerberos communication
- On IdM clients, add the Active Directory realm to the [realms] section of the
/etc/krb5.conf
file. Set thekdc
andkpasswd_server
parameters to point to the IdM server's fully qualified domain name followed by/KdcProxy
':AD.EXAMPLE.COM = { kdc = https://server.idm.example.com/KdcProxy kpasswd_server = https://server.idm.example.com/KdcProxy }
- On IdM clients, disable the creation of
/var/lib/sss/pubconf/kdcinfo.*
files which could override the/etc/krb5.conf
specifications from the previous step. Edit the/etc/sssd/sssd.conf
file, setting thekrb5_use_kdcinfo
toFalse
:[domain/example.com] krb5_use_kdcinfo = False
- On IdM servers, set the
use_dns
option totrue
in the/etc/ipa/kdcproxy/kdcproxy.conf
file to utilize DNS service (SRV) records to find AD servers to communicate with:use_dns = true
Alternatively, if you do not want to use DNS SRV records, add explicit AD servers to the [realms] section of the/etc/krb5.conf
file:AD.EXAMPLE.COM = { kdc = ad-server.ad.example.com kpasswd_server = ad-server.ad.example.com }
Note
You can perform steps 2 and 3 of the procedure by running a script, for example an Ansible script. This is especially useful when making changes on multiple systems. - On IdM servers, restart IPA services:
# ipactl restart
- To verify that the procedure has been successful, run the following on an IdM client:
# rm /var/lib/sss/pubconf/kdcinfo* # kinit ad_user@AD.EXAMPLE.COM Password for ad_user@AD.EXAMPLE.COM: # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad_user@AD.EXAMPLE.COM Valid starting Expires Service principal [... output truncated ...]
5.4. Changing the LDAP Search Base for Users and Groups in a Trusted Active Directory Domain
5.4.1. Prerequisites
- To ensure that SSSD does not resolve all groups the users belongs to, consider disabling the support for the
tokenGroups
attribute on the Active Directory side.WithtokenGroups
enabled, SSSD resolves all groups the user belongs to because the attribute contains a flat list of SIDs. See Token-Groups attribute on Microsoft Developer Network for details about the attribute.
5.4.2. Configuring the LDAP Search Base to Restrict Searches
/etc/sssd/sssd.conf
file.
Considerations
- If your SSSD clients are directly joined to an Active Directory domain, perform this procedure on all the clients.
- If your SSSD clients are in an Identity Management domain that is in a trust with Active Directory, perform this procedure only on the Identity Management server.
Procedure
- Make sure the trusted domain has a separate
[domain]
section insssd.conf
. The headings of trusted domain sections follow this template:[domain/main_domain/trusted_domain]
For example:[domain/idm.example.com/ad.example.com]
- Edit the
sssd.conf
file to restrict the search base to a specific organizational unit (OU). For example, theldap_search_base
option changes the search base for all types of objects.[domain/idm.example.com/ad.example.com]
ldap_search_base = ou=finance,dc=ad,dc=example,dc=com
You can also use theldap_user_search_base
,ldap_group_search_base
,ldap_netgroup_search_base
, andldap_service_search_base
options. For more details on these options, see the sssd-ldap(5) man page. - Restart SSSD.
#
systemctl restart sssd.service
- To verify, resolve a few Active Directory users on the SSSD client. For example, to test a change to the user search base and group search base:
# getent passwd ad_user@ad.example.com
# getent group ad_group@ad.example.com
If SSSD is configured correctly, you are able to resolve only objects from the configured search base.
- Expire the SSSD caches.
#
sss_cache --everything
- In the general
[domain]
section ofsssd.conf
, set thedebug_level
option to9
. - Repeat the command for resolving a user.
- In the SSSD logs at
/var/log/sssd/
, look for messages from thesdap_get_generic_*
functions. The functions log the filter and search base used in user searches.
Additional Resources
- For a list of options you can use in trusted domain sections of
sssd.conf
, seeTRUSTED DOMAIN SECTION
in the sssd.conf(5) man page.
5.5. Changing the Format of User Names Displayed by SSSD
user_name@domain_name
format when displaying user names. Before you change the format, see Section 5.2.1.9, “Supported User Name Formats” to learn about the reason of this default value.
- Add the following entry to the domain's section in the
/etc/sssd/sssd.conf
file:full_name_format = %1$s
- Restart SSSD:
# systemctl restart sssd
5.6. Restricting Identity Management or SSSD to Selected Active Directory Servers or Sites in a Trusted Active Directory Domain
5.6.1. Configuring SSSD to Contact a Specific Active Directory Server
/etc/sssd/sssd.conf
file.
Considerations
- If your SSSD clients are directly joined to an Active Directory domain, perform this procedure on all the clients.In this setup, restricting the Active Directory domain controllers (DCs) or sites also configures the SSSD clients to connect to a particular server or site for authentication.
- If your SSSD clients are in an Identity Management domain that is in a trust with Active Directory, perform this procedure only on the Identity Management server.In this setup, restricting the Active Directory DCs or sites does not configure the Identity Management clients to connect to a particular server or site for authentication. Although trusted Active Directory users and groups are resolved through Identity Management servers, authentication is performed directly against the Active Directory DCs. Starting with Red Hat Enterprise Linux 7.6 and sssd-1.16.2-5.el7, you can configure SSSD on IdM clients to use a specific AD server or site using the
ad_server
andad_site
options. In prior versions of Red Hat Enterprise Linux 7, restrict authentication by defining the required Active Directory DCs in the/etc/krb5.conf
file on the clients.
Procedure
- Make sure the trusted domain has a separate
[domain]
section insssd.conf
. The headings of trusted domain sections follow this template:[domain/main_domain/trusted_domain]
For example:[domain/idm.example.com/ad.example.com]
- Edit the
sssd.conf
file to list the host names of the Active Directory servers or sites to which you want SSSD to connect.Use thead_server
and, optionally,ad_backup_server
options for Active Directory servers. Use thead_site
option for Active Directory sites. For more details on these options, see the sssd-ad(5) man page.For example:[domain/idm.example.com/ad.example.com]
ad_server = dc1.ad.example.com
- Restart SSSD.
#
systemctl restart sssd.service
- To verify, on the SSSD client, resolve or authenticate as an Active Directory user from the configured server or site. For example:
#
id ad_user@ad.example.com
- In the general
[domain]
section ofsssd.conf
, set thedebug_level
option to9
. - Inspect the SSSD logs at
/var/log/sssd/
to see which servers SSSD contacted.
Additional Resources
- For a list of options you can use in trusted domain sections of
sssd.conf
, seeTRUSTED DOMAIN SECTION
in the sssd.conf(5) man page.
5.7. Active Directory Trust for Legacy Linux Clients
nss_ldap
, nss-pam-ldapd
, or SSSD version 1.8 or earlier. Clients running the following versions of Red Hat Enterprise Linux do not use SSSD 1.9 and are therefore considered to be legacy clients:
- Red Hat Enterprise Linux 5.7 or later
- Red Hat Enterprise Linux 6.0 – 6.3
Important
- Kerberos authentication
- host-based access control (HBAC)
- SELinux user mapping
sudo
rules
- information look-up
- password authentication
5.7.1. Server-side Configuration for AD Trust for Legacy Clients
- The ipa-server package for IdM and the ipa-server-trust-ad package for the IdM trust add-on have been installed.
- The
ipa-server-install
utility has been run to set up the IdM server. - The
ipa-adtrust-install --enable-compat
command has been run, which ensures that the IdM server supports trusts with AD domains and that the compat LDAP tree is available.If you have already runipa-adtrust-install
without the--enable-compat
option in the past, run it again, this time adding--enable-compat
. - The
ipa trust-add ad.example.org
command has been run to establish the AD trust.
allow_all
rule is disabled, enable the system-auth
service on the IdM server, which allows authentication of the AD users.
allow_all
directly from the command line using the ipa hbacrule-show
command. If the rule is disabled, Enabled: FALSE
is displayed in the output:
[user@server ~]$ kinit admin
[user@server ~]$ ipa hbacrule-show allow_all
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
Note
system-auth
on the IdM server, create an HBAC service named system-auth
and add an HBAC rule using this service to grant access to IdM masters. Adding HBAC services and rules is described in Configuring Host-Based Access Control section in the Linux Domain Identity, Authentication, and Policy Guide. Note that HBAC services are PAM service names; if you add a new PAM service, make sure to create an HBAC service with the same name and then grant access to this service through HBAC rules.
5.7.2. Client-side Configuration Using the ipa-advise
Utility
ipa-advise
utility provides the configuration instructions to set up a legacy client for an AD trust.
ipa-advise
can provide configuration instructions, run ipa-advise
without any options. Running ipa-advise
prints the names of all available sets of configuration instructions along with the descriptions of what each set does and when it is recommended to be used.
[root@server ~]# ipa-advise config-redhat-nss-ldap : Instructions for configuring a system with nss-ldap as a IPA client. This set of instructions is targeted for platforms that include the authconfig utility, which are all Red Hat based platforms. config-redhat-nss-pam-ldapd : Instructions for configuring a system (...)
ipa-advise
utility with an instruction set as a parameter:
[root@server ~]# ipa-advise config-redhat-nss-ldap #!/bin/sh # ---------------------------------------------------------------------- # Instructions for configuring a system with nss-ldap as a IPA client. # This set of instructions is targeted for platforms that include the # authconfig utility, which are all Red Hat based platforms. # ---------------------------------------------------------------------- # Schema Compatibility plugin has not been configured on this server. To # configure it, run "ipa-adtrust-install --enable-compat" # Install required packages via yum yum install -y wget openssl nss_ldap authconfig # NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was # introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not # be able to interoperate with IPA server 3.x. # Please note that this script assumes /etc/openldap/cacerts as the # default CA certificate location. If this value is different on your # system the script needs to be modified accordingly. # Download the CA certificate of the IPA server mkdir -p -m 755 /etc/openldap/cacerts wget http://idm.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ca.crt (...)
ipa-advise
utility by running the displayed instructions as a shell script or by executing the instructions manually.
- Create the script file.
[root@server ~]# ipa-advise config-redhat-nss-ldap > setup_script.sh
- Add execute permissions to the file using the
chmod
utility.[root@server ~]# chmod +x setup_script.sh
- Copy the script to the client using the
scp
utility.[root@server ~]# scp setup_script.sh root@client
- Run the script on the client.
[root@client ~]# ./setup_script.sh
Important
Always read and review the script file carefully before you run it on the client.
ipa-advise
from the command line.
5.8. Troubleshooting Cross-forest Trusts
5.8.1. Troubleshooting the ipa-extdom Plug-in
ipa-extdom
to receive information about AD users and groups and forwards them to the requesting client.
Setting the Config Timeout of the ipa-extdom Plug-in
ipa-extdom
plug-in sends a request to SSSD for the data about AD users. However, not all requested data might be already in the cache of SSSD. In this case, SSSD requests the data from the AD domain controller (DC). This can be time-consuming for certain operations. The config timeout value defines the time in milliseconds of how long the ipa-extdom
plug-in waits for a reply of SSSD before the plug-in cancels the connection and returns a timeout error to the caller.
10000
milliseconds (10 seconds).
- If you set a too small value, such as
500
milliseconds, SSSD might not have enough time to reply and requests will always return a timeout. - If the value is too large, such as
30000
milliseconds (30 seconds), a single request might block the connection to SSSD for this amount of time. Since only one thread can connect to SSSD at a time, all other requests from the plug-in have to wait. - If there are many requests sent by IdM clients, they can block all available workers configured for Directory Server and, as a consequence, the server might not be able to reply to any kind of request for some time.
- If IdM clients frequently receive timeout errors before their own search timeout is reached when requesting information about AD users and groups, the config timeout value is too small.
- If the Directory Server on the IdM server is often locked and the
pstack
utility reports that many or all worker threads are handlingipa-extdom
requests at this time, the value is too large.
20000
milliseconds (20 seconds), enter:
# ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssTimeout ipaExtdomMaxNssTimeout: 20000
Setting the Maximum Size of the ipa-extdom Plug-in Buffer Used for NSS Calls
ipa-extdom
plug-in uses calls which use the same API as typical name service switch (NSS) calls to request data from SSSD. Those calls use a buffer where SSSD can store the requested data. If the buffer is too small, SSSD returns an ERANGE
error and the plug-in retries the request with a larger buffer. The ipaExtdomMaxNssBufSize
attribute in the cn=ipa_extdom_extop,cn=plugins,cn=config
entry of Directory Server on the IdM master defines the maximum size of the buffer in bytes.
134217728
bytes (128 MB). Only increase the value if, for example, a group has so many members that all names do not fit into the buffer and the IPA client cannot resolve the group.
268435456
bytes (256 MB), enter:
# ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssBufSize ipaExtdomMaxNssBufSize: 268435456
Part III. Integrating a Linux Domain with an Active Directory Domain: Synchronization
Active Directory
and Identity Management
users, how to migrate existing environments from synchronization to trust, and how to use ID Views
in Active Directory
environments.
Chapter 6. Synchronizing Active Directory and Identity Management Users
6.1. Supported Windows Platforms
- Forest functional level range: Windows Server 2008 - Windows Server 2012 R2
- Domain functional level range: Windows Server 2008 - Windows Server 2012 R2
- Windows Server 2012 R2
- Windows Server 2016
6.2. About Active Directory and Identity Management
Figure 6.1. Active Directory and IdM Synchronization
Windows Information | IdM Information |
---|---|
|
|
Figure 6.2. Synchronization Topology
- A synchronization operation runs every five minutes. To modify the frequency, set the
winSyncInterval
attribute in the Active Directory peers DN:cn=meTowinserver.ad.example.com,cn=replica,cn=dc\3Didm\,dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
- Synchronization can only be configured with one Active Directory domain.
- Synchronization can only be configured with one Active Directory domain controller.
- Only user information is synchronized; group information is not.
- Both user attributes and passwords can be synchronized.
- While modifications are bidirectional (going both from Active Directory to IdM and from IdM to Active Directory), creating accounts is only unidirectional, from Active Directory to Identity Management. New accounts created in Active Directory are synchronized over to IdM automatically. However, user accounts created in IdM must also be created in Active Directory before they will be synchronized. In this situation, the synchronization process tries to find a matching account with the same value for the
uid
attribute in IdM than for thesAMAccountName
attribute in Active Directory. If a match is found, the IdMntUserDomainId
attribute is set to the Active DirectoryobjectGUID
value. These attributes are globally unique and immutable, and entries stay synchronized, even if they are moved or renamed. - Account lock information is synchronized by default, so a user account which is disabled in one domain is disabled in the other.
- Password synchronization changes take effect immediately. If a user password is added or changed on one peer, that change is immediately propagated to the other peer server.The Password Synchronization client synchronizes new passwords or password updates.Existing passwords, which are stored in a hashed form in both IdM and Active Directory, cannot be decrypted or synchronized when the Password Synchronization client is installed, so existing passwords are not synchronized. User passwords must be changed to initiate synchronization between the peer servers.
- While there can only be one agreement, the PassSync service must be installed on every Active Directory server.
6.3. About Synchronized Attributes
Note
User Schema That Are the Same in Identity Management and Windows Servers
- cn[2]
- physicalDeliveryOfficeName
- description
- postOfficeBox
- destinationIndicator
- postalAddress
- facsimileTelephoneNumber
- postalCode
- givenname
- registeredAddress
- homePhone
- sn
- homePostalAddress
- st
- initials
- street
- l
- telephoneNumber
- mail
- teletexTerminalIdentifier
- mobile
- telexNumber
- o
- title
- ou
- userCertificate
- pager
- x121Address
Identity Management | Active Directory |
---|---|
cn[a] | name |
nsAccountLock | userAccountControl |
ntUserDomainId | sAMAccountName |
ntUserHomeDir | homeDirectory |
ntUserScriptPath | scriptPath |
ntUserLastLogon | lastLogon |
ntUserLastLogoff | lastLogoff |
ntUserAcctExpires | accountExpires |
ntUserCodePage | codePage |
ntUserLogonHours | logonHours |
ntUserMaxStorage | maxStorage |
ntUserProfile | profilePath |
ntUserParms | userParameters |
ntUserWorkstations | userWorkstations |
[a]
The cn is mapped directly (cn to cn ) when synchronizing from Identity Management to Active Directory. When synchronizing from Active Directory cn is mapped from the name attribute in Active Directory to the cn attribute in Identity Management.
|
6.3.1. User Schema Differences between Identity Management and Active Directory
6.3.1.1. Values for cn Attributes
cn
attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Identity Management cn
attribute is synchronized, then, only one value is sent to the Active Directory peer.
cn
value is added to an Active Directory entry and that value is not one of the values for cn
in Identity Management, then all of the Identity Management cn
values are overwritten with the single Active Directory value.
cn
attribute as its naming attribute, where Identity Management uses uid
. This means that there is the potential to rename the entry entirely (and accidentally) if the cn
attribute is edited in the Identity Management.
6.3.1.2. Values for street and streetAddress
streetAddress
for a user's postal address; this is the way that 389 Directory Server uses the street
attribute. There are two important differences in the way that Active Directory and Identity Management use the streetAddress
and street
attributes, respectively:
- In 389 Directory Server,
streetAddress
is an alias forstreet
. Active Directory also has thestreet
attribute, but it is a separate attribute that can hold an independent value, not an alias forstreetAddress
. - Active Directory defines both
streetAddress
andstreet
as single-valued attributes, while 389 Directory Server definesstreet
as a multi-valued attribute, as specified in RFC 4519.
streetAddress
and street
attributes, there are two rules to follow when setting address attributes in Active Directory and Identity Management:
- The synchronization process maps
streetAddress
in the Active Directory entry tostreet
in Identity Management. To avoid conflicts, thestreet
attribute should not be used in Active Directory. - Only one Identity Management
street
attribute value is synchronized to Active Directory. If thestreetAddress
attribute is changed in Active Directory and the new value does not already exist in Identity Management, then allstreet
attribute values in Identity Management are replaced with the new, single Active Directory value.
6.3.1.3. Constraints on the initials Attribute
initials
attribute, Active Directory imposes a maximum length constraint of six characters, but 389 Directory Server does not have a length limit. If an initials
attribute longer than six characters is added to Identity Management, the value is trimmed when it is synchronized with the Active Directory entry.
6.3.1.4. Requiring the surname (sn) Attribute
person
entries to be created without a surname attribute. However, RFC 4519 defines the person
object class as requiring a surname attribute, and this is the definition used in Directory Server.
person
entry is created without a surname attribute, that entry will not be synchronized over to IdM since it fails with an object class violation.
6.3.2. Active Directory Entries and POSIX Attributes
uidNumber
and gidNumber
attributes, WinSync does not synchronize these values over to Identity Management. Instead, it creates new UID and GID values in Identity Management.
uidNumber
and gidNumber
are different in Active Directory and in Identity Management.
6.4. Setting up Active Directory for Synchronization
6.4.1. Creating an Active Directory User for Synchronization
- Grant the synchronization user account Replicating directory changes rights to the synchronized Active Directory subtree. Replicator rights are required for the synchronization user to perform synchronization operations.Replicator rights are described in http://support.microsoft.com/kb/303972.
- Add the synchronization user as a member of the Account Operators and Enterprise Read-only Domain Controllers groups. It is not necessary for the user to belong to the Domain Admins group.
6.4.2. Setting up an Active Directory Certificate Authority
6.5. Managing Synchronization Agreements
6.5.1. Creating Synchronization Agreements
ipa-replica-manage connect
command because it creates a connection to the Active Directory domain. To establish an encrypted connection to Active Directory, IdM must to trust the Windows CA certificate.
- Copy the root certificate authority (CA) certificate to the IdM server:
- If your Active Directory CA certificate is self-signed:
- Export the Active Directory CA certificate on the Windows server.
- Press the Super key+R combination to open the Run dialog.
- Enter
certsrv.msc
and click . - Right-click on the name of the local Certificate Authority and choose Properties.
- On the General tab, select the certificate to export in the CA certificates field and click .
- On the Details tab, click to start the Certificate Export Wizard.
- Click Base-64 encoded X.509 (.CER)., and then select
- Specify a suitable directory and file name for the exported file. Clickto export the certificate, and then click .
- Copy the exported certificate to the IdM server machine.
- If your Active Directory CA certificate is signed by an external CA:
- To find out what certificate is the CA root certificate, display the certificate chain:
# openssl s_client -connect adserver.example.com:636 CONNECTED(00000003) depth=1 C = US, O = Demo Company, OU = IT, CN = Demo CA-28 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/O=Demo Company/OU=IT/CN=adserver.example.com i:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1 1 s:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1 i:/C=US/O=Demo Company/OU=IT/CN=Demo Root CA 2
The previous example shows that the Active Directory server's CA certificate is signed byCN=Demo CA-1
, which is signed byCN=Demo Root CA 2
. This means thatCN=Demo Root CA 2
is the root CA. - Copy the CA certificate to the IdM server.
- Remove any existing Kerberos credentials on the IdM server.
$ kdestroy
- Use the
ipa-replica-manage
command to create a Windows synchronization agreement. This requires the--winsync
option. If passwords will be synchronized as well as user accounts, then also use the--passsync
option and set a password to use for Password Synchronization.The--binddn
and--bindpw
options give the user name and password of the system account on the Active Directory server that IdM will use to connect to the Active Directory server.$ ipa-replica-manage connect --winsync \ --binddn cn=administrator,cn=users,dc=example,dc=com \ --bindpw Windows-secret \ --passsync secretpwd \ --cacert /etc/openldap/cacerts/windows.cer \ adserver.example.com -v
--winsync
: Identifies this as a Windows synchronization agreement.--binddn
: IdM uses this DN of an Active Directory account to bind to the remote directory and synchronize attributes.--bindpw
: Password for the synchronization account.--cacert
: Full path and file name to the:- Active Directory CA certificate, if the CA was self-signed.
- external CA certificate, if the Active Directory CA was signed by an external CA.
--win-subtree
: DN of the Windows directory subtree containing the users to synchronize. The default value iscn=Users,$SUFFIX
.AD_server_name
: Fully qualified domain name (FQDN) of the Active Directory domain controller.
- When prompted, enter the Directory Manager password.
- Optional. Configure Password Synchronization, as in Section 6.6.2, “Setting up Password Synchronization”. Without the Password Synchronization client, user attributes are synchronized between the peer servers, but passwords are not.
Note
The Password Synchronization client captures password changes and then synchronizes them between Active Directory and IdM. This means that it synchronizes new passwords or password updates.Existing passwords, which are stored in a hashed form in both IdM and Active Directory, cannot be decrypted or synchronized when the Password Synchronization client is installed, so existing passwords are not synchronized. User passwords must be changed to initiate synchronization between the peer servers.
6.5.2. Changing the Behavior for Synchronizing User Account Attributes
ldapmodify
command to modify the LDAP server entry directly.
ipaWinSyncAcctDisable
attribute. (Changing this means that if an account is disabled in Active Directory, it is still active in IdM and vice versa.)
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password dn: cn=ipa-winsync,cn=plugins,cn=config changetype: modify replace: ipaWinSyncAcctDisable ipaWinSyncAcctDisable: none modifying entry "cn=ipa-winsync,cn=plugins,cn=config"
General User Account Parameters
ipaWinSyncNewEntryFilter
: Sets the search filter to use to find the entry which contains the list of object classes to add to new user entries.Default value:(cn=ipaConfig)
ipaWinSyncNewUserOCAttr
: Sets the attribute in the configuration entry which actually contains the list of object classes to add to new user entries.Default value:ipauserobjectclasses
ipaWinSyncHomeDirAttr
: Identifies which attribute in the entry contains the default location of the POSIX home directory.Default value:ipaHomesRootDir
ipaWinSyncUserAttr
: Sets an additional attribute with a specific value to add to Active Directory users when they are synchronized over from the Active Directory domain. If the attribute is multi-valued, then it can be set multiple times, and the synchronization process adds all of the values to the entry.Example:ipaWinSyncUserAttr: attributeName attributeValue
Note
This only sets the attribute value if the entry does not already have that attribute present. If the attribute is present, then the entry's value is used when the Active Directory entry is synchronized over.ipaWinSyncForceSync
: Sets whether existing IdM users that match existing AD users should be forced to be synchronized. When set totrue
, such IdM users are automatically edited so that they are synchronized.Possible values:true | false
If an IdM user account has auid
parameter which is identical to thesAMAccountName
in an existing Active Directory user, then that account is not synchronized by default. This attribute tells the synchronization service to add thentUser
andntUserDomainId
to the IdM user entries automatically, which allows them to be synchronized.
User Account Lock Parameters
ipaWinSyncAcctDisable
: Sets which way to synchronize account lockout attributes. It is possible to control which account lockout settings are in effect. For example,to_ad
means that when account lockout attribute is set in IdM, its value is synchronized over to Active Directory and overrides the local Active Directory value. By default, account lockout attributes are synchronized from both domains.Possible values:both
(default),to_ad
,to_ds
,none
ipaWinSyncInactivatedFilter
: Sets the search filter to use to find the DN of the group used to hold inactivated (disabled) users. This does not need to be changed in most deployments.Default value:(&(cn=inactivated)(objectclass=groupOfNames))
Group Parameters
ipaWinSyncDefaultGroupAttr
: Sets the attribute in the new user account to reference to see what the default group for the user is. The group name in the entry is then used to find thegidNumber
for the user account.Default value:ipaDefaultPrimaryGroup
ipaWinSyncDefaultGroupFilter
: Sets the attribute in the new user account to reference to see what the default group for the user is. The group name in the entry is then used to find thegidNumber
for the user account.Default value:ipaDefaultPrimaryGroup
Realm Parameters
ipaWinSyncRealmAttr
: Sets the attribute which contains the realm name in the realm entry.Default value:cn
ipaWinSyncRealmFilter
: Sets the search filter to use to find the entry which contains the IdM realm name.Default value:(objectclass=krbRealmContainer)
6.5.3. Changing the Synchronized Windows Subtree
cn=users,cn=accounts,$SUFFIX
, and for Active Directory, the default is CN=Users,$SUFFIX
.
--win-subtree
option. After the agreement is created, the Active Directory subtree can be changed by using the ldapmodify
command to edit the nsds7WindowsReplicaSubtree
value in the synchronization agreement entry.
- Get the name of the synchronization agreement, using
ldapsearch
. This search returns only the values for thedn
andnsds7WindowsReplicaSubtree
attributes instead of the entire entry.[jsmith@ipaserver ~]$ ldapsearch -xLLL -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com -b cn=config objectclass=nsdswindowsreplicationagreement dn nsds7WindowsReplicaSubtree dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com ... 8< ...
- Modify the synchronization agreement
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -W -p 389 -h ipaserver.example.com <<EOF dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsds7WindowsReplicaSubtree nsds7WindowsReplicaSubtree: cn=alternateusers,dc=example,dc=com EOF modifying entry "cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
6.5.4. Configuring Uni-directional Synchronization
oneWaySync
parameter on the synchronization agreement. The possible values are fromWindows
(for Active Directory to Identity Management synchronization) and toWindows
(for Identity Management to Active Directory synchronization).
[jsmith@ipaserver ~]$ ldapmodify -x -D "cn=directory manager" -w password -p 389 -h ipaserver.example.com dn: cn=meToWindowsBox.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: oneWaySync oneWaySync: fromWindows
Important
6.5.5. Deleting Synchronization Agreements
ipa-replica-manage disconnect
command and then the host name of the Active Directory server.
- Delete the synchronization agreement.
# ipa-replica-manage disconnect adserver.ad.example.com
- List the certificates in the IdM directory certificate database:
# certutil -L -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IDM.EXAMPLE.COM IPA CA CT,C,C CN=adserver,DC=ad,DC=example,DC=com C,, Server-Cert u,u,u
- Remove the Active Directory CA certificate from the IdM server database:
# certutil -D -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -n "CN=adserver,DC=ad,DC=example,DC=com"
6.5.6. Winsync Agreement Failures
One of the most common synchronization agreement failures is that the IdM server cannot connect to the Active Directory server:
"Update failed! Status: [81 - LDAP error: Can't contact LDAP server]
/etc/dirsrv/slapd-DOMAIN/
directory) with the name Imported CA. This can be checked using certutil
:
$ certutil -L -d /etc/dirsrv/slapd-DOMAIN/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA certificate CTu,u,Cu Imported CA CT,,C Server-Cert u,u,u Imported CA CT,,C
# certutil -d /etc/dirsrv/slapd-DOMAIN-NAME -D -n "Imported CA"
For some entries in the user database, there may be an informational error message that the password is not being reset because the entry already exists:
"Windows PassSync entry exists, not resetting password"
6.6. Managing Password Synchronization
Note
6.6.1. Setting up the Windows Server for Password Synchronization
- Active Directory must be running in SSL.
Note
Install the Microsoft Certificate System in Enterprise Root Mode. Active Directory will then automatically enroll to retrieve its SSL server certificate. - The Password Synchronization Service must be installed on each Active Directory domain controller. To synchronize a password from Windows, the PassSync service requires access to the unencrypted password to synchronize it over a secure connection to IdM. Because users can change their passwords on every domain controller, the installation of the PassSync service on each domain controller is necessary.
- The password policy must be set similar on IdM and Active Directory side. When the synchronization destination receives an updated password, it was only validated to match the policy on the source. It is not re-validated on the synchronization destination.
> dsquery * -scope base -attr pwdProperties pwdProperties 1
pwdProperties
is set to 1
, the password complexity policy is enabled for the domain.
Note
- Run
gpmc.msc
from the command line. - Select.
- Open→ → .
- Right-click theentry and select .
- The
Group Policy Management Editor
opens automatically. - Open→ → → → → .
- Enable the
Password must meet complexity requirements
option and save.
6.6.2. Setting up Password Synchronization
- Download the
RedHat-PassSync-*.msi
file to the Active Directory domain controller:- Log in to the Customer Portal.
- Click Downloads at the top of the page.
- Select Red Hat Enterprise Linux from the product list.
- Select the most recent version of Red Hat Enterprise Linux 6 or Red Hat Enterprise Linux 7 and architecture.
- Download WinSync Installer for the architecture of the Active Directory domain controller by clicking the button.
- Double-click the
MSI
file to install it. - The Password Synchronrization Setup window appears. Hit Next to begin installing.
- Fill in the information to establish the connection to the IdM server.
- The IdM server connection information, including the host name and secure port number.
- The user name of the system user which Active Directory uses to connect to the IdM machine. This account is configured automatically when synchronization is configured on the IdM server. The default account is
uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com
. - The password set in the
--passsync
option when the synchronization agreement was created. - The search base for the people subtree on the IdM server. The Active Directory server connects to the IdM server similar to an
ldapsearch
or replication operation, so it has to know where in the IdM subtree to look for user accounts. The user subtree iscn=users,cn=accounts,dc=example,dc=com
. - The certificate token is not used at this time, so that field should be left blank.
Hit, then to install Password Synchronization. - Import the IdM server's CA certificate into the PassSync certificate store.
- Download the IdM server's CA certificate from
http://ipa.example.com/ipa/config/ca.crt
. - Copy the IdM CA certificate to the Active Directory server.
- Install the IdM CA certificate in the Password Synchronization database. For example:
cd "C:\Program Files\Red Hat Directory Password Synchronization" certutil.exe -d . -A -n "IPASERVER.EXAMPLE.COM IPA CA" -t CT,, -a -i ipaca.crt
- Reboot the Windows machine to start Password Synchronization.
Note
The Windows machine must be rebooted. Without the rebooting,PasswordHook.dll
is not enabled, and password synchronization will not function. - If passwords for existing accounts should be synchronized, reset the user passwords.
Note
The Password Synchronization client captures password changes and then synchronizes them between Active Directory and IdM. This means that it synchronizes new passwords or password updates.Existing passwords, which are stored in a hashed form in both IdM and Active Directory, cannot be decrypted or synchronized when the Password Synchronization client is installed, so existing passwords are not synchronized. User passwords must be changed to initiate synchronization between the peer servers.
.msi
.
admin
group. This is an intended behavior to prevent, for example, password synchronization agents or low level user administrators to change passwords of top level administrators.
Note
cn
is treated differently than other synchronized attributes. It is mapped directly (cn
to cn
) when synchronizing from Identity Management to Active Directory. When synchronizing from Active Directory to Identity Management, however, cn
is mapped from the name
attribute on Windows to the cn
attribute in Identity Management.
Chapter 7. Migrating Existing Environments from Synchronization to Trust
7.1. Migrate from Synchronization to Trust Automatically Using ipa-winsync-migrate
Important
ipa-winsync-migrate
utility is only available on systems running Red Hat Enterprise Linux 7.2 or later.
7.1.1. How Migration Using ipa-winsync-migrate
Works
ipa-winsync-migrate
utility migrates all synchronized users from an AD forest, while preserving the existing configuration in the Winsync environment and transferring it into the AD trust. For each AD user created by the Winsync agreement, ipa-winsync-migrate
creates an ID override in the Default Trust View (see Section 8.1, “Active Directory Default Trust View”).
- The ID overrides for the AD users have the following attributes copied from the original entry in Winsync:
- Login name (
uid
) - UID number (
uidnumber
) - GID number (
gidnumber
) - Home directory (
homedirectory
) - GECOS entry (
gecos
)
- The user accounts in the AD trust keep their original configuration in IdM, which includes:
- POSIX attributes
- User groups
- Role-based access control rules
- Host-based access control rules
- SELinux membership
sudo
rules
- The new AD users are added as members of an external IdM group.
- The original Winsync replication agreement, the original synchronized user accounts, and all local copies of the user accounts are removed.
Note
The user must make sure before callingipa-winsync-migrate
that there is no entry on the AD side with the same name as the IdM administrator ("admin" by default). Otherwiseipa-winsync-migrate
will remove the local copy of the "admin" user account, meaning that it will delete IdM admin user.
7.1.2. How to Migrate Using ipa-winsync-migrate
- Back up your IdM setup using the
ipa-backup
utility. See Backing Up and Restoring Identity Management in the Linux Domain Identity, Authentication, and Policy Guide.Reason: The migration affects a significant part of the IdM configuration and many user accounts. Creating a backup enables you to restore your original setup if necessary.
- Create a trust with the synchronized domain. See Chapter 5, Creating Cross-forest Trusts with Active Directory and Identity Management.
- Run
ipa-winsync-migrate
and specify the AD realm and the host name of the AD domain controller:# ipa-winsync-migrate --realm example.com --server ad.example.com
If a conflict occurs in the overrides created byipa-winsync-migrate
, information about the conflict is displayed, but the migration continues. - Uninstall the Password Sync service from the AD server. This removes the synchronization agreement from the AD domain controllers.
7.2. Migrate from Synchronization to Trust Manually Using ID Views
- Create a backup of the original synchronized user or group entries.
- Create a trust with the synchronized domain. For information about creating trusts, see Chapter 5, Creating Cross-forest Trusts with Active Directory and Identity Management.
- For every synchronized user or group, preserve the UID and GIDs generated by IdM by doing one of the following:
- Individually create an ID view applied to the specific host and add user ID overrides to the view.
- Create user ID overrides in the Default Trust View.
Note
Only IdM users can manage ID views. AD users cannot. - Delete the original synchronized user or group entries.
Chapter 8. Using ID Views in Active Directory Environments
Note
- Overriding AD User Attributes, such as POSIX Attributes or SSH Login Details
- See Section 8.3, “Using ID Views to Define AD User Attributes” for details.
- Migrating from synchronization-based to trust-based integration
- Performing per-host group override of the IdM user attributes
- See Section 8.4, “Migrating NIS Domains to IdM” for details.
8.1. Active Directory Default Trust View
8.1.1. What Is the Default Trust View
ipa-adtrust-install
and cannot be deleted.
Values in AD | Default Trust View | Result | ||
---|---|---|---|---|
Login | ad_user | ad_user | → | ad_user |
UID | 111 | 222 | → | 222 |
GID | 111 | (no value) | → | 111 |
Note
8.1.2. Overriding the Default Trust View with Other ID Views
- If an attribute is defined in the host-specific ID view, IdM applies the value from this view.
- If an attribute is not defined in the host-specific ID view, IdM applies the value from the Default Trust View.
Values in AD | Default Trust View | Host-Specific View | Result | ||
---|---|---|---|---|---|
Login | ad_user | ad_user | (no value) | → | ad_user |
UID | 111 | 222 | 333 | → | 333 |
GID | 111 | (no value) | 333 | → | 333 |
8.1.3. ID Overrides on Clients Based on the Client Version
- Legacy clients: RHEL 6.3 and earlier (SSSD 1.8 and earlier)
- The clients can request a specific ID view to be applied.To use a host-specific ID view on a legacy client, change the base DN on the client to:
cn=id_view_name,cn=views,cn=compat,dc=example,dc=com
. - RHEL 6.4 to 7.0 (SSSD 1.9 to 1.11)
- Host-specific ID views on the clients are not supported.
- RHEL 7.1 and later (SSSD 1.12 and later)
- Full support.
8.2. Fixing ID Conflicts
8.3. Using ID Views to Define AD User Attributes
Note
- Create a new ID view.
- Add a user ID override in the ID view, and specify the require attribute value.
- Apply the ID view to a specific host.
8.4. Migrating NIS Domains to IdM
- Create the users and groups in the IdM domain. For details, see
- Use ID views for existing hosts to override the IDs IdM generated during the user creation:
- Create an individual ID view.
- Add ID overrides for the users and groups to the ID view.
- Assign the ID view to the specific hosts.
- Installing and Uninstalling Identity Management Clients in the Linux Domain Identity, Authentication, and Policy Guide.
- Decommission the NIS domains.
8.5. Configuration Options for Using Short Names to Resolve and Authenticate Users and Groups
user_name@domain
or domain\user_name
fully qualified names format to resolve and authenticate users and groups in an Active Directory (AD) environment. You can configure this:
- in Identity Management (IdM) that trusts AD
- on Red Hat Enterprise Linux joined to an AD using SSSD
8.5.1. How Domain Resolution Works
domain resolution order
option to specify the order in which a list of domains is searched to return a match for a given user name. You can set the option:
domain resolution order
option can be set in more than one of the three locations above. The order in which a client consults the three locations is:
- the local
sssd.conf
configuration - the id view configuration
- the global IdM configuration
Note
- A user name exists in multiple domains
- The SSSD configuration includes the
default_domain_suffix
option and you want to make a request towards a domain not specified with that option
8.5.2. Configuring the Domain Resolution Order on an Identity Management Server
8.5.2.1. Setting the Domain Resolution Order Globally
ipa config-mod
command. For example, in an IdM domain that trusts an AD forest with multiple child domains:
$ ipa config-mod --domain-resolution-order='idm.example.com:ad.example.com:subdomain1.ad.example.com:subdomain2.ad.example.com' Maximum username length: 32 Home directory base: /home ... Domain Resolution Order: idm.example.com:ad.example.com:subdomain1.ad.example.com:subdomain2.ad.example.com ...With the domain resolution order set in this way, users from both the IdM domain and from the trusted AD forest can log in using short names only.
8.5.2.2. Setting the Domain Resolution Order for an ID view
- Create an ID view with the
domain resolution order
option set:$ ipa idview-add example_view --desc "ID view for custom shortname resolution on server.idm.example.com" --domain-resolution-order subdomain2.ad.example.com:subdomain1.ad.example.com --------------------------------- Added ID View "example_view" --------------------------------- ID View Name: example_view Description: ID view for custom shortname resolution on server.idm.example.com Domain Resolution Order: subdomain2.ad.example.com:subdomain1.ad.example.com
- Apply the view on the clients. For example:
$ ipa idview-apply example_view --hosts server.idm.example.com ----------------------------------- Applied ID View "example_view" ----------------------------------- hosts: server.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
8.5.3. Configuring the Domain Resolution Order on an IdM Client
domain_resolution_order
option, in the [sssd] section, in the /etc/sssd/sssd.conf
file, for example:
domain_resolution_order = subdomain1.ad.example.com, subdomain2.ad.example.com
domain_resolution_order
option, see the sssd.conf(5) man page.
Appendix A. Revision History
Revision History | |||
---|---|---|---|
Revision 7.0-51 | Thu Mar 4 2021 | ||
| |||
Revision 7.0-50 | Wed May 27 2020 | ||
| |||
Revision 7.0-49 | Tue Aug 06 2019 | ||
| |||
Revision 7.0-48 | Wed Jun 05 2019 | ||
| |||
Revision 7.0-47 | Tue Apr 08 2019 | ||
| |||
Revision 7.0-46 | Mon Oct 29 2018 | ||
| |||
Revision 7.0-45 | Mon Jun 25 2018 | ||
| |||
Revision 7.0-44 | Thu Apr 5 2018 | ||
| |||
Revision 7.0-43 | Wed Feb 28 2018 | ||
| |||
Revision 7.0-42 | Mon Feb 12 2018 | ||
| |||
Revision 7.0-41 | Mon Jan 29 2018 | ||
| |||
Revision 7.0-40 | Fri Dec 15 2017 | ||
| |||
Revision 7.0-39 | Mon Dec 6 2017 | ||
| |||
Revision 7.0-38 | Mon Dec 4 2017 | ||
| |||
Revision 7.0-37 | Mon Nov 20 2017 | ||
| |||
Revision 7.0-36 | Mon Nov 6 2017 | ||
| |||
Revision 7.0-35 | Mon Oct 23 2017 | ||
| |||
Revision 7.0-34 | Mon Oct 9 2017 | ||
| |||
Revision 7.0-33 | Tue Sep 26 2017 | ||
| |||
Revision 7.0-32 | Tue Jul 18 2017 | ||
| |||
Revision 7.0-31 | Tue May 23 2017 | ||
| |||
Revision 7.0-30 | Mon Apr 24 2017 | ||
| |||
Revision 7.0-29 | Mon Apr 10 2017 | ||
| |||
Revision 7.0-28 | Mon Mar 27 2017 | ||
| |||
Revision 7.0-27 | Mon Feb 27 2017 | ||
| |||
Revision 7.0-26 | Wed Nov 23 2016 | ||
| |||
Revision 7.0-25 | Tue Oct 18 2016 | ||
| |||
Revision 7.0-24 | Thu Jul 28 2016 | ||
| |||
Revision 7.0-23 | Thu Jun 09 2016 | ||
| |||
Revision 7.0-22 | Tue Feb 09 2016 | ||
| |||
Revision 7.0-21 | Fri Nov 13 2015 | ||
| |||
Revision 7.0-20 | Thu Nov 12 2015 | ||
| |||
Revision 7.0-19 | Fri Sep 18 2015 | ||
| |||
Revision 7.0-18 | Thu Sep 10 2015 | ||
| |||
Revision 7.0-17 | Mon Jul 27 2015 | ||
| |||
Revision 7.0-16 | Thu Apr 02 2015 | ||
| |||
Revision 7.0-15 | Fri Mar 13 2015 | ||
| |||
Revision 7.0-13 | Wed Feb 25 2015 | ||
| |||
Revision 7.0-11 | Fri Dec 05 2014 | ||
| |||
Revision 7.0-7 | Mon Sep 15 2014 | ||
| |||
Revision 7.0-5 | June 27, 2014 | ||
| |||
Revision 7.0-4 | June 13, 2014 | ||
| |||
Revision 7.0-3 | June 11, 2014 | ||
|