Hi,
we want to setup several PCs in a way that they are accessible by different (untrusted, i.e. not with root rights) people.
In principal, the requirements are: - Each person gets an unique (UNIX) account that is managed at a server. - Each person gets a home directory that is shared across all PCs, comes from a central server. Ideally, the home directory is only mounted when someone logs in and checks in the process the authenticity of the user, the authenticity of the client and that of the server. - Ideally, one person is not able to access any data from the other person. - The PCs should authenticate to the server. All communication should be encrypted (at least all communication regarding authentication). - I should hold that only a user with a valid account can login on a PC with a valid key and mount data from a server with a valid key.
This seems to be a classical problem for LDAP, Kerberos, NFSv4 with sssd as the client side daemon to manage all that. However, I'm not quite sure, if I understood the interworkings completely and if sssd is capable of working in the wanted way.
- We have an LDAP database which stores the users (of class posixAccount). - We have set up a Kerberos daemon which uses this LDAP as database. - We have set up an NFSv4 server that has an Kerberos principal and a keytab.
In my understanding the next steps now would be: - Each user in the LDAP database also gets a Kerberos keytab (which can be different from their login password). - SSSD now has to do the following steps: - When the user types in their password in the login manager, PAM in connection with sssd use this to bind to the LDAP server (so sssd uses LDAP as id_provider and LDAP as auth_provider). - After the successful authentication, sssd gets the Kerberos key from the Kerberos database and uses that key to securely mount the NFSv4 home directory on the PC (the target folder is also specific as part of the user attributes, but where can sssd find the folder on the host?).
Is that possible? I also read that Kerberos in connection with NFSv4 can be used to authenticate the NFSv4 server, the NFSv4 client _and_ the specific user. Can that happen all simultaneously, so in one mount command? I only find the `sec=krb5x` mount options where the NFSv4 client and the NFSv4 server authenticates to the Kerberos server but without using anything from the user.
Best, Gerion
On 9/5/23 3:42 PM, Gerion Entrup wrote:
Hi,
we want to setup several PCs in a way that they are accessible by different (untrusted, i.e. not with root rights) people.
In principal, the requirements are:
- Each person gets an unique (UNIX) account that is managed at a server.
- Each person gets a home directory that is shared across all PCs, comes from a central server. Ideally, the home directory is only mounted when someone logs in and checks in the process the authenticity of the user, the authenticity of the client and that of the server.
- Ideally, one person is not able to access any data from the other person.
- The PCs should authenticate to the server. All communication should be encrypted (at least all communication regarding authentication).
- I should hold that only a user with a valid account can login on a PC with a valid key and mount data from a server with a valid key.
This seems to be a classical problem for LDAP, Kerberos, NFSv4 with sssd as the client side daemon to manage all that. However, I'm not quite sure, if I understood the interworkings completely and if sssd is capable of working in the wanted way.
- We have an LDAP database which stores the users (of class posixAccount).
- We have set up a Kerberos daemon which uses this LDAP as database.
- We have set up an NFSv4 server that has an Kerberos principal and a keytab.
In my understanding the next steps now would be:
- Each user in the LDAP database also gets a Kerberos keytab (which can be different from their login password).
- SSSD now has to do the following steps:
- When the user types in their password in the login manager, PAM in connection with sssd use this to bind to the LDAP server (so sssd uses LDAP as id_provider and LDAP as auth_provider).
- After the successful authentication, sssd gets the Kerberos key from the Kerberos database and uses that key to securely mount the NFSv4 home directory on the PC (the target folder is also specific as part of the user attributes, but where can sssd find the folder on the host?).
Is that possible? I also read that Kerberos in connection with NFSv4 can be used to authenticate the NFSv4 server, the NFSv4 client _and_ the specific user. Can that happen all simultaneously, so in one mount command? I only find the `sec=krb5x` mount options where the NFSv4 client and the NFSv4 server authenticates to the Kerberos server but without using anything from the user.
Best, Gerion
sssd-users mailing list --sssd-users@lists.fedorahosted.org To unsubscribe send an email tosssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
your requirements are sound. for the PAM stuff, i use authselect, to setup PAM and nsswitch.conf for the bits and pieces. the home directory being mounted will have to be done with an automount process. i used fedora, so the package is autofs. sssd can manage this and you have to specify the mount directives in LDAP. the syntax for that did not make sense to me at first. example:
# parent object dn: automountMapName=auto.master,ou=WorkStations,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com automountmapname: auto.master objectclass: automountMap objectclass: top
# any shares not specifically /home dn: automountKey=/-,automountMapName=auto.master,ou=WorkStations,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com automountinformation: auto.shares automountkey: /- objectclass: automount objectclass: top
# home share dn: automountKey=/home,automountMapName=auto.master,ou=WorkStations,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com automountinformation: auto.home automountkey: /home objectclass: automount objectclass: top
# parent object dn: automountMapName=auto.home,ou=WorkStations,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com automountmapname: auto.home objectclass: automountMap objectclass: top
# actual home dir dn: automountKey=*,automountMapName=auto.home,ou=WorkStations,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com automountinformation: nfs.bpk2.com:/export/home/& automountkey: * description: home dirs objectclass: automount objectclass: top
there is quite a bit to understand in all of that, and that may be out of scope for this thread/mailing list, but it should work if you customize the DN's, etc to your environment.
when it come to the NFS keytab, the location of that can be tricky. normally, it defaults to /etc/krb5.keytab, but if your nfs server uses a conf file like /etc/nfs.conf, you can specify the keytab location there.
your understandings are close, but some clarity... users dont normally use/need keytabs. keytabs are encrypted/hashed credentials on the filesystem and generally are used by processes not users. users acquire kerberos tickets/tokens for the different resources they are entitled to. i dont think you need to create keytabs for the users. just create their kerberos principals and map the kerberos identity to a ldap object, if not already done.
properly configuring sssd with all the necessary directives should get you properly working. auth_provider should be krb5, though, not ldap. my sssd config:
[sssd] domains = bpk2.com services = nss, pam, sudo, autofs config_file_version = 2 #debug_level = 4
[nss] filter_groups = root filter_users = root
[pam]
[sudo]
[autofs]
[domain/bpk2.com] #debug_level = 4 id_provider = ldap ldap_schema = rfc2307bis ldap_uri = _srv_,ldap://ldap.bpk2.com ldap_search_base = dc=bpk2,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/nas.bpk2.com ldap_sasl_realm = BPK2.COM
auth_provider = krb5 krb5_server = _srv_,kerberos.bpk2.com krb5_kpasswd = _srv_,kerberos.bpk2.com krb5_realm = BPK2.COM krb5_renewable_lifetime = 7d krb5_lifetime = 24h krb5_renew_interval = 1h krb5_store_password_if_offline = true cache_credentials = true
sudo_provider = ldap ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
autofs_provider = ldap #ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com ldap_autofs_search_base = ou=NASs,cn=autofs-test,ou=Daemons,dc=bpk2,dc=com ldap_autofs_map_object_class = automountMap ldap_autofs_entry_object_class = automount ldap_autofs_map_name = automountMapName ldap_autofs_entry_key = automountKey ldap_autofs_entry_value = automountInformation
#min_id = 1000 #max_id = 2000 enumerate = false
again, a fair amount to dig into there, but customizing that to your environment should provide a solid starting point.
once the user is authenticated the first time , a kerberos TGT (ticket granting ticket), not a key, will be used to authenticate to the NFS server. the user will fetch a nfs ticket from the krb server and present that to the NFS server to prove their identity. the properly configured nfs server will be able to validate the ticket, using the ticket aquired during the service start up. as you can see the autofs directives are in the sssd.conf and point to the ldap entries i provided as an example.
with regards to the authentication of users and sec=krb5/i/p, i use sec=krb5p, which authenticates the user, enforces integrity and encrypts the comms. the nuances with all of the inner workings is a bit of reading, and may be an exercise left to the reader. suffice it to say, when i want to allow a server to use a nfs share, say for backups, i do not include the sec= directive in /etc/exports. when i want to grant a user access to a share, i use the sec=krb5p directive, and the user must have be able to pull a nfs ticket from the krb server in order to access the share. from there, ownership and file permissions control authorization. there are further ACLs that can be implemented for more fine grained control over the dirs and files, but i havent gotten that far into it.
hope this helps,
brendan
sssd-users@lists.fedorahosted.org