Red Hat Enterprise Linux 7 Show
Integrating Linux systems with Active Directory environmentsMarc MuehlfeldRed Hat Customer Content Services Filip HanzelkaRed Hat Customer Content Services Lucie MaňáskováRed Hat Customer Content Services Aneta Šteflová PetrováRed Hat Customer Content Services Tomáš ČapekRed Hat Customer Content Services Ella Deon BallardRed Hat Customer Content Services Abstract Heterogeneous IT environments often contain various different domains and operating systems that need to be able to seamlessly communicate. Red Hat Enterprise Linux offers multiple ways to tightly integrate Linux domains with Active Directory (AD) on Microsoft Windows. The integration is possible on different domain objects that include users, groups, services, or systems. This guide also covers different integration scenarios, ranging from lightweight AD pass-through authentication to full-fledged Kerberos trusted realms. In addition to this guide, you can find documentation on other features and services related to Red Hat Enterprise Linux Identity Management in the following guides: 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 Chapter 1. Ways to Integrate Active Directory and Linux EnvironmentsIT environments have a structure. The systems in them are arranged with a purpose. Integrating two separate infrastructures requires an assessment of the purpose of each of those environments and an understanding of how and where they interact. 1.1. Defining Windows IntegrationWindows integration can mean very different things, depending on the required interaction between the Linux environment and the Windows environment. It could mean that individual Linux systems are enrolled into a Windows domain, it could mean that a Linux domain is configured to be a peer to the Windows domain, or it could simply mean that information is copied between environments. There are several points of contact between a Windows domain and Linux systems. Each of these points revolve around identifying different domain objects (users, groups, systems, services) and the services which are used in that identification. User Identities and Authentication
In most environments, the Active Directory domain is the central hub for user information, which means that there needs to be some way for Linux systems to access that user information for authentication requests. The real question then is how to obtain that user information and how much of that information is available to external systems. There also needs to be a balance between information required for Linux systems (POSIX attributes) and Linux users (certain application administrators) and how that information is managed. Host and Service Principals
DNS Domains, Queries, and Name Resolution
Security Policies
Change Management
As important as which elements in the domains are integrated, is how that integration is maintained. If a particular instrument of integration is heavily manual, yet the environment has a large number of systems which are frequently updated, then that one instrument may not work for that environment from a maintenance standpoint. The following sections outline the main scenarios for integration with Windows. In direct integration, Linux systems are connected to Active Directory without any additional intermediaries. Indirect integration, on the other hand, involves an identity server that centrally manages Linux systems and connects the whole environment to Active Directory of the server-to-server level. 1.2. Direct IntegrationYou need two components to connect a Linux system to Active Directory (AD). One component interacts with the central identity and authentication source, which is AD in this case. The other component detects available domains and configures the first component to work with the right identity source. There are different options that can be used to retrieve information and perform authentication against AD. Among them are: Native LDAP and Kerberos PAM and NSS modules Among these modules are 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 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:
The main reason to transition from Winbind to SSSD is that SSSD can be used for both direct and indirect integration and allows to switch from one integration approach to another without significant migration costs. The most convenient way to configure SSSD or Winbind in order to directly integrate a Linux system with AD is to use the Direct integration is a simple way to introduce Linux systems to AD environment. However, as the share of Linux systems grows, the deployments usually see the need for a better centralized management of the identity-related policies such as host-based access control, sudo, or SELinux user mappings. At first, the configuration of these aspects of the Linux systems can be maintained in local configuration files. With a growing number of systems though, distribution and management of the configuration files is easier with a provisioning system such as Red Hat Satellite. This approach creates an overhead of changing the configuration files and then distributing them. When direct integration does not scale anymore, it is more beneficial to consider indirect integration described in the next section. 1.2.1. Supported Windows Platforms for direct integrationYou can directly integrate your Linux machine with Active Directory forests that use the following forest and domain functional levels:
Direct integration has been tested on the following supported operating systems using the mentioned functional levels:
1.3. Indirect IntegrationThe main advantage of the indirect integration is to manage Linux systems and policies related to those systems centrally while enabling users from Active Directory (AD) domains to transparently access Linux systems and services. There are two different approaches to the 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. 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: Synchronization-based solutionAn 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:
In some integration scenarios, the user synchronization may be the only available option, but in general, use of the synchronization approach is discouraged in favor of the cross-realm trust-based integration. Part I. Adding a Single Linux System to an Active Directory Domain This part describes how the System Security Services Daemon ( Chapter 2. Using Active Directory as an Identity Provider for SSSDThe System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client) to an external back-end system (a domain). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm. When used as an identity management service for AD integration, SSSD is an alternative to services such as NIS or Winbind. This chapter describes how SSSD works with AD. For more details on SSSD, see the System-Level Authentication Guide. 2.1. How the AD Provider Handles Trusted Domains This section describes how SSSD handles trusted domains if you set
2.2. Configuring an AD Provider for SSSDThe AD provider enables SSSD to use the LDAP identity provider and the Kerberos authentication provider with optimizations for AD environments. 2.2.1. Overview of the Integration OptionsLinux and Windows systems use different identifiers for users and groups:
Do not use the same user name in Windows and Active Directory. Users authenticating to a Red Hat Enterprise Linux system, including AD users, must have a UID and GID assigned. For this purpose, SSSD provides the following integration options: 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 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:
AD can create and store POSIX attributes, such as 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.3. Configuring SSSD to Use POSIX Attributes Defined in ADPreviously, the Identity Management for UNIX extension was available to provide POSIX attributes to user accounts. The extension is now deprecated. See the Microsoft Developer Network for details. If you have been using Identity Management for UNIX, see this Knowledgebase article for answers to frequently asked questions. For old procedures that reference Identity Management for Unix and the Services for Unix package, see these Red Hat Knowledgebase articles: RecommendationsFor best performance, publish the POSIX attributes to the AD global catalog. If POSIX attributes are not present in the global catalog, SSSD connects to the individual domain controllers directly on the LDAP port. Join the Linux System to the AD DomainDisable ID Mapping in SSSD
SSSD will now use POSIX attributes from AD, instead of creating them locally. Additional Resources For further details about ID mapping and the 2.3. Automatic Kerberos Host Keytab RenewalSSSD automatically renews the Kerberos host keytab file in an AD environment if the adcli package is installed. The daemon checks daily if the machine account password is older than the configured value and renews it if necessary. The default renewal interval is 30 days. To change the default:
To disable the automatic Kerberos host keytab renewal, set
2.4. Enabling Dynamic DNS UpdatesAD allows its clients to refresh their DNS records automatically. AD also actively maintains DNS records to make sure they are updated, including timing out (aging) and removing (scavenging) inactive records. DNS scavenging is not enabled by default on the AD side. SSSD allows the Linux system to imitate a Windows client by refreshing its DNS record, which also prevents its record from being marked inactive and removed from the DNS record. When dynamic DNS updates are enabled, the client's DNS record is refreshed:
DNS updates are sent to the AD server using Kerberos/GSSAPI for DNS (GSS-TSIG). This means that only secure connections need to be enabled. The dynamic DNS configuration is set for each domain. For example: [domain/ad.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = ad For details on these options, see the sssd-ad(5) man page. 2.5. Using Range Retrieval Searches with SSSDSSSD supports AD's Searching Using Range Retrieval feature. For details on range retrieval searches, see the Microsoft Developer Network. If you set custom filters in the group or search bases, the filters might not work well with very large groups. 2.6. Group Policy Object Access ControlGroup Policy is a Microsoft Windows feature that enables administrators to centrally manage policies for users and computers in Active Directory (AD) environments. A group policy object (GPO) is a collection of policy settings that are stored on a domain controller (DC) and can be applied to policy targets, such as computers and users. GPO policy settings related to Windows logon rights are commonly used to manage computer-based access control in AD environments. 2.6.1. How SSSD Works with GPO Access ControlWhen you configure SSSD to apply GPO access control, SSSD retrieves GPOs applicable to host systems and AD users. Based on the retrieved GPO configuration, SSSD determines if a user is allowed to log in to a particular host. This enables the administrator to define login policies honored by both Linux and Windows clients centrally on the AD domain controller. Security filtering is a feature that enables you to further limit the scope of GPO access control to specific users, groups, or hosts by listing them in the security filter. However, SSSD only supports users and groups in the security filter. SSSD ignores host entries in the security filter. To ensure that SSSD applies the GPO access control to a specific system, create a new OU in the AD domain, move the system to the OU, and then link the GPO to this OU. 2.6.2. GPO Settings Supported by SSSDTable 2.2. GPO access control options retrieved by SSSD
2.6.3. Configuring GPO-based Access Control for SSSD GPO-based access control can be configured in the
The ad_gpo_access_control = enforcing The ad_gpo_access_control = disabled The Before starting to use the GPO-based access control and setting
The following parameters related to the GPO-based access control can also be specified in the
For a detailed list of available GPO parameters as well as their descriptions and default values, see the sssd-ad(5) man page. 2.6.4. Additional Resources2.9. Troubleshooting SSSDFor details about troubleshooting SSSD, see the Troubleshooting SSSD appendix in the System-Level Authentication Guide.
Chapter 3. Using realmd to Connect to an Active Directory Domain The Chapter 2, Using Active Directory as an Identity Provider for SSSD describes how to use the System Security Services Daemon (SSSD) on a local system and Active Directory as a back-end identity provider. Ensuring that the system is properly configured for this can be a complex task: there are a number of different configuration parameters for each possible identity provider and for SSSD itself. In addition, all domain information must be available in advance and then properly formatted in the SSSD configuration for SSSD to integrate the local system with AD. The 3.1. Supported Domain Types and Clients The
The following domain clients are supported by
3.2. Prerequisites for Using realmd To use the # yum install realmd In
addition, make sure that the oddjob, oddjob-mkhomedir, sssd, and adcli packages are installed. These packages are required to be able to manage the system using 3.3. realmd Commands The
The central utility in realm command arguments For example: realm join ad.example.com realm permit user_name Table 3.1. realmd Commands
For more information about the 3.4. Discovering and Joining Identity Domains The The
Discovering Domains When run without any options, the # 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 It is also possible to run a discovery for a specific domain. To do this, run # realm discover ad.example.com The The The # realm discover --server-software=active-directory One of the attributes returned in the discovery search is For more information about the Joining a DomainNote that Active Directory domains require unique computer names to be used. Both NetBIOS computer name and its DNS host name should be uniquely defined and correspond to each other. To join the system to an identity domain, use the # realm join ad.example.com realm: Joined ad.example.com domain By default, the join is performed as the domain administrator. For AD, the administrator account is called # realm join ad.example.com -U user The command first attempts to connect without credentials, but it prompts for a password if required. If Kerberos is properly configured on a Linux system, joining can also be performed with a Kerberos ticket for authentication. To select a
Kerberos principal, use the # kinit user # realm join ad.example.com -U user The Example 3.1. Example Procedure for Enrolling a System into a Domain
Note that when discovering or joining a domain,
The record is created by default when AD is configured, which enables it to be found by the service discovery. Testing the System Configuration after Joining a DomainTo test whether the system was successfully enrolled into a domain, verify that you can log in as a user from the domain and that the user information is displayed correctly:
The 3.6. Listing Domains The # realm list --all --name-only ad.example.com The most notable options accepted by
The --name-only
The For more information about the 3.7. Managing Login Permissions for Domain UsersBy default, domain-side access control is applied, which means that login policies for domain users are defined in the domain itself. This default behavior can be overridden so that client-side access control is used. With client-side access control, login permission are defined by local policies only. If a domain applies client-side access control, you can use the To set the access rules, use the following two commands:
The realm permit The
Note that allowing access currently only works for users in primary domains, not for users in trusted domains. This is because while user logins must contain the domain name, SSSD currently cannot provide It is safer to only allow access to specifically selected users or
groups than to deny access to some, while enabling it to everyone else. Therefore, it is not recommended to allow access to all by default while only denying it to specified users with For more information about the 3.8. Changing Default User Configuration The To override the default home directory and shell POSIX attributes, specify the
following options in the
The default-shell The For example: [users] default-home = /home/%u default-shell = /bin/bash For more information about the options, see the realmd.conf(5) man page. 3.9. Additional Configuration for the Active Directory Domain Entry Custom settings for each individual domain can be defined in the [ad.example.com] attribute = value attribute = value To change the
configuration for a domain, edit the corresponding section in [ad.example.com] computer-ou = ou=Linux Computers,DC=domain,DC=example,DC=com user-principal = host/ automatic-id-mapping = no Note that the same configuration can also be set when originally joining the system to the domain using the # realm join --computer-ou="ou=Linux Computers,dc=domain,dc=com" --automatic-id-mapping=no --user-principal=host/ Table 3.2, “Realm Configuration Options” lists the most notable options that can be set in the domain default section in
Table 3.2. Realm Configuration Options
Chapter 4. Using Samba for Active Directory IntegrationSamba implements the Server Message Block (SMB) protocol in Red Hat Enterprise Linux. The SMB protocol is used to access resources on a server, such as file shares and shared printers. You can use Samba to authenticate Active Directory (AD) domain users to a Domain Controller (DC). Additionally, you can use Samba to share printers and local directories to other SMB clients in the network. 4.1. Using winbindd to Authenticate Domain Users Samba's Using 4.1.1. Joining an AD Domain If you want to join an AD domain and use the 4.2. Using SMB shares with SSSD and WinbindThis section describes how you can use SSSD clients to access and fully use shares based on the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS) protocol. SSSD does not support all the services that Winbind provides. For example, SSSD does not support authentication using the NT LAN Manager (NTLM) or NetBIOS name lookup. If you need these services, use Winbind. Note that in Identity Management domains, Kerberos authentication and DNS name lookup are available for the same purposes. 4.2.1. How SSSD Works with SMBThe SMB file-sharing protocol is widely used on Windows machines. In Red Hat Enterprise Linux environments with a trust between Identity Management and Active Directory, SSSD enables seamless use of SMB as if it was a standard Linux file system. To access a SMB share, the system must be able to translate Windows SIDs to Linux POSIX UIDs and GIDs. SSSD clients use the SID-to-ID or SID-to-name algorithm, which enables this ID mapping. 4.2.2. Switching Between SSSD and Winbind for SMB Share AccessThis procedure describes how you can switch between SSSD and Winbind plug-ins that are used for accessing SMB shares from SSSD clients. For Winbind to be able to access SMB shares, you need to have the cifs-utils package installed on your client. To make sure that cifs-utils is installed on your machine: $ rpm -q cifs-utils
The 32-bit version platform, such as i686 in RHEL 7, uses the 4.3. Additional ResourcesPart II. Integrating a Linux Domain with an Active Directory Domain: Cross-forest Trust This part provides recommended
practices for integrating a Chapter 5. Creating Cross-forest Trusts with Active Directory and Identity ManagementThis chapter describes creating cross-forest trusts between Active Directory and Identity Management. A cross-forest trust is the recommended one of the two methods to integrate Identity Management and Active Directory (AD) environments indirectly. The other method is synchronization. If you are unsure which method to choose for your environment, read Section 1.3, “Indirect Integration”. Kerberos implements a concept of a trust. In a trust, a principal from one Kerberos realm can request a ticket to a service in another Kerberos realm. Using this ticket, the principal can authenticate against resources on machines belonging to the other realm. Kerberos also has the ability to create a relationship between two otherwise separate Kerberos realms: a cross-realm trust. Realms that are part of a trust use a shared pair of a ticket and key; a member of one realm then counts as a member of both realms. Red Hat Identity Management supports configuring a cross-forest trust between an IdM domain and an Active Directory domain. 5.1. Introduction to Cross-forest TrustsKerberos realm only concerns authentication. Other services and protocols are involved in complementing identity and authorization for resources running on the machines in the Kerberos realm. As such, establishing Kerberos cross-realm trust is not enough to allow users from one realm to access resources in the other realm; a support is required at other levels of communication as well. 5.1.1. The Architecture of a Trust RelationshipBoth Active Directory and Identity Management manage a variety of core services such as Kerberos, LDAP, DNS, or certificate services. To transparently integrate these two diverse environments, all core services must interact seamlessly with one another. Active Directory Trusts, Forests, and Cross-forest TrustsKerberos cross-realm trust plays an important role in authentication between Active Directory environments. All activities to resolve user and group names in a trusted AD domain require authentication, regardless of how access is performed: using LDAP protocol or as part of the Distributed Computing Environment/Remote Procedure Calls (DCE/RPC) on top of the Server Message Block (SMB) protocol. Because there are more protocols involved in organizing access between two different Active Directory domains, trust relationship has a more generic name, Active Directory trust. Multiple AD domains can be organized together into an Active Directory forest. A root domain of the forest is the first domain created in the forest. Identity Management domain cannot be part of an existing AD forest, thus it is always seen as a separate forest. When trust relationship is established between two separate forest root domains, allowing users and services from different AD forests to communicate, a trust is called Active Directory cross-forest trust. Trust Flow and One-way TrustsA trust establishes an access relationship between two domains. Active Directory environments can be complex so there are different possible types and arrangements for Active Directory trusts, between child domains, root domains, or forests. A trust is a path from one domain to another. The way that identities and information move between the domains is called a trust flow. The trusted domain contains users, and the trusting domain allows access to resources. In a one-way trust, trust flows only in one direction: users can access the trusting domain's resources but users in the trusting domain cannot access resources in the trusted domain. In Figure 5.1, “One-way Trust”, Domain A is trusted by Domain B, but Domain B is not trusted by Domain A. Figure 5.1. One-way Trust Transitive and Non-transitive TrustsTrusts can be transitive so that a domain trusts another domain and any other domain trusted by that second domain. Figure 5.2. Transitive Trusts Trusts can also be non-transitive which means the trust is limited only to the explicitly included domains. Cross-forest Trust in Active Directory and Identity ManagementWithin an Active Directory forest, trust relationships between domains are normally two-way and transitive by default. Because trust between two AD forests is a trust between two forest root domains, it can also be two-way or one-way. The transitivity of the cross-forest trust is explicit: any domain trust within an AD forest that leads to the root domain of the forest is transitive over the cross-forest trust. However, separate cross-forest trusts are not transitive. An explicit cross-forest trust must be established between each AD forest root domain to another AD forest root domain. From the perspective of AD, Identity Management represents a separate AD forest with a single AD domain. When cross-forest trust between an AD forest root domain and an IdM domain is established, users from the AD forest domains can interact with Linux machines and services from the IdM domain. Figure 5.3. Trust Direction 5.1.2. Active Directory Security Objects and TrustActive Directory Global CatalogThe global catalog contains information about objects of an Active Directory. It stores a full copy of objects within its own domain. From objects of other domains in the Active Directory forest, only a partial copy of the commonly most searched attributes is stored in the global catalog. Additionally, some types of groups are only valid within a specific scope and might not be part of the global catalog. Note that the cross-forest trust context is wider than a single domain. Therefore, some of these server-local or domain-local security group memberships from a trusted forest might not be visible to IdM servers. Global Catalog and POSIX AttributesActive Directory does not replicate POSIX attributes with its default settings. If it is required to use POSIX attributes that are defined in AD Red Hat strongly recommends to replicate them to the global catalog service.
5.1.3. Trust Architecture in IdMOn the Identity Management side, the IdM server has to be able to recognize Active Directory identities and appropriately process their group membership for access controls. The Microsoft PAC (MS-PAC, Privilege Account Certificate) contains the required information about the user; their security ID, domain user name, and group memberships. Identity Management has two components to analyze data in the PAC on the Kerberos ticket:
Trusts with Different Active Directory ForestsIdM can also be part of trust relationships with different AD forests. Once a trust is established, additional trusts with other forests can be added later, following the same commands and procedures. IdM can trust multiple entirely unrelated forests at the same time, allowing users from such unrelated AD forests access to resources in the same shared IdM domain. 5.1.3.1. Active Directory PACs and IdM TicketsGroup information in Active Directory is stored in a list of identifiers in the Privilege Attribute Certificate (MS-PAC or PAC) data set. The PAC contains various authorization information, such as group membership or additional credentials information. It also includes security identifiers (SIDs) of users and groups in the Active Directory domain. SIDs are identifiers assigned to Active Directory users and groups when they are created. In trust environments, group members are identified by SIDs, rather than by names or DNs. A PAC is embedded in the Kerberos service request ticket for Active Directory users as a way of identifying the entity to other Windows clients and servers in the Windows domain. IdM maps the group information in the PAC to the Active Directory groups and then to the corresponding IdM groups to determine access. When an Active Directory user requests a ticket for a service on IdM resources, the process goes as follows:
When the IdM client evaluates the service ticket, the process includes the following steps:
5.1.3.2. Active Directory Users and Identity Management GroupsWhen managing Active Directory users and groups, you can add individual AD users and whole AD groups to Identity Management groups. Non-POSIX External Groups and SID MappingGroup membership in the IdM LDAP is expressed by specifying a distinguished name (DN) of an LDAP object that is a member of a group. AD entries are not synchronized or copied over to IdM, which means that AD users and groups have no LDAP objects in the IdM LDAP. Therefore, they cannot be directly used to express group membership in the IdM LDAP. For this reason, IdM creates non-POSIX external groups: proxy LDAP objects that contain references to SIDs of AD users and groups as strings. Non-POSIX external groups are then referenced as normal IdM LDAP objects to signify group membership for AD users and groups in IdM. SIDs of non-POSIX external groups are processed by SSSD; SSSD maps SIDs of groups to which an AD user belongs to POSIX groups in IdM. The SIDs on the AD side are associated with user names. When the user name is used to access IdM resources, SSSD in IdM resolves that user name to its SID, and then looks up the information for that SID within the AD domain, as described in Section 5.1.3.1, “Active Directory PACs and IdM Tickets”. ID RangesWhen a user is created in Linux, it is assigned a user ID number. In addition, a private group is created for the user. The private group ID number is the same as the user ID number. In Linux environment, this does not create a conflict. On Windows, however, the security ID number must be unique for every object in the domain. Trusted AD users require a UID and GID number on a Linux system. This UID and GID number can be generated by IdM, but if the AD entry already has UID and GID numbers assigned, assigning different numbers creates a conflict. To avoid such conflicts, it is possible to use the AD-defined POSIX attributes, including the UID and GID number and preferred login shell. AD stores a subset of information for all objects within the forest in a global catalog. The global catalog includes every entry for every domain in the forest. If you want to use AD-defined POSIX attributes, Red Hat strongly recommends that you first replicate the attributes to the global catalog. When a trust is created, IdM automatically detects what kind of ID range to use and creates a unique ID range for the AD domain added to the trust. You can also choose this manually by
passing one of the following options to the 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-posixThis range option is used for IDs defined in POSIX attributes in the AD entry. IdM obtains the POSIX attributes, including For example: [root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix Recreating a trust with the other ID range If the ID range of the created trust
does not suit your deployment, you can re-create the trust using the other
5.1.3.3. Active Directory Users and IdM Policies and ConfigurationSeveral IdM policy definitions, such as SELinux, host-based access control, sudo, and netgroups, rely on user groups to identify how the policies are applied. Figure 5.4. Active Directory Users and IdM Groups and Policies Active Directory users are external to the IdM domain, but they can still be added as group members to IdM groups, as long as those groups are configured as external groups described in Section 5.1.3.2, “Active Directory Users and Identity Management Groups”. In such cases, the sudo, host-based access controls, and other policies are applied to the external POSIX group and, ultimately, to the AD user when accessing IdM domain resources. The user SID in the PAC in the ticket is resolved to the AD identity. This means that Active Directory users can be added as group members using their fully-qualified user name or their SID. 5.1.4. One-Way and Two-Way TrustsIdM supports two types of trust agreements, depending on whether the entities that can establish connection to services in IdM are limited to only AD or can include IdM entities as well. 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 trustTwo-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. After a trust is established, it is not possible to modify its type. If you require a different type of trust, run the 5.1.5. External Trusts to Active DirectoryAn external trust is a trust relationship between domains that are in a different forests. While forest trusts always require to establish the trust between the root domains of Active Directory forests, you can establish an external trust to any domain within the forest. 5.1.6. Trust Controllers and Trust AgentsIdM provides the following types of IdM servers that support trust to Active Directory: 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. 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 agentsIdM servers that can perform identity lookups against Active Directory domain controllers. In addition to trust controllers and agents, the IdM domain can also include replicas without any role. However, these servers do not communicate with Active Directory. Therefore, clients that communicate with these servers cannot resolve Active Directory users and groups or authenticate and authorize Active Directory users. Table 5.1. A comparison of the capabilities provided by trust controllers and trust agents
When planning the deployment of trust controllers and trust agents, consider these guidelines:
If you ever want to create additional trust controllers or if an existing trust controller fails, create a new trust controller by promoting a trust agent or a
replica. To do this, use the You cannot downgrade an existing trust controller to a trust agent. The trust controller server role, once installed, cannot be removed from the topology. 5.2. Creating Cross-forest Trusts5.2.1. Environment and Machine RequirementsBefore configuring a trust agreement, make sure that both the Active Directory and Identity Management servers, machines, and environments meet the requirements and settings described in this section. 5.2.1.1. Supported Windows PlatformsYou can establish a trust relationship with Active Directory forests that use the following forest and domain functional levels:
The following operating systems are supported and tested for establishing a trust using the mentioned functional levels:
Previous versions of Windows Server are not supported for establishing a trust. 5.2.1.2. DNS and Realm SettingsTo establish a trust, Active Directory and Identity Management require specific DNS configuration: Unique primary DNS domains Each system must have its own unique primary DNS domain configured. For example:
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 All machines must be able to resolve DNS records from all DNS domains involved in the trust relationship: No overlap between IdM and AD DNS domainsSystems 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. 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 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 ConfigurationBefore configuring trust, verify that the Identity Management and Active Directory servers can resolve themselves and also each other. If running the commands described below does not display the expected results, inspect the DNS configuration on the host where the commands were executed. If the host configuration seems correct, make sure that DNS delegations from the parent to child domains are set up correctly. Note that AD caches the results of DNS lookups, and changes you make in DNS are therefore sometimes not visible immediately. You can delete the current cache by running the 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.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
5.2.1.3. NetBIOS NamesThe NetBIOS name is critical for identifying the Active Directory (AD) domain and, if IdM has a trust configured with AD, for identifying the IdM domain and services. As a consequence, you must use a different NetBIOS name for the IdM domain than the NetBIOS names used in the AD domains to which you want to establish the forest trust. The NetBIOS name of an
Active Directory or IdM domain is usually the far-left component of the corresponding DNS domain. For example, if the DNS domain is The maximum length of a NetBIOS name is 15 characters. 5.2.1.4. Firewalls and PortsTo enable communication between AD domain controllers and IdM servers, make sure you meet the following port requirements: Table 5.2. Ports Required for an AD Trust
Table 5.3. Ports Required by IdM Servers in a Trust
Table 5.4. Ports Required by IdM Clients in an AD Trust
Additional Resources
5.2.1.5. IPv6 SettingsThe IdM system must have the IPv6 protocol enabled in the kernel. If IPv6 is disabled, then the CLDAP plug-in used by the IdM services fails to initialize. 5.2.1.6. Clock SettingsBoth the Active Directory server and the IdM server must have their clocks in sync. 5.2.1.7. Creating a Conditional Forwarder for the IdM Domain in ADPrepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server:
5.2.1.8. Creating a Forward Zone for the AD Domain in IdMPrepare the IdM DNS server to forward queries for the AD domain to the AD DNS server:
5.2.1.9. Supported User Name Formats IdM performs user name mapping in the local SSSD client. The default output user name format for users from trusted domains supported by SSSD is Users can use either only their user name ( Preferably, use the fully-qualified user name to avoid conflicts if the same user name exists in multiple domains. If a user specifies only the user name with out the domain, SSSD searches the account in all domains configured in the To identify the user name and the domain to which the user name belongs, SSSD uses a regular expression defined in the re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$)) 5.2.2. Creating TrustsThe following sections describe creating trusts in various configuration scenarios. Section 5.2.2.1, “Creating a Trust from the Command Line” contains the full procedure for configuring a trust from the command line. The other sections describe the steps which are different from this basic configuration scenario and reference the basic procedure for all other steps. If you set up a replica in an existing trust environment, the replica is not automatically configured as a trust controller. To configure the replica as an additional trust controller, follow the procedures in this section. 5.2.2.1. Creating a Trust from the Command LineCreating a trust relationship between the IdM and Active Directory Kerberos realms involves the following steps: 5.2.2.1.1. Preparing the IdM Server for TrustTo set up the IdM server for a trust relationship with AD, follow these steps:
5.2.2.1.2. Creating a Trust Agreement Create a trust agreement for the Active Directory domain and the IdM domain by using the # ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password The The following example establishes a two-way trust by using the [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 ConfigurationTo verify the Kerberos configuration, test if it is possible to obtain a ticket for an IdM user and if the IdM user can request service tickets. To verify a two-way trust:
To verify a one-way trust from the IdM side:
The 5.2.2.3. Verifying the ID MappingTo verify the ID mapping:
5.2.2.4. Creating a Trust on an Existing IdM InstanceWhen configuring a trust for an existing IdM instance, certain settings for the IdM server and entries within its domain are already configured. However, you must set the DNS configuration for the Active Directory domain and assign Active Directory SIDs to all existing IdM users and groups.
5.2.2.5. Adding a Second TrustWhen adding a trust on an IdM server that already has one or more trust agreements configured, certain general IdM trust settings, such as installing the trust-related packages or configuring SIDs, is no longer required. To add an additional trust, you only must configure DNS and establish a trust agreement. 5.2.2.6. Creating a Trust in the Web UIOnce the initial configuration is set, a trust agreement can be added in the IdM web UI:
5.2.3. Post-installation Considerations for Cross-forest Trusts5.2.3.1. Potential Behavior Issues with Active Directory Trust5.2.3.1.1. Active Directory Users and IdM AdministrationCurrently, Active Directory (AD) users and administrators can only see their self-service page after logging into the IdM Web UI. AD administrators cannot access the administrator's view of IdM Web UI. For details, see the Authenticating to the IdM Web UI as an AD User section in the Linux Domain Identity, Authentication, and Policy Guide. Additionally, AD users currently cannot manage their own ID overrides. Only IdM users can add and manage ID overrides. 5.2.3.1.2. Authenticating Deleted Active Directory UsersBy default, every IdM client uses the SSSD service to cache user identities and credentials. If the IdM or AD back-end provider is temporarily unavailable, SSSD enables the local system to reference identities for users who have already logged in successfully once. Because SSSD maintains a list of users locally, changes that are made on the back end might not be immediately visible to clients that run SSSD offline. On such clients, users who have previously logged into IdM resources and whose hashed passwords are stored in the SSSD cache are able to log in again even if their user accounts have been deleted in AD. If the above conditions are met, the user identity is cached in SSSD, and the AD user is able to log into IdM resources even if the user account is deleted AD. This problem will persist until SSSD becomes online and is able to verify AD user logon against AD domain controllers. If the client system runs SSSD online, the password provided by the user is validated by an AD domain controller. This ensures that deleted AD users are not allowed to log in. 5.2.3.1.3. Credential Cache Collections and Selecting Active Directory PrincipalsThe Kerberos credentials cache attempts to match a client principal to a server principal based on the following identifiers in this order:
When the client and server mapping is based on the host name or real name and credential cache collections are used, unexpected behavior can occur in binding as an AD user. This is because the realm name of the Active Directory user is different than the realm name of the IdM system. If an AD user obtains a ticket using the For example, if the AD user is [root@server ~]# kinit Password for : [root@server ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ renew until 28.11.2015 11:25:16 This is set as the default principal in the Active Directory ticket cache. However, if any IdM user also has a Kerberos ticket (such as [root@vm-197 ~]# ssh -l ipaclient.example.com @ipaclient.example.com's password: [root@vm-197 ~]# klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0 This is because the realm name of the IdM principal matches the realm of the IdM resource. 5.2.3.1.4. Resolving Group SIDsLosing Kerberos Tickets Running a command to obtain a SID from
the Samba service, such as You are not required to run commands such as Cannot Verify Group Membership for UsersIt is not possible to verify that a specific trusted user is associated with a specific IdM group, external or POSIX. Cannot Display Remote Active Directory Group Memberships for an Active Directory UserNote that this problem no longer occurs if the IdM server and client run on Red Hat Enterprise Linux 7.1 or later. The To work around
this, you can use the [root@ipaserver ~]# id ADDOMAIN\user uid=1921801107() gid=1921801107() groups=1921801107(),129600004(ad_users),1921800513(domain ) 5.2.3.2. Configuring Trust Agents After you set up a new replica in a trust environment, the replica does not automatically have the
5.3. Managing and Configuring a Cross-forest Trust Environment5.3.1. User Principal Names in a Trusted Domains Environment IdM supports the logging in using user principal names (UPN). A UPN is an alternative to the user name to authenticate with, and has the format For example, if a company uses the Kerberos realm UPN suffixes are only visible for IdM when defined in the AD forest root. As an AD administrator, you can define UPNs with the To configure UPN suffixes for users, Red Hat recommends to use
tools that perform error validation, such as the Red Hat recommends against configuring UPNs through low-level modifications, such as using When you add or remove UPN suffixes in a trusted AD forest, you have to refresh the information for the trusted forest on the IdM master: [root@ipaserver ~]# ipa trust-fetch-domains Realm-Name: ad.example.com ------------------------------- No new trust domains were found ------------------------------- ---------------------------- Number of entries returned 0 ---------------------------- Verify that the alternative UPN was fetched, by running: [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 The UPN suffixes for a domain are stored in the multi-value attribute 5.3.3. Creating IdM Groups for Active Directory UsersUser groups are required to set access permissions, host-based access control, sudo rules, and other controls on IdM users. These groups are what grant access to IdM domain resources, as well as restricting access. Both AD users and AD groups can be added directly to IdM user groups. To do that, first add the AD users or groups to a non-POSIX IdM external group and then to a local IdM POSIX group. The POSIX group can then be used for user and role management of the AD users. The principles of handling non-POSIX groups in IdM are described in Section 5.1.3.2, “Active Directory Users and Identity Management Groups”. It is also possible to add AD user groups as members to IdM external groups. This might make it easier to define policies for Windows users, by keeping the user and group management within the single AD realm.
5.3.4. Maintaining TrustsTrust management involves several areas, such as global trust configuration, Kerberos trust configuration, DNS realm configuration, or ID ranges assignment to Active Directory users. 5.3.4.1. Editing the Global Trust Configuration The The global trust configuration contains five attributes:
The trust configuration is stored in the
5.3.4.1.1. Changing the NetBIOS NameChanging the NetBIOS name in most cases requires to re-establish all existing trusts. Therefore, Red Hat recommends not to change the attribute. A NetBIOS name compatible within an Active Directory topology is configured for the IdM server when running the [root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME 5.3.4.1.2. Changing the Default Group for Windows UsersWhen Identity Management is configured to trust an Active Directory forest, an MS-PAC record is added to the Kerberos tickets of IdM users. An MS-PAC record contains security identifiers (SIDs) of the groups to which an IdM user belongs. If the primary group of the IdM user has no SID assigned, the value of the security identifier defined for the Default SMB Group will be used. The same logic is applied by the Samba suite when the AD domain controller requests user information from the IdM trust controller. The Default SMB Group is a fallback group created automatically by the To set the default group from the command line, use the [root@server ~]# kinit admin [root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group" To set the default group from the IdM web UI:
5.3.4.2. Discovering, Enabling, and Disabling Trust Domains IdM has a trust with the root domain in a forest and, due to transitivity, all of its child domains and other domains from the same forest are implicitly included in that trust. IdM follows that topology as Windows users from anywhere in the forest attempt to access IdM resources. Each domain and child domain is a
trust domain in the IdM trust configuration. Each domain is stored in its own entry, IdM attempts to discover and map the full Active Directory topology when the trust is first configured, although in some cases it is required or beneficial to retrieve that topology manually. That is done with the [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 ---------------------------- When adding a trust with a shared secret, you need to manually retrieve topology of the AD
forest. After running the Once the topology is retrieved (through automatic or manual discovery), individual domains and child domains in that topology can be enabled, disabled, or removed entirely within the IdM trust configuration. For example, to disallow users from a specific child domain from using IdM resources, disable that trust domain: [root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com ------------------------------------------ Disabled trust domain "test.ad.example.com" ------------------------------------------ That trust domain can be re-enabled using the If a domain should be permanently removed from the topology, than it can be deleted from the IdM trust configuration. [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 Domains that are associated with the
IdM Kerberos realm are stored in the [root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa realmdomains-show Domain: ipa.example.org, ipa.example.com, example.com In an IdM setup with integrated DNS:
In an IdM setup without integrated DNS:
5.3.4.4. Adding Ranges for UID and GID Numbers in a Transitive Trust Creating ID ranges at the time when a trust is originally configured is described in the section called “ID Ranges”. To add an ID range later, use the
In the following example, the base ID is 1,200,000 and the RID is 1,000. The resulting ID number is then 1,201,000. [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 Make sure that the manually defined ID range does not overlap with the ID range used by IdM. 5.3.4.5. Adjusting DNA ID ranges manuallyIn some cases, you may need to manually adjust Distributed Numeric Assignment (DNA) ID ranges for existing replicas, for example to recover a DNA ID range assigned to a non-functioning replica or to extend a range that has run out of IDs. When adjusting a DNA ID range manually, make sure that the newly adjusted range is included
in the IdM ID range. You can check this using the To recover a DNA ID range from a non-functioning replica, use the Do not create overlapping ID ranges. If any of the ID ranges you assign to servers or replicas overlap, it could result in two different servers assigning the same ID value to different entries. To define the current DNA ID range for a specified server, use the
To define the next DNA ID range for a specified server, use the
5.3.4.6. Kerberos Flags for Services and Hosts Accessing services or hosts in a trusted domain can require special flags for the Kerberos
ticket-granting ticket (TGT). For example, if you want to log in using single sign-on to an IdM client with an Active Directory (AD) account from an AD client, the Kerberos TGT flag For more information and how to set Kerberos flags, see Kerberos Flags for Services and Hosts in the Linux Domain Identity, Authentication, and Policy Guide. 5.3.5. Setting PAC Types for ServicesOn IdM resources, if an Active Directory user requests a ticket for a service, then IdM forwards the request to Active Directory to retrieve the user information. Access data, associated with the Active Directory group assignments for the user, is sent back by Active Directory and embedded in the Kerberos ticket. Group information in Active Directory is stored in a list of identifiers in each Kerberos ticket for Active Directory users in a special data set called privileged access certificates or MS-PAC. The group information in the PAC has to be mapped to the Active Directory groups and then to the corresponding IdM groups to help determine access. IdM services can be configured to generate PACs for each authentication request when a user first attempts to authenticate to a domain service. 5.3.5.1. Setting Default PAC TypesThe IdM server configuration defines which PAC types are generated by default for a service. The global settings can be overridden by changing the local settings on a specific service.
5.3.5.2. Setting PAC Types for a ServiceThe global policy sets what PAC types to use for a service if nothing is set explicitly for that service. However, the global settings can be overridden on the local service configuration. To change the PAC setting from the command line, use the $ 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 ... To change the PAC setting in the web UI:
5.3.6. Using POSIX Attributes Defined in Active Directory
5.3.6.1. Defining UID and GID Attributes for Active Directory UsersIf the Windows administrator manually defines POSIX UID and GID attributes for a user, create a matching group on the IdM server with the same GID for the user. Creating the group ensures that the user is associated with a primary user group. If such group does not exist, the IdM server is unable to look up all groups to which the user belongs.
5.3.6.2. Transferring Login Shell and Home Directory AttributesThe client must be enrolled with an IdM server based on Red Hat Enterprise Linux 7.1 or later to benefit from this functionality. SSSD is able to read the following attribute values from an Active Directory server in a trust relationship with IdM:
When a custom shell or home directory value is defined on the AD server using these attributes, the custom value is then displayed to the IdM client for the AD user. Therefore, the same user shell is displayed for the AD user both on the AD side and on the IdM side. Note that to display the AD user's home directory to the IdM client, the [domain/example.com] subdomain_homedir = %o If the AD administrator modifies
5.3.7. Using SSH from Active Directory Machines for IdM ResourcesWhen a trust is configured, Active Directory users can access machines, services, and files on IdM hosts using SSH and their AD credentials. 5.3.7.1. Caching ConsiderationsIdM clients do not connect to Active Directory domain controllers (DC) directly to retrieve user attributes. Instead, a client connects to an IdM server who caches this information. For this reason, if you disable a user in Active Directory, the user can still authenticate to IdM clients using SSH key authentication until the record of the user expires in the IdM database. IdM updates a record of a user in the following situations:
5.3.7.2. Using SSH Without Passwords The The plug-in provides a reliable mapping mechanism across multiple realms and trusts: when In certain situations, users use an SSH bastion host to access other Red Hat Enterprise Linux machines. By default, if you use Kerberos to authenticate to SSH on the bastion host, the Kerberos
ticket cannot be forwarded to authenticate using Kerberos to other Red Hat Enterprise Linux hosts. To enable such forward authentication, add the # 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 In Red Hat Enterprise Linux 7.1 and newer systems, SSSD automatically configures the SSSD allows
user names in the format On systems with Manual Configuration of Kerberos Authentication for AD Users On systems where the To enable Active Directory users to use Kerberos for authentication in this situation, configure the Configuring The following procedure describes how to configure realm mapping in the Kerberos configuration.
Note that if you configure Kerberos authentication using the
For more information about setting .k5login The following procedure configures the system to find the Kerberos principal name for a local user name.
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 For more information about configuring the Either one of these configuration procedures results in AD users being able to log in using Kerberos. 5.3.8. Using a Trust with Kerberos-enabled Web ApplicationsAny existing web application can be configured to use Kerberos authentication, which references the trusted Active Directory and IdM Kerberos realms. For the full Kerberos configuration directives, see the Configuration page for the mod_auth_kerb module. After changing the Apache application configuration, restart the Apache service: [root@ipaserver ~]# systemctl restart httpd.service For example, for an Apache server, there are several options that define how the Apache server connects to the IdM Kerberos realm:
The Krb5Keytab The KrbServiceName The KrbMethodK5Passwd and KrbMethodNegotiate The These options are recommended for ease of use for many users. KrbLocalUserMapping The 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. Example 5.1. Kerberos Configuration in an Apache Web Application <Location "/mywebapp"> AuthType Kerberos AuthName "IPA Kerberos authentication" KrbMethodNegotiate on KrbMethodK5Passwd on KrbServiceName HTTP 5.4. Changing the LDAP Search Base for Users and Groups in a Trusted Active Directory DomainAs an administrator, you can set a different search base for users and groups in the trusted Active Directory domain. For example, this enables you to filter out users from inactive organizational units so that only active Active Directory users and groups are visible to the SSSD client system. 5.4.1. Prerequisites
5.4.2. Configuring the LDAP Search Base to Restrict Searches This procedure describes restricting searches in SSSD to a specific subtree by editing the Considerations
Procedure
If you are able to resolve users from other search domains, troubleshoot the problem by inspecting the SSSD logs:
Additional Resources
5.5. Changing the Format of User Names Displayed by SSSD By default, SSSD uses the To configure that SSSD displays only the user name without domain:
5.7. Active Directory Trust for Legacy Linux ClientsLinux clients running Red Hat Enterprise Linux with SSSD version 1.8 or earlier (legacy clients) do not provide native support for IdM cross-forest trusts with Active Directory. Therefore, for AD users to be able to access services provided by the IdM server, the legacy Linux clients and the IdM server have to be properly configured. Instead of using SSSD version 1.9 or later to communicate with the IdM server to obtain LDAP information, legacy clients use other utilities for this purpose, for example
Do not use the configuration described in this section for non-legacy clients, that is, clients running SSSD version 1.9 or later. SSSD 1.9 or later provides native support for IdM cross-forest trusts with AD, meaning AD users can properly access services on IdM clients without any additional configuration. When a legacy client joins the domain of an IdM server in a trust relationship with AD, a compat LDAP tree provides the required user and group data to AD users. However, the compat tree enables the AD users to access only a limited number of IdM services. Legacy clients do not provide access to the following services:
Access to the following services is provided even in case of legacy clients:
5.7.1. Server-side Configuration for AD Trust for Legacy ClientsMake sure the IdM server meets the following configuration requirements:
If the host-based access control (HBAC) You can determine the current status of [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 To enable 5.7.2. Client-side Configuration Using the ipa-advise Utility The To display the complete list of scenarios for which [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 (...) To display a set of instructions, run the [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 (...) You can configure a Linux client using the
To run the instructions as a shell script:
To configure the client manually, follow and execute the instructions displayed by 5.8. Troubleshooting Cross-forest TrustsThis section provides information about possible problems in an cross-forest trust environment and ways to solve them. 5.8.1. Troubleshooting the ipa-extdom Plug-in IdM clients in an IdM domain with a trust to Active Directory (AD) cannot receive information about users and groups from AD directly. Additionally, IdM does not store information about AD users in Directory Server running on IdM masters. Instead, IdM servers use the Setting the Config Timeout of the ipa-extdom Plug-in The By default, the config timeout is
Change the config timeout in the following situations:
For example, to set the config value to # 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 The By default, the buffer is For example, to set the buffer to # 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 This part provides instruction on how to synchronize Chapter 6. Synchronizing Active Directory and Identity Management UsersIdentity Management uses synchronization to combine the user data stored in an Active Directory domain and the user data stored in the IdM domain. Critical user attributes, including passwords, are copied and synchronized between the services. Entry synchronization is performed through a process similar to replication, which uses hooks to connect to and retrieve directory data from the Windows server. Password synchronization is performed through a Windows service which is installed on the Windows server and then communicates to the Identity Management server. 6.1. Supported Windows PlatformsSynchronization is supported with Active Directory forests that use the following forest and domain functional levels:
The following operating systems are explicitly supported and tested for synchronization using the mentioned functional levels:
PassSync 1.1.5 or later is compatible with all supported Windows Server versions. 6.2. About Active Directory and Identity ManagementWithin the IdM domain, information is shared among servers and replicas by copying that information, reliably and predictably, between data masters (servers and replicas). This process is replication. A similar process can be used to share data between the IdM domain and a Microsoft Active Directory domain. This is synchronization. Synchronization is the process of copying user data back and forth between Active Directory and Identity Management. When users are synchronized between Active Directory and Identity Management, the directory synchronization (DirSync) LDAP server extension control is used to search a directory for objects that have changed. Figure 6.1. Active Directory and IdM Synchronization Synchronization is defined in an agreement between an IdM server and an Active Directory domain controller. The agreement defines all of the information required to identify user entries that can be synchronized, such as the subtree to synchronize, as well as defining how account attributes are handled. The synchronization agreements are created with default values which can be tweaked to meet the needs of a specific domain. When two servers are involved in synchronization, they are called peers. Table 6.1. Information in a Synchronization Agreement
Synchronization is most commonly bidirectional. Information is sent back and forth between the IdM and the Windows domain in a process that is very similar to how IdM servers and replicas share information among themselves. An exception are new user entries, which are only added from the Windows domain to the IdM domain. It is possible to configure synchronization to only synchronize one way. That is unidirectional synchronization. To prevent the risk of data conflicts, only one directory should originate or remove user entries. This is typically the Windows directory, which is the primary identity store in the IT environment, and then new accounts or account deletions are synchronized to the Identity Management peer. Either directory can modify entries. Synchronization, then, is configured between one Identity Management server and one Active Directory domain controller. The Identity Management server propagates throughout to the IdM domain, while the domain controller propagates changes throughout the Windows domain. Figure 6.2. Synchronization Topology There are some key features to IdM synchronization:
When Active Directory users are synchronized over to IdM, certain attributes (including Kerberos and POSIX attributes) will have IPA attributes automatically added to the user entries. These attributes are used by IdM within its domain. They are not synchronized back over the corresponding Active Directory user entry. Some of the data in synchronization can be modified as part of the synchronization process. For examples, certain attributes can be automatically added to Active Directory user accounts when they are synced over to the IdM domain. These attribute changes are defined as part of the synchronization agreement and are described in Section 6.5.2, “Changing the Behavior for Synchronizing User Account Attributes”. 6.3. About Synchronized AttributesIdentity Management synchronizes a subset of user attributes between IdM and Active Directory user entries. Any other attributes present in the entry, either in Identity Management or in Active Directory, are ignored by synchronization. Most POSIX attributes are not synchronized. Although there are significant schema differences between the Active Directory LDAP schema and the 389 Directory Server LDAP schema used by Identity Management, there are many attributes that are the same. These attributes are simply synchronized between the Active Directory and IdM user entries, with no changes to the attribute name or value format. User Schema That Are the Same in Identity Management and Windows Servers
Some attributes have different names but still have direct parity between IdM (which uses 389 Directory Server) and Active Directory. These attributes are mapped by the synchronization process. Table 6.2. User Schema Mapped between Identity Management and Active Directory
6.3.1. User Schema Differences between Identity Management and Active DirectoryEven though attributes may be successfully synchronized between Active Directory and IdM, there may still be differences in how Active Directory and Identity Management define the underlying X.500 object classes. This could lead to differences in how the data are handled in the different LDAP services. This section describes the differences in how Active Directory and Identity Management handle some of the attributes which can be synchronized between the two domains. 6.3.1.1. Values for cn Attributes In 389 Directory Server, the What this means for synchronization is that, potentially, if a One other
important difference is that Active Directory uses the 6.3.1.2. Values for street and streetAddress Active Directory uses the attribute
Because of the different ways that 389 Directory Server and Active Directory handle
6.3.1.3. Constraints on the initials Attribute For the 6.3.1.4. Requiring the surname (sn) Attribute Active Directory allows If an Active Directory 6.3.2. Active Directory Entries and POSIX Attributes When a Windows user account
contains values for the As a result, the values for 6.4. Setting up Active Directory for SynchronizationSynchronizing user accounts is enabled within IdM. It is only necessary to set up a synchronization agreement (Section 6.5.1, “Creating Synchronization Agreements”). However, the Active Directory does need to be configured in a way that allows the Identity Management server to connect to it. 6.4.1. Creating an Active Directory User for SynchronizationOn the Windows server, it is necessary to create the user that the IdM server will use to connect to the Active Directory domain.
6.4.2. Setting up an Active Directory Certificate Authority
The Identity Management server connects to the Active Directory server using a secure connection. This requires that the Active Directory server have an available CA certificate or CA certificate chain available, which can be imported into the Identity Management security databases, so that the Windows server is a trusted peer. While this could technically be done with an external (to Active Directory) CA, most deployments should use the Certificate Services available with Active Directory. 6.5. Managing Synchronization Agreements6.5.1. Creating Synchronization Agreements Synchronization agreements are created on the IdM server using the
6.5.2. Changing the Behavior for Synchronizing User Account AttributesWhen the synchronization agreement is created, it has certain default behaviors defined for how the synchronization process handles the user account attributes during synchronization. The types of behaviors are things like how to handle lockout attributes or how to handle different DN formats. This behavior can be changed by editing the synchronization agreement. The synchronization agreement exists as a special plug-in entry in the LDAP server and each attribute behavior is set through an LDAP attribute. To change the synchronization behavior, use the For example, account lockout attributes are synchronized between IdM and Active Directory by default, but this can be disabled by editing the [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" The following is an overview of synchronization settings attributes: General User Account Parameters
User Account Lock Parameters
Group Parameters
Realm Parameters
6.5.3. Changing the Synchronized Windows Subtree Creating a synchronization agreement automatically sets the two subtrees to use as the synchronized user database. In IdM, the default is The value for the Active Directory subtree can be set to a non-default value when the
synchronization agreement is created by using the
The new subtree setting takes effect immediately. If a synchronization operation is currently running, then it takes effect as soon as the current operation completes. 6.5.4. Configuring Uni-directional SynchronizationBy default, all modifications and deletions are bidirectional. A change in Active Directory is synchronized over to Identity Management, and a change to an entry in Identity Management is synchronized over to Active Directory. This is essentially an equitable, multi-master relationship, where both Active Directory and Identity Management are equal peers in synchronization and are both data masters. However, there can be some data structure or IT designs where only one domain should be a data master and the other domain should accept updates. This changes the synchronization relationship from a multi-master relationship (where the peer servers are equal) to a master consumer relationship. This is done by setting the For example, to synchronize changes from Active Directory to Identity Management: [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 Enabling unidirectional synchronization does not automatically prevent changes on the unsynchronized server, and this can lead to inconsistencies between the synchronization peers between synchronization updates. For example, unidirectional synchronization is configured to go from Active Directory to Identity Management, so Active Directory is (in essence) the data master. If an entry is modified or even deleted on the Identity Management, then the Identity Management information is different then the information and those changes are never carried over to Active Directory. During the next synchronization update, the edits are overwritten on the Directory Server and the deleted entry is re-added. 6.5.5. Deleting Synchronization Agreements Synchronization can be stopped by deleting the synchronization agreement
which disconnects the IdM and Active Directory servers. In the inverse of creating a synchronization agreement, deleting a synchronization agreement uses the
6.5.6. Winsync Agreement FailuresCreating the synchronization agreement fails because it cannot connect to the Active Directory server. 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] This can occur if the wrong
Active Directory CA certificate was specified when the agreement was created. This creates duplicate certificates in the IdM LDAP database (in the $ 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 To resolve this issue, remove the CA certificate from the certificate database: # certutil -d /etc/dirsrv/slapd-DOMAIN-NAME -D -n "Imported CA" There are errors saying passwords are not being synchronized because it says the entry exists 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" This is not an error. This message occurs when an exempt user, the Password Synchronization user, is not being changed. The Password Synchronization user is the operational user which is used by the service to change the passwords in IdM. 6.6. Managing Password SynchronizationSynchronizing user entries is configured with the synchronization agreement. However, passwords in both Active Directory and Identity Management are not part of the normal user synchronization process. A separate client must be installed on the Active Directory servers to capture passwords as user accounts are created or passwords are changed, and then to forward that password information with the synchronized updates. 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.6.1. Setting up the Windows Server for Password SynchronizationSynchronizing passwords requires these things:
To verify that the Active Directory password complexity policy is enabled, run on an Active Directory domain controller: > dsquery * -scope base -attr pwdProperties pwdProperties 1 If the value of the attribute If you are unsure if group policies define deviating password settings for Organizational Units (ou), ask your group policy administrator. To enable the Active Directory password complexity setting for the whole domain:
6.6.2. Setting up Password SynchronizationInstall the Password Synchronization Service on every domain controller in the Active Directory domain in order to synchronize Windows passwords.
The first attempt to synchronize passwords, which happened when the Password Synchronization application is installed, will always fail because of the
SSL connection between the Directory Server and Active Directory synchronization peers. The tools to create the certificate and key databases is installed with the The password synchronization client cannot synchronize passwords for members of the IdM Chapter 7. Migrating Existing Environments from Synchronization to TrustSynchronization and trust are two possible approaches to indirect integration. Synchronization is generally discouraged, and Red Hat recommends to use the approach based on Active Directory (AD) trust instead. See Section 1.3, “Indirect Integration” for details. This chapter describes how to migrate an existing synchronization-based setup to AD trust. The following migrating options are available in IdM: 7.1. Migrate from Synchronization to Trust Automatically Using ipa-winsync-migrate The 7.1.1. How Migration Using ipa-winsync-migrate Works The After the migration completes:
7.1.2. How to Migrate Using ipa-winsync-migrateBefore you begin:
To migrate:
See the ipa-winsync-migrate(1) man page for more details about the utility. 7.2. Migrate from Synchronization to Trust Manually Using ID ViewsYou can use ID views to manually change the POSIX attributes that AD previously generated for AD users.
Chapter 8. Using ID Views in Active Directory EnvironmentsID views enable you to specify new values for POSIX user or group attributes, as well as to define on which client host or hosts the new values will apply. Integration systems other than Identity Management (IdM) sometimes generate UID and GID values based on an algorithm different than the algorithm used in IdM. By overriding the previously generated values to make them compliant with the values used in IdM, a client that used to be a member of another integration system can be fully integrated with IdM. You can use ID views in AD environments for the following purposes: Overriding AD User Attributes, such as POSIX Attributes or SSH Login DetailsMigrating from synchronization-based to trust-based integrationPerforming per-host group override of the IdM user attributes8.1. Active Directory Default Trust View8.1.1. What Is the Default Trust View The Default Trust View is the default ID
view always applied to AD users and groups in trust-based setups. It is created automatically when you establish the trust using Using the Default Trust View, you can define custom POSIX attributes for AD users and groups, thus overriding the values defined in AD. Table 8.1. Applying the Default Trust View
The Default Trust View only accepts overrides for AD users and groups, not for IdM users and groups. It is applied on the IdM server and clients and therefore only need to provide overrides for Active Directory users and groups. 8.1.2. Overriding the Default Trust View with Other ID ViewsIf another ID view applied to the host overrides the attribute values in the Default Trust View, IdM applies the values from the host-specific ID view on top of the Default Trust View.
The Default Trust View is always applied to IdM servers and replicas as well as to AD users and groups. You cannot assign a different ID view to them: they always apply the values from the Default Trust View. Table 8.2. Applying a Host-Specific ID View on Top of the Default Trust View
8.1.3. ID Overrides on Clients Based on the Client VersionThe IdM masters always apply ID overrides from the Default Trust View, regardless of how IdM clients retrieve the values: using SSSD or using Schema Compatibility tree requests. However, the availability of ID overrides from host-specific ID views is limited: 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: 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 ConflictsIdM uses ID ranges to avoid collisions of POSIX IDs from different domains. For details on ID ranges, see ID Ranges in the Linux Domain Identity, Authentication, and Policy Guide. POSIX IDs in ID views do not use a special range type, because IdM must allow overlaps with other kinds of ID ranges. For example, AD users created through synchronization have POSIX IDs from the same ID range as IdM users. POSIX IDs are managed manually in ID views on the IdM side. Therefore, if an ID collision occurs, fix it by changing the conflicting IDs. 8.3. Using ID Views to Define AD User Attributes
With ID views, you can change the user attribute values defined in AD. For a complete list of the attributes, see Attributes an ID View Can Override. For example: If you are managing a mixed Linux-Windows environment and want to manually define POSIX attributes or SSH login attributes for an AD user, but the AD policy does not allow it, you can use ID views to override the attribute values. When the AD user authenticates to clients running SSSD or authenticates using a compat LDAP tree, the new values are used in the authentication process. Only IdM users can manage ID views. AD users cannot. The process for overriding the attribute values follows these steps:
8.4. Migrating NIS Domains to IdMIf you are managing a Linux environment and want to migrate disparate NIS domains with different UIDs and GIDs into a modern identity management solution, you can use ID views to set host specific UIDs and GIDs for existing hosts to prevent changing the permissions on existing files and directories. The process for the migration follows these steps:
8.5. Configuration Options for Using Short Names to Resolve and Authenticate Users and Groups This section describes configuration options enabling you to use short user or group names instead of the
8.5.1. How Domain Resolution Works You can use the In environments with an Active Directory trust, applying one or both of the server-based options is recommended. From the perspective of a particular client, the
Only the domain resolution order setting found first will be used. In environments in which Red Hat Enterprise Linux is directly integrated into an AD, you can only set the domain resolution order on the client. You must use qualified names if:
8.5.2. Configuring the Domain Resolution Order on an Identity Management ServerSelect the server-based configuration if a large number of clients in a domain or subdomain should use an identical domain resolution order. 8.5.2.1. Setting the Domain Resolution Order Globally Select this option for setting the domain resolution order to all the clients in the trust. In order to do this,
use the $ 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 viewSelect this option to apply the setting to the clients in a specific domain. For example, on your subdomain server, server.idm.example.com, you observe many more logins from the subdomain2.ad.example.com subdomain than from subdomain1.ad.example.com. The global resolution order states, however, that the subdomain1.ad.example.com subdomain user database is tried out before subdomain2.ad.example.com when resolving user names. To set a different order for certain servers, set up a domain resolution order for a specific view:
8.5.3. Configuring the Domain Resolution Order on an IdM ClientSet the domain resolution order on the client if you want to set it on a low number of clients or if the clients are directly connected to AD. Set
the domain_resolution_order = subdomain1.ad.example.com, subdomain2.ad.example.com For further information on configuring the Appendix A. Revision HistoryNote that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Enterprise Linux.
Legal NoticeCopyright © 2020 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. Which of the following services and protocols are required for Active Directory?AD DS relies on several established protocols and standards, including LDAP (Lightweight Directory Access Protocol), Kerberos and DNS (Domain Name System).
What directory service protocol is used by Active Directory and also supported by Linux?LDAP. Lightweight directory access protocol (LDAP) provides a common open protocol for interfacing and querying directory service information provided by network operating systems. LDAP is widely used for the overwhelming majority of internal identity services including, most notably, Active Directory.
Which partition contains the definition of the objects and their attributes that can exist in Active Directory?The schema partition contains information that defines object classes and attributes used within the domain. It determines what objects can exist within Active Directory, and what attributes each can have.
What is a domain controller in Active Directory?A domain controller is a type of server that processes requests for authentication from users within a computer domain. Domain controllers are most commonly used in Windows Active Directory (AD) domains but are also used with other types of identity management systems.
|