Skip to content

Configuring ownCloud 9 & Active Directory / LDAP Plugin Successfully

With this step-by-step guide, you will have your ownCloud 9 (and earlier) cloud server authenticating against Active Directory or LDAP correctly in no time!

Introduction

 

Recently, I went through the process of setting up a brand new ownCloud 9.1 server, after my previous ownCloud server had seen upgrades from 6.x all the way up to 8x.  If you’ve used ownCloud that long, you know the abundant changes and improvements that have been made along the way did not come without their growth pains; especially if you delved into encryption.  So, I decided to start fresh.  I use Active Directory to provide a centralized authentication source for everything in my personal “cloud,” so after setting up my new Dropbox clone, the first thing I needed to do was configure the LDAP user and group backend plugin.  I had a lot of problems getting the Active Directory usernames to match the ownCloud usernames, instead of showing a long string off numbers.  It was a lot of confusing UID, UUID, SAMAccountName and DN related confusion.  There aren’t any great guides to keep you from getting a headache, so I decided to make one.

 

Problems with the LDAP user and group backend plugin

 

It’s pretty straight forward to get an ownCloud server authenticating against and Active Directory server, but the biggest problem I’ve seen is the mapped usernames end up being long strings of numbers in ownCloud.  Although the display names are correct in owncloud, the actual username for all AD mapped logins, by default, are a long unique string makes things difficult.  For one, if you need to get to a users ownCloud data folder, there’s no intuitive way of knowing who’s is who’s folder from the command line.

With this step-by-step guide, you will have your ownCloud server authenticating against Active Directory / LDAP, with the following benefits:

 

  • The ownCloud username will match the Active Directory / LDAP username (no long incomprehensible string of numbers)
  • Any user added to a specified group created in Active Directory will automatically have ownCloud login privileges.
  • ownCloud users will be able to login using their username or email address (if specified in AD) interchangeably.

These three pluses make everything very seemless and saves a lot of headaches. So, lets get started.

Setting up Active Directory or LDAP

 

Before starting on the ownCloud configuration, you need to login to your AD server and perform a few quick tasks.  I won’t go into detail here, I will just tell you what needs to be done.  Afterall, if you’re configuring or installing ownCloud, you should be able to do these things.  If not, feel free to ask specifics in the comments section at the bottom.

Log into your Domain Controller and fire up ADUC (Active Directory Users and Computers).  If you haven’t already done so, make sure the following is done.

  • Create a group specifically for users you would like to have access to ownCloud.  I created a group called ownCloud.
  • Create a service account specifically for ownCloud to use to scrape active directory unless you have anonymous binding enabled, which I hope you don’t!
  • Create a test user and add that test user to your newly created ownCloud group.  I suggest specifying an email address in the user’s properties, if you don’t already have an exchange server taking care of that.  This will allow you to verify email addresses are pulled in automatically for notification emails generated by ownCloud, as well as interchangeable login using usernames or email addresses in the username field.

After you’ve got all of that finished, go ahead and login to your ownCloud server with an account that has admin privileges (part of the admin group on the ownCloud server).

 

Configuring the ownCloud

 

The first thing you need to do enable the LDAP user and group backend plugin.  Go ahead and do that by going to Apps > Not enabled > LDAP user and group backend (it’s all the way at the bottom of the Not Enabled page).  If you get an error about ldap not being installed or available, scroll down this page for info on how to fix that.

 

oc-ldap2

 

If you tried to click Enable and and got an error saying LDAP is not installed or not available, login to your ownCloud server via SSH or Console and run the following command to install php-ldap support and resolve this on a Debian based distribution, such as Ubuntu (scroll down for CentOS/RedHat instructions).  If you were able to enable the plugin without any errors, skip this step.

 

#  sudo apt-get install php-ldap -y

 

It’s a quick install and you should end up seeing something like this.

 

oc-ldap1

 

If you are running CentOS or a Red Hat based distribution, you will need to use Yum to install php ldap support.  (you may not need sudo included in this command)

 

#  sudo yum install php-ldap

 

Now, assuming the LDAP / Active Directory plugin is now enabled on your ownCloud server, lets configure it.  Navigate to the Admin configuration page (click the icon in the top right corner of the ownCloud page, and select Admin) and scroll down to LDAP.

 

On the Server Tab

  • Server – This should be your Active Directory domain controller (preferably Global Catalog), or LDAP server.
  • Port – This should be 389, unless you have some crazy custom configuration.
  • Username – The username of the service account you created in ADUC, probably owncloud.
  • Password – The password you assigned to that service/user account.
  • DN – For simplicity’s sake, unless you have a HUGE AD infrastructure, I would just put the Base DN.  So, in my test lab my domain name is serenity-networks.com, so my Base DN is dc=serenity-networks,dc=com.  If your domain is example.com, your Base DN would be dc=example,dc=com
  • Click Continue.

 

oc-ldap-3

 

Next, is the Users Tab

  • Only these object classes – This should be left as “person” unless you have a reason to change it.
  • Only from these groups – Find your newly created ownCloud group (mine is called “ownCloud Users”), select it, then click the arrow pointing to the right to add it.
  • Click Verify settings and count users.  It will give you the number of users that are currently in the group.
  • Click Continue.

 

oc-ldap-4

 

The Groups Tab

  • Only these object classes – This should be set to group unless you have a reason to change it.
  • Only from these groups – Again, find the ownCloud group you created earlier and click the rigth arron to add it to the empty side.
  • Click Verify settings and count groups.

 

At this point, you could log in with Active Directory credentials (DON’T), but it’s going to set every AD user’s owncloud username to a very long numerical string, which is insane and impossible to manage; not to mention annoying and not aesthetically pleasing.  They say its to prevent duplicate usernames, but I don’t understand how that could happen.  I would never use mixed local / LDAP authentication, and there is never going to be duplicate usernames in AD…  But anyways, to fix that, click the “Expert” tab all the way to the right side.

 

The Expert Tab

  • Internal Username Attribute – Exactly like you see in the screenshot below, set this to SAMAccountName  (I’m not sure if it’s case sensitive but I wouldn’t try to figure it out the hard way.
  • UUID Attribute for Users – Leave this blank
  • UUID Attribute for Groups – Leave this blank
  • Clear Username-LDAP User Mappings – Click this ONCE
  • Clear Groupname-LDAP Group Mappings – Click this ONCE

 

oc-ldap-6-username-fix

 

You can click Test Configuration if you like, but at this point everything should be perfect.  If you click the icon in the top right corner and select Users, you should now see all of your Active Directory / LDAP users automatically populate on the Users page.  Changes are pretty much instant.  So, if you remove a user from the ownCloud group in AD, reload the page, they will be gone.  Also, now would be a good time to verify that the Username field on the Users page matches the users Active Directory username, their Name matches the AD Name, and their email address matches the one specified in AD or assigned by an Exchange Server.

 

It took me quite a few hours of trial and error to get this right.  I hope it saves you some time and headache.  If you have any problems, questions, tips, advice, please feel free to post in the comments below.  I enjoy hearing from my readers!  Thanks and have a great day!