Log in with domain credentials

NethServer Version: V7RC4
Module: Samba4 AD Accountprovider

With the Samba4 AD account provider, we can create domain users. Maybe in most cases, Windows clients are used and adding those machines to the domain is quite easy. The Samba4 wiki explains this quite well. After adding a windows machine to the domain, logging in with with a domain user account is simple.

But now the Linux client part. I did find a nice article about adding a Linux machine to the domain, but I still can not log in with a domain useraccount on my Ubuntu laptop.

I tried to login as INTERLIN\rob wich results in these lines in /var/log/auth.log:

Jan 22 13:57:54 E540 lightdm: pam_succeed_if(lightdm:auth): requirement “user ingroup nopasswdlogin” not met by user "INTERLIN\rob"
Jan 22 13:57:56 E540 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=INTERLIN\rob
Jan 22 13:57:56 E540 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=INTERLIN\rob
Jan 22 13:57:56 E540 lightdm: pam_sss(lightdm:auth): received for user INTERLIN\rob: 6 (Permission denied)

And as rob@interlin.lan, which led to these lines in /var/log/auth.log:

Jan 22 13:58:03 E540 lightdm: pam_succeed_if(lightdm:auth): requirement “user ingroup nopasswdlogin” not met by user "rob@interlin.lan"
Jan 22 13:58:08 E540 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=rob@interlin.lan
Jan 22 13:58:08 E540 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=rob@interlin.lan
Jan 22 13:58:08 E540 lightdm: pam_sss(lightdm:auth): received for user rob@interlin.lan: 6 (Permission denied)

I also see this come by quite often:

Jan 22 13:57:58 E540 lightdm: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
Jan 22 13:57:58 E540 lightdm: PAM adding faulty module: pam_kwallet.so

Any help with troubleshooting is appreciated… :wink:
Goal is to create a howto for Linux clients to add them to the NethServer Samba4 domain and be able to log in with a domain user account.


@ctek suggested that maybe the order of the PAM modules is not the correct one ? Just an ideea to check if any of the pam_sss module should be more to the top of the list than others (like pam_kwallet)
or put sufficent instead of required for pam_kwallet
or for the lightdm

When I look at my /etc/pam.d/lightdm it says:

cat lightdm
auth requisite pam_nologin.so
auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
auth optional pam_gnome_keyring.so
auth optional pam_kwallet.so
auth optional pam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
#session required pam_loginuid.so
session required pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_gnome_keyring.so auto_start
session optional pam_kwallet.so auto_start
session optional pam_kwallet5.so auto_start
session required pam_env.so readenv=1
session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-password

And common-auth is like this:

auth [success=2 default=ignore] pam_unix.so nullok_secure
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

Any thoughts?

I suggest we keep this open untill we find a proper way to document all the needed steps.
It’s clear that only the information contained in that how-to it will not guarantee success.

For the moment will be [W.I.P.]


1 Like

Thank you!

@Ctek @robb

Just like a Wiki or HowTo I need and many more as well.

Let’s try to get all the necessary things straight. This is [WIP] so add whatever you think needs to be added:

We need to check if the Domain Controller is accessible from the client.
>dig -t SRV _ldap._tcp.subdomain.domain.tld
If you don’t have a subdomain configured, you should leave out the subdomain part. The response you should get is something like this:
> beheer@E540:~$ dig -t SRV _ldap._tcp.interlin.lan

> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t SRV _ldap._tcp.interlin.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26802
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
>  ;_ldap._tcp.interlin.lan.	IN	SRV
> _ldap._tcp.interlin.lan. 900	IN	SRV	0 100 389 nsdc-hs001.interlin.lan.
> interlin.lan.		3600	IN	SOA	nsdc-hs001.interlin.lan. hostmaster.interlin.lan. 1 900 600 86400 3600
> ;; Query time: 15 msec
> ;; SERVER:
> ;; WHEN: Tue Jan 24 09:14:13 CET 2017
> ;; MSG SIZE  rcvd: 119

In the Answer section you will find the Domain Controller(s) of your domain. For NethServer this is the NSDC container for Samba4 AD.

Check if you can reach the Domain Controller from your client: ping YourDC.subdomain.domain.tld
In my case: ping nsdc-hs001.interlin,lan

Install packages on client
sudo apt-get -y install realmd sssd sssd-tools samba-common krb5-user packagekit samba-common-bin samba-libs adcli ntp

