Steps to reproduce
1.Move Active Directory OU (containing the User account for owncloud) to a new OU
2.Change the pointer to the new location
3.usernames are now "A363A5EC-FBDB-40D5-BF7D-5812851BC2AF"
Expected behaviour
that user names should be as they appear in AD
Actual behaviour
As above. But again... I think I broke it
Server configuration
Operating system:
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64
Web server:
Server version: Apache/2.4.25 (Debian)
Server built: 2017-09-19T18:58:57
Server's Module Magic Number: 20120211:68
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
Database:
10.1.26-MariaDB-0+deb9u1
PHP version:
PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
ownCloud version: (see ownCloud admin page)
10.0.3 (stable)
Updated from an older ownCloud or fresh install:
Fresh install
Where did you install ownCloud from:
Offical Repositories
Signing status (ownCloud 9.0 and above):
Not sure
Login as admin user into your ownCloud and access
http://example.com/index.php/settings/integrity/failed
paste the results into https://gist.github.com/ and puth the link here.
```https://gist.github.com/anonymous/c351405b2166849957c47d14dcc1f878
**The content of config/config.php:**
```
Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.
or
If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder
*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.
```https://gist.github.com/anonymous/cdbab6ee3978c19ba503fedacfb58001
**List of activated apps:**
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "app:list" is not defined.
Did you mean this?
app:check-code
.... Not sure what to there
```
If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.
```
**Are you using external storage, if yes which one:** local/smb/sftp/...
Tried to get that working but have had no success
**Are you using encryption:** yes/no
no
**Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/...
yes
#### LDAP configuration (delete this part if not used)
```
With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder
Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';
Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.
```
### Client configuration
**Browser:**
**Operating system:**
### Logs
#### Web server error log
```
Insert your webserver log here
```Not sure how to get this
#### ownCloud log (data/owncloud.log)
```
Insert your ownCloud log here
```Again .. sorry for being new at this
#### Browser log
```
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...I hope most of that was useful.
I did Google this a bit before posting here. I noted that this was an issue back in the 5.x.x days, and many people suggested to change the "Internal Username Attribute" but since this was working just fine until I broke it... I don't want to make any more changes.
Worse yet, I was just starting to use the desktop client and when it could not log in, it created a new account and duplicated all of my files, and since the accounts are referencing AD, there does not appear to be a way to 'delete' them.
So since I am not in production yet, and still testing... I have some suggestions (just don't know how) to fix this:
1. Delete the accounts on the server, recreated the LDAP User Authentication for fresh accounts
2. Fix the user names and deleted the second accounts (have already backed up my data on a different source)
3. Rebuild the whole thing from scratch <---not my first pick
Oh, and before you ask, no I am not an advanced linux/debian user, so I was still trying to figure out how to get backups working ... So I don have one yet
Hope I have provided enough information so that I can get this fixed. Thanks for any help in advance!
-Charles