[HOWTO] Setting up sssd clients with QNAP LDAP

Don't miss a thing. Post your questions and discussion about other uncategorized NAS features here.
Post Reply
User avatar
ContextSwitch
Know my way around
Posts: 197
Joined: Mon Jan 16, 2012 5:09 pm
Location: Darwen, UK
Contact:

[HOWTO] Setting up sssd clients with QNAP LDAP

Post by ContextSwitch »

What this is about
This article describes how to set up your NAS so that client machines on your local network authenticate against domain users in the QNAP LDAP database using sssd on client machines so that:
  • Users can authenticate against domain users on the NAS
  • Users can change their own passwords
  • Users cannot login to any account you have set to expired on the NAS
Obviously you get all the sssd goodness as well :)

Whilst doing this myself I came across numerous difficulties so I'm posting this so that others won't have to wade through sssd source code or follow developer threads which I had to do.

In this article I am specifically talking about the QNAP supplied LDAP database which is part of the firmware, if you are using an installed LDAP databse then this article may help but may not be totally suitable to your needs. The QNAP supplied LDAP presents some challenges that are described in this article and, as you will see, they are easily overcome.

I'm going to assume some knowledge of the way LDAP works; I don't intend to make this a tutorial on LDAP.

Something to note is the version of sssd your distribution installs, if it's 1.9.0 or above then you're good to go, if it's 1.8.x or below then the best you're going to get is basic authentication; you won't be able to expire an account and your users will not be able to change their own passwords.

Why do this
I guess there are two questions:

Why set up your users in an LDAP database?
My answer to this is: because I'm lazy. I have six people in my house and there are four computers (not counting the NAS). That's a total of twenty four local user accounts for me to administer. I'd like to centralise all user accounts. There's also another reason, my NAS serves files via NFS so all my users accounts need to have their details (user ids, groups ids) synchronised, that comes automatically with the LDAP approach.

Why use sssd on the clients
sssd provides an interface to the LDAP server but the main functions it serves on my network is caching of user credentials so that if a laptop is taken to another location or my NAS is down then users can still log on to their PCs. You can to this with nscd and pam_ccreds but I found this solution unsatisfactory as log in times grew to a point where people complained (to me, dammit) and you are forced to flush the cache periodically.

The Process

Step 1
Get some domain users onto the NAS. This simply means enabling the LDAP database, setting it up with a domain and adding some users. All this can be done with the QNAP web interface. Do it now, don't worry, I'll wait, just don't use any user names that are the same as on your client machines.

You will need to configure the LDAP server with a domain name, in this article I will assume your domain name is "example.com" so the LDAP server will be configured as "dc=example,dc=com".

You will also have to set a root DN on the server with a password, the root DN is already defined as "cn=admin,dc=example,dc=com" but you will need to give it a password.

Once you get things working you can delete the local users on the client machines and re-create them on the NAS but lets get things working first. Older versions of the QNAP firmware didn't quite create the domain users properly; they missed setting the attribute "homeDirectory" but don't worry we'll check this later and fix it if needs be. Any firmware from 3.8 onwards and you should be okay.

Step 2
We need to set up your local machines to talk to the LDAP server, how you do this will depend on your distribution but please note that you will need the ldap utilities; on Debian you will need to install ldap-utils which should pull in libldap, other distributions will be similar.

Now that we've got LDAP on our local machine then we need to see if the PC can talk "LDAP" with the NAS so let's configure it. When sssd performs its duties it demands to have an encrypted link between the PC and the NAS so we're going to get the public certificate off the NAS.

Use ssh to logon to the NAS and look at this file: /etc/openldap/slapd.conf, you will find a line that starts with "TLSCertificateFile". Find the file referenced on this line (in my case it is /etc/config/stunnel/backup.cert) and copy it to the PC, put it somewhere permanent, maybe under /etc/ssl. It's probably a good idea to change the name of the file to something meaningful, in this article I'll assume /etc/ssl/mynas.cert.

Edit the file /etc/ldap/ldap.conf and change it so it looks like this.

Code: Select all

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=example,dc=com
URI     ldap://<FQDN of NAS> ldaps://<FQDN of NAS>

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/mynas.cert
TLS_REQCERT     never
You'll need to change <FQDN of NAS> to the fully qualified domain name of your NAS, in particular it should match whatever was used to sign the certificate.

Ok, now your PC should be able to query the LDAP server on the NAS, try this:

Code: Select all

ldapsearch -x
and you should get a list of all the domain users on the NAS and their attributes. If you didn't you'll need to debug LDAP and I suggest that Google will be your friend here.

That was a clear text query, lets try one that requires TLS (as sssd will).

Code: Select all

ldapsearch -ZZ -D "cn=admin,dc=example,dc=com" -W
put in the LDAP root password and you should see the same list (actually it contains more data than the previous one but if you see the list then we can be sure that TLS is working).

Step 3
Now that the PC and the NAS are talking "LDAP" we can check if the NAS set up the users properly. From the list generated at the end of step 2 have a look at the attributes of one of the users you created, it should have a "homeDirectory" attribute, if it has you can skip the rest of this step. If not, do the following:
Create a file, lets call it "addhome", and make it look like this

