QA:Testcase freeipa use legacy sssd to give access to trusted domain users

From FedoraProject

Jump to: navigation, search

Contents

Description

Use an old version of SSSD to gain access to trusted domain users

Setup

  1. Make sure your FreeIPA server is set up as in QA:Testcase_freeipa_trust_establish.
  2. Make sure SSSD is installed. This test uses RHEL-6.3 as an example, but the steps should be similar for other distribution or OS

How to test

Add test users and groups on the IPA server

When testing the legacy client, we will begin by creating a user and a group he is a member of on the server first to establish a baseline.

$ kinit admin
$ ipa user-add --first=test --last=user tuser
$ ipa group-add --desc="test group" tgroup
$ ipa group-add-member --users=tuser tgroup

Also set some password for the newly created user so that we can log in using his credentials.

$ ipa passwd tuser

Install required packages

The package installation step differs for every OS or distribution. in Fedora/RHEL, simply install the packages using yum:

 # yum install sssd authconfig

The authconfig utility will help us configure the PAM stack and the SSSD itself.

Download the CA certificate

The SSSD doesn't support authentication over an unencrypted channel. We need to download the CA certificate of the IPA server

wget http://srv.ipa.example.org/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt

And then generate hashes for the openldap library:

cacertdir_rehash /etc/openldap/cacerts/

Configure SSSD

Next the SSSD needs to be configured. The configuration will point to a "compat tree" which is a parallel LDAP tree autogenerated from the main tree and tailored so that it matches the expectations legacy clients might have. The configuration includes two important items:

  1. LDAP URI - The URI is simply the host name of the IPA server prefixed with ldap://. For example, if the hostname was srv.ipa.example.org, then the URI would be ldap://srv.ipa.example.org
  2. LDAP search base - The LDAP search base we need consists of the base DN prefixed with "cn=compat", which is the container the compat tree lives in. To get the base DN, take the IPA domain name and substitute each dot for a "dc=". For example, the IPA domain ipa.example.org would yield base DN dc=ipa,dc=example,dc=org. The full search base you want to use would then be cn=compat,dc=ipa,dc=example,dc=org

Using authconfig

Configuring the system to authenticate with IPA using authconfig is a little more involved than in case of nss-pam-ldapd as we need to configure the sssd.conf ourselves. Use the authconfig to configure nsswitch.conf and the PAM stack:

authconfig --updateall --enablesssd --enablesssdauth

Next, we will configure the SSSD itself. One important non-default setting is the custom value of re_expression. The re_expression parameter tells the SSSD how to split the username and domain component of a quety. By default, the user- and group-names are stored in the compat tree in fully-qualified format (user@domain). However, this format matches the default value of re_expression as well. To avoid conflict, the re_expression is set to only ever match a username. Copy the snippet below to /etc/sssd/sssd.conf and make sure the permissions on the file are 0600, otherwise the SSSD will not start!

[sssd]
services = nss, pam
config_file_version = 2
domains = default
re_expression = (?P<name>.+)
[domain/default]
cache_credentials = True
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://srv.ipa.example.org
ldap_search_base = cn=compat,dc=ipa,dc=example,dc=org

Configure NSS and PAM manually

On systems without a helper tool such as authconfig, one needs to configure the client system manually. The configuration involves several steps:

1. configure nsswitch.conf - append sss to the lines beginning with passwd and group.

passwd:     files sss
group:      files sss

2. configure PAM - configuring the PAM stack differs on particular distributions. The resulting PAM stack should look like this one:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so
password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

3. Configure /etc/sssd/sssd.conf - See above.

4. start sssd

service sssd start

Identity lookups of IPA users and groups

Try to request data about the user that was created on the start of this test:

$ getent passwd tuser
$ getent group tgroup
$ id tuser

The commands above should reflect that tuser is member of tgroup.

Authentication as IPA user

This testcase currently does not work due to referral returned from the server.

ssh client.example.org -l tuser

The error you would see would be similar to:

pam_ldap: error trying to bind as user "uid=tuser,cn=users,cn=compat,dc=ipatest,dc=example,dc=com" (Referral)

Identity lookups of trusted users and groups

When requesting the user from a trusted domain, the username must be fully qualified in the form of username@ad-domain. Additionaly, to conform with nss-pam-ldapd limitation, the username and domain name must be lowercased to match the name in the compat tree with respect to case.

To request a from the trusted domain:

$ getent passwd administrator@ad.example.org

Authentication as trusted user

Again, the username must be fully qualified and lowercased:

ssh client.example.org -l administrator@ad.example.org

Expected Results

Both users from the IPA domain and the trusted domain should be able to log in.