Problems with PAM, SSSD, AD provider - authentication against Active Directory

Hello,

I am calling on you openSuse PAM/SSSD/WINBIND gurus as I have a problem that I cannot seem to figure out on my own.

I have not been able to find the openSuse Leap 42.1 cookbook that will allow me to authenticate a ssh session ( or a simple login) to our openSuse leap 42.1 server, which we will call phoenix2.domain.local for the purpose of this post without having to create any local users on the opensuse server. Instead, I would like to

  • login with the Windows user IDs defined in our AD
  • have the openSuse server authenticate against AD
  • create the user’s homedir on the openSuse server whenever the homedir does not already exist.

Here are a few elements needed to understand our config

  • openSuse 42.1 server => phoenix2.domain.local
  • DOMAIN => domain.local
  • AD servers => mtlsrvdc01.domain.local, mtlsrvdc02.domain.local
  • The phoenix2 server is setup with Samba to allow Windows users to connect to it for file sharing purposes only. That is working fine (and we like to preserve this working setup).
  • phoenix2 is joined to the domain.local domain
  • kerberos is configured, (although I do not know how it was configured or how to check that it is functional)

Essentially, here is the problem: We need to be able to ssh (or login) to our openSuse 42.1 server and authenticate against Active Directory, using SSSD (with WINBIND and the AD provider in SSSD). If necessary, the process should also create the user’s home directory (pam_mkhomedir)

Two weeks ago, this worked but in trying to mount the user’s Windows home dir (which I now understand may not be possible), I messed up the working configuration and have not been able to bring it back to a working state since then.

I have read so many man pages, Internet forum posts and configuration manuals but I have not been able to find the recipe book that will get my setup working again.

I apologize for being a newbie in what is the PAM/SSSD/WINBIND/AD configuration but I would greatly appreciate help from any knowledgeable openSuse guru.

At this point in time, when I attempt to “ssh DOMAIN\username@phoenix2.domain.local”, I am prompted three times for a password and end up with an error message which says “Permission denied (publickey,keyboard-interactive)”. I can obviously provide you with many log file excerpts; I just do not know which ones to include at this point.

Your help would be greatly appreciated.

Daniel

For starters,
You will need to describe whether this is your first attempt at setting this up or if you’ve had this working for any other machines.
And, you need to describe which version of AD you’re running.

But before you even take one more step down this path, you should evaluate whether you want to deploy this setup at all. Be aware that Microsoft announced years ago its intention to deprecate Identity Services related to non-Windows machines like Linux, and it appears that the just released Windows Server 2016 has done just that… It’s not supported and not installable any more. So, regardless whether you can set up on your own existing AD or not, be aware that if you intend to upgrade your Windows AD to Windows 2016 Server or later, your current approach will have to be trashed.

Here is the Microsoft Technet article describing this change, and recommendations for alternative approaches including joining your openSUSE directly to the AD which has been possible for a very long time.
https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/

TSU

To be clear, the role to manage the NIS attributes using the MMC is being discontinued, the schema will remain for other applications and clients that can use it. Including the SSSD.

Moreover, when the ID mapping capabilities of the daemon are utilised even the presence of the attributes in Active Directory become even more irrelevant. Administrators and organisations still need to consider their use cases and design well from the start, but that is true of any authentication infrastructure. The SSSD and Active Directory use case will certainly increase as it’s development curve will likely follow Active Directory’s tightly.

– lawrence

For the forum, I am currently working with Daniel to ferret out the issues experienced. So far we have determined that NTP and DNS issues were present and interfered with the deployment prerequisites for the SSSD Active Directory providers. Specifically joining the referenced system to the target domain.

When the issue is resolved, I’ll post the results and solution here.

– lawrence

Hi ddansereau, I have some doubts with the post You have put originally.

  1. Have you configured your SSH server (phoenix2) to use DNS so that it can reach AD servers (mtlsrvdc1 or mtlsrvdc2) by name? If so please can u post ping result by typing
 ping mtlsrvdc1  
  1. U told phoenix2 is joined to the domain.local. If so can u login with AD account into phoenix2? If so can u check ssh in the same machine (phoenix2) by typing
ssh phoenix2

I can try supporting online if you are OK. Please install TeamViewer and ping me to shrivathsaacharya in skype…

For the forum,

After working with Daniel through his issues with the Leap system and SSSD I can offer the following summary (hoping to help others, obviously):

The fact that the SSSD software stack had already been installed and a configuration attempt(s) already made the logical path to resolution here was:

  • Agreement on the desired use case and result
  • Discover the current system configuration and make corrections where necessary
  • Rejoin the system to the target domain
  • Configure the SSSD
  • Reconfigure Samba

The system was previously joined to the target domain and using “winbindd” for authentication. This, and the PAM stack configuration in general, was verified using “pam-config”.

~# pam-config --query --ldap
~# pam-config --query --krb5
~# pam-config --query --winbind
~# pam-config --query --sss
~# pam-config --query --mkhomedir

The following changes were made:

~# pam-config --delete --winbind
~# pam-config --add --mkhomedir

The following lined in the /etc/nsswitch.conf were changed from:

passwd compat winbind sss
group compat winbind sss

to:

passwd compat sss
group compat sss

Ensured the Name Service Caching Daemon (nscd) is shut down and disabled. The SSSD will perform session caching and all other user and group caching services.

~# systemctl stop nscd.service
~# systemctl disable nscd.service

Ensured the desired SSSD software stack/providers was installed:

~# zypper install sssd sssd-tools python-sssd-config sssd-ad sssd-ldap

The Leap system was re-configured to use the same time source and participate in the name space as the domain controllers in the target domain.

Server participation in those services was tested:

~# ntpq -p

~# host -t SRV _ldap._tcp.<DOMAIN_FQDN>
~# host -t SRV _kerberos._tcp.<DOMAIN_FQDN>
~# host -t SRV _gc._tcp.<DOMAIN_FQDN>

The existing computer object for the Leap server was deleted, and attempts were made to rejoin the system to the domain using the YaST Domain Membership module, unsuccessfully.

The openLDAP and Kerberos clients were installed and configured to facilitate addition troubleshooting and error capture.

~# zypper install krb5-client openldap2-client

Backup the /etc/krb5.conf and /etc/openldap/ldap.conf files if they exist and implement the following ones:

/etc/krb5.conf:

[libdefaults]
default_realm = <DOMAIN_FQDN>
default_ccache_name = /tmp/krb5cc_%{uid}

[realms]
<DOMAIN_FQDN> = {
kdc = <DC_FQDN>
default_domain = <DOMAIN_FQDN>
admin_server = <DC_FQDN>
}

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON

[domain_realm]
cantrexnw.local = <DOMAIN_FQDN>
.cantrexnw.local = <DOMAIN_FQDN>

[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 10000
clockskew = 300
external = sshd
use_shmem = sshd
}

/etc/openldap/ldap.conf

LDAP Defaults

See ldap.conf(5) for details

This file should be world readable but not world writable.

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

URI ldap://<DC_FQDN>
BASE dc=<DOM_LEV_2>,dc=<DOM_LEV_1>

REFERRALS OFF

Attempted to join the system manually using the samba “net” utility:

~# net ads join -U administrator
Enter administrator’s password:
Failed to join domain: failed to lookup DC info for domain ‘<DOMAIN_FQDN>’ over rpc: Undetermined error

It was verified that there were intermittent DNS issues preventing a DC from being located to perform the join, so the DC’s referenced were added to the /etc/hosts file temporarily to facilite a successful join.

The SSSD was configured and started successfully:

[sssd]
config_file_version = 2
services = nss,pam
domains = <DOMAIN_FQDN>

[nss]
reconnection_retries = 3
filter_users = root,sync,shutdown,halt,pvm
filter_groups = root,utmp,pvm,nscd,nslcd,rpc,rpcuser,gopher,tape,utempter,ntp,video,apache,ftp,lock,ldap,audio,haldaemon,vcsa,tcpdump,sshd,saslauth,dbus,screen,postfix,postdrop,hsqldb,nobody,nfsnobody,mock,stapusr,stapsys,stapdev,abrt,cgred

[pam]
reconnection_retries = 3

[domain/<DOMAIN_FQDN>]
enumerate = false
cache_credentials = true

The Global Catalog provides a subset of object information, which will work in most cases, but if custom attributes

or non-indexed attributes are used disregarding the GC could optimise searches in large environments

ad_enable_gc = false

If dymanic DNS functionality is not configured, consider disabling it for optimisation reasons as well.

dyndns_update = false

id_provider = ad
auth_provider = ad

If no access filter is specified (see below) this directive alone will prevent expired and disabled accounts from logging in

access_provider = ad

Specify filters to use to authorise access to the server, such as group membership or other LDAP filters

ad_access_filter = DOM:<DOMAIN_FQDN>:(memberOf=CN=SOME_AD_GROUP,CN=Users,dc=<DOM_LEV_2>,dc=<DOM_LEV_1>)

ad_access_filter = DOM:<DOMAIN_FQDN>:(&(objectclass=user)(employeeNumber=1234))

When using ID mapping defaults for some POSIX attributes are not specified and left to daemon and the Linux system defaults

default_shell = /bin/bash

Creates a dedicated home directory root for AD user home directories (%d - SSSD domain name), and creates the directory on

login if it doesn’t exist or is not mounted (%u - user name)

override_homedir =/home/%d/%u

The samba file is being adjusted by removing the winbindd directives and modifying group references used for share access control to utilise UPN’s (GROUP@<DOMAIN_FQDN> as opposed to legacy NetBios syntax (DOMAIN/GROUP).

– lawrence