Difference between revisions of "SSSD"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Starting with CentOS6, remote account login authentication is performed using SSSD. Configuring SSSD to authenticate to an LDAP server can be tricky, but the following instructions work perfectly.
 
Starting with CentOS6, remote account login authentication is performed using SSSD. Configuring SSSD to authenticate to an LDAP server can be tricky, but the following instructions work perfectly.
 +
  
 
== Configuring SSSD ==
 
== Configuring SSSD ==
 +
# Install: <code>yum install -y sssd  openldap-clients sssd-ldap nss-pam-ldapd libsss_sudo </code>
 +
# Copy Gourd ldap dir in /etc: <code>rsync -ravH gourd:/etc/openldap . </code>
 +
## Check/edit the ldap.conf if needed.
 +
## Copy gourd sssd.conf in /etc/sssd:  <code>scp gourd:/etc/sssd/sssd.conf . </code>
  
1. Make sure the proper packages are installed
+
=== Configuring SSSD - Details ===
  yum install sssd libsss_sudo
 
  
 +
;1.  Setting up a failover [https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/chap-SSSD_User_Guide-Setting_Up_SSSD.html Fedora sssd ]
 +
8.2.3.2.4. Configuring Failover
 +
The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers.
 +
For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values:
 +
ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org
 +
In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that server is unavailable, it then attempts to connect to ldap2.mydomain.org.
 +
If the parameter that specifies which server to connect to for the specific domain (for example, ldap_uri, krb5_server, …) is not specified, the back end defaults to using Use service discovery. Refer to Section 8.2.3.2.4.1, “Using SRV Records with Failover” for more information on service discovery.
  
2. Use authconfig to enable the proper settings to allow authentication via SSSD
+
;2. Use authconfig to enable the proper settings to allow authentication via SSSD
  authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
+
; See: [https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/ch-Authentication_Configuration.html Authconfig]
 +
At the bottom is a list of command line features.
  
 +
  authconfig --enablesssd --enablesssdauth --enableldap --enableldapauth --enablemkhomedir \
 +
  --ldapserver=ldap://einstein --ldapbasedn=dc=physics,dc=unh,dc=edu --enablelocauthorize --enableldaptls --update
  
3. Modify /etc/sssd/sssd.conf to reflect the following settings:
+
;3. Exsmple /etc/sssd/sssd.conf:
  
  [sssd]
+
  [nss]
  config_file_version = 2
+
  # The following prevents SSSD from searching for the root user/group in
  services = nss, pam
+
  # all domains (you can add here a comma-separated list of system accounts that
  domains = default
+
  # are always going to be /etc/passwd users, or that you want to filter out).
 +
  filter_groups = root
 +
  #filter_users = root
 +
  filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
 +
  reconnection_retries = 3
  
  [nss]
+
  [pam]
  filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
+
  reconnection_retries = 3
  
  [domain/default]
+
  [domain/LDAP]
  ldap_tls_reqcert = never
+
  id_provider = ldap
  auth_provider = ldap
+
  ldap_schema = rfc2307
  ldap_schema = rfc2307bis
+
  autofs_provider = ldap
  krb5_realm = EXAMPLE.COM
+
  ldap_autofs_search_base = cn=automount,dc=physics,dc=unh,dc=edu
  ldap_search_base = dc=physics,dc=unh,dc=edu
 
  id_provider = ldap
 
  ldap_id_use_start_tls = False
 
  chpass_provider = ldap
 
  ldap_uri = ldaps://einstein.unh.edu
 
  krb5_kdcip = kerberos.example.com
 
  cache_credentials = True
 
  ldap_tls_cacertdir = /etc/openldap/cacerts
 
  entry_cache_timeout = 600
 
  ldap_network_timeout = 3
 
  ldap_access_filter = (&(objectclass=shadowaccount)(objectclass=posixaccount))
 
  
  
4. Modify /etc/openldap/ldap.conf to point to the LDAP server:
+
  [domain/default]
 +
  enumerate = True
 +
  ldap_tls_reqcert = never
 +
  auth_provider = ldap
 +
  krb5_realm = physics.unh.edu
 +
  ldap_search_base = dc=physics,dc=unh,dc=edu
 +
  id_provider = ldap
 +
  ldap_id_use_start_tls = False
 +
  chpass_provider = ldap
 +
  ldap_uri = ldaps://einstein, ldaps://pepper
 +
  chpass_provider = ldap
 +
  krb5_kdcip = einstein.farm.physics.unh.edu
 +
  cache_credentials = True
 +
  ldap_tls_cacertdir = /etc/openldap/cacerts
 +
  entry_cache_timeout = 600
 +
  ldap_network_timeout = 3
 +
  ldap_rfc2307_fallback_to_local_users = True
 +
  sudo_provider = ldap
 +
  ldap_sudo_search_base = ou=groups,dc=physics,dc=unh,dc=edu
 +
  ldap_sudo_full_refresh_interval = 86400
 +
  ldap_sudo_smart_refresh_interval = 3600
 +
  autofs_provider = ldap
 +
 
 +
