Integrating Synology DS with FreeIPA

I recently decided to replace my outdated Synology DS 1010+ NAS (in service 24×7 for over 8 years without major issues) with a new DS 1618+ NAS. Of course the new NAS is a lot faster, has an additional drive bay but to me most important was to replace the hardware and benefit from the newer version of DSM (Synology’s NAS software platform). However, this post is not about my new NAS (there are sufficient other sites describing / testing / comparing these devices).

Of course, now that I am integrating everything with FreeIPA (replacing my MacOS OpenDirectory setup) I also needed the Synology NAS to be fully integrated with FreeIPA. Jack Henschel’s excellent post that gave me some clue’s but wasn’t quite clear in how things worked and what was really needed. The article itself was clear in the steps to take but not everything worked for me immediately so I had to find out why and how to fix that and document that in this post.

Synology DSM is a pretty open and user-friendly platform and works great when integrating with ‘standard’ things, i.e. with other Synology devices, Windows Active Directory or standard LDAP directories. However, since FreeIPA is also still in development and takes a slightly different approach here and there, the integration was a little more complex than simply setting up a host and service in FreeIPA to access the LDAP directory. Unfortunately the FreeIP documentation wasn’t very helpful either so this required some experimenting. In the end I integrated DSM 6.2 with FreeIPA though this was not trivial and required some setup and changes to the FreeIPA setup.

Background

Before getting into the details of how to set things up let me share the FreeIPA-specific quirks I noticed / observed when getting this working. Feel free to skip this if you’re only interested in getting things working for you setup.

1. FreeIPA is capable of integrating with Microsoft Active Directory and build up a domain trust, but (at least at this moment) does not support being an Active Directory domain controller. Documentation and presentations on this topic only cover setting up a domain trust and one of the developers stated that their “eventual goal is to allow IPA-hosted identities to be used to login to Windows machines joined to Samba AD“.
2. To support the domain trusts, FreeIPA includes a number of plugins for this in its LDAP server. I have not been able to uncover much documentation on that but looking at the source of those plugins there is magic happening based in the backend on objects having certain objectclasses/attributes.
3. As per various documents on how to integrate FreeRadius and FreeIPA for MS-CHAPv2 authentication (which uses the NTLM (RC4) password hash, running the script freeipa-adtrust-install will make the necessary modifications to expose the ipaNTHash attribute to LDAP for authorized user. This is also required to have samba clients authenticate with NTLM.
4. Other Samba clients (e.g. Synology DSM) rely on the user object having the sambaNTPassword attribute to be able to access SMB shares. Unfortunately the FreeIPA team has decided to use another attribute for this (ipaNTHash) but a bit of digging in the schema files uncovered that FreeIPA does have the Samba schema present. I found that if a user has the objectclass sambaSAMAccount, FreeIPA would also populate the sambaNTPassword attribute with a usuable hash for NTLM authentication when a user password is changed. Some clients (e.g. Synology DSM) also require thesambaPwdLastSet attribute for password expiry, which is then also available.
5. No all required attributes required for a user object to become a sambaSAMAccount object are populated automatically, some will have to be set manually. Fortunately this is a one-time change for each new account but a but tricky as some are dynamic (i.e. user-dependent). I got things working with the following mapping:
   • sambaSID: value of user object’s ipaNTSecurityIdentifier
   • sambaAcctFlags: hardcoded: [U ]
   • sambaDomainName: set to the Kerberos Realm
6. For users to have the new password attributes, it is required to change their password after the the necessary setup has been done. (i.e. the ipaNTHash and sambaNTPassword attributes won’t appear magically after configuration but do require a password change).
7. For users to be able to change their password including the ipaNTHash and sambaNTPassword attributes they must be granted access to set these attributes.

With this information we’re able to integrate Synology DSM with FreeIPA.

Configuration

Some of the actions below require multiple steps and some are needed more often, therefore I have created scripts to perform them that are used in the steps below. Please download these scripts from my GitLab repository.

Enable AD Domain support

The first step is to enable Active Directory trust support (which also ensures the Samba LDAP schema becomes available and the necessary LDAP server plugins are enabled). Activate this on your FreeIPA server by running:

sudo ipa-adtrust-install --add-sid

The --add-sid parameter tiggers generation of a SID for each existing user and is required if you want existing users to be converted, which is probably what you want.
Please note: due to a bug in the script it will fail the SID generation if you have users in stage, remove these before running this command!.

Modify Self-Service rights

For users to be able to change the NTLM password hash while changing their own password the following command must be run to make the necessary LDAP attributes available for this:

ipa selfservice-mod --attrs=ipaNTHash \
                    --attrs=userpassword \
                    --attrs=krbprincipalkey \
                    --attrs=sambalmpassword \
                    --attrs=sambantpassword \
                    "Self can write own password"

Make users a sambaSAMAccount

For users to have the necessary attributes to login to Synology DSM (and for FreeIPA to maintain some of them) they must have the sambaSAMAccount objectclass. This class has a number of mandatory attributes, one of them to be copied from an existing attribute) so I created the script freeipa-samba-user.sh (available from my GitLab repository) to handle this as this change will also have to be performed later for any new user. This script will only convert users that do not have the sambaSAMAccount objectclass and accepts a list of users to convert (use * for all users except admin). So to convert all existing users (except admin) use:

./freeipa-samba-user.sh \*

(the backslash above is needed to avoid shell expansion of the *). In case you do need the admin user (not useful for Synology DSM but may be needed in other cases) run:

./freeipa-samba-user.sh admin

Please note: Since each user needs to be converted, this command should either be run manually after creating a user (simply re-run with parameter \*) or can be run from cron when needed.

Create LDAP Service Account

To access the FreeIPA LDAP database, the Synology DSM NAS needs a service account with a password. Although it is quite straightforward to setup a host and service account in FreeIPA, giving it a simple password that allows it to do a simple bind (without requiring Kerberos) requires a direct change to the LDAP database. As this is needed more often and for other integrations, the script freeipa-service-password.sh was written that expects a hostname and service(s) as parameter and:

• creates the host in FreeIPA (if it does not exists). When a new host is created, it also scans and add the SSH keys for that host to the host record so that this is store in FreeIPA
• Creates each service under the host in FreeIPA (if it does not exists).
• Resets each service’s LDAP password to a long generated random password (always)

As it always sets the password this script can be used for initial setup as well as to reset the service password. To setup the required service account run run it like:

./freeipa-service-password.sh <hostname> <service>

(replacing <hostname> with DNS name of your NAS and <service> with ldap) When it is done the script prints the service’s bind DN and generated password (needed later to setup the connection from the NAS).

Grant Service Account access to NTLM Password

Samba on the NAS uses NLTM Password authentication to avoid sending clear-text passwords unprotected over the network (which is simply bad). In order to authenticate using NTLM, the Synology NAS needs access to certain attributes that are (and need to be) protected as they could be used to guess the password (see also Windows passwords: “Dead in Six Hours” – paper from Oslo password hacking conference). To allow a service account access to these attributes in FreeIPA some things need to be setup:

• A permission must exist to grant read access to the necessary attributes
• A privilege must exist so that the permission can be granted
• A role with the privilege must exist so that it can be assigned
• the role must be granted to the service account.

As this is needed for other integrations as well, the script freeipa-service-ntlm.sh was written to set this up, which expects a hostname and service(s) as parameter and should be run as:

./freeipa-service-ntlm.sh <hostname> <service>

(replacing <hostname> and <service> with the values used in the previous step). This will ensure the necessary role exists and assign it to the service account so that the NAS can access the necessary attributes to perform NTLM authentication.

Setup Synology DSM

Once the setup on FreeIPA is complete the configuration of the Synology DSM NAS is straightforward. Login to you NAS as admin and open the control panel. In case you don’t see an icon configure Domain/LDAP (as in the picture below) you must enable Advanced Mode by clicking on the link in the top-left corner.

Open the Domain/LDAP configuration screen to configure it.

In the screen that follows (below is a screenshot from my working setup with fields emptied hence the Connected in it), go to the LDAP tab. In case you already had a Domain configured you will have to disable that in order to switch to LDAP (they cannot be active both).

Next Fill in the following details:

• LDAP Server address: the FreeIPA server’s hostname (or IP address)
• Encryption: set to SSL/TLS (works for me, STARTTLS may also work).
• Base DN: the Base DN of your FreeIPA LDAP directory (normally something like dc=mydomain, dc=tld). You can also click on the little triangle to have you NAS look it up from the FreeIPA LDAP Server.
• Profile: leave this at standard (works for me)
• Update user/group list(minutes): determines how often your NAS will refresh the user list (as it caches that), set to a sensible value for your environment based on how often you add/remove users. (Please note that it is also possible to refresh this manually from the LDAP Users tab after LDAP has been setup).
• Other options: leave disabled (no reason to activate)

Next click the Apply button to proceed. A popup window appears to add the service account credentials:

Enter the service account’s DN and password setup before with freeipa-service-password.sh and again press the Apply button to activate the setup. Unless all users have been converted to a sambaSAMAccount (which won’t happen with admin by default) and have changed their password after that, you will get the following message:

This is normal an not an issue, as soon as users have the sambaSAMAccount objectclass added and changed their password afterwards, these attributes will become available upon the next refresh of the LDAP users. This synchronization can also be initiated manually from the LDAP Users tab next to the LDAP configuration tab once connected.

With this setup users that changed their password can login using the web interface, in apps/modules like Drive and Moments as well as access shares using SMB (and AFP in case you are still using that). The good thing is that for SMB shares it will use NTLM password authentication and not clear-text passwords (which is unsafe and requires additional configuration on the client side to allow.

Please note that when you add new users, they must be enhanced with the sambaSAMAccount objectclass using the freeipa-samba-user.sh script before they can login. For this include running this script in your workflow to run it manually. It should be possible to schedule to run from cron as well but I have not looked at this as I don’t need that (may do so in the future).

I have documented this for my own use (as it took quite some time to get to this point even though now it is a 10-minute guide) and hope this may be useful for others. In case you have any issues with this (or find any bugs in the scripts), please comment or raise an issue for that on my GitLab repository.