This is a perfect example of banging your head against the wall for a day. Integration information between FreeIPA and just about anything is hard to come by, so I decided to put this short guide together covering it and Nextcloud. This is just a drop in a bucket that desperately needs to be filled. As always, I will endeavour to explain how I figured this out because understanding the how and why is important! Ultimately this investigation resulted in me tracking down a bug in the LDAP app in Nextcloud, and a patch has been merged for the Nextcloud 12 release.
You’ll require a read-only System account in your FreeIPA instance. This is for Nextcloud to bind to for reading users and groups. Basic instructions for creating a user for this purpose are located here on the FreeIPA wiki.
With this in hand and the LDAP / AD Integration app enabled in your Nextcloud instance you can get to configuring. You should be aware of some of your basic configuration settings in FreeIPA, like your basedn which you can find in
/etc/ipa/default.conf on your IPA server.
The initial configuration page as seen above requires a few different fields of information, specifically
- IPA server’s hostname, and LDAP port (typically 389)
- Your bind user’s DN, which was mentioned earlier
- Its password
- Your directory’s Base DN
For the Users tab, you can limit users to meeting specific criteria. This can be further limited on the Groups tab, so a general setting of ipausers is reasonable.
On the Login Attributes tab you can choose the fields used for logins to Nextcloud. If you want to enable logging in with the user’s email address and have trouble with the LDAP / AD Email Address choice, use the
The Groups tab can be used for limiting user logins to only include those in certain object classes or groups. This is something specific to your setup and needs, so there’s not much to say about this.
From here, some Advanced and Expert tab configuration is required.
Under the Advanced tab, you can input your FreeIPA replica and its port (if that’s how your FreeIPA environment is configured). The important settings for everyone using FreeIPA come next under Directory Settings and Special Attributes.
The settings for the Base User Tree and Base Group Tree can be discovered by utilizing
ldapsearch to get some insight into user and group structure.
$ ldapsearch -H ldap://ipa.example.com -x -b "dc=ipa,dc=example,dc=com" -D "uid=robind,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com" -W "uid=jsmith"
Enter LDAP Password:
# jsmith, users, accounts, ipa.example.com
In the above example by searching for one of our user’s UIDs, we can see the user’s DN and DN of its group memberships. There is a lot of other information I have simply cropped out, but another important one is the attribute where the UUID is being stored, which we’ll come back to later.
- User Display Name Field:
- Base User Tree:
cn=users,cn=accounts,dc=ipa,dc=example,dc=comwith the Base DN matching your own
- Group Display Name Field:
- Base Group Tree:
cn=groups,cn=accounts,dc=ipa,dc=example,dc=comwith the Base DN matching your own
After that, the Special Attributes can be updated.
- At a bare minimum update the Email Field to be
- Choose an attribute for the User Home Folder Naming Rule, I’m using
uidwhich for the example user above is jsmith. In a default installation this would have folders being created as
/var/ncdata/jsmithfor example, with the files actually being located in
With the configuration done up to this point…nothing will work. Turning up debugging will give you no further information, and login attempts with users in your FreeIPA directory will result in a misleading error message about the display name.
LDAP Login: Could not get user object for DN uid=jsmith,cn=users,cn=accounts,dc=ipa,dc=example,dc=com. Maybe the LDAP entry has no set display name attribute?
It’s worth understanding a little bit about what Nextcloud is doing under the hood with LDAP. Inside the database are two mapping tables (
oc_ldap_user_mapping). This allows an LDAP DN to be linked to something internally appropriate to Nextcloud. The application is meant to do automatic UUID discovery based on some typical attribute names, including FreeIPA’s UUID attribute (which we saw earlier,
ipaUniqueID), but some part of this is actually broken, and therein lies the crux of the problem.
I’ve confirmed in packet captures of the LDAP conversation between Nextcloud and FreeIPA that the
ipaUniqueID attribute is requested and even receives a valid response with the user’s UUID, but the critical mapping step never actually happens. Without mapping, no users. How do we fix this?
Under the Expert tab we’re offered several fields. To get things working, Override UUID detection is what we’re looking for. By setting this to
ipaUniqueID for both Users and Groups, you’ll be up and running, but maybe not as you expected!
When the Internal Username field is left blank, Nextcloud will default to using the UUID. If you were to visit your Users list with this left blank your LDAP user’s Username as shown would be their UUID string which might not be desirable. By setting this instead to
uid for example, you will instead have
jsmith, for example.
If you’re running a mixed directory, you may want to leave it as the UUID. You probably also want to make sure that your LDAP directory is not serving a user named
admin if you do choose to use the
uid… (Have not confirmed if that would cause issues, but better safe than sorry)
Once this configuration is done, you should be ready to login to Nextcloud with your FreeIPA users!