Adding ownCloud 8 or 9 to Active Directory 2012 R2 – Part 4: connecting to Active Directory

Part 1: Introduction
Part 2: Installing Debian 8
Part 3: Installing ownCloud 8
Part 4: Connecting to Active Directory
Part 5: Security
Part 6: Miscellany
Part 7: Server maintenance

OwnCloud’s documentation on Active Directory is better than before but still had me mystified. It does shed some light on the interface and inner workings but there’s room for improvement.

Part of the reason the interface is so confusing is because ownCloud can work with LDAP systems other than AD so the interface must be generic. But it doesn’t need to be; it’s a matter of design.

Anyway – it works.

Important: show Advanced Features in AD Users and Computers
Head over to your Active Directory Domain Controller and open Active Directory Users and Computers. You’ll need to know a bit about LDAP attributes in order to point ownCloud in the right direction. By default AD Users and Computers won’t show all attributes but you can politely request it will. In AD Users and Computers, click View and check Advanced Features.

Now if you view an object’s properties, among other extra goodies you get an Attribute Editor tab showing all the object’s attributes.

Active Directory Users and Computers: show Advanced Features
Active Directory Users and Computers: show Advanced Features

Create a dedicated ownCloud user
While it is possible to use any AD user or even the administrator account you should create a dedicated ownCloud user in Active Directory. The advantages of a dedicated user for ownCloud are:

  • OwnCloud doesn’t break if you change any other password but its own.
  • You can use a strong password and you don’t need to remember it. If you forget it, just create a new one because you know it will not impact other applications.
  • If your ownCloud server gets compromised it doesn’t compromise your administrator account.

The ownCloud account does not have to be a member of any special groups. It does not have to be an administrator account. The account must be enabled. If you disable it your users will not be able to log into ownCloud.

I created an ownCloud account by the name of ocsvc (OwnCloud SerViCe) but you can use any sensible name you want.

Enable LDAP in ownCloud
From the ownCloud web interface click Admin (top left) > Apps.

On the left click Not enabled. (If you don’t see the left pane increase the window width ;)) Scroll down to LDAP user and group backend and click Enable.


From the menu top right choose Admin.


Now is the time to check your logfile
We covered logging in part 3: installing ownCloud 8.This is a good time to do
# tail -f /var/log/owncloud.log
on your ownCloud server to see what ownCloud has to say. It is normal that you see a lot of stuff logged when things just work.

LDAP queries
We’re going to put LDAP queries in ownCloud. OwnCloud has a tendency to hang if you botch your query. If it does just restart Apache:
# service apache2 restart
…reload ownCloud’s web interface and put in a different query.

In AD Users and Computers rightclick your dedicated ownCloud user and choose Properties. On the Attribute tab find the attribute called distinguishedName, select it and click View.

The Attribute Editor tab
The Attribute Editor tab

A window will pop up showing you the exact value. Copy the value and close the Editor and the Properties window.

Copy the LDAP attribute
Copy the LDAP attribute

In the left pane on the ownCloud web interface click LDAP. LDAP queries in AD are not case sensitive but it doesn’t hurt to use the correct cases because ownCloud and AD are not the same thing. On the Server tab fill out the following values:

LDAP | Server tab
LDAP | Server tab

Host: your AD domain’s LDAP name, for example server01.testnet.local
User DN: paste the value you copied just now: CN=ocsvc,CN=Users,DC=testnet,DC=local
Password: your dedicated ownCloud user’s password
Base DN: the OU containing all users and groups that need to be able to access ownCloud. By default this would the Users OU but you can use any OU/s you like as long as they span your users and groups. I’m adding the Users OU.


Rightclick your OU and choose Properties.

On the Attribute Editor tab find the attribute called distinguishedName and click View.


Copy the value and paste it in the Base DN field.

The Detect Port button should find the correct port number. If it doesn’t just enter 389. The Test Base DN button should find a number and tell you about it in an orange bar on top of the page. If it doesn’t: check your values and check your log. The light after Configuration should turn green. Sometimes it doesn’t and most of the time it’s correct.


Pressing Continue takes us to the Users tab.

The function of the Users tab is to tell ownCloud which users to list as user on the administrative page. Its function is not to determine who is allowed to log in. That is what the Login Attributes tab is for.

A side note: you may wonder why on the Users, Login Attributes and Groups tab the dropdown boxes are disabled. They are enabled only if your LDAP server supports ‘member-of-overlay’. This is an OpenLDAP feature and either not supported or handled differently by AD. So the dropdown boxes are only enabled for OpenLDAP, never for Active Directory. If you’re using AD you must always enter your own LDAP queries.

