sssd in connection with LDAP, Kerberos and NFSv4

[Gerion Entrup]

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

[Brendan Kearney]

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(a)lists.fedorahosted.org
>  To unsubscribe send an email tosssd-users-leave(a)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/[e-mail]...
>  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