Manually enroll SLES12 systems to Redhat IdM

RHEL and Ubuntu systems leverage the ipa-client software to easily enrolled them to a Redhat IdM system. Unfortunately SLES12 lacks the required packages. Nevertheless, SLES12 systems can be enrolled manually. This article is about how to achieve this.

Why using IPA for SLES systems?

Most organizations are not pure RHEL or pure SLES shops, the reality shows a heterogeneous mix of Linux distributions in corporate data centers. It makes sense to use the same authentication and authorization system to manage them.

Disclaimer

All the “special” behavior of SLES12 is based on SP2 without any patches, I do not have a SLES subscription for this test. Some of this behavior may have been fixed.

Before touching any system, please have a valid backup ready, just in case.

Preparation work

IPA is picky when it comes to host names, they must be fully qualified. Unfortunately, the default for SLES systems is to use the short host name, this must be changed first, otherwise the functionality will be limited (besides that short host names are a potential security thread).

sles12sp2:~ # hostnamectl set-hostname $(hostname -f)

In case hostname -f does not work, check if the fully qualified host name is set to the primary IP address in /etc/hosts and try again.

Unfortunately this will not survive a reboot, a dirty hack is needed. If someone has a better idea, please let me know.

sles12sp2:~ # echo 'echo $(hostname -f) > /proc/sys/kernel/hostname' >> /etc/init.d/boot.local

Please ensure that system time is correct as Kerberos is picky about having the time in sync with the KDC.

Install the required software

SLES12 comes with the basic IPA libraries and the sssd plugin needed. It just lacks the ipa-client.

sles12sp2:~ # zypper install sssd-ipa sssd-tools sssd-krb5 krb5-client sssd-ad

All dependencies will be installed automatically.

Enable sssd start at boot time, as it is not by default

sles12sp2:~ # systemctl enable sssd

Remove nscd, caching will be done by sssd.

sles12sp2:~ # zypper remove nscd

Log out and in again to get /usr/lib/mit/ in the PATH environment.

Adding the host to IPA

[root@ipa1 ~]# ipa host-add --ip-address=192.168.100.115 sles12sp2.example.com 
----------------------------------
Added host "sles12sp2.example.com"
----------------------------------
  Host name: sles12sp2.example.com
  Principal name: host/sles12sp2.example.com@EXAMPLE.COM
  Principal alias: host/sles12sp2.example.com@EXAMPLE.COM
  Password: False
  Keytab: False
  Managed by: sles12sp2.example.com
[root@ipa1 ~]# 

Generating the Kerberos Keytab and copy it to the destination host

[root@ipa1 ~]# ipa-getkeytab -s ipa1.example.com -p host/sles12sp2.example.com@EXAMPLE.COM -k sles12sp2.example.com.keytab
Keytab successfully retrieved and stored in: sles12sp2.example.com.keytab
[root@ipa1 ~]#  

Copy the Keytab to the system:

[root@ipa1 ~]# scp sles12sp2.example.com.keytab sles12sp2.example.com:/etc/krb5.keytab

Ensure ownership and permissions are set correctly

sles12sp2:~ # chmod 0600 /etc/krb5.keytab
sles12sp2:~ # chown root:root /etc/krb5.keytab

Configuration

Usually Yast is a quite nice tool to configure a SLES system. Unfortunately Yast is very confusing when it comes to SSSD configuration. Lets do it manually.

Get the IPA CA certificate

sles12sp2:~ # mkdir /etc/ipa
sles12sp2:~ # wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/ipa/ca.crt

/etc/krb5.conf

sles12sp2:~ # cat > /etc/krb5.conf << EOF

[plugins]
 localauth = {
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }


[libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  dns_canonicalize_hostname = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  canonicalize = true
  default_ccache_name = KEYRING:persistent:%{uid}

[realms]
  EXAMPLE.COM = {
    pkinit_anchors = FILE:/etc/ipa/ca.crt
    pkinit_pool = FILE:/etc/ipa/ipa.crt

  }

[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
  $(hostname) = EXAMPLE.COM
EOF

/etc/sssd/sssd.conf/

sles12sp2:~ # cat > /etc/sssd/sssd.conf << EOF
[domain/example.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = $(hostname)
chpass_provider = ipa
ipa_server = _srv_, ipa1.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh

domains = example.com
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[ifp]

[secrets]
EOF

Ensure ownership and permissions are correct:

sles12sp2:~ # chown root:root /etc/sssd/sssd.conf
sles12sp2:~ # chmod 600 /etc/sssd/sssd.conf

Restart sssd

sles12sp2:~ # systemctl restart sssd

nsswitch.conf and PAM

Enable sssd

sles12sp2:~ # pam-config --add --sss

Enable automatic homedir creation on first login

sles12sp2:~ # pam-config --add --mkhomedir --mkhomedir-umask=0077

Change nsswitch.conf to use sssd

sles12sp2:~ # sed -i 's/passwd: compat/passwd: compat sss/g' /etc/nsswitch.conf
sles12sp2:~ # sed -i 's/group:  compat/group: compat sss/g' /etc/nsswitch.conf
sles12sp2:~ # echo "sudoers: sss" >> /etc/nsswitch.conf

Configure sshd and ssh to use GSSAPI for authentication

sles12sp2:~ # cat >> /etc/ssh/sshd_config << EOF
GSSAPIAuthentication yes
EOF
sles12sp2:~ # cat >> /etc/ssh/ssh_config << EOF
GSSAPIAuthentication yes
EOF

Reboot to ensure its all working and caches are clean

sles12sp2:~ # reboot

Further readings

Conclusion

Using IPA for authenticating users on SLES systems works, but it is not as comfortable as with RHEL, Fedora and Ubuntu. Suse should include the ipa-client in its distribution.

Enrolling SLES systems is not easy to automate without the ipa-client, probably Ansible could help here.

The functionality is almost the same to that for RHEL7, HBAC (host based access control) is working as expected, the same applies to centralized sudoers. Unfortunately the sssd-tools are quite outdated, sss_cache -E will not delete the sudoers cache. Suse should rebase sssd to the latest upstream version. Suse customers can file a request for enhancement in the SUSE Customer Center 😉

Have fun 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *