- 1 Description
- 2 Setup
- 3 How to test
- 3.1 Add test users and groups on the IPA server
- 3.2 Install required packages
- 3.3 Download the CA certificate
- 3.4 Configure SSSD
- 3.5 Identity lookups of IPA users and groups
- 3.6 Authentication as IPA user
- 3.7 Identity lookups of trusted users and groups
- 3.8 Authentication as trusted user
- 4 Expected Results
Use an old version of SSSD to gain access to trusted domain users
- Make sure your FreeIPA server is set up as in QA:Testcase_freeipa_trust_establish.
- 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:
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:
- 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 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.orgwould yield base DN
dc=ipa,dc=example,dc=org. The full search base you want to use would then be
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: 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
/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 email@example.com
Authentication as trusted user
Again, the username must be fully qualified and lowercased:
ssh client.example.org -l firstname.lastname@example.org
Both users from the IPA domain and the trusted domain should be able to log in.