Federated ID with LDAP

Server
, , ,
1

Hi everybody, I'm having a problem with my owncloud server.
This is my situation, I have two owncloud servers in two different branch offices.
The two server heve LDAP bind with two different Active Directory domains.
Everything works grate except for the federation sharing.
When someone tries to share something from one owncloud server to the other
the share works perfectly but the users are shown with their Federated ID, that is created (in case of LDAP bind)
using the UUID of the user and the FQDN of the server.
I agree with your choice to use UUID to identify users, but in my opinion it should never been displayed.
The most annoying problem that comes to this is that users doesn't recognize who are sharing with,
and it makes the feature almost unusable.

P.S.: I know I'm not using the newest version of ownclod but I've checked the changelog and didn't see anything about this problem so I prefer not to upgrade without being sure it fix the problem. Thank you in advance

Steps to reproduce

  1. Setup two different owncloud server
  2. Setup the bind with two different Active Directory domains
  3. Share a file between a user of one server to an LDAP user of the other
  4. You'll see in the list of user the federated id that is not understandable by the users

Expected behaviour

I expect owncloud server to use the federated ID to share the file and translate it with the Displayed Name in the web UI

Actual behaviour

Now owncloud display the federated ID in the UI

Server configuration

CentOS Linux release 7.3.1611 (Core)

Web server:
Apache/2.4.6 (CentOS)

Database:
5.5.52-MariaDB

PHP version:
PHP 5.6.30

ownCloud version: (see ownCloud admin page)
version "9.1.3.1"

Updated from an older ownCloud or fresh install:
Fresh install

Where did you install ownCloud from:
Installed from EPEL Repository

2

you could add a trusted federated server in both servers, and they could find the other users.

I checked with 10.0.7 and show me the users. Probably you have to check that version.

3

Hi @cdamken and thank you for the reply

What do you mean with trusted federated?
Do I need another server to federate them both?
They are alrady federated with eachother.
Just to be sure, are you in the same condition of me?
I have owncloud-server1 binded with active-directory1
and
owncloud-server2 binded with active-directory2.
When a user of owncloud-server1 shares a file with a user of the second server
he types the name and the display-name appear correct, but when he clicks on it and share the file
in the shared properties appear with the UUID

4

Just to explain better what appens:
When you type the name of the federate user it's shown like this

6

But once you shared it becomes like thist

7

I think this link will help you to understand the federated shares I'm asking:
https://doc.owncloud.com/server/10.0/admin_manual/configuration/files/federated_cloud_sharing_configuration.html

8

I have read this link, it's the one I used when I created the federation.
I followed all the tutorial and used the "user share" to create the federation.
My connection between the two server is green

Indeed the sharing is working as described, the problem is that when owncloud creates LDAP users from Active Directory
uses the UUID as UserName.
So when the share is created (as you can see in my previous comment) you will see UUID@https://owncloud.url
That is exactly what happens in the tutorial: username@https://owncloud.url

9

when you configured the LDAP, I suppose you left the attributes empty in the expert tab?

That means the user is with UUID configures as name and as Attribute.

If you are already in production: DON'T CHANGE IT!, it will break everything.

Which parameters do you have in your configuration from LDAP?

10

You are right, the attributes tab in the expert tab are empty.
We didn't figured out it could have been useful until we sow the problem of this topic.
it would have been better to use SamAccountName or something similar but, unfortunatelly,
the server has been in production for some time.

Anyway, in my opinion there is a problem with owncloud account management.
I mean, owncloud uses UserName field as the unique ID, so in middle/big companies,
it is a good practice not to use the name of the colleague or somthing similar,
because if the colleague leaves or is fired or is moved in another company of the group it's
impossible to rename the account.
(it's even more important when someone get's married and the name change)
So in my opinion it's important to have a unique ID loose from the physical person.
(I've read some other topics on this forum where owncloud staff said the same)
The problem is that (always in my opinion) the user IDs should never be displayed to the final user.
So, as I said when I opened the topic, owncloud should retrieve the DisplayName from the federated server
and use it on the UI instead of using the UserName

11

Did you try to syncronize the address books?

occ dav:sync-system-addressbook
occ federation:sync-addressbooks

Adding in the cron job is faster (as example):

11 0 * * * /usr/bin/php -f /var/www/owncloud/occ dav:sync-system-addressbook
16 0 * * * /usr/bin/php -f /var/www/owncloud/occ federation:sync-addressbooks
12

This gave me some hope but unfortunatelly nothing changed.
Do I have to restart any service after run those commands?
(I run them in both servers)

13

It would be good if you create an issue in https://github.com/owncloud/core/issues

I think for now the behavior works as designed because you selected UUIDs as default, but probably could be an improvement to add the different user options to the search with the name instead.