Linux login with ldap

After an absence of a few weeks (due to just having too much work to do and not time to write anything up) i finally made the effort. It was prompted by the fact that what i though would be a relatively easy thing to set up turned out to be anything but and i spent way too many hours on this.

What i was trying to do was get authentication to linux machines working with just my 'normal' login (in my specific case within Azure - but the logic holds true anywhere). I had previously blogged about a couple of other ways of doing this

A long time ago using this method

http://dbaharrison.blogspot.com/2016/11/linux-in-azure-single-sign-on.html

And much more recently using this method

http://dbaharrison.blogspot.com/2019/01/linux-login-using-azure-active.html

Both of these work fine - but both have a couple of limitations - specifically the former does not work for federated accounts (at least in our setup) and the latter forces the username to be username@domain where i specifically need it just to be username.to be compatible with some of the applications.

So how to deal with this?

Well - the answer is ldap - and the setup is actually fairly simple once you get to that point. I found however that getting to this point was not at all easy - various blogs/docs seem to show apparent solutions - but for me at least i couldn't get it working as described.

So here are my steps now to get this working - in my specific case I am authenticating against Azure Active directory domain services (AADDS) - this is the PaaS version of AD you can get with Azure. As part of these service you get ldap - however ldaps is not enabled by default and this has to be in place for this login to work (this is one of the things that other articles did not make clear)

To do this you can just follow this article

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap

At the end of it you should see this enabled in the domain services screen

For non AADDS - just make sure whatever ldap service you have is ssl/tls enabled (i.e. ldaps).

Once that is in place lets move on to the machine config - now in my case I've proven it on SLES12 and SLES15 - i would think that this would work find on any linux (as it's pretty generic) but that isn't guaranteed (i.e. don't blame me if this doesn't work....)

First up we install the 2 bits of software it needs to work

zypper install sssd samba-client

Then we add sss to the pam config (this will likely vary between linux vendors)

pam-config --add --sss

Update nsswitch.conf config (make sure the passwd line refers to sss) - so in my case the line looks like:

passwd: compat sss

Now update the 2 key environment files that will be specific to your environment - i pasted mine here redacted to help:

1) /etc/sssd/sssd.conf


[sssd]
config_file_version = 2
services = nss, pam
domains = YOURDOMAIN.ONMICROSOFT.COM

[nss]

[pam]

[domain/YOURDOMAIN.ONMICROSOFT.COM]
ldap_uri = ldaps://yourldapipaddress
ldap_search_base = dc=yourdomain,dc=onmicrosoft,dc=com
ldap_schema = ad
id_provider = ldap
ldap_id_mapping = true
auth_provider = ldap
ldap_user_object_class = user
ldap_tls_reqcert = never
ldap_user_name = sAMAccountName
ldap_group_object_class = group
cache_credentials = false
enumerate = false
ldap_default_bind_dn = cn=useryouwanttheservicetorunas,OU=AADDC Users,dc=yourdomain,dc=onmicrosoft,dc=com
ldap_default_authtok = password-of-above-user

2) /etc/samba/smb.conf

[global]
        workgroup = YOURDOMAIN
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        include = /etc/samba/dhcp.conf
        logon path = \\%L\profiles\.mmsprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = P:
        usershare allow guests = No
        idmap gid = 10000-20000
        idmap uid = 10000-20000
        realm = yourdomain.onmicrosoft.com
        security = ADS
        template homedir = /home/%u
        template shell = /bin/bash
        winbind refresh tickets = yes
        winbind use default domain = yes
        kerberos method = secrets and keytab
        client signing = yes
        client use spnego = yes
[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
[profiles]
        comment = Network Profiles Service
        path = %H
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
[users]
        comment = All users
        path = /home
        read only = No
        inherit acls = Yes
        veto files = /aquota.user/groups/shares/
[groups]
        comment = All groups
        path = /home/groups
        read only = No
        inherit acls = Yes
[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No
[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = @ntadmin root
        force group = ntadmin
        create mask = 0664
        directory mask = 0775

Now the config is all in place we just need to make sure the sssd daemon starts on boot and that we restart it now to pick up the config changes

chkconfig sssd on

service sssd restart

Now we're ready to go......

If i now login with an account from my AADDS it works just fine. And this works for user replicated from on premise via AADconnect, those created directly in Azure AD ('cloud only accounts as we call them) and also for accounts created directly in AADDS (which is possible though not entirely recommended....) - so 'all' users that AADDS is aware of and exist in the directory

And there you go - works...

Howver for me at least there was one snag - the login process was taking about a minute (we have a huge AD and loads of group memberships but also a 50ms delay in ldap queries due to it currently being in a legacy ASM network in Azure) - after a bit of debugging this is due to the fact that ldap is recursively checking group memberships an the details of them. There is supposedly a flag to restrict how much of the checking ldap does but for AD at least this did not seem to work as advertised.

I did however find a workaround - if in the sssd.conf file you set this

ldap_group_object_class = groupx

Then when ldap comes to check group membership the groupx object class does not exist so there is nothing for it to check and the login is pretty instant.

This does mean though that you can't check any group memberships of logging on users (which is a bit of a pain) so it means you have to control who can actually login via some non ldap method - for example a static list in sshd config - which is not great to be honest.......

If you really wanted the fast speed and group checking then perhaps it needs some sort of ldap proxy (which isn't ad) in front of AADDS and perhaps then this nested checking behaviour is addressed