In the Users tab we need to enter a query that returns objects which are members of the ownCloud group in AD, or member of a group that is itself a member of the ownCloud group (an indirect member).

AD-speak for this condition is: (memberOf:1.2.840.113556.1.4.1941:=CN=owncloud,CN=users,DC=testnet,DC=local)

“memberOf:1.2.840.113556.1.4.1941:” (excluding the double quotes but INCLUDING the trailing colon) means: member of the following group and/or member of a group that is itself a member of the following group (ad infinitum). So “memberOf:1.2.840.113556.1.4.1941:” gives you all direct and indirect members.

It is important to understand that this number is static. Is is a name, just like “displayName” and “sAMAccountName”. The number is the same in all AD 2012R2 installations.

LDAP | Users tab
LDAP | Users tab

You can find your ownCloud group value by rightclicking the group in AD Users and Computers, choosing Properties and from the Attribute Editor tab selecting distinguishedName. Click View if you want to copy the value.


Click ‘Verify settings and count users’. If the correct number of users appears and the Configuration light turns green click Continue. If not troubleshoot until it does.

On to the Login Attributes tab.

As I mentioned before the funtion of the Login Attributes tab is to determine who is allowed to log in. We need to do two things here:
1. Tell ownCloud who is allowed to log in.
2. Tell ownCloud which AD attribute the user will enter as their username.

The username that is entered in ownCloud’s logon screen is passed here as “%uid” (without the double quotes). The syntax to concatenate two LDAP conditions is: (&(key=value)(key=value)). The complete query becomes:

If you want your users to log in with their e-mail address replace “sAMAccountName” with “mail”.

OwnClouds documentation says you can specify that users can log in with either username or e-mail address by using

 ((&(objectClass=inetOrgPerson)(memberOf=cn=owncloudusers,ou=groups,dc=example, dc=com)(|(uid=%uid)(mail=%uid)))

(I believe they’re missing a bracket there.)

Our query would then result in:


I recommend against using more than one identifier in more complex situations to prevent confusion.

Enter a username in the Test Loginname field and click Verify settings. The username should be the exact username the user would enter in the ownCloud logon screen. When you click Verify settings ownCloud will tell you whether the user is allowed to log on or not. Try various users to make sure your query returns the values you expect.

OwnCloud’s previous version would actually tell you the user was found. This version however just moans about some other setting being incorrect. You can tell your query was succesful by the length of the moan. One short snarl means it’s ok. A sermon means either the query was unsuccesful or the user doesn’t exist. (Actually the sermon does provide useful troubleshooting information so perhaps I’m being to harsh here ;))

If you’re having trouble creating the right query remember to use your logfile!

I assume ownCloud will grow up at one point and show useful commentary in the top bar.

LDAP | Login Attributes tab - Alice is allowed to access ownCloud
LDAP | Login Attributes tab – Alice is allowed to access ownCloud

Alice is a direct member of the ownCloud group in Active Directory.

Login Attributes - Bob is allowed to access ownCloud
Login Attributes – Bob is allowed to access ownCloud

Bob is an indirect member of the ownCloud group in Active Directory. Bob is a member of the Management group; the Management group is a member of the ownCloud group.

Login Attributes - Charlie is not allowed to access ownCloud
Login Attributes – Charlie is not allowed to access ownCloud

Charlie is not a member of the ownCloud nor the Management group.

Login Attributes - Alice the Other may also log in.
Login Attributes – Alice the Other may also log in.

Just for fun I added Alice the Other (login name alice2) to AD. I made Alice2 a member of both the ownCloud and the Management group just to see what would happen. As it turns out nothing spectacular happened.

Login Attributes - Users can log in with their e-mail address
Login Attributes – Users can log in with their e-mail address

In this setup users can also log in with their e-mail address. Just make sure they have their e-mail addresses filled out in their AD profiles!

Press Continue to go to the Groups tab.

The Groups tab is like the Users tab only for groups: its function is to show Active Directory groups in ownCloud’s User administration page. Its function is not to determine which groups are allowed to log in.

Note that ownCloud’s access to Active Directory is read-only. Anything you change in the ownCloud web interface will NOT be reflected in AD.

If you leave the Groups query empty ownCloud will only recognize its own default admin group and the groups you created in ownCloud itself.

