Cari di RHE Linux 
     Red Hat Enterprise Linux Manual
Daftar Isi ☛
(Sebelumnya) 3 : Chapter 7. Identity Integr ...3 : Chapter 9. Identity Integr ... (Berikutnya)

Identity Management Guide

Chapter 8. Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts

8.1. The Meaning of "Trust"
8.1.1. How Trust Works: Transparency Between Kerberos and DNS Realms
8.1.1.1. Components Involved in Trusts
8.1.1.2. Active Directory and Identity Management Directories
8.1.1.3. DNS Domains
8.1.1.4. Kerberos Realms, Authentication, and Authorization
8.1.2. Trust in Contrast to Synchronization
8.1.3. Active Directory Users and IdM Features: sudo and Host-Based Access Control Policies
8.1.4. Potential Issues with Group Mapping and SIDs
8.1.5. Active Directory Users and IdM Administration
8.2. Environment and Machine Requirements to Set Up Trusts
8.2.1. Domain and Realm Names
8.2.2. NetBIOS Names
8.2.3. Integrated DNS
8.2.4. Firewalls and Ports
8.2.5. Clock Settings
8.2.6. Supported Username Formats
8.2.7. Trust Can Only Be Configured Once
8.3. Setting up Trust with IdM as a DNS Subdomain of Active Directory
8.4. Setting up Trust with IdM and Active Directory in Different DNS Domains
8.5. Creating IdM Groups for Active Directory Users
8.6. Using SSH from Active Directory Machines for IdM Resources
8.7. Using Trust with Kerberized Web Applications
Kerberos allows the configuration of trusted realms. Each realm has its own resources and users, yet the trust relationship allows users of any trusted realm to obtain tickets and connect to machines or services in a peer realm as if they were members of that peer realm.
Because of differences in the way that Windows and Linux domains implement LDAP services, DNS management, and even Kerberos realms, it is difficult to establish a direct trust between Active Directory and Linux domains manually. A trust relationship using IdM centrally defines and establishes the Kerberos trust and DNS mappings so that Active Directory users can access Linux hosts and services completely transparently, using one set of credentials.

8.1. The Meaning of "Trust"

Kerberos has the ability to create a relationship between two otherwise separate realms. This is called a cross-realm trust. This is described in some detail in Managing Single Sign-On and Smart Cards. These realms create a shared ticket and key so a member of one realm is perceived as a member of both realms. One realm trusts another.

8.1.1. How Trust Works: Transparency Between Kerberos and DNS Realms

Both Active Directory and Identity Management manage a variety of core services: Kerberos, LDAP, DNS, certificate services. For these two disparate domains to be integrated transparently, all of these core services need to be able to interact cleanly with one another.
Those services can be broken into two major points of interaction: a Kerberos realm and a DNS domain. Certificate services, LDAP entries, and other services can be managed independently for Active Directory and IdM. The place where they interect is where identities need to be authenticated (Kerberos) and a mechanism to route queries between domains (DNS).

8.1.1.1. Components Involved in Trusts

IdM cross-realm trusts leverage four primary components:
  • Active Directory
  • Samba, to perform identity lookups on Active Directory and retrieve user and group security identifiers (SIDs) for authorization information
  • SSSD, to cache user, group, and ticket information for users and to map Kerberos and DNS domains
  • Identity Management

8.1.1.2. Active Directory and Identity Management Directories

One of the most common backends for user identities is Active Directory, and many environments - even primarily Linux or heterogenous environments - rely on Active Directory for user management. In many environments, however, that means that an entirely different set of users must be defined to access Linux systems.
Trusts allows a natural division of labor in an IT environment between user administration (in Active Directory) and Linux or data center management (through IdM). All user accounts can be stored in Active Directory, without needing to recreate user accounts on Linux systems, while all Linux systems can still be centrally managed using native Linux tools.
Trusts, then, are essentially unidirectional. Active Directory users can access IdM resources and services, but IdM users cannot access Active Directory resources. Trust allows Windows administrators and users to be able to access and manage Linux resources[4].
A trust relationship is established between a single Active Directory domain and a single IdM domain.

NOTE

No Windows machine can be a client of the IdM domain in a trust environment. All Windows machines must be in the Active Directory domain.
A relationship is established between the Active Directory environment and the IdM environment through a trust agreement, which identifies the involved domains and the settings for the trust environment.

8.1.1.3. DNS Domains

Both Active Directory and Identity Management can define DNS services, and those DNS domains must interact cleanly with each other. There are two potential DNS configurations:
  • The DNS domains can be independent.
  • Identity Management can be configured as a subdomain of Active Directory.
In both cases, the different domains forward requests to each other as necessary and maintain different DNS namespaces. It is just a matter of defining how they recognize each other for forwarding queries.

IMPORTANT

Both Active Directory and Identity Management must be configured with integrated DNS servers.
Separate DNS Domains
In this case, there are two entirely different namespaces, such as ipaexample.com and adexample.com. For these domains to communicate, they must be configured as conditional forwarders of each other's domain.
Identity Management as a Subdomain
In this case, Identity Management is a namespace within the larger Active Directory space, such as linux.example.com and example.com. IdM can be configured to send all requests to the Active Directory domain (a forward-only policy) or it can send queries first to Active Directory and then attempt to resolve them itself (a foward-first policy).

8.1.1.4. Kerberos Realms, Authentication, and Authorization

Group information in Active Directory is stored in a list of identifiers in each Kerberos ticket for Active Directory users in a special dataset 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. A PAC is essentially an account usability extension.
Understanding the group mapping for trusts can help clarify how groups should be structured in trust environments.
Microsoft uses a special authorization structure called privileged access certificates or MS-PAC. A PAC is embedded in a Kerberos ticket as a way of identifying the entity to other Windows clients and servers in the Windows domain.
On 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. The PAC information sent back by Active Directory is embedded in the Kerberos ticket.

NOTE

All Kerberos communication for both Active Directory and IdM for trusts uses GSS-API.
IdM (through SSSD, as an IdM client), extracts the Active Directory group security identifiers (SIDs) from the PAC. IdM then compares the Active Directory SIDs in the PAC to the group SIDs configured as members in IdM groups. If the Active Directory group is a member of an IdM group, then the IdM group SID is added to the PAC, and the Kerberos ticket is updated with the new PAC.
That new ticket is then used to generate a service ticket for the user, and the user is granted access to the IdM-hosted services. according to their access rules. Additionally, the IdM group information in the SSSD user cache is updated to include the mapped IdM groups for the Active Directory user.
SSSD stores multiple TGTs and tickets for each user, as new services are accessed.
A simpler way of saying this is that Active Directory supplies a list of groups for each user, based on an identifier for the group. IdM compares that list of Active Directory groups to memberships in IdM groups (where each group member is identified by that SID, rather than by a name or DN). If the Active Directory groups to which the user belongs are known to the IdM domain, then the user is recognized by the IdM domain.
The crucial factor to realize in this is that Active Directory users are recognized to the IdM domain not by their Active Directory user entry, but by their Active Directory group memberships. In a sense, Active Directory users are not trusted by the IdM domain - Active Directory groups are.
But this method of mapping Active Directory group SIDs to IdM group members means that group structure in IdM is important. Active Directory groups have different attributes than Linux groups and, therefore, different attributes than IdM groups. Most critically, Active Directory groups are not POSIX groups, while IdM groups are.
IdM has introduced an intermediary, non-POSIX group type, external groups, which allow entities outside IdM or a Linux system to be added as member. That external group can then be added to a standard IdM (POSIX) group as a member.
When Active Directory groups are added to an IdM group, they can be idenfitied by their SID or by name, in the formats DOMAIN\group_name or group_name@domain. IdM then resolves the group name to the SID and stores the SID as the group member entry, to be compared to any offered user PAC.
Actually configuring groups for Active Directory users is described in Section 8.5, "Creating IdM Groups for Active Directory Users".

IMPORTANT