You will be prompted to give the kerberos realm. Note kerberos realms are ALWAYS in CAPITALS

I created DHCP reservation for my client in NethServer DHCP and added the client to the local hosts file too. In my case the FQDN of NethServer is hs001.interlin.lan
The NSDC container FQDN is generated during install of Samba4 AD module and based on the NS7 FQDN. Both NS7 and the NSDC container have fixed IP addresses
Added entries in /etc/hosts:   E540.interlin.lan    hs001.interlin.lan    nsdc-hs001.interlin.lan

Timestamps are very important for Kerberos tickets. So you must sync your client with the NSDC ntp server. On the client I commented out external ntp servers and added the NSDC ntp server.
Add the entry:
server nsdc-hs001.interlin.lan

Note: adapt os-name and os-version to your situation.

default-home = /home/%D/%U
default-shell = /bin/bash
default-client = sssd
os-name = Ubuntu Desktop Linux
os-version = 16.04
automatic-install = no
fully-qualified-names = no
automatic-id-mapping = yes
user-principal = yes
manage-system = no

Join the client to the AD domain

sudo kinit administrator@SUBDOMAIN.DOMAIN.TLD
(ommit SUBDOMAIN if you don’t have that configured)
The user you use must be a member of domain admins. The administrator account must be given een password to activate it in NethServer.

With @Ctek I discussed what should go here. There might be some settings overdone. Needs testing what can be left out. Note: kerberos realm must be in UPPERCASE:

        default_realm = INTERLIN.LAN

        kdc = NSDC-HS001.INTERLIN.LAN
        master_kdc = NSDC-HS001.INTERLIN.LAN
        admin_server = NSDC-HS001.INTERLIN.LAN

        .interlin.lan = INTERLIN.LAN
        interlin.lan = INTERLIN.LAN

I have the following lines in sssd.conf. Unsure what the last line (for my domain username) is doing.

domains = interlin.lan
config_file_version = 2
services = nss, pam

ad_domain = interlin.lan
krb5_realm = INTERLIN.LAN
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
simple_allow_users = rob

AS far as I know this is quite default. the modules to load are:
session required pam_unix.so
session optional pam_sss.so
session optional pam_systemd.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
# end of pam-auth-update config

/etc/lightdm/lightdm.conf (on an Ubuntu client with Unity Desktop Manager, settings for Gnome/KDE/Cinnamon etc???)
For Ubuntu 16.04 the lightdm.conf is located on a different location. You have to look for: /usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf. manual login is active since you want to be able to log in with a domain account. First login you will need to use account@domain.tld as username to log in.


Check for errors in:

  • /var/log/auth.log
  • /var/log/syslog
  • /var/log/sssd/*
1 Like

Great work Rob!.
We are going in the right direction now :slight_smile:

The content of the config files should be added here for refference
Also on the client the NS machine should be added as nameserver and also in the hosts file as host entry with FQDN.

I think the step of adding the NS to host file can be skipped if the DNS is configured in NS to have a entry for itself.

1 Like

Then you should have 2 entries in DNS for itself:
The NethServer7 server and the NSDC container.

1 Like

But the ldap and kerberos entries should already be there when you install / configure the AD module in NS…

1 Like

Are we talking Samba4 DNS or the DNS module of NethServer7?

Should provide all the info required. because Samba4DNS should be inside the container (if i’m not mistaking)

1 Like

Yup, Samba4DNS is in the container as part of the Samba4 package.
But if it is NS7 DNS, then you will have to add the NSDC entry too. It is not added by the install procedure.

1 Like

This was my point also

1 Like

@robb I didn’t understand if you got it working or not :slight_smile:

Hi Alessio, It worked.
Now to document the steps

Hi @alefattorini
yes I log in with my domain account. And the account info is cached on the local install because I can log in even when network isn’t up yet (wlan only activates after logging in here).

I now want those shares mounted when logging in, so I can use them automagically. (IE a private ‘home’ share and maybe some group shares)

1 Like

I installed OpenSuSE Leap 42 with KDE desktop manager in a VM and joining the Domain and logging in with a Domain account was completely painless.

After a default install, updated the install.
Open Yast2: from SuSE application menu - settings - YaST
You will be prompted for an admin password. The user must be member of the sudo group. When you install SuSE, the account that you create is created as sudo user, so type in the password to open YaST.

Click Network Services
Click Windows Domain membership

Follow the wizard and after reboot you can log in with your Domain account. Never seen it this easy!