Is it possible to use an alternate home directory and not the system /etc/passwd file?
I’ve got the server configured for single sign on with OpenID Connect and I’d like
to not have to define the users in the passwd file. I tried enabling UserDir in userdir.conf
but it still uses the system. I’m open to a simple mapping, using ldap or even dbm.
Can someone point me in the right direction?
Hi and welcome!
I think LDAP is probably your best bet. I believe we’ll grab HOME from there and the Ruby Etc libraries we use will also respond to that.
Indeed - I think that’s how most systems are run. Most systems use LDAP users and not local users.
Thanks Jeff. Are you aware of any documentation that shows how to set this up?
I take it you don’t already have an LDAP provider? FreeIPA is likely a good choice. @tdockendorf do you have other recommendations?
If all you want is LDAP, FreeIPA might be overkill. The underlying LDAP in FreeIPA is 389DS from RedHat which you can deploy by itself. 389 Directory Server - Documentation. 389DS does have a graphical UI component but it also behaves like standard LDAP so can be configured with cn=config changes.
Where is the OpenID Connect identities coming from? Generally the thing doing OpenID Connect would also be the thing defining home directories unless you are doing SSO from some external identity provider that isn’t local. At OSC our OIDC setup uses Keycloak which allows SSO via our local LDAP so Keycloak and the underlying host all have access to the same LDAP data.
I have an OpenLDAP server running. I’m looking for guidance in configuring the ood side.
I forgot the second part. The OpenID Connect auth is coming from ND’s Identity and Access Mgmt group and is not providing home directory info. Only authorization.
This is a bit out of my wheelhouse, maybe @tdockendorf can provide more because all I can really do is LMGTFY.
Here’s a ubuntu docs I came up with
https://ubuntu.com/server/docs/service-ldap-introduction
And of course the OpenLDAP docs
https://openldap.org/doc/admin25/
Lastly here’s an example of how we configure our toolset containers to use a central LDAP. This is only an example - but could be useful.
If the usernames from your OIDC match local LDAP user names, then you will need to configure the local identity stack on OnDemand host to look at LDAP so it can map usernames to home directories. I’d recommend SSSD.
Example SSSD config for OSC’s OpenLDAP:
$ sudo cat /etc/sssd/sssd.conf
# Managed by Puppet.
[domain/LDAP]
ldap_uri = ldaps://ldap1.OMIT:636/
ldap_backup_uri = ldaps://ldap2.OMIT:636/, ldaps://ldap3.OMIT:636/
cache_credentials = true
debug_level = 4
entry_cache_timeout = 1800
enumerate = false
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
sudo_provider = none
ldap_search_base = dc=osc,dc=edu
ldap_schema = rfc2307bis
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_access_filter = (&(objectClass=shadowAccount)(objectClass=posixAccount)(!(loginDisabled=TRUE)))
ldap_access_order = expire, filter
ldap_account_expire_policy = 389ds
ldap_group_member = member
[nss]
filter_groups = root, wheel
filter_users = root
memcache_timeout = 300
[sssd]
config_file_version = 2
domains = LDAP
services = pam, nss
[pam]
offline_credentials_expiration = 1
[ssh]
ssh_known_hosts_timeout = 180
Once SSSD is configured, start the service via systemctl start sssd. If it’s not already installed, will of course have to install and it should be available in OS repos as most major distros support SSSD.
It’s worth noting we have a lot of custom schemas added which is why we use rfc2307bis and 389ds configs as we added those schemas to expand what we could do with OpenLDAP.
Then you need to configure nsswitch:
$ cat /etc/nsswitch.conf
# This file is controlled by Puppet
passwd: files sss
shadow: files sss
group: files sss
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: files sss
publickey: nisplus
automount: files sss
aliases: files nisplus
To validate:
$ getent passwd $USER
tdockendorf:*:20821:5509:Trey Dockendorf:/users/sysp/tdockendorf:/bin/bash
Is it safe to assume I don’t have the ability to just configure the user’s home directory using something like Apache’s mod_userdir or do a custom mapping via a script?
mod_userdir is intended to be used to allow people to access a user’s home directory via web browser so that many users could easily share their home directory contents via Apache. It won’t help with OnDemand I don’t think since OnDemand is asking the Linux host for the home directory value so the Linux host, not just Apache, needs to be aware of the home directory path.
Depending on the path, you could setup SSSD to map the home directory:
[nss]
override_homedir = /home/%u
If the home directory is the above pattern, then you could setup SSSD to map but the SSSD service still needs to be told what users exist so the Linux host knows which users exist would get you back to either using /etc/passwd or LDAP. Also with OnDemand the UID/$HOME/etc used on the OnDemand host must match those values used on the compute nodes since it’s expected the home directory on the OnDemand host is also accessible for compute nodes and with things like Slurm and likely other schedulers, the usernames and UIDs between those various systems must all match so either you’d be making /etc/passwd updates to OnDemand and the HPC cluster or using LDAP to keep both sides in sync.
Thanks for the clarification Trey. I’ll look at both options. I appreciate the information!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.