Unable to log into a Debian Jessie system using an UCS domain username

sleroux · April 7, 2017, 8:52am

I try to install a genuine Debian Jessie system into an UCS domain.

I (think I) followed strictly the instructions found there:
https://docs.software-univention.de/domain-4.2.html#ext-dom-unix

But I’m still unable to log in the Debian Jessie client using an UCS domain username/password.

At this point:

The UCS managed user “sylvain” appears in the result of “getent passwd”

root@ucs-debian-client-01:/home/user# getent passwd | grep sylvain
sylvain:x:2008:5001:Sylvain Leroux:/home/sylvain:/bin/bash

I can change the Kerberos password:

root@ucs-debian-client-01:/home/user# kpasswd sylvain
sylvain@ITSFOSS.INTRANET's Password:
New password for sylvain@ITSFOSS.INTRANET: 
Verify password - New password for sylvain@ITSFOSS.INTRANET: 
Success : Password changed

In addition, I created the home directory for the user with the right permissions:

total 8
4 drwxr-xr-x  2 2008 5001 4096 Apr  7 10:07 sylvain
4 drwxr-xr-x 15 user user 4096 Mar 28 17:34 user

lib-pam heimdal is installed.

BUT I’m still unable to log in my system using the “sylvain” user.
I don’t know if this is related, but you can see above my system does not seem to map uid 2008 / gid 5001 to the proper names.

This is confirmed by getpwname being unable to locate the domain user:

root@ucs-debian-client-01:/home/user# getent passwd sylvain
root@ucs-debian-client-01:/home/user#  <-- nothing

Here is an archive of the config files I’ve modified on the client:
http://chicoree.fr/pub/univention/ucs42-debian-config.tar.gz

Any help or pointer to what I’ve done wrong or missed would be greatly appreciated!

coopra9 · April 11, 2017, 7:07pm

Hello,

to be honest, my last Debian integration was: following the guide for Ubuntu and copying that one missing package (auth-client-config) from the Ubuntu repos, then installing it via “dpkg -i”. I guess that’s a dirty hack, but it works flawlessly so far

birkefeld · April 18, 2017, 12:06pm

Hi Sylvain,

sleroux:

The UCS managed user “sylvain” appears in the result of “getent passwd”
   root@ucs-debian-client-01:/home/user# getent passwd | grep sylvain
   sylvain:x:2008:5001:Sylvain Leroux:/home/sylvain:/bin/bash

It’s look like, that this is a local user and not the domain user.
Do you set up an additional user (next to root) during the Debian installation?

Your information is not really clear. One time you get a user with “getent” and than not.

sleroux:

At this point:

The UCS managed user “sylvain” appears in the result of “getent passwd”
root@ucs-debian-client-01:/home/user# getent passwd | grep sylvain
sylvain:x:2008:5001:Sylvain Leroux:/home/sylvain:/bin/bash
…

This is confirmed by getpwname being unable to locate the domain user:
root@ucs-debian-client-01:/home/user# getent passwd sylvain
root@ucs-debian-client-01:/home/user#  &lt;-- nothing

Maybe your nsswitch is not set up right. Please check this

