Jump to: navigation, search

V3/Serving legacy clients for trusts


Overview

Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD > 1.9, Active Directory users cannot access services on IPA clients.

This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version.

Use Cases

Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts.

Design

Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features:

  • information about both IPA and AD users can be queried;
  • it is possible to enumerate members of IPA and AD groups;
  • authentication bind to IPA LDAP as AD users should automatically trigger obtaining ticket from AD DC; in case TGT is obtained, authentication bind should be treated as successful.

Since old clients are often unable to use multiple search bases, LDAP tree will be served by a modified slapi-nis plugin which will be able to augment queries to main IPA tree with requests to SSSD cache.

Authentication

There are two types of Kerberos based authentication involved. First and preferred one, if the client can handle Kerberos authentication it should do it directly against AD. In most cases this would give the user a valid ticket in his credential cache which he can use for SSO to other services. This case splits to two sub-cases:

  • AD application understands Kerberos and uses it to connect to the IPA client service. In such case AD client obtains a ticket to IPA client service through the AD DC which first gives cross-realm TGT and then issues referral to IPA KDC for the ticket to a service. AD client then connects to IPA client service with already obtained service ticket for the service.
  • AD user uses application that doesn't obtain Kerberos ticket prior to use of IPA client service. This sub-case include log-in into IPA client machine console where AD user credentials are entered directly. In this case PAM stack configuration is used to authenticate. The client (pam_ldap module) does an authenticated LDAP bind to validate the credentials the user gave at the login prompt. Since the IPA server cannot do the validation itself, it will in the end do a kinit with the forwarded credentials of the user against AD DC. In this case the user on the client will not have any Kerberos tickets after login, but at least authentication of AD users would be possible even for an LDAP only client.

In order to allow Kerberos authentication afterwards, IPA KDC needs to issue referrals to the trusted domains KDCs (AD DCs). On client side what is needed is dns_lookup_kdc = true in /etc/krb5.conf.

On the server side a plugin is needed for 389-ds to allow authentication bind of AD user. This plugin will define bind pre-op hook to intercept bind and also create virtual DN for the user. Authentication will happen through an attempt to obtain a TGT for the user in question against AD DC in AD realm. Actual information about the virtualized DN will be served via slap-nis plugin.

Implementation

  1. IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade
  2. ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree
  3. Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. For this purpose slapi-nis plugin would be extended to allow queries against SSSD (getpwnam_/getgrnam_r) instead of LDAP directory.
  4. Directory server plugin will provide bind pre-op hook to perform authentication for AD user. The DN for AD user will be virtual one, handled by the previous plugin.
  5. IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM, cifs/fqdn@REALM, and HTTP/fqdn@REALM principal of IPA masters. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal and Python code in IPA server to do trust range discoveries. Additionally cifs/fqdn@REALM service needs to communicate to AD DC.

For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode

Feature Management

UI

The feature is transparent and not exposed in UI

CLI

The feature is not directly exposed in CLI.

IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs.

Major configuration options and enablement

Given complexity of the configuration, it is advisable to create a script on IPA server that will read out existing configuration and provide generated scriplets that configure different systems.

The generated scriptlets should support following configurations. Each scriplet when run should output recommended configuration as a text on standard output or instruction to run appropriate system commands in case where direct modification of the configuration files in not possible (Solaris LDAP configuration).

The utility will be called ipa-advise and provide pluggable way to add new "advises". Each "advise" will be named <action>-<system>-<variant> to allow them being structured. Below you can find an imaginary example:

  ipa-advise config-solaris11-padl
      ....    config-freebsd7-padl
      ....    config-aix63-native
      ....    setup-ipa-trust2ad
      ....    setup-ipa-dnsdelegation

and so on.

   ipa-advise

would show all plugins (filtering itself, i.e. list and help plugin) with their short descriptions.

SSSD 1.9 and after

SSSD 1.9 and onwards natively supports IPA cross-realm trusts with AD. No need to explicitly use AD compatibility tree

SSSD 1.11

Additionally, on IPA master sssd.conf will have ipa_server_mode = true set. This is the mode that will allow IPA master to ask SSSD for resolution of AD users using Global Catalog.

