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 to sssd-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.org
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