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.

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
[code]
# tail -f /var/log/owncloud.log
[/code]
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:
[code]
# service apache2 restart
[/code]
…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.

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

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:

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.

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:
[code]
(&(memberOf:1.2.840.113556.1.4.1941:=CN=owncloud,CN=users,DC=testnet,DC=local)(sAMAccountName=%uid))
[/code]

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:

[code]
(&(memberOf:1.2.840.113556.1.4.1941:=CN=owncloud,CN=users,DC=testnet,DC=local)(|(sAMAccountName=%uid)(mail=%uid)))
[/code]

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.

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

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.

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

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.

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.

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.

‘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’).

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.

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.

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.

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?

Congratulations; you are now an LDAP expert!

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.

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!