SSSD prior to 1.9

Compat tree can be configured to search both main IPA LDAP tree and AD compatibility data.

PADL pam_ldap/nss_ldap

PADL pam_ldap is in use by all GNU/Linux distributions and many other UNIX-like operating systems.

Vendor-specific pam_ldap

While PADL pam_ldap supports AIX 5L, FreeBSD 3.x and above, HP-UX 11i, IRIX 6.x, Linux, Mac OS X 10.2 and above, and Solaris 2.6 and above, many vendors provide their own version also called pam_ldap.

Solaris pam_ldap implementation does not use directly editable files. Instead, special utility is used to configure LDAP options.

Replication

No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients.

Updates and Upgrades

During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'.

Dependencies

Depends on SSSD implementing IPA server mode (sssd 1.11)

External Impact

https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode

Backup and Restore

No external configuration files are affected

Legacy clients and HBAC rules

One of limitations of legacy support is the fact that authentication and authorization is first performed at IPA server side using system-auth PAM service. At this point what is checked by HBAC rules is access by the user to the service called 'system-auth' on IPA master, not on the legacy client.

Test Plan

  • FreeIPA server: ipa.example.org
  • Active Directory: ad.example.org

Test case: Legacy client with SSSD < 1.9 configured with authconfig

Autotest

{{{autotest}}}

Setup

Implementation detail: This test requires setting the TESTHOST_LEGACY_CLIENT_SSSD_REDHAT_env<x> environment variable, where x is the environment number of your IPA server. See V3/Integration_testing#Additional_roles

  1. Configure IPA server.
    1. Run ipa-server-install.
    2. Run ipa-adtrust-install with --enable-compat.
  2. Setup proper DNS records both on AD and IPA server
  3. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org
    2. Establish a trust to Active Directory (it does not matter whether the server has POSIX support or not)
  4. Add a user in Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use testuser as a logon name.

Actions

  1. On the IPA server, add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. On the IPA server, ask for advice how to configure legacy client with SSSD < 1.9
    1. ipa-advise config-redhat-sssd-before-1-9 , if the system uses authconfig
  3. On the legacy client, apply the given advice.
    1. ipa-advise utility outputs script that can be directly executed on the server
  4. Test that native IPA user is resolvable.
    1. getent passwd admin
  5. Test that native IPA group is resolvable
    1. getent group editors
  6. Test that IPA user identity can be retrieved
    1. id admin
  7. Test that AD user is resolvable
    1. getent passwd testuser@ad.example.com
  8. Test that AD group is resolvable
    1. getent group testgroup@ad.example.com
  9. Test that IPA user identity can be retrieved
    1. id Administrator@ad.example.com
  10. Log in into the legacy client using native IPA user's credentials.
  11. Log in into the legacy client using AD user's credentials.
  12. Try to log in to the legacy client using disabled IPA user's credentials.
  13. Try to log in to the legacy client using disabled AD user's credentials.

Expected results

  1. Trust should be estabilished and verified.
  2. ipa-advise should output instructions how to configure the legacy client that can be executed as a script.
  3. Applying the script should be successful.
  4. Native IPA user should resolve.
  5. Native IPA group should resolve.
  6. IPA user information should retrieve successfully.
  7. AD user should resolve.
  8. AD group should resolve.
  9. AD user information should retrieve successfully.
  10. Successful login into the legacy client using native IPA user's credentials.
  11. Successful login into the legacy client using AD user's credentials.
  12. Login should be rejected.
  13. Login should be rejected.

Test case: Legacy client with SSSD < 1.9 configured without authconfig

Autotest

{{{autotest}}}

Setup

  1. Configure IPA server.
    1. Run ipa-server-install.
    2. Run ipa-adtrust-install with --enable-compat.
  2. Setup proper DNS records both on AD and IPA server
  3. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org
    2. Establish a trust to Active Directory (it does not matter whether the server has POSIX support or not)
  4. Add a user in Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use testuser as a logon name.

