As you may know, the LDAP backend in ownCloud 5 got a couple of new features and some changes under the hood (see point 3 on ownCloud 5 released, Google Reader Alternative). Seven maintenance releases later, some bugs have been smashed, but an irksome quirk is left.

A newly introduced behaviour in creating the ownCloud username may be unwanted in the way the default is. Back in ownCloud 4.5, there were just usernames that were used to display and to identify users. In the LDAP backend we make sure that no concflicts with usernames appear in order to avoid same usernames between LDAP users, local users and other possible backends. Having the same username would make files and data availablle for all of them.

Generating (internal) Usernames

In onwCloud < 5 the username was restricted to basic ASCII chars. Our approach in the LDAP backend was to create the username from the value of the attribute given in the "User Display Name Field". Special characters were replaced were possible, or omitted. On collisions, the DN was addded in a almost readable manner. The username is stored in a database table and assigned to a reliable LDAP identifier to find him again.

In ownCloud 5.0 Display Names were introduced. The internal username (shown as Login Name on the Users page, a bit misleading) is still the same, but now there is support for a fancy name per user and without character limitations. With the LDAP backend, we made use of it and did the following: because the internal username was not visible for the User anymore, the internal ownCloud name will be generated from the UUID now. This avoids sanitation and is already practicably unqiue. The ownCloud display name is exactly what the value of the attribute specified as "User Display Name Field" retrieves.

From Undesirable Side Effects…

This decision (made close to Feature Freeze) had some effects:

1. The user directory in ownCloud is named after the internal username (if not specified differently in "User Home Folder Naming Rule")
2. All the *DAV URLs contain the internal username in the path.
3. The Ampache server (Media Player) also expects the internal username for login as it does the authentication on its own

Reactions after the release made us aware that often the login name and "User Display Name Field" were the same in the "old days of ownCloud 4.5", leading to undesired behaviour. Issue #1 is acutally not much of a problem and can be fixed with the settings option mentioned above. Issue #2 and #3 (special in it's own way) could not be circumvented. Until 5.0.7.

… To More Flexibility

With ownCloud 5.0.7 we introduce a new tab in the ownCloud settings called "Expert". The attribute used for creating the internal username can be customized there, so that it matches with the uid (or whichever attribute you prefer) again. Please note that it does not have effect on existing users, because there is no rename mechanism in ownCloud. You should ensure that those values are unique, because on naming collisions a username in the pattern of attributevalue_1234 (random number) will be created instead.

Another option is to specify the UUID attribute. Actually, the default behaviour is identical to what we did in ownCloud 4.5. Since uids, cn or DNs may change, we need a permanent value to recognize LDAP users. We need to be able to reliably map the internal ownCloud username to an LDAP representation. You can override this behaviour, too. Note: this will not have immediate effect on existing users, but can cause trouble when a user DN changes. Do not use it after putting your ownCloud in production use.

Furthermore mapping tables can be deleted. The mapping tables associate the internal ownCloud username with the LDAP user representation. You do not want to click on them on a production server! More information provides the LDAP Backend Documentation Page

The Missing Icing On The Cake

For existing users there is not much to gain, unfortunately. What you can do there is to change the owncloud_name in the oc_ldap_user_mapping table as well as in database columns where the username is used (for instance 'share_with' and 'uid_owner' in oc_share and more depending on the apps in use). This is scriptable. Also scriptable is to update the UUID values from the current to the desired attribute. However, the scripts (or as improvements to the backend) need to be done first.