No AD groups in ownCloud
No AD groups in ownCloud

If you enter an LDAP condition in the Groups’ query field ownCloud will show the resulting groups in the Users administrative section. AD groups will work but remember they are read-only, except for changes local to ownCloud. Imagine the mess you’d end up with in complex setups.

By default the group membership will probably not be complete. We’ll fix that when we get to the Advanced tab.

LDAP | Groups tab
LDAP | Groups tab

‘objectClass=group’ (without the quotes) will give you all AD groups. Open up an AD group’s Attribute Editor to find other characteristics to filter on. Look for the GroupType attribute. For example, groupType=-2147483646 will give you all security enabled account groups which is probably more than you want but less of what you do not want than all groups (with ‘objectClass=group’).

LDAP - Set group type
LDAP – Set group type

Ignore the moaning about not being able to connect to LDAP. You and I know better.

To the Advanced tab!

Once you have a working setup under the Server tab the Configuration Active option gets checked automatically. Seems to me that’s exactly what you want.

Connection settings section
While you’re testing set Cache Time-To-Live to 15. This means LDAP query results will get cached for only 15 seconds (the minimum setting advised by ownCloud) and your test results will be current. Once you’re done testing set it to something higher to lighten the load on your domain controller. 3600 seems like a decent value but you should decide for yourself.

LDAP | Advanced | Connection Settings
LDAP | Advanced tab | Connection Settings

Directory settings section
User Display Name Field: This is the name that gets displayed under Full Name in the Users administration section and on the user’s own account top right next to their avatar. I suggest using displayName as value because that’s what it’s for.

LDAP | Advanced | Directory Settings
LDAP | Advanced | Directory Settings

Base User Tree: the OU that spans all users who should be able to log into ownCloud. You can use more than one OU; this would mostly be useful if you have a large Active Directory forest and/or a slow connection to it so your LDAP queries are expensive in terms of speed. If in doubt just enter the OU we’ve been using all along: CN=Users,DC=testnet,DC=local. You can find it by rightclicking the OU, choosing Properties, Attribute Editor. The value we need is the one from distinguishedName.


Group Display Name Field: the way your groups are represented in ownCloud. I recommend cn.

Base Group Tree: same story as with Base User Tree but for groups.

Group-Member association: member (AD). This is how ownCloud will determine group membership (remember I said we’d get to that?). The default uniqueMember results in the group memberships showing only one group per user. Using ‘member (AD)’ all the users’ groups are recognized and you can work with groups in the Users administration section.

Nested Groups: it would be nice if this checkbox actually represented something. Checking or unchecking it has no effect on AD group membership evaluation. I tend to leave it unchecked.

To my surprise ownCloud 8.2.0 filled out the values on this form automatically. It left the Group-Member association set on uniqueMember however. In AD users may be members of any number of groups so I suggest selecting ‘member (AD)’ here. I suppose the ‘(AD)’ bit isn’t there for nothing.


Special Attributes section
In the Special Attributes section enter ‘mail’ in the Email Field. Or not. It’s up to you. Since AD is read-only to ownCloud users will be unable to enter their e-mail address in their ownCloud account. You can provide them with the e-mail address stored in their AD user object. They won’t be able to change it but it it’s needed in some places in ownCloud, for example if you’re sharing a file via an e-mail link and want to have a copy of the mail sent to your own address.

LDAP | Advanced | Special Attributes
LDAP | Advanced | Special Attributes

When you’re done click the Test Configuration button to make sure everything works.

We’re almost done; one more tab to go!

There’s one thing we need to change in the Expert tab: the Internal Username Attribute. This is the key who’s value will be used as the user’s Username in the User administration section.

You wouldn’t want Alice Atkins to show up as 363DB987-70EC-405C-9AFD-1EEEAAE1025F , would you?

 Internal Username Attribute - Unreadable names by default
Internal Username Attribute – Unreadable names by default

Congratulations; you are now an LDAP expert!

Set Internal Username Attribute to sAMAccountName
Set Internal Username Attribute to sAMAccountName

In the Internal Username Attribute field type sAMAccountName and then click the Clear Username-LDAP User Mapping button. WARNING: ONLY DO THIS **BEFORE** TAKING THE MACHINE INTO PRODUCTION. Read the tekst above the Clear button.

Internal Username Attribute - readable usernames
Internal Username Attribute – readable usernames

You’re done! Press Contol+Shift+N in your browser to start an incognito session or use an other browser to test with various user accounts.

