Client Authentication:Ubuntu via sssd/ldap
- 1 Introduction
- 2 Backup
- 3 Assumptions
- 4 Configuration of the SME-server
- 5 Configuration of the Ubuntu client
- 6 PHPKi
- 7 Letsencrypt
- 8 Desktop Setup
- 9 Miscellaneous Notes
This how-to shows how to configure a SME-server (>=8b6) and a client Ubuntu for a LDAP based SSSD authentication of the client machine on the configured user accounts of the SME.
The main advantage in comparaison to nss_ldap is that the authentication information stays in the cache and the authentication can therefore still work even in offline mode (when the server not available).
Nevertheless, the creation of a local user with the admin rights is recommended for the emergency case.
These lines are a translation of the method given by Daniel: https://wikit.firewall-services.com/doku.php/tuto/ipasserelle/authentification/ubuntu_sssd_on_sme. Many thanks to him for it.
cp /etc/pam.d/common* /home/myhome/backup
In this how-to we assume that:
the host name of the SME is "sme-server" and the domain is "domain.tld".
Configuration of the SME-server
There is little configuration required in SME server.
- The only thing to do is to create a user (named "auth" in this how-to) via the server-manager and to give them a valid password ("something_very_secret" in the how-to).
It is not required to make "auth" member of any group.
- In addition, it is recommended to install and configure PHPki in order to make the managing of the self-created certificates easier.
Configuration of the Ubuntu client
Installation of the required packages
sudo apt-get install sssd libnss-sss libpam-sss auth-client-config
There seems to be a bug in the version of sssd from Ubuntu and therefore the following links must be created:
ln -s /usr/lib /usr/modules
Without it, sssd can't manage membership to the groups in LDAP (source http://us.generation-nt.com/bug-599644-sssd-unable-resolve-ldap-group-memberships-help-200739341.html)
Managing the CA on SME
After having installed PHPki, go to https://www.domain.tld/phpki and download the certificate of authority (ca-certificates.crt) to the client machine.
Place a copy of it or of another CA into /etc/ssl/certs/ and give the 644 permissions:
cp ~/Downloads/ca-certificates.crt /etc/ssl/certs/ chmod 644 /etc/ssl/certs/ca-certificates.crt
If you use Letsencypt for your certificates then your client machine should already have the ca-certificate for letsencrypt installed
You should be able to set the following in sssd.conf
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
The configuration of sssd is achieved in a standard way (as per Ubuntu or Fedora for example) and is made by the file /ets/sssd/sssd.conf.
- At the beginning of this file, the used domain has to be set. In sssd, a domain can be taken as a source of content. It is possible to set several domains in order of priority.
- And deeper in the file, we will add the configuration of the domain
If the file doesn't exist by default it has to be created and it needs to get the permissions 600 to allow the daemon to start. On Ubuntu clients using sudo you may need to get a root shell first:
Now we can copy and paste this into the terminal:
cat <<'_EOF' > /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = LDAP [nss] [pam]
[domain/LDAP] # Debug is now per domain # Debug level can be 0-10 for simple levels, # or for more control hex values Format is 0xXXXX # 1 = 0x0010 2 = 0x0020 3 = 0x040 4 = 0x080 5 = 0x0100 6 = 0x0200 # see man sssd for more # https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sssd-troubleshooting debug_level = 3 id_provider = ldap auth_provider = ldap ldap_schema = rfc2307 ldap_uri = ldap://sme-server.domain.tld ldap_default_bind_dn = uid=auth,ou=Users,dc=domain,dc=tld ldap_default_authtok = something_very_secret ldap_default_authtok_type = password ldap_search_base = dc=domain,dc=tld ldap_user_search_base = ou=Users,dc=domain,dc=tld ldap_group_search_base = ou=Groups,dc=domain,dc=tld ldap_user_object_class = inetOrgPerson ldap_user_gecos = cn ldap_tls_reqcert = hard ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt ldap_id_use_start_tls = true # uncomment below if the SME is a “iPasserelle” #ldap_user_shell = desktopLoginShell # comment below if the SME is a “iPasserelle” override_shell = /bin/bash cache_credentials = true enumerate = true # It is possible to filter the logins via a LDAP-filer # by commenting the both lines below. # In this exemple, only the users member of the group netusers # will be valid on this host. # posixMemberOF is a parameter only for a iPasserelle #access_provider = ldap #ldap_access_filter = (|(posixMemberOf=admins)(uid=backup)) _EOF
Now we need to set the correct permissions on the file:
chmod 600 /etc/sssd/sssd.conf
Configure the system to use SSSD as a source of authentication:
Setup to use the tool auth-client-config.
We can copy and paste in a terminal to add following lines:
cat <<'_EOF' > /etc/auth-client-config/profile.d/sss [sss] nss_passwd= passwd: compat sss nss_group= group: compat sss nss_shadow= shadow: compat nss_netgroup= netgroup: nis pam_auth= auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth [success=1 default=ignore] pam_sss.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so pam_account= account required pam_unix.so 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 pam_password= password sufficient pam_unix.so obscure sha512 password sufficient pam_sss.so use_authtok password required pam_deny.so pam_session= session required pam_mkhomedir.so skel=/etc/skel/ umask=0077 session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_sss.so session required pam_unix.so _EOF
And enable this:
sudo auth-client-config -a -p sss
Now you should be able to reboot and login as a LDAP member.
We should be able to restore the original pam config files with
sudo auth-client-config -a -p sss -r
Create a 'cliadmins' group on the server. This will be used to identify domain users to the desktop machine.
So that domain users have sudo rights we need to add this group to /etc/sudoers
NOTE - use visudo so you do not break this file ! :
%cliadmins ALL=(ALL) ALL
System Permissions & PolicyKit
I also found to enable shutdown/restart, network indicator etc I had to add this to /etc/auth-client-config/profile.d/sss
pam_session= session optional pam_systemd.so
Check if you run Policykit (most likely):
pgrep -lf polkit
To allow admin access on the desktop we need to edit the following file:
Add the following to sections as required:
[Mounting, checking, etc. of internal drives] [Setting the clock] [Adding or changing system-wide NetworkManager connections] [Update already installed software] [usb-creator] [Printer administration] [Modify error reporting settings]
LightDM Login Box
If you want to have a simple login box with manual login only you can do the following:
Add the following:
[SeatDefaults] greeter-show-manual-login=true greeter-hide-users=true
If you can successfully login with a domain account you can now try and automatically mounts shares.
You will require at least cif-utils and libpam-mount
sudo apt-get install libpam-mount cifs-utils
In the above file /etc/auth-client-config/profile.d/sss
We need to add the following to the sections for:
pam_auth= auth optional pam_mount.so enable_pam_password
pam_session= session optional pam_mount.so enable_pam_password
We now need to setup global mounts for all users with /etc/security/pam_mount.conf.xml
Note: you can exclude local users from mounting directories with sgrp setting. You MAY need need nounix in mntoptions (needs testing)
Add the following:
cat <<'_EOF' >/etc/security/pam_mount.conf.xml <pam_mount> <debug enable = "0" /> <mntoptions allow = "nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,noexec" /> <mntoptions require = "nosuid,nodev,noexec" /> <logout wait = "5" hup = "0" term="yes" kill="0" /> <mkmountpoint enable = "1" remove = "true" /> <volume fstype = "cifs" server = "sme.server.com" path = "%(USER)" mountpoint = "/home/e-smith/files/users/%(USER)/Partages/Personnel" options = "uid=%(USER),nosuid,nodev,noexec" user = "*" sgrp = "admins"/> <volume fstype = "cifs" server = "sme.server.com" path = "artwork" mountpoint = "/home/e-smith/files/users/%(USER)/Mounts/artwork" options = "uid=%(USER),nosuid,nodev,noexec" user = "*" sgrp = "admins"/> </pam_mount> _EOF
Now when you login as a domain user your shares should mount and you should have full sudo access.
Local password required for sudo
One irritation that I have seen is that when you run a program requiring sudo e.g. Synaptic it may ask you for the password of a LOCAL user, not the domain user.
I believe adding your new group to the following file will then present you with a list of users who can authenticate:
It will present an 'Authenticate' box with a list of users - I have not yet found how to just accept the password for the current logged in user (as per normal case for standalone user). Most likely it requires a modification to lightdm similar to above.
You may get the following error:
PAM unable to dlopen(pam_winbind.so): /lib/security/pam_winbind.so: cannot open shared object file: No such file or directory
This is due to a file location issue. You can resolve this error by doing the following:
cd /lib;ln -s /lib/x86_64-linux-gnu/security security
If you do not use kwallet and get annoyed by this message:
PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
edit /etc/pam.d/lightdm and lightdm-greeter and comment lines containing the following:
Wish I knew all this a week ago !