Actions

  1. On the IPA server, add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. On the IPA server, ask for advice how to configure legacy client with SSSD < 1.9
    1. ipa-advise config-generic-linux-sssd-before-1-9 , if the system uses authconfig
  3. On the legacy client, apply the given advice.
    1. ipa-advise utility outputs script that can be directly executed on the server
  4. Test that native IPA user is resolvable.
    1. getent passwd admin
  5. Test that native IPA group is resolvable
    1. getent group editors
  6. Test that IPA user identity can be retrieved
    1. id admin
  7. Test that AD user is resolvable
    1. getent passwd testuser@ad.example.com
  8. Test that AD group is resolvable
    1. getent group testgroup@ad.example.com
  9. Test that IPA user identity can be retrieved
    1. id Administrator@ad.example.com
  10. Log in into the legacy client using native IPA user's credentials.
  11. Log in into the legacy client using AD user's credentials.
  12. Try to log in to the legacy client using disabled IPA user's credentials.
  13. Try to log in to the legacy client using disabled AD user's credentials.

Expected results

  1. Trust should be estabilished and verified.
  2. ipa-advise should output instructions how to configure the legacy client that can be executed as a script.
  3. Applying the script should be successful.
  4. Native IPA user should resolve.
  5. Native IPA group should resolve.
  6. IPA user information should retrieve successfully.
  7. AD user should resolve.
  8. AD group should resolve.
  9. AD user information should retrieve successfully.
  10. Successful login into the legacy client using native IPA user's credentials.
  11. Successful login into the legacy client using AD user's credentials.
  12. Login should be rejected.
  13. Login should be rejected.

Test case: Legacy client with nss-pam-ldapd configured using authconfig

Autotest

{{{autotest}}}

Setup

Implementation detail: This test requires setting the TESTHOST_LEGACY_CLIENT_NSS_PAM_LDAPD_REDHAT_env<x> environment variable, where x is the environment number of your IPA server. See V3/Integration_testing#Additional_roles

  1. Configure IPA server.
    1. Run ipa-server-install.
    2. Run ipa-adtrust-install with --enable-compat.
  2. Setup proper DNS records both on AD and IPA server
  3. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org
    2. Establish a trust to Active Directory (it does not matter whether the server has POSIX support or not)
  4. Add a user in Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use testuser as a logon name.

Actions

  1. On the IPA server, add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. On the IPA server, ask for advice how to configure legacy client with nss-pam-ldapd
    1. ipa-advise config-redhat-nss-pam-ldapd
  3. On the legacy client, apply the given advice.
    1. ipa-advise utility outputs script that can be directly executed on the server
  4. Test that native IPA user is resolvable.
    1. getent passwd admin
  5. Test that native IPA group is resolvable
    1. getent group editors
  6. Test that IPA user identity can be retrieved
    1. id admin
  7. Test that AD user is resolvable
    1. getent passwd testuser@ad.example.com
  8. Test that AD group is resolvable
    1. getent group testgroup@ad.example.com
  9. Test that IPA user identity can be retrieved
    1. id Administrator@ad.example.com
  10. Log in into the legacy client using native IPA user's credentials.
  11. Log in into the legacy client using AD user's credentials.
  12. Try to log in to the legacy client using disabled IPA user's credentials.
  13. Try to log in to the legacy client using disabled AD user's credentials.

Expected results

  1. Trust should be estabilished and verified.
  2. ipa-advise should output instructions how to configure the legacy client that can be executed as a script.
  3. Applying the script should be successful.
  4. Native IPA user should resolve.
  5. Native IPA group should resolve.
  6. IPA user information should retrieve successfully.
  7. AD user should resolve.
  8. AD group should resolve.
  9. AD user information should retrieve successfully.
  10. Successful login into the legacy client using native IPA user's credentials.
  11. Successful login into the legacy client using AD user's credentials.
  12. Login should be rejected.
  13. Login should be rejected.

Test case: Legacy client with nss-pam-ldapd configured without authconfig

Autotest

{{{autotest}}}