Both Active Directory and Identity Management must be configured with integrated certificate services.
All sessions in a trust environment are ultimately secured with Kerberos tickets, but users have different login options:
  • Ticket-based authentication through kinit
  • Simple username/password authentication that is negotiated into a ticket
  • Passwordless authentication that is negotiated into a ticket (depending on the Kerberos client configuration

8.1.2. Trust in Contrast to Synchronization

Trusts and synchronization are fundamentally different approaches to integrating an IdM domain and Active Directory domain. The structure of trust domains (outlined in Section 8.1.1, "How Trust Works: Transparency Between Kerberos and DNS Realms"), the complexity of group assignments, the location of user and group entries, and other factors all influence which solution is most effective for a given environment.
Synchronization has a certain simplicity in its overall topology and setup, and it has a relatively small administrative footprint. However, it is much more limited in how it handles directory data, its ability to map entries, its overall performance, and its security.

Table 8.1. Positives and Negatives of Using Sync

Positives of SyncNegatives of Sync
  • Simple setup procedures
  • Few rules about the Active Directory configuration, including being agnostic about DNS and Kerberos domains
  • Users and groups can originate in both Active Directory and IdM domains
  • Active Directory users can function as IdM users, including as administrators
  • Windows machines can be added as clients to the IdM domain
  • Limited set of synchronized attributes and problematic data mapping
  • Potential data inconsistency between Active Directory and IdM entries for the same user
  • Different LDAP versions, synchronization protocols, and other technology differences
  • Delays in relaying updates between directories
  • Decreased performance
  • Security implications of syncing passwords - or administrative complexity for maintaining different passwords for the same user account in difference locations

The initial environment configuration for trusts is much more complex than synchronization, but it has advantages in simplifying single sign-on to systems, web applications, or terminals; not requiring additional directory administration; and preserving data integrity.

Table 8.2. Positives and Negatives of Using Trusts

Positives of TrustsNegatives of Trusts
  • Pulls in authentication, group, and authorization data automatically when a user logs in
  • Allows true single sign-on, with a single stored password and without having to synchronize passwords between directories
  • Caches data in a local database
  • Allows users to be entirely defined in a single domain, yet have access to multiple domains
  • Can be configured without having to know or restructure the underlying directory trees
  • Allows Kerberos authentication, username/password authentication (which generates a Kerberos ticket), or passwordless logins
  • Has very specific DNS configuration requirements
  • Can potentially have long wait times to retrieve data when a user initially logs in
  • Prefers that users be located in a single directory and resources in another
  • Windows machines cannot be clients of the IdM domain

NOTE

There is no clear migration path from using synchronization to using trusts because the entries already exist in the backend IdM LDAP directory. This means that Active Directory user entries (or all user entries, if IdM users are also synced) are duplicated, which can lead to odd behavior with logins, group associations, and lookups.

8.1.3. Active Directory Users and IdM Features: sudo and Host-Based Access Control Policies

Active Directory users cannot be added directly to an IdM group as a member. This means that policies and configuration in IdM which rely on group associations - such as host-based access control rules and sudo policies - must be configured in a kind of daisy-chain.
The Active Directory user is added to an Active Directory group, then that Active Directory group is added to an IdM external group, which is added as a member to a POSIX group. The sudo, host-based access controls, and other policies are applied against that POSIX group and, ultimately, through nesting memberships applied to the Active Directory user when accessing IdM domain resources.
  Active Directory Server Identity Management Server--------------------------- -------------------------------------------------------|   AD user -> AD group ->| -> | External Group -> POSIX Group -> sudo/HBAC policies |--------------------------- -------------------------------------------|-----------  ^   V  |--------------------------------------------------------------------

NOTE

Testing tools such as hbactest will not work with trusted users because the trusted user group associations are resolved dynamically, not stored in the IdM directory.

8.1.4. Potential Issues with Group Mapping and SIDs

Losing Kerberos Tickets
Running any command to obtain a SID from the Samba service - such as net getlocalsid or net getdomainsid - kills any existing admin ticket in the Kerberos cache.
Cannot Verify Group Membership for Users
There is no way 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 User
For Linux system users, local group associations can be shown for a user using the id command. However, Active Directory group memberships are not displayed with id for Active Directory users, even though they are with Samba tools.
The wbinfo command can be used to obtain a SID for an Active Directory user and then to display groups associated with that SID.
[root@ipaserver ~]# wbinfo -n ADDOMAIN\\jsmithS-1-5-21-1689615952-3716327440-3249090444-1104 SID_USER (1)[root@ipaserver ~]# wbinfo --user-domgroups=S-1-5-21-1689615952-3716327440-3249090444-1104S-1-5-21-1689615952-3716327440-3249090444-513S-1-5-21-1689615952-3716327440-3249090444-1106
The same query using id shows only the user information, not the Active Directory group membership information.
[root@ipaserver ~]# id ADDOMAIN\\jsmithuid=1921801104([email protected]) gid=1921801104([email protected]) groups=1921801104([email protected])

TIP

To work around this, ssh into an IdM client machine as the given Active Directory user. After the first successful login, the Active Directory group memberships are detected and returned in the id search.
[root@ipaserver ~]# id ADDOMAIN\jsmithuid=1921801107([email protected]) gid=1921801107([email protected]) groups=1921801107([email protected]),129600004(ad_users),1921800513(domain [email protected])

8.1.5. Active Directory Users and IdM Administration

Trust relationships are unidirectional. Active Directory users exist only within the Active Directory domain and are limited to what resources within the IdM domain they can access. Active Directory users are not administrators for IdM because they do not exist within IdM.
Active Directory users, then, cannot use any IdM administrative tools, including the web UI and command-line tools.

8.2. Environment and Machine Requirements to Set Up Trusts

Make sure that both the Active Directory and IdM servers, machines, and environments meet the requirements and settings in this section before configuring a trust agreement.

8.2.1. Domain and Realm Names

The IdM DNS domain name and Kerberos realm name must be different than the Active Directory DNS domain name and Kerberos realm name.

8.2.2. NetBIOS Names

The NetBIOS name is the far-left component of the domain name. For example, if the domain is linux.example.com, the NetBIOS name is linux, while if the domain name is simply example.com, it is example. The NetBIOS name is critical for identifying the Active Directory domain and, if the IdM domain is within a subdomain of Active Directory DNS, for identifying the IdM domain and services.
The IdM domain and Active Directory domain must have different NetBIOS names.

8.2.3. Integrated DNS

Both the Active Directory server and the IdM server must be configured to run their own respective DNS services.

8.2.4. Firewalls and Ports

Required Ports
For a trust relationship, the Active Directory server and IdM server must have almost all of the required system ports open that are required for an IdM server installation, with the exception of the LDAP ports.

Table 8.3. IdM Ports

ServicePortsType
HTTP/HTTPS
80
443
TCP
Kerberos
88
464
TCP and UDP
DNS53TCP and UDP
NTP123UDP

IMPORTANT

The IdM backend LDAP server must not be reachable by the Active Directory domain controller. The associated ports - 389 and 636 - on the IdM server host must be shut down for the Active Directory domain controller.
Starting iptables at Boot Time
Configure the iptables service to start when the system boots:
[root@ipaserver ]# chkconfig iptables on
Setting iptables Configuration
The iptables configuration needs to allow access to the required IdM ports and reject access to the IdM LDAP ports. The order of the rules is important. Active Directory-based requests to LDAP ports must be blocked first (based on the Active Directory server IP address), then there must be connections allowed to all IdM TCP adn UDP ports.
  1. Open the iptables configuration file.
    [root@ipaserver ~]# vim /etc/sysconfig/iptables
  2. Add the rule to restrict access to LDAP ports for the Active Directory host.
    -A INPUT -s ad_ip_address -p tcp -m multiport --dports 389,636 -m state --state NEW,ESTABLISHED -j REJECT
  3. Make sure that there lines to allow access to the TCP and UDP ports required by IdM.
    -A INPUT -p tcp -m multiport --dports 80,443,389,636,88,464,53,138,139,445 -m state --state NEW,ESTABLISHED -j ACCEPT-A INPUT -p udp -m multiport --dports 88,464,53,123,138,139,389,445 -m state --state NEW,ESTABLISHED -j ACCEPT
  4. Save the file.
  5. Restart the iptables service:
    [root@ipaserver ]# service iptables restart

Example 8.1. Example iptables Configuration File

*filter:INPUT ACCEPT [0:0]:FORWARD ACCEPT [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT-A INPUT -p icmp -j ACCEPT-A INPUT -i lo -j ACCEPT-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT-A INPUT -s ad_ip_address -p tcp -m multiport --dports 389,636 -m state --state NEW,ESTABLISHED -j REJECT-A INPUT -p tcp -m multiport --dports 80,443,389,636,88,464,53,138,139,445 -m state --state NEW,ESTABLISHED -j ACCEPT-A INPUT -p udp -m multiport --dports 88,464,53,123,138,139,389,445 -m state --state NEW,ESTABLISHED -j ACCEPT-A INPUT -p udp -j REJECT-A INPUT -p tcp -j REJECT-A FORWARD -j REJECT --reject-with icmp-host-prohibitedCOMMIT

8.2.5. Clock Settings

Both the Active Directory server and the IdM server must have their clocks in sync.

8.2.6. Supported Username Formats

Username mapping is performed in the local SSSD client. A Python regular expression is used by SSSD to identify the username and the domain to which it belongs.
By default in SSSD, the username format is defined in the form name@domain. This uses the regular expression:
re_expression = (?P<name>[^@]+)@?(?P<domain>[^@]*$)
Active Directory can support several different kinds of name formats, however, so the re_expression parameter in the SSSD configuration file for IdM backends or Active Directory backends uses a more complex expression:
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
This supports usernames in multiple formats:

TIP

An additional SSSD parameter, default_domain_suffix, can be used to supply a default domain value for usernames. For example, if all users are in a trusted Active Directory domain of adexample.com and the identity backend is the IdM domain of ipa.example.com, the default_domain_suffix parameter can be set with the value adexample.com. All users are automatically assumed to belong to that user domain unless the domain value is explicitly given with the username.
This is explained in more detail in the SSSD chapter of the Deployment Guide.

8.2.7. Trust Can Only Be Configured Once

WARNING

The ipa-ad-trust-install command can only be run once. If any information is entered incorrectly - particularly the NetBIOS name for the IdM server, but also the administrative credentials or other settings - then the trust services and all IdM packages must be uninstalled and then reinstalled and rerun.
It is not possible to rerun the ipa-ad-trust-install command to change the settings.

8.3. Setting up Trust with IdM as a DNS Subdomain of Active Directory

  1. Stop the Windows firewall service.
  2. Stop iptables and ip6tables on the IdM server.
    [root@ipaserver ]# service iptables stop
  3. Install the required trust packages, updated Samba4 packages, and LDAP-DNS packages for IdM DNS management.
    [root@ipaserver ]# yum install ipa-server "*ipa-server-trust-ad" samba4-winbind-clients bind-dyndb-ldap samba4-client

    IMPORTANT

    The Samba4 packages conflict with the default Samba3 packages on the Red Hat Enterprise Linux system. There may be dependency issues with other applications as the Samba3 packages are removed.
    The cifs-utils package is removed when Samba3 is removed. This must be re-installed.
    [root@ipaserver ]# yum install cifs-utils
    It is recommended that you remove the samba4-winbind-krb5-locator package to improve Kerberos performance.
    [root@ipaserver ]# yum remove samba4-winbind-krb5-locator
  4. For a new IdM server. Set up the IdM server to use its own, integrated DNS services (--setup-dns), its own DNS domain (-n), and the Active Directory DNS server as a forwarder (--forwarder). For example:
    [root@ipaserver ]# ipa-server-install --setup-dns --forwarder=2555.255.255.255 -p secret -a secret -r IPAEXAMPLE -n linux.adexample.com --hostname ipaserver.linux.adexample.com -U
    ipa-server-install options are described in Section 2.4.1, "About ipa-server-install".
    If the IdM server was set up without using Active Directory as a forwarder. If an IdM server was configured without using Active Directory as a forwarder, then the Active Directory server can be added as a confitional forwarder. This requires the IP address of the Active Directory DNS server.
    [root@ipaserver ]# ipa dnsconfig-mod --forwarder=255.255.255.255 --forward-policy=first
    Using a first policy means that queries are sent to the forwarder first and then to the local named process. Alternatively, this can be set to only, so that only the DNS forwarder is queried, never named.
  5. Add the IdM domain as a subdomain entry in the Active Directory configuration and add an NS record for the IdM DNS. For this exmaple, the IdM configuration has a NetBIOS name of linux (the subdomain) and the domain name is adexample.com.
    1. Open the command prompt, using Run as Administrator.
    2. Use the dnscmd command to add the A record for the IdM server, using the IdM hostname, NetBIOS name, and IP address.
      /RecordAdd ad_domain ipa_hostname.ipa_netbios A ipa_ip_address
      For example:
      C:\> dnscmd 127.0.0.1 /RecordAdd adexample.com ipaserver.linux A 255.255.255.0
    3. Then add the NS record for the IdM server. This has the format:
      /RecordAdd ad_domain ipa_netbios NS ipa_hostname.ipa_subdomain
      For example:
      C:\> dnscmd 127.0.0.1 /RecordAdd adexample.com linux NS ipaserver.linux.adexample.com
  6. Check the SRV records for both domains from both servers.
    On the IdM server, use the dig SRV command to list the records for the Active Directory domain and the IdM domain.
    [root@ipaserver ~]# dig SRV _ldap._tcp.adexample.com; ANSWER SECTION:_ldap._tcp.adexample.com. 600 IN SRV 0 100 389 adserver.adexample.com.; ADDITIONAL SECTION:adserver.adexample.com. 3600 IN A 192.168.2.161; ADDITIONAL SECTION:adserver.adexample.com. 3600 IN A 192.168.2.161[root@ipaserver ~]# dig SRV _ldap._tcp.linux.adexample.com; ANSWER SECTION:_ldap._tcp.linux.adexample.com. 86400 IN SRV 0 100 389 ipaserver.linux.adexample.com.; AUTHORITY SECTION:linux.adexample.com. 86400 IN NS ipaserver.linux.adexample.com.; ADDITIONAL SECTION:ipaserver.linux.adexample.com. 1200 IN A 192.168.2.158
    On the Active Directory server, open the nslookup tool and check the corresponding SRV records.
    > nslookup> set type=srv> _ldap._tcp.adexample.com> _ldap._tcp.linux.adexample.com> quit
  7. Enable DNS lookups in the Kerberos realm for the Kerberos client.
    1. Open the /etc/krb5.conf configuration file.
      [root@ipaserver ]# vim /etc/krb5.conf
    2. In the [libdefaults] section, add or set the dns_lookup_kdc value to true.
      [libdefaults]....dns_lookup_kdc = true
  8. Configure the IdM server to enable trust services. This requires the NetBIOS name of the IdM server and the password of the IdM administrator with the -a. Optionally, use the -U argument to run the script non-interactively.
    [root@ipaserver ]# ipa-adtrust-install --netbios-name=IPAEXAMPLE -a secret -U
  9. To verify the IdM configuration at this point, use the Samba tools to check that the Windows-related services are running and accessible. The smbclient command shows whether the domain is in the Samba registry.
    [root@ipaserver ~]# smbclient -L ipaserver.ipaexample.com -klp_load_ex: changing to config backend registryDomain=[IPAEXAMPLE] OS=[Unix] Server=[Samba 4.0.0rc4] Sharename   Type  Comment ---------   ----  ------- IPC$ IPC   IPC Service (Samba 4.0.0rc4)Domain=[IPAEXAMPLE] OS=[Unix] Server=[Samba 4.0.0rc4] Server   Comment --------- ------- Workgroup Master --------- -------
    The wbinfo command shows whether the IdM domain is online.
    [root@ipaserver ~]# wbinfo --online-statusBUILTIN : onlineIPAEXAMPLE : online
  10. If there are existing IdM users and groups. For existing IdM users, it is required that all users and groups have an Active Directory-style security identifier (SID). A new ipaNTSecurityIdentifier containing a SID can be created automatically for each entry by running a special ipa-sidgen-task operation on the backend LDAP directory.
    If there are no existing IdM users or groups, then this step can be skipped.
    [root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipaexample.com:389 -D "cn=directory manager" -w Passwd -fdn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=configchangetype: addobjectClass: topobjectClass: extensibleObjectcn: sidgennsslapd-basedn: dc=ipadomain,dc=comdelay: 0adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
    When the task completes successfully, there will be a message in the error logs that the SID generation task (Sidgen task) finished with a status of zero (0).
    [root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IPALAB-QE/errors[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ...[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
  11. Create a trust agreement for the Active Directory domain and the IdM domain. This command requires the Active Directory domain and the credentials of an administrative user to use to connect to the domain.
    ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
    For example:
    [root@ipaserver ~]# ipa trust-add --type=ad adexample.com --admin Administrator --passwordActive directory domain administrator's password: ------------------------------------------------------Added Active Directory trust for realm "adexample.com"------------------------------------------------------  Realm name: adexample.com  Domain NetBIOS name: ADEXAMPLE  Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444  Trust direction: Two-way trust  Trust type: Active Directory domain  Trust status: Established and verified
  12. Request a ticket for an IdM user to check the Kerberos configuration, and then check that that user can request service tickets.
    [root@ipaserver ~]# kinit jsmith
    First, request service tickets for services within the IdM domain.
    [root@ipaserver ]# kvno host/[email protected]
    Then, request service tickets for services within the Active Directory domain.
    [root@ipaserver ]# kvno cifs/[email protected]
    If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/[email protected].
    [root@ipaserver ]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: [email protected] starting Expires Service principal06/15/12 12:13:04  06/16/12 12:12:55  krbtgt/[email protected]/15/12 12:13:13  06/16/12 12:12:55  host/[email protected]06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/[email protected]06/15/12 12:14:58  06/15/12 22:14:58  cifs/[email protected]

    NOTE

    This ticket is requested as an IdM user because Kerberos realm mappings are not yet configured to allow Active Directory users to use Kerberos authentication to the realm.
  13. Configure realm mapping in the Kerberos configuration. This allows Kerberos authentication for Active Directory users.
    1. Open the /etc/krb5.conf configuration file.
      [root@ipaserver ]# vim /etc/krb5.conf
    2. In the [libdefaults] section, enable DNS lookups in the Kerberos realm.
      [libdefaults]....dns_lookup_kdc = true
    3. In the [realms] section, identify the IdM realm by name, and then add two auth_to_local lines to define the Kerberos principal name mapping. One rule should have a value of DEFAULT, for standard Unix usernames, and the other should include a rule which maps different Active Directory username formats and the specific Active Directory domain. For example, this rule allows usernames in the format first.last@ADDOMAIN, username@ADDOMAIN[.something], or username@addomain[.something]; the last two expressions allow upper-case or lower-case domain names, since Kerberos is case-sensitive.
      [realms]IDM = {....auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/auth_to_local = DEFAULT}
    4. Restart the KDC service.
      [root@ipaserver ~]# service krb5kdc restart
  14. Configure domain mapping in SSSD.
    1. Open the /etc/sssd/sssd.conf.
      [root@ipaserver ]# vim /etc/sssd/sssd.conf
    2. In the [sssd] section, add pac to the services list to enable the SSSD service to request and use Kerberos tickets with PAC data.
      [sssd]services = nss, pam, ssh, pac....
    3. In the IdM domain section, add the subdomains_provider parameter to explicitly enable SSSD to refer from the configured IdM domain to any domains trusted by that domain.
      [domain/ipa.lan]cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = example2b.comid_provider = ipaauth_provider = ipaaccess_provider = ipaipa_hostname = ipa2.example.comchpass_provider = ipaipa_server = ipa2.example.comldap_tls_cacert = /etc/ipa/ca.crtsubdomains_provider = ipa
      The trusted Active Directory domain is not explicitly defined in the SSSD configuration. The IdM domain is automatically created in the SSSD configuration when the client is installed; adding this line makes it possible to use the existing configuration.
      Subdomains and SSSD are described in more detail in the IdM provider configuration examples in the SSSD chapter of the Deployment Guide.
    4. Save the changes to the sssd.conf file.
    5. Restart SSSD.
      [root@ipaserver ]# service sssd restart
  15. Restart the iptables and ip6tables services on the IdM server.
    [root@ipaserver ]# service iptables start
  16. Restart the Windows firewall.

8.4. Setting up Trust with IdM and Active Directory in Different DNS Domains

  1. Stop the Windows firewall service.
  2. Stop iptables and ip6tables on the IdM server.
    [root@ipaserver ]# service iptables stop
  3. Install the required trust packages, updated Samba4 packages, and LDAP-DNS packages for IdM DNS management.
    [root@ipaserver ]# yum install ipa-server "*ipa-server-trust-ad" samba4-winbind-clients bind-dyndb-ldap samba4-client

    IMPORTANT

    The Samba4 packages conflict with the default Samba3 packages on the Red Hat Enterprise Linux system. There may be dependency issues with other applications as the Samba3 packages are removed.
    The cifs-utils package is removed when Samba3 is removed. This must be re-installed.
    [root@ipaserver ]# yum install cifs-utils
    It is recommended that you remove the samba4-winbind-krb5-locator package to improve Kerberos performance.
    [root@ipaserver ]# yum remove samba4-winbind-krb5-locator
  4. For a new IdM server. Set up the IdM server to use its own, integrated DNS services (--setup-dns), its own DNS domain (-n), and the Active Directory DNS server as a forwarder (--forwarder). For example:
    [root@ipaserver ]# ipa-server-install --setup-dns --forwarder=ad-dns.adserver.example.com -p secret -a secret -r IPAEXAMPLE -n ipaexample.com --hostname ipaserver.ipaexample.com -U
    ipa-server-install options are described in Section 2.4.1, "About ipa-server-install".
    If the IdM server was set up without using Active Directory as a forwarder. If an IdM server was configured without using Active Directory as a forwarder, then the Active Directory server can be added as a confitional forwarder. This requires the IP address of the Active Directory DNS server.
    [root@ipaserver ]# ipa dnsconfig-mod --forwarder=255.255.255.255 --forward-policy=first
    Using a first policy means that queries are sent to the forwarder first and then to the local named process. Alternatively, this can be set to only, so that only the DNS forwarder is queried, never named.
  5. Add the IdM server as a conditional forwarder in the Active Directory DNS configuration.
    1. Open the Administrative Tools menu, and select the DNS item.
    2. Right-click the Conditional Forwarders item in the left column of the window.
    3. Select the New Conditional Forwarder... button.
    4. Enter the DNS domain name of the IdM domain and the IP address of the IdM DNS server.
    5. Save the new forwarder.
    Alternatively, use the dnscmd command-line utility to add the forwarder entry:
    > dnscmd 127.0.0.1 /ZoneAdd IPAEXAMPLE.COM /Forwarder 255.255.255.0
  6. Check the SRV records for both domains from both servers.
    On the IdM server, use the dig SRV command to list the records for the Active Directory domain and the IdM domain.
    [root@ipaserver ~]# dig SRV _ldap._tcp.adexample.com; ANSWER SECTION:_ldap._tcp.adexample.com. 600 IN SRV 0 100 389 adserver.adexample.com.; ADDITIONAL SECTION:adserver.adexample.com. 3600 IN A 192.168.2.161; ADDITIONAL SECTION:adserver.adexample.com. 3600 IN A 192.168.2.161[root@ipaserver ~]# dig SRV _ldap._tcp.ipaexample.com; ANSWER SECTION:_ldap._tcp.ipaexample.com. 86400 IN SRV 0 100 389 ipaserver.ipaexample.com.; AUTHORITY SECTION:ipaexample.com. 86400 IN NS ipaserver.ipaexample.com.; ADDITIONAL SECTION:ipaserver.ipaexample.com. 1200 IN A 192.168.2.158
    On the Active Directory server, open the nslookup tool and check the corresponding SRV records.
    > nslookup> set type=srv> _ldap._tcp.adexample.com> _ldap._tcp.ipaexample.com> quit
  7. Enable DNS lookups in the Kerberos realm for the Kerberos client.
    1. Open the /etc/krb5.conf configuration file.
      [root@ipaserver ]# vim /etc/krb5.conf
    2. In the [libdefaults] section, add or set the dns_lookup_kdc value to true.
      [libdefaults]....dns_lookup_kdc = true
  8. Configure the IdM server to enable trust services. This requires the NetBIOS name of the IdM server and the password of the IdM administrator with the -a. Optionally, use the -U argument to run the script non-interactively.
    [root@ipaserver ]# ipa-adtrust-install --netbios-name=IPAEXAMPLE -a secret -U
  9. To verify the IdM configuration at this point, use the Samba tools to check that the Windows-related services are running and accessible. The smbclient command shows whether the domain is in the Samba registry.
    [root@ipaserver ~]# smbclient -L ipaserver.ipaexample.com -klp_load_ex: changing to config backend registryDomain=[IPAEXAMPLE] OS=[Unix] Server=[Samba 4.0.0rc4] Sharename   Type  Comment ---------   ----  ------- IPC$ IPC   IPC Service (Samba 4.0.0rc4)Domain=[IPAEXAMPLE] OS=[Unix] Server=[Samba 4.0.0rc4] Server   Comment --------- ------- Workgroup Master --------- -------
    The wbinfo command shows whether the IdM domain is online.
    [root@ipaserver ~]# wbinfo --online-statusBUILTIN : onlineIPAEXAMPLE : online
  10. If there are existing IdM users and groups. For existing IdM users, it is required that all users and groups have an Active Directory-style security identifier (SID). A new ipaNTSecurityIdentifier containing a SID can be created automatically for each entry by running a special ipa-sidgen-task operation on the backend LDAP directory.
    If there are no existing IdM users or groups, then this step can be skipped.
    [root@ipaserver ]# ldapmodify -x -H ldap://ipaserver.ipaexample.com:389 -D "cn=directory manager" -w Passwd -fdn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=configchangetype: addobjectClass: topobjectClass: extensibleObjectcn: sidgennsslapd-basedn: dc=ipadomain,dc=comdelay: 0adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
    When the task completes successfully, there will be a message in the error logs that the SID generation task (Sidgen task) finished with a status of zero (0).
    [root@ipaserver ]# grep "sidgen_task_thread" /var/log/dirsrv/slapd-IPALAB-QE/errors[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ...[20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
  11. Create a trust agreement for the Active Directory domain and the IdM domain. This command requires the Active Directory domain and the credentials of an administrative user to use to connect to the domain.
    ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
    For example:
    [root@ipaserver ~]# ipa trust-add --type=ad adexample.com --admin Administrator --passwordActive directory domain administrator's password: ------------------------------------------------------Added Active Directory trust for realm "adexample.com"------------------------------------------------------  Realm name: adexample.com  Domain NetBIOS name: ADEXAMPLE  Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444  Trust direction: Two-way trust  Trust type: Active Directory domain  Trust status: Established and verified
  12. Request a ticket for an IdM user to check the Kerberos configuration, and then check that that user can request service tickets.
    [root@ipaserver ~]# kinit jsmith
    First, request service tickets for services within the IdM domain.
    [root@ipaserver ]# kvno host/[email protected]
    Then, request service tickets for services within the Active Directory domain.
    [root@ipaserver ]# kvno cifs/[email protected]
    If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/[email protected].
    [root@ipaserver ]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: [email protected] starting Expires Service principal06/15/12 12:13:04  06/16/12 12:12:55  krbtgt/[email protected]/15/12 12:13:13  06/16/12 12:12:55  host/[email protected]06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/[email protected]06/15/12 12:14:58  06/15/12 22:14:58  cifs/[email protected]

    NOTE

    This ticket is requested as an IdM user because Kerberos realm mappings are not yet configured to allow Active Directory users to use Kerberos authentication to the realm.
  13. Configure realm mapping in the Kerberos configuration. This allows Kerberos authentication for Active Directory users.
    1. Open the /etc/krb5.conf configuration file.
      [root@ipaserver ]# vim /etc/krb5.conf
    2. In the [libdefaults] section, enable DNS lookups in the Kerberos realm.
      [libdefaults]....dns_lookup_kdc = true
    3. In the [realms] section, identify the IdM realm by name, and then add two auth_to_local lines to define the Kerberos principal name mapping. One rule should have a value of DEFAULT, for standard Unix usernames, and the other should include a rule which maps different Active Directory username formats and the specific Active Directory domain. For example, this rule allows usernames in the format first.last@ADDOMAIN, username@ADDOMAIN[.something], or username@addomain[.something]; the last two expressions allow upper-case or lower-case domain names, since Kerberos is case-sensitive.
      [realms]IDM = {....auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/auth_to_local = DEFAULT}
    4. Restart the KDC service.
      [root@ipaserver ~]# service krb5kdc restart
  14. Configure domain mapping in SSSD.
    1. Open the /etc/sssd/sssd.conf.
      [root@ipaserver ]# vim /etc/sssd/sssd.conf
    2. In the [sssd] section, add pac to the services list to enable the SSSD service to request and use Kerberos tickets with PAC data.
      [sssd]services = nss, pam, ssh, pac....
    3. In the IdM domain section, add the subdomains_provider parameter to explicitly enable SSSD to refer from the configured IdM domain to any domains trusted by that domain.
      [domain/ipa.lan]cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = example2b.comid_provider = ipaauth_provider = ipaaccess_provider = ipaipa_hostname = ipa2.example.comchpass_provider = ipaipa_server = ipa2.example.comldap_tls_cacert = /etc/ipa/ca.crtsubdomains_provider = ipa
      The trusted Active Directory domain is not explicitly defined in the SSSD configuration. The IdM domain is automatically created in the SSSD configuration when the client is installed; adding this line makes it possible to use the existing configuration.
      Subdomains and SSSD are described in more detail in the IdM provider configuration examples in the SSSD chapter of the Deployment Guide.
    4. Save the changes to the sssd.conf file.
    5. Restart SSSD.
      [root@ipaserver ]# service sssd restart
  15. Restart the iptables and ip6tables services on the IdM server.
    [root@ipaserver ]# service iptables start
  16. Restart the Windows firewall.

8.5. Creating IdM Groups for Active Directory Users

User 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.
However, Active Directory users cannot be added directly to IdM user groups. This means that Active Directory users require special configuration in order to access IdM domain resources.
As described in Section 8.1.1.4, "Kerberos Realms, Authentication, and Authorization", Active Directory users are added to the IdM domain in a kind of daisy chain. They are added to a group on the Active Directory side, then that group is added to an IdM external group (meaning, a non-POSIX group), and then that external group is added to a local POSIX group as a member. The IdM POSIX group can then be used for user/role management of Active Directory users.
  1. Create or select the group in the Active Directory domain to use to manage Active Directory users in the IdM realm. (Multiple groups can be used and added to different groups on the IdM side.)
  2. Create an external group in the IdM domain for the Active Directory users. This correlates to the Active Directory group. Using the --external argument indicates that this group will contain members from outside the IdM domain. For example:
    [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external-------------------------------Added group "ad_users_external"-------------------------------  Group name: ad_users_external  Description: AD users external map
  3. Create the POSIX group for actually administering the IdM policies.
    [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users----------------------Added group "ad_users"----------------------  Group name: ad_users  Description: AD users  GID: 129600004
  4. Add the Active Directory group to the IdM external group as an external member. The Active Directory group is identified by the name DOMAIN\group_name. The group name is then mapped to the Active Directory SID for the group. For example:
    [root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users" [member user]:  [member group]:   Group name: ad_users_external  Description: AD users external map  External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2)-------------------------Number of members added 1-------------------------
  5. Add the external IdM group to the POSIX IdM group as a member. For example:
    [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external  Group name: ad_users  Description: AD users  GID: 129600004  Member groups: ad_users_external-------------------------Number of members added 1-------------------------

8.6. Using SSH from Active Directory Machines for IdM Resources

When a trust is configured, Active Directory users can access machines, services, and files on IdM hosts using SSH and their Active Directory credentials.
One critical factor when using SSH is the username. The username must meet several criteria:
  • The username must have the format ad_user@ad_domain.
  • The domain name itself must be lower-case. This is required for Kerberos principal mapping.
  • The case of the username must match, exactly, the case of the username in Active Directory. jsmith and JSmith are considered different users because of the different cases.

NOTE

When using PuTTY on the Windows machine, make sure that GSS-API credential delegation is enabled.

8.7. Using Trust with Kerberized Web Applications

Any existing web application can be configured to use Kerberos authentication, which references the trusted Active Directory and IdM Kerberos realms.
For example, for an Apache server, set the KrbAuthRealms directive for the application location to the name of the IdM domain and set the location for the keytab (Krb5Keytab). Also set other paramters to enable Kerberos authentication, the service name used for the keytab (HTTP), and the Kerberos methods (which enables password-based authentication for valid users).
<Location "/mywebapp">   AuthType Kerberos   AuthName "IPA Kerberos authentication"   KrbMethodNegotiate on   KrbMethodK5Passwd on   KrbServiceName HTTP   KrbAuthRealms IDM_DOMAIN   Krb5Keytab /etc/httpd/conf/ipa.keytab   KrbSaveCredentials off   Require valid-user</Location>
The Kerberos configuration directives are covered in the mod_auth_kerb module man pages.
After changing the Apache application configuration, restart the Apache service:
[root@ipaserver ~]# service httpd restart

[4] Trusted users, however, cannot manage Identity Management itself.
(Sebelumnya) 3 : Chapter 7. Identity Integr ...3 : Chapter 9. Identity Integr ... (Berikutnya)