SDS@hd/Access/ID-Mapping

From bwHPC Wiki
< SDS@hd‎ | Access
Revision as of 01:49, 29 November 2024 by H Schumacher (talk | contribs) (2. to 3. level caption)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

SDS@hd ID-Mapping

ID-Mapping allows you to map the uidNumbers/gidNumbers of SDS@hd accounts to more descriptive usernames.

If ID-Mapping is not or not correct configured, the ownerships and permissions of files/folders you see in the filesystem, will be incorrect. This could be confusing for users, but nevertheless the permission checking is done correctly on serversite.

Because SSSD is one of the standard tools and it supports more than one ldap/identity provider on a system, we are showing here an example configuration for this tool.

But of course you can use any other mechanism/tool to do the LDAP queries for ID Mapping if you want. The connection to SDS@hd LDAP Server is authenticated with the kerberos keytab of your machine. You can use any tool which supports GSSAPI with kerberos for authentication with the following parameters:

  • uri: ldap://bwservices.uni-heidelberg.de
  • search_base: dc=bwservices,dc=uni-heidelberg.de,dc=de
  • sasl mech: GSSAPI Authentication
  • krb5 Realm: BWSERVICES.UNI-HEIDELBERG.DE


If you don't need a machine keytab, but you still need ID Mapping (e.g. for CIFS Mounts on linux), you can use your Servicepassword to create a user keytab for LDAP authentication.

Example configuration of SSSD

The authentication to SDS@hd is done via kerberos.

If you have setup a working kerberos environment, you have to install the needed packages for kerberos and SSSD, e.g:

  • RedHat/CentOS:
$ yum install sssd-client sssd-krb5 sssd-ldap
  • debian/ubuntu:
$ apt install sssd sssd-krb5 sssd-ldap sssd-tools libnss-sss libsasl2-modules-gssapi-mit

If not existing, create a SSSD configuration file (/etc/sssd/sssd.conf) like this:

[sssd]
            domains = BWSERVICESAD
            config_file_version = 2
            services = nss

[domain/BWSERVICESAD]
            id_provider = ldap
            ldap_uri = ldap://bwservices.uni-heidelberg.de
            ldap_search_base = dc=bwservices,dc=uni-heidelberg,dc=de
            ldap_referrals = false

            ldap_schema = ad
            ldap_id_mapping = true
            min_id = 2000

            ldap_sasl_mech = GSSAPI
            krb5_realm = BWSERVICES.UNI-HEIDELBERG.DE
            ldap_sasl_authid = <HOSTNAME$  or Username>
            ldap_krb5_keytab = <path_to_your_keytab>
            krb5_server = bwservices.uni-heidelberg.de
            ldap_sasl_canonicalize = false
            krb5_canonicalize = false

            use_fully_qualified_names = true
            full_name_format = %3$s\%1$s

            re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(?P<name>.+$))
            enumerate = false

Attention: Don't forget to change "ldap_sasl_authid" to the Hostname/Username corresponding to your keytab file and the path to your keytab (e.g. /etc/krb5.keytab)!

If you are allready using another service for authentication or name resolution on the machine, an additional domain block can be set up for this and has to be added to the line "domains".

To enable SSSD for ID-Mapping in your system the lines "passwd" and "group" in file "/etc/nsswitch.conf" have to be extended by "sss", e.g.:

$ cat /etc/nsswitch.conf
        [...]
        passwd: compat sss
        group: compat sss

Note: If you are using sssd you should not use "nscd" in parallel! Otherwise this could lead to undefined behaviour due to double caching passwd and group entries.

After configuring SSSD you should enable and restart the service, e.g.:

$ systemctl enable sssd.service 
$ systemctl restart sssd.service