Setup

  1. Configure IPA server.
    1. Run ipa-server-install.
    2. Run ipa-adtrust-install with --enable-compat.
  2. Setup proper DNS records both on AD and IPA server
  3. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org
    2. Establish a trust to Active Directory (it does not matter whether the server has POSIX support or not)
  4. Add a user in Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use testuser as a logon name.

Actions

  1. On the IPA server, add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. On the IPA server, ask for advice how to configure legacy client with SSSD < 1.9
    1. ipa-advise config-generic-linux-nss-pam-ldapd
  3. On the legacy client, apply the given advice.
    1. ipa-advise utility outputs script that can be directly executed on the server
  4. Test that native IPA user is resolvable.
    1. getent passwd admin
  5. Test that native IPA group is resolvable
    1. getent group editors
  6. Test that IPA user identity can be retrieved
    1. id admin
  7. Test that AD user is resolvable
    1. getent passwd testuser@ad.example.com
  8. Test that AD group is resolvable
    1. getent group testgroup@ad.example.com
  9. Test that IPA user identity can be retrieved
    1. id Administrator@ad.example.com
  10. Log in into the legacy client using native IPA user's credentials.
  11. Log in into the legacy client using AD user's credentials.
  12. Try to log in to the legacy client using disabled IPA user's credentials.
  13. Try to log in to the legacy client using disabled AD user's credentials.

Expected results

  1. Trust should be estabilished and verified.
  2. ipa-advise should output instructions how to configure the legacy client that can be executed as a script.
  3. Applying the script should be successful.
  4. Native IPA user should resolve.
  5. Native IPA group should resolve.
  6. IPA user information should retrieve successfully.
  7. AD user should resolve.
  8. AD group should resolve.
  9. AD user information should retrieve successfully.
  10. Successful login into the legacy client using native IPA user's credentials.
  11. Successful login into the legacy client using AD user's credentials.
  12. Login should be rejected.
  13. Login should be rejected.

Test case: Legacy client with nss-ldap configured using authconfig

Autotest

{{{autotest}}}

Setup

Implementation detail: This test requires setting the TESTHOST_LEGACY_CLIENT_NSS_LDAP_REDHAT_env<x> environment variable, where x is the environment number of your IPA server. See V3/Integration_testing#Additional_roles

  1. Configure IPA server.
    1. Run ipa-server-install.
    2. Run ipa-adtrust-install with --enable-compat.
  2. Setup proper DNS records both on AD and IPA server
  3. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org
    2. Establish a trust to Active Directory (it does not matter whether the server has POSIX support or not)
  4. Add a user in Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use testuser as a logon name.

Actions

  1. On the IPA server, add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. On the IPA server, ask for advice how to configure legacy client with SSSD < 1.9
    1. ipa-advise config-redhat-nss-ldap
  3. On the legacy client, apply the given advice.
    1. ipa-advise utility outputs script that can be directly executed on the server
  4. Test that native IPA user is resolvable.
    1. getent passwd admin
  5. Test that native IPA group is resolvable
    1. getent group editors
  6. Test that IPA user identity can be retrieved
    1. id admin
  7. Test that AD user is resolvable
    1. getent passwd testuser@ad.example.com
  8. Test that AD group is resolvable
    1. getent group testgroup@ad.example.com
  9. Test that IPA user identity can be retrieved
    1. id Administrator@ad.example.com
  10. Log in into the legacy client using native IPA user's credentials.
  11. Log in into the legacy client using AD user's credentials.
  12. Try to log in to the legacy client using disabled IPA user's credentials.
  13. Try to log in to the legacy client using disabled AD user's credentials.

Expected results

  1. Trust should be estabilished and verified.
  2. ipa-advise should output instructions how to configure the legacy client that can be executed as a script.
  3. Applying the script should be successful.
  4. Native IPA user should resolve.
  5. Native IPA group should resolve.
  6. IPA user information should retrieve successfully.
  7. AD user should resolve.
  8. AD group should resolve.
  9. AD user information should retrieve successfully.
  10. Successful login into the legacy client using native IPA user's credentials.
  11. Successful login into the legacy client using AD user's credentials.
  12. Login should be rejected.
  13. Login should be rejected.

RFE Author