context

I'm trying to configure LDAP authentication on an Ubuntu 18.04 machine.

steps to reproduce

In order to do that, I followed the following steps:

• apt install sssd libpam-sss libnss-sss

• create a /etc/sssd/sssd.conf with the following content

  [sssd]
  debug_level = 0x01E0
  services = nss, pam
  config_file_version = 2
  domains = default
  [nss]
  debug_level = 0x01E0
  [pam]
  debug_level = 0x01E0
  offline_credentials_expiration = 60
  [domain/default]
  debug_level = 0x01E0
  ldap_id_use_start_tls = False
  cache_credentials = True
  ldap_search_base = ou=department,o=company,c=country
  id_provider = ldap
  auth_provider = ldap
  chpass_provider = ldap
  access_provider = ldap
  ldap_uri = ldaps://ldap.company.country
  ldap_default_bind_dn = cn=***,o=company,c=country
  ldap_default_authtok = *****
  ldap_tls_reqcert = try
  ldap_search_timeout = 50
  ldap_network_timeout = 60
  ldap_access_order = filter
  ldap_access_filter = (objectClass=inetOrgPerson)

• made sure that only root has access to the config file:

  chown root:root /etc/sssd/sssd.conf
  chmod 0600 /etc/sssd/sssd.conf

• restarted the service

  sudo systemctl restart sssd

• made sure that the service is started correctly: sudo systemctl status sssd

  ● sssd.service - System Security Services Daemon
  Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
  Active: active (running) since Tue 2021-01-19 08:26:45 UTC; 1h 1min ago
  Main PID: 24043 (sssd) Tasks: 4 (limit: 2316)
  CGroup: / ├─24043 /usr/sbin/sssd -i --logger=files ├─24064 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain default --uid 0 --gid 0 --logger=files ├─24070 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files └─24071 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
  Jan 19 08:26:45 ubuntu1804.localdomain systemd[1]: Starting System Security Services Daemon...
  Jan 19 08:26:45 ubuntu1804.localdomain sssd[24043]: Starting up
  Jan 19 08:26:45 ubuntu1804.localdomain sssd[be[24064]: Starting up
  Jan 19 08:26:45 ubuntu1804.localdomain sssd[24070]: Starting up
  Jan 19 08:26:45 ubuntu1804.localdomain sssd[24071]: Starting up
  Jan 19 08:26:45 ubuntu1804.localdomain systemd[1]: Started System Security Services Daemon.

troubleshooting steps

logs

When I look at the logs, everything seem to be fine:

│(Tue Jan 19 09:28:56 2021) [sssd] [sss_names_init_from_args] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)]. │
│(Tue Jan 19 09:28:56 2021) [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. │
│(Tue Jan 19 09:28:56 2021) [sssd] [start_service] (0x0100): Queueing service default for startup │
│(Tue Jan 19 09:28:56 2021) [sssd] [client_registration] (0x0100): Received ID registration: (%BE_default,1) │
│(Tue Jan 19 09:28:56 2021) [sssd] [mark_service_as_started] (0x0100): Now starting services! │
│(Tue Jan 19 09:28:56 2021) [sssd] [start_service] (0x0100): Queueing service nss for startup │
│(Tue Jan 19 09:28:56 2021) [sssd] [start_service] (0x0100): Queueing service pam for startup │
│(Tue Jan 19 09:28:56 2021) [sssd] [client_registration] (0x0100): Received ID registration: (pam,1) │
└(Tue Jan 19 09:28:56 2021) [sssd] [client_registration] (0x0100): Received ID registration: (nss,1) │
┌(Tue Jan 19 09:28:56 2021) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [sss_names_init_from_args] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)]. │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s]. │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [8192] │
│(Tue Jan 19 09:28:56 2021) [sssd[nss]] [sss_dp_get_reply] (0x0100): Data Provider does not support this operation. │
└(Tue Jan 19 09:28:56 2021) [sssd[nss]] [id_callback] (0x0100): Got id ack and version (1) from Monitor │
┌(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap.company.country' in files │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'ldap.company.country' as 'resolving name' │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ldap.company.country' in files │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ldap.company.country' in DNS │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'ldap.company.country' as 'name resolved' │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [simple_bind_send] (0x0100): Executing simple bind as: cn=***,o=company,c=country │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 636 of server 'ldap.company.country' as 'working' │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'ldap.company.country' as 'working' │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [be_ptask_enable] (0x0080): Task [SUDO Smart Refresh]: already enabled │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [sdap_sudo_load_sudoers_done] (0x0040): Received 0 sudo rules │
│(Tue Jan 19 09:29:06 2021) [sssd[be[default]]] [be_ptask_enable] (0x0080): Task [SUDO Full Refresh]: already enabled

When I try to login with a local account (vagrant), the authentication is OK:

│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): domain: not set │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): user: vagrant │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): service: sshd │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): rhost: 10.0.2.2 │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 24354 │
│(Tue Jan 19 09:39:52 2021) [sssd[pam]] [pam_print_data] (0x0100): logon name: vagrant │
└(Tue Jan 19 09:39:52 2021) [sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal. │
┌(Tue Jan 19 09:39:52 2021) [sssd[be[default]]] [sysdb_get_real_name] (0x0040): Cannot find user [vagrant@default] in cache │
│(Tue Jan 19 09:39:52 2021) [sssd[be[default]]] [sysdb_get_real_name] (0x0040): Cannot find user [vagrant@default] in cache

so far, so good...

Now, when I try to login with an ldap user, I get a permission denied error:

(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): domain: not set │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): user: jaep │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): service: sshd │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): rhost: 10.0.2.2 │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 24480 │
│(Tue Jan 19 09:42:27 2021) [sssd[pam]] [pam_print_data] (0x0100): logon name: jaep │
└(Tue Jan 19 09:42:27 2021) [sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal. │
┌(Tue Jan 19 09:42:27 2021) [sssd[be[default]]] [sysdb_get_real_name] (0x0040): Cannot find user [jaep@default] in cache

getent

I found the following question: Enabling OpenLdap authentication in ubuntu 18.04

it suggests to use the getent passwd to list accounts on the machine. In my case, the vagrant user appears:

vagrant:x:1000:1000:vagrant,,,:/home/vagrant:/bin/bash

while my ldap user does not show up.

it looks like the system is not even trying to authenticate me against the LDAP directory.

What am I missing? How can I get to authenticate against LDAP?

1 Answer

I tried this however I found that until I added the two vars into the sssd.conf sssd wasn't able to connect:

--sssd.conf--
[domain/stuff]
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/my_root_ca.crt