I recently got a Raspberry Pi 3 on which I installed Ubuntu Server 16.04. I decided for science that I wanted to enable my AD users to authenticate to the RPi. Most guides I saw required Kerberos which is perfectly reasonable but I don’t have a Kerberos server so I needed another solution. It was a bumpy road and I’m quite unfamiliar with most of the stuff, so I decided to document my steps, mostly for myself in case I’d need to replicate them in the future. Then again I probably already forgot some details…
First add new Organization Units in AD. I added OU=People and OU=Groups. Since Identity Management for Unix is getting deprecated, I am going to manually edit the Unix attributes via the Attribute Editor tab of the user properties. This is well documented here. Essentially you need to set the values for gidNumber for groups and uidNumber, gidNumber, loginShell and unixHomeDirectory for users.
Add some users to the People OU, also creating one for LDAP bind. Add a group for those users.
On the RPi client, we’ll be using SSSD for authentication.
$> sudo apt install sssd python3-sss sssd-tools ldap-utils
/usr/bin/python to ‘/usr/bin/python3’ because reasons, and that caused some errors installing SSSD which is dumb, so if anyone is in a similar situation, temporarily run
ln -sf /usr/bin/python2 /usr/bin/python, re-attempt to install SSSD. Then do
ln -sf /usr/bin/python3 /usr/bin/python again. I needed that for some CloudFlare script to run…
At this point it may be good to ensure connectivity to the AD server.
$> ldapsearch -v -x -H ldaps://<ldap server>:636 -b dc=ldap,dc=example,dc=com -D 'CN=<bind user cn>,OU=People,dc=ldap,dc=example,dc=com' -W 'cn=Some Other User'
Export your CA certificate in base-64 format to install on the RPi. I installed mine in
/etc/ldap/certs and chmod’ed it to 600.
/etc/ldap.conf. The important settings should be
base dc=ldap,dc=example,dc=com uri ldaps://ldap.example.com ldap_version 3 tls_cacertdir /etc/ldap/certs
/etc/ldap/ldap.conf. What worked for me was
BASE dc=ldap,dc=example,dc=com URI ldap://ldap.example.com TLS_REQCERT allow TLS_CACERT /etc/ldap/certs/name-of-my-ca-cert.cer SSL start_tls
Actually I’m not even sure this last file is being used at all since when I checked in Apache Directory Studio I could only connect using LDAPS and not StartTLS…
At this point I think an encrypted connection to the AD can be attempted.
$> ldapsearch -v -H ldaps://<ldap server>:636 -b dc=ldap,dc=example,dc=com -D 'CN=<bind user cn>,OU=People,dc=ldap,dc=example,dc=com' -W 'cn=Some Other User'
passwd: compat sss shadow: compat sss services: db files sss netgroup: nis sss sudoers: files sss
Leave the other existing entries intact.
We finally get to configuring
/etc/sssd/sssd.conf. Most of my settings were sourced from this CentOS guide
$> touch /etc/sssd/sssd.conf $> chown root:root /etc/sssd/sssd.conf $> chmod 600 /etc/sssd/sssd.conf $> nano /etc/sssd/sssd.conf
[sssd] config_file_version = 2 services = nss, pam domains = ldap.example.com [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] [domain/ldap.example.com] debug_level = 1 enumerate = false cache_credentials = true min_id = 100 # just in case, if the AD is IPv6-only lookup_family_order = ipv6_first id_provider = ldap auth_provider = ldap access_provider = simple chpass_provider = ldap ldap_id_use_start_tls = False ldap_schema = rfc2307bis ldap_tls_cacert = /etc/ldap/certs/name-of-my-ca-cert.cer ldap_tls_reqcert = never ldap_user_search_base = dc=ldap,dc=example,dc=com ldap_group_search_base = dc=ldap,dc=example,dc=com ldap_user_object_class = user ldap_user_principal = userPrincipalName ldap_user_name = sAMAccountName ldap_user_gecos = displayName ldap_group_object_class = group ldap_group_name = sAMAccountName ldap_user_home_directory = unixHomeDirectory ldap_uri = ldaps://ldap.example.com:636 ldap_default_bind_dn = CN=<bind cn>,OU=People,DC=ldap,DC=example,DC=com ldap_default_authtok_type = obfuscated_password ldap_default_authtok = replaceme simple_allow_groups = <the group for unix users>
For details on what each entry does: RTM. Then to obfuscate the bind dn password run
$> sss_obfuscate -d ldap.example.com -f /etc/sssd/sssd.conf
And it should replace the
ldap_default_authtok entry in
Now SSSD can be started
$> service sssd start
In my case the service failed to start with some obscure error about being unable to convert the obfuscated password back to plain-text. And changing
ldap_default_authtok to the plain-text password still gave the same error. The reason for that turned out to be due to some stupid python2 vs python3 (did I mention I hate python?) problem preventing
sss_obfuscate from running correctly the first time and
cache_credentials = true in
sssd.conf. Some bogus value was generated by
sss_obfuscate and it remained in the cache.
$> rm -rf /var/lib/sss/db/* $> service sssd start $> echo victory, finally
You can check that everything works by running
$> id someusername
And it should return some information on that AD user. Now you should be able to
ssh into the RPi with your AD users.
Permission denied (publickey)
…or not. In my case I disabled password login, so some extra steps are needed. The default AD schema doesn’t have any entry for SSH public keys, and this discussion suggests modifying the registry to allow modifications to the AD schema. I don’t feel that comfortable doing that as it may lead to unwanted consequences were the server to be upgraded to Windows Server 2016 so caution is advised.
At the bottom of the discussion however one user suggests using some other built-in AD field. Since I’m now using that altSecurityIdentities field, it seems like an acceptable solution. It is as simple as adding your SSH public key to the altSecurityIdentities field, and editing
services = nss, pam, ssh, sudo ldap_user_ssh_public_key = altSecurityIdentities
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser root
Restart SSSD and SSHD
…aaand it doesn’t work. For now I simply manually added the
authorized_keys to the user’s home profile and called it a day. Other issues I’m currently having is that
sudo won’t work as passwords are also not being synced or something. I’ll leave fixing that to another day however as I’ve already spent a lot of time on this. I suspect the password problem has something to do with Identity Management for Unix being deprecated (and me not installing it for that reason).