Remember to implement security on your ownCloud server!


  1. geronimo

    Thank you for your post, lots of ideas and explanations!
    I have a problem with email address. All my users are listed, and they can connect without problem. But I don’t find the correct attribution for import from AD for the email. I try, like your example in ‘Special Attributes section’ to write on ‘Email Field’ mail, or email but no change. Any idea?

    • Kapitein Vorkbaard

      In Active Directory Users and Computers open a user’s properties. On the General tab you see an ‘E-mail’ field. This is the field that represents the ‘mail’ attribute of the LDAP object which is the user. On the Attribute Editor tab you will find that this is the ‘mail’ attribute. (If you do not see the Attribute Editor, in AD Users and Computers open the View menu and enable Advanced Features.)

      So I think you need to enter the users’ e-mail addresses in their AD accounts by filling out the E-mail field on their AD properties.

      Hope that helps. If not just let me know :)

  2. Saulo

    Dear Kapiten Volkbaard,
    I hope you are doing well.

    I’ve been trying to get this to work since your previous article on the matter. I feel a bit odd of throwing this over the fence.

    So at the time of your previous article, I still didn’t manage to get LDAP integrate. My users populated but I’d never get the authentication to work. But, at the time, I was running owncloud under Windows and I thought of trying again only after migrating to Linux.

    So now I have 8.1.2 running under Debian 8. My Windows 2012 R2 domain is very simple and runs from my living room. There are only a few test users and no customization whatsoever. LDAP integration works for my AIX 7.1 test machine and also for my FreeNAS box – and it has been working for almost two years.

    When I try to do the initial setup following your steps and test the base DN, I get the correct count of objects (CN=Users,DC=yyy,DC=xxx), but after following your steps, all I get is 0 objects. My hints were:

    “Requested attribute entryuuid not found for cn=saulo paiva,cn=users,dc=yyy,dc=xxx


    “message”:”No DN found for on”
    (The blank was worrying me)

    After no success with Google and long troubleshooting, I managed to get my users populating:

    LDAP query for users: (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=yyy,DC=xxx)
    LDAP query for login attributes: %uid=uid

    But I’d still not be able to log in. At least in the logs I’d see a valid query (without a blank) going to Active Directory. So I swapped my login attribute and username attribute to use ‘mail’.

    And it apparently was doing something. So I decided to go to bed to see what would happen. Today I found an Internal Server Error on screen and here are the logs:

    Error when searching: Can’t contact LDAP server code -1

    Attempt for Paging? 1

    Login failed: ‘’ (Remote IP: ‘

    PDOStatement::execute(): MySQL server has gone away at /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php#91

    PDOStatement::execute(): Error reading result set’s header at /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php#91

    Any ideas?

    • Kapitein Vorkbaard

      Hi Saulo,

      A couple of issues here:
      1 – It looks like you have an error in your LDAP query for users (objectCategory=CN=Person does not look valid), but I could be mistaken.
      2 – The error log at the end of your questions looks like a third party plugin error. Disable the plugin and check again.
      3 – If your login attribute is ‘uid’ then you should use ‘mail’, not ‘uid’ unless your internal AD domain name is ;)

      Good luck troubleshooting and keep us posted :)

      • Saulo

        I’m not experienced with LDAP, so I’m not sure whether I’m write or wrong and the only third party plug in I have enabled is the one enabling LDAP. =)

        Regarding mail, I just made my mail field in my user to be In theory, that’s the one the system is querying.

        I will do more debugging and see what happens. Good idea on reviewing my LDAP query! I will do some research.

        • Saulo

          Hello everybody,
          No success so far. I spent a bit of my December holdays on this. Funny I also use Debian and I can authenticate against AD with my FreeNAS box and my AIX box. Oh… =((

  3. Steve

    This was a great run though – thanks! Unfortunately I just can’t get any AD user to log in :(
    1) OC reports that the LDAP config is ok (nice green circle)
    2) Under the Users tab “Verify settings and count users” returns 3 (this is correct – I have 3 test users in my owncloud group)
    3) Under login attributes I can enter a user’s ID, click verify settings and OC displays “User found and settings verified”
    4) There are no errors reported in the log file

    … but it keeps saying “Wrong password” whenever I try and log in :(

    I’ve tried different accounts in AD and even reset passwords just to make 100% sure but still no joy.

    NB. I’m using AD’s “User logon name” to log in but have also tried the Display Name (just in case!)

    Do you have any idea what could be going wrong?

Comments are closed.

Back to Top