Code: Select all

dn: cn=<user>,dc=example,dc=com
changetype: modify
add: homeDirectory
homeDirectory: /home/<user>
change <user> to the user name in question. If you have more than one user needing this modification then you can repeat these lines in the same file just modifying <user> each time.

Now run this command:

Code: Select all

ldapmodify -ZZ -D "cn=admin,dc=example,dc=com" -W -f addhome
put in the LDAP root password again. You can now delete the "addhome" file.

Step 4
We are now ready to install sssd onto your PCs but before we do please take note:

WARNING
Having a badly configured sssd can seriously ruin your day


You need to have a recovery strategy if sssd does not work for any reason as you can find yourself unable to login as any user including root. Personally I have a copy of System Rescue on both cd and flash drive, and yes, I have needed to use them.

Now install the following packages onto your PC:
  • sssd
  • sssd-tools
  • libnss-sss
  • libpam-sss
actually you don't need sssd-tools to follow this article but it's useful to have around.

sssd runs as a daemon at start up and is configured by editing /etc/sssd/sssd.conf. This file does not exist when sssd is first installed so we'll create it now. In addition sssd is fussy about who can access this file so we'll change this as well. This won't be the first time you'll notice the sssd developers trying to hold our hands and insist we use their policy instead of ours.

Run the following as root:

Code: Select all

touch /etc/sssd/sssd.conf
chmod 600 /etc/sssd/sssd.conf
First of all we're going to set up sssd.conf for basic operation, this will give us authentication and allow users to update their own passwords, it won't allow account expiration, we'll add that later.

Edit sssd.conf so it looks like this:

Code: Select all

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://<fqdn>
ldap_user_search_base = ou=people,dc=example,dc=com
enumerate = true
cache_credentials = true
tls_reqcert = never
ldap_tls_cacert = /etc/ssl/mynas.cert
as before change <fqdn> to the fully qualified domain name of your NAS.

You will now need to run the sssd daemon, if it starts successfully then try to login as one of the domain users you set up in step 1. If everything is well you'll be able to login as a domain user and that user should be able to change their password using the passwd utility.

Step 5
If you're not interested in expiring any accounts then you can finish now but if you do want the ability to use the QNAP web interface to set accounts as expired and have your PCs honour that setting then you need to add a few more lines to sssd.conf.

All the lines we're going to add will have to be inserted after the line that says "[domain/LDAP]".

First of all we're going to tell sssd that we want it to take note of the shadow attributes for each user. You may be tempted to try "ldap_pwd_policy = shadow" but do not do this. If you do then you'll find that your users will be unable to change their own passwords. This behaviour is by DESIGN; the sssd developers have decided that shadow policies should be invoked at the server. OpenLDAP does this with the ppolicy module but QNAP have not included this. Instead we add the following lines:

Code: Select all

access_provider = ldap
ldap_account_expire_policy = shadow
ldap_access_order = expire
ldap_chpass_update_last_change = true
When sssd checks for shadow attributes it looks for the "shadowLastChange" attribute from the server and if it can't find this attribute sssd will decide they do not exist on the server and hence cannot use shadow attributes to determine if an account has expired. Now here's the relevant part from the access control list on the NAS:

Code: Select all

access to attrs=shadowLastChange,sambaPwdLastSet
        by self write
        by users read
For some reason QNAP have made shadowLastChange visible to only identified users but sssd performs this check before it's bound to any particular user so doesn’t see the attribute and consequently does not honour the shadow attribute settings.

To get around this we need to tell sssd to bind as the root LDAP user as this user bypasses all access controls. To do this add the following lines to sssd.conf:

Code: Select all

ldap_default_bind_dn = cn=admin,dc=example,dc=com
ldap_default_authtok = <password>
You need to substitute <password> for the password you set up in step 1.

Restart sssd and that's it! You now should have a PC that can:
  • Authenticate against domain users on the NAS
  • Users can change their own passwords
  • Users cannot login to any account you have set to expired on the NAS
--
Geoff
Scoobie
Starting out
Posts: 45
Joined: Fri Oct 29, 2010 12:10 am

Re: [HOWTO] Setting up sssd clients with QNAP LDAP

Post by Scoobie »

THANKS !!! This is just what i'm looking for :!: :mrgreen: :mrgreen:
Tengri
First post
Posts: 1
Joined: Sat Dec 20, 2008 7:09 pm

Re: [HOWTO] Setting up sssd clients with QNAP LDAP

Post by Tengri »

Sorry, I struggled with the implementation on my opensuse 13.1 system. My QNAP is a TS 421 with the actual firmware 4.0.2
Is there some advice I could follow to get it working?
And sorry, I'm not that familiar with LINUX, still in the transition from Windows to LINUX so be patient and provide clear instructions.

Thanks a lot in advance.
Tengri
TS 409 pro and since a few weeks TS 421
Post Reply

Return to “Miscellaneous”