;4. Example /etc/openldap/ldap.conf to point to the LDAP server:
  
 
   URI ldaps://einstein.unh.edu
 
   URI ldaps://einstein.unh.edu
Line 47: Line 77:
 
Note: If you are not able to get back proper information with the 'id' command try removing the ca certs from the /etc/openldap/cacerts/ directory and restarting the sssd service.  Always back that directory up before removing the contents of it.
 
Note: If you are not able to get back proper information with the 'id' command try removing the ca certs from the /etc/openldap/cacerts/ directory and restarting the sssd service.  Always back that directory up before removing the contents of it.
  
5. Modify /etc/nsswitch.conf to reflect the following settings:
+
;5. Modify /etc/nsswitch.conf to reflect the following settings:
  
 
   passwd    files sss
 
   passwd    files sss
Line 55: Line 85:
  
  
6. Restart the sssd service to enable changes:
+
;6. Restart the sssd service to enable changes:
  
 
   service sssd restart
 
   service sssd restart
  
  
7. To test the configuration, try requesting user information:  
+
;7. To test the configuration, try requesting user information:  
  
 
   id <username>
 
   id <username>
 +
  getent passwd
 +
  Try to log in, try auto mount.
 +
 +
== Trouble Shooting ==
 +
 +
You can try if LDAP is talking with you using the ldapsearch command. A very basic test is:
 +
 +
ldapsearch -x -d8 -H ldap://einstein.farm.physics.unh.edu  -b dc=physics,dc=unh,dc=edu '(uid=maurik)'
 +
 +
Then you can check if TLS is working by adding an s:
 +
 +
  ldapsearch -x -d8 -H ldaps://einstein.farm.physics.unh.edu  -b dc=physics,dc=unh,dc=edu '(uid=maurik)'
 +
 +
If you get the error:
 +
 +
TLS: certificate [CN=einstein.unh.edu,OU=Nuclear Physics Group,O=University of New Hampshire,L=Durham,ST=New Hampshire,C=US] is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure..
 +
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
 +
TLS: can't connect: TLS error -8157:Certificate extension not found..
 +
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 +
 +
Then you need to check your certificates. It may be the disabled MD5 kind, see: http://blogs.dlt.com/rhel-64-ga-potential-authentication-issues
 +
There they suggest setting NSS_HASH_ALG_SUPPORT=+MD5. This did indeed work on the Centos7 install on Gourd, for command line ldapsearch. It does NOT solve the issue for sssd, so "getent" and "id" do not work.
 +
 +
The work-around, for now, is to connect with "ldap" instead of "ldaps" and not use the TLS at all.
  
 
== Notes ==
 
== Notes ==
The command 'getent passwd' will not work by default, as SSSD disables user enumeration. Instead, if you specify the user you are looking for, i.e. 'getent passwd <USERNAME>', SSSD will give you the proper information as usual. You can always use the 'id' command for this purpose as well.
+
The command 'getent passwd' will not work by default, as SSSD disables user enumeration. Instead, if you specify the user you are looking for, i.e. 'getent passwd <USERNAME>', SSSD will give you the proper information as usual. You can always use the 'id' command for this purpose as well. It does work if you have "enumerate = True" in the sssd.conf
  
 
== External Information ==
 
== External Information ==
 
* https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
 
* https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
 
* http://www.couyon.net/1/post/2012/04/enabling-ldap-usergroup-support-and-authentication-in-centos-6.html
 
* http://www.couyon.net/1/post/2012/04/enabling-ldap-usergroup-support-and-authentication-in-centos-6.html

Latest revision as of 14:35, 8 August 2017

Starting with CentOS6, remote account login authentication is performed using SSSD. Configuring SSSD to authenticate to an LDAP server can be tricky, but the following instructions work perfectly.


Configuring SSSD

  1. Install: yum install -y sssd openldap-clients sssd-ldap nss-pam-ldapd libsss_sudo
  2. Copy Gourd ldap dir in /etc: rsync -ravH gourd:/etc/openldap .
    1. Check/edit the ldap.conf if needed.
    2. Copy gourd sssd.conf in /etc/sssd: scp gourd:/etc/sssd/sssd.conf .

Configuring SSSD - Details