sudo nss_updatedb ldap
ls -l /var/lib/misc/*.db

also your “/etc/nsswitch.conf” should search in ldap:

passwd:         files ldap [NOTFOUND=return] db
group:          files ldap [NOTFOUND=return] db

For more infos and hints see PamsCcredsHowto (this should work on Debian as well).

Best regards,
Tobi

birkefeld · April 18, 2017, 12:20pm

Hi Sylvain,

I just looked into your archive. I think the parts with PAM is missing at all. So there will be no mapping/lookup from PAM to ldap.
I’m not sure that this will fix it at all, but in the Ubuntu integration guide there are some additional configurations to be done (or done by the SSSD installation) in the PAM stack.

I think you have to configure some parts in /etc/pam.d/common-auth. As I’m using an Ubuntu Client, I can’t check it out for you, but my /etc/pam.d/common-auth look like this:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth    required    pam_group.so use_first_pass
auth    [success=3 default=ignore]      pam_unix.so nullok_secure try_first_pass
auth    [success=2 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so 
# end of pam-auth-update config

The line auth [success=1 default=ignore] pam_sss.so use_first_pass is responsible for the lookup in SSSD (and ldap as well).
Maybe libpam-ccreds will work for you.

sleroux · April 18, 2017, 2:00pm

Hi Tobi,

Thank you for your reply. Few comments in line:

No, it isn’t (i.e.: “sylvain” is not in /etc/passwd)

That was part of the puzzle. Depending the parameters given, “getent” do not issue the same system call. And in some case, I get back the domain user. In the other one, I didn’t.

According to “man getent”:

Apparently, with my current settings, “{set,get,end}pwent” and “getpwnam” do not provide consistent results.

For your other remarks, I’ll check that in few minutes when I will have access to my test environment.

sleroux · April 18, 2017, 2:29pm

I’ve installed the nss-updatedb package and run those commands:

The domain users are successfully retrieved and I can see the entry for the user “sylvain” in the /var/lib/misc/passwd.db file.

But “getent passwd sylvain” still do not successfully retrieve the user data.

I didn’t installed before libpam-sss. It is now done. And my /etc/pam.d/common-auth was updated to something similar to yours as part of the process (with the exception of pam_winbind and krb5_ccache_type which are absent in mine)

Still no change.

sleroux · April 18, 2017, 2:34pm

I’ve made some progress.

Indeed there was an issue with my /etc/nsswitch.conf file. The {passwd,group} entries were missing the db option

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat ldap [NOTFOUND=return] db
group:          compat ldap [NOTFOUND=return] db
shadow:         compat ldap [NOTFOUND=return] db

gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

Now, “getent passwd sylvain” returns something:

sh# getent passwd sylvain
sylvain:x:2008:5001:Sylvain Leroux:/home/sylvain:/bin/bash

Unfortunately, I’m still unable to log in–but this time the error message is different:

sh$ su sylvain
Password: 
su: Authentication service cannot retrieve authentication info

ollikaa · May 4, 2017, 9:15am

Hi sieroux,
based on the provided information for joining ubuntu-clients into an UCS domain, i could successfully join my Debian testsystem into such a domain.

Here is how i did it.

I installed a clean UCS 4.2 server without selecting any components.
UCS Domain Name: example.com
IP: 192.168.22.100

The client system (Debian 8.7.1) was also installed without any additional Software. DNS was set to the IP of the UCS server and domain set equal to the UCS Domain Name.

Login as root to the client system and execute the following script:

#!/bin/bash

# Install required packages
apt-get install -y sudo lsb-release krb5-user sssd-ldap

# Set IP of the domain controller
export MASTER_IP=192.168.22.100

mkdir /etc/univention
ssh -n root@${MASTER_IP} 'ucr shell | grep -v ^hostname=' >/etc/univention/ucr_master
echo "master_ip=${MASTER_IP}" >>/etc/univention/ucr_master
chmod 660 /etc/univention/ucr_master
. /etc/univention/ucr_master

echo "${MASTER_IP} ${ldap_master}" >>/etc/hosts

# Download the SSL certificate
mkdir -p /etc/univention/ssl/ucsCA/
wget -O /etc/univention/ssl/ucsCA/CAcert.pem http://${ldap_master}/ucs-root-ca.crt

# Create an account and save the password
password="$(tr -dc A-Za-z0-9_ </dev/urandom | head -c20)"

ssh -n root@${ldap_master} udm computers/linux create --position "cn=computers,${ldap_base}" --set name=$(hostname) --set password="${password}" --set operatingSystem="$(lsb_release -is)" --set operatingSystemVersion="$(lsb_release -rs)"

printf '%s' "$password" >/etc/ldap.secret
chmod 0400 /etc/ldap.secret

# Create ldap.conf
cat >/etc/ldap/ldap.conf <<__EOF__
TLS_CACERT /etc/univention/ssl/ucsCA/CAcert.pem
URI ldap://$ldap_master:7389
BASE $ldap_base
__EOF__

# Create sssd.conf
cat >/etc/sssd/sssd.conf <<___EOF___
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, sudo
domains = $kerberos_realm

[nss]
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/$kerberos_realm]
auth_provider = krb5
krb5_kdcip = ${master_ip}
krb5_realm = ${kerberos_realm}
krb5_server = ${ldap_master}
krb5_kpasswd = ${ldap_master}
id_provider = ldap
ldap_uri = ldap://${ldap_master}:7389
ldap_search_base = ${ldap_base}
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ldap/cacerts/CAcert.pem
cache_credentials = true
enumerate = true
ldap_default_bind_dn = cn=$(hostname),cn=computers,${ldap_base}
ldap_default_authtok_type = password
ldap_default_authtok = $(cat /etc/ldap.secret)
___EOF___

chmod 600 /etc/sssd/sssd.conf

/etc/init.d/sssd start

The script asks you twice for the password of the Domain-Administrator eg. root

Now check if everything works (replace UCS.EXAMPLE.COM with the FQDN of your DC):

root@test:~# ktutil
ktutil:  add_entry -password -p Administrator@UCS.EXAMPLE.COM -k 1 -e aes128-cts-hmac-sha1-96
Password for Administrator@UCS.EXAMPLE.COM: 
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    1            Administrator@UCS.EXAMPLE.COM
ktutil:  q
root@test:~# su Administrator
Administrator@test:/root$ exit
exit
root@test:~# getent passwd Administrator
Administrator:*:2002:5000:Administrator:/home/Administrator:/bin/bash

Create any Account in your UCS-Webinterface and try to login via SSH.

There was no need for any other configuration of nsswitch.conf or PAM.

Have fun

sleroux · May 6, 2017, 8:54am

Thank you @ollikaa for your answer.

As a matter of fact, I finally fixed my Debian test system, but as I tried many different things, I wasn’t sure exactly what was my main issue

What I can say is it was apparently related to sssd I didn’t install initially. My test system being a minimal Debian install, it was pretty possible some required packages were missing.

All that being said, after a quick check, the solution you mentioned seems to work on a stock Debian system.

Interesting enough, when comparing your script with the one provided on https://docs.software-univention.de/domain-4.1.html#ext-dom-ubuntu, I noticed you skip the part related to auth-client (which is available on Ubuntu, but not on genuine Debian). Was that on purpose?

ollikaa · May 7, 2017, 7:23pm

Hi sieroux,
with the package auth-client-config you can store multiple authentication profiles. More detailed informations are explained here. As far as i understand it, this is useful for logins to different domains on the same computer. Correct me if i am wrong.

So far it is not mandatory if you have only one domain.

You can try to adapt the steps 1.3 (Configuring user logins) and 1.4 (Kerberos integration).
I haven’t tried that with Debian, only with CentOS. Let me know if it works.