1. Setting up a failover Fedora sssd

8.2.3.2.4. Configuring Failover The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers. For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values: ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that server is unavailable, it then attempts to connect to ldap2.mydomain.org. If the parameter that specifies which server to connect to for the specific domain (for example, ldap_uri, krb5_server, …) is not specified, the back end defaults to using Use service discovery. Refer to Section 8.2.3.2.4.1, “Using SRV Records with Failover” for more information on service discovery.

2. Use authconfig to enable the proper settings to allow authentication via SSSD
See
Authconfig

At the bottom is a list of command line features.

  authconfig --enablesssd --enablesssdauth --enableldap --enableldapauth --enablemkhomedir \
 --ldapserver=ldap://einstein --ldapbasedn=dc=physics,dc=unh,dc=edu --enablelocauthorize --enableldaptls --update
3. Exsmple /etc/sssd/sssd.conf
 [nss]
 # The following prevents SSSD from searching for the root user/group in
 # all domains (you can add here a comma-separated list of system accounts that
 # are always going to be /etc/passwd users, or that you want to filter out).
 filter_groups = root
 #filter_users = root
 filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
 reconnection_retries = 3
 [pam]
 reconnection_retries = 3
 [domain/LDAP]
 id_provider = ldap
 ldap_schema = rfc2307
 autofs_provider = ldap
 ldap_autofs_search_base = cn=automount,dc=physics,dc=unh,dc=edu


 [domain/default]
 enumerate = True
 ldap_tls_reqcert = never
 auth_provider = ldap
 krb5_realm = physics.unh.edu
 ldap_search_base = dc=physics,dc=unh,dc=edu
 id_provider = ldap
 ldap_id_use_start_tls = False
 chpass_provider = ldap
 ldap_uri = ldaps://einstein, ldaps://pepper
 chpass_provider = ldap
 krb5_kdcip = einstein.farm.physics.unh.edu
 cache_credentials = True
 ldap_tls_cacertdir = /etc/openldap/cacerts
 entry_cache_timeout = 600
 ldap_network_timeout = 3
 ldap_rfc2307_fallback_to_local_users = True
 sudo_provider = ldap
 ldap_sudo_search_base = ou=groups,dc=physics,dc=unh,dc=edu
 ldap_sudo_full_refresh_interval = 86400
 ldap_sudo_smart_refresh_interval = 3600
 autofs_provider = ldap
4. Example /etc/openldap/ldap.conf to point to the LDAP server
  URI ldaps://einstein.unh.edu
  BASE dc=physics,dc=unh,dc=edu
  TLS_CACERTDIR /etc/openldap/cacerts

Note: If you are not able to get back proper information with the 'id' command try removing the ca certs from the /etc/openldap/cacerts/ directory and restarting the sssd service. Always back that directory up before removing the contents of it.

5. Modify /etc/nsswitch.conf to reflect the following settings
  passwd     files sss
  shadow     files sss
  group      files sss
  sudoers    files sss


6. Restart the sssd service to enable changes
  service sssd restart


7. To test the configuration, try requesting user information
  id <username>
  getent passwd 
  Try to log in, try auto mount.

Trouble Shooting

You can try if LDAP is talking with you using the ldapsearch command. A very basic test is:

ldapsearch -x -d8 -H ldap://einstein.farm.physics.unh.edu  -b dc=physics,dc=unh,dc=edu '(uid=maurik)'

Then you can check if TLS is working by adding an s:

 ldapsearch -x -d8 -H ldaps://einstein.farm.physics.unh.edu  -b dc=physics,dc=unh,dc=edu '(uid=maurik)' 

If you get the error:

TLS: certificate [CN=einstein.unh.edu,OU=Nuclear Physics Group,O=University of New Hampshire,L=Durham,ST=New Hampshire,C=US] is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure..
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
TLS: can't connect: TLS error -8157:Certificate extension not found..
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Then you need to check your certificates. It may be the disabled MD5 kind, see: http://blogs.dlt.com/rhel-64-ga-potential-authentication-issues There they suggest setting NSS_HASH_ALG_SUPPORT=+MD5. This did indeed work on the Centos7 install on Gourd, for command line ldapsearch. It does NOT solve the issue for sssd, so "getent" and "id" do not work.

The work-around, for now, is to connect with "ldap" instead of "ldaps" and not use the TLS at all.

Notes

The command 'getent passwd' will not work by default, as SSSD disables user enumeration. Instead, if you specify the user you are looking for, i.e. 'getent passwd <USERNAME>', SSSD will give you the proper information as usual. You can always use the 'id' command for this purpose as well. It does work if you have "enumerate = True" in the sssd.conf

External Information