You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Configure storage with SMB personal to only be available for certain AD groups
Verify when use logs in that the share is showing available in All Files
Expected behaviour
Have LDAP authenticating correctly in User Authentication and I am mounting using SMB Personal and verifying permissions using AD groups. The expected behavior would be that when a user logs in, if they are apart of the AD group the external share mounts to their all files folder, and if not it doesn’t.
Actual behaviour
Instead the Storage tab will say that the “External mount has been added successfully”, but will not mount to users all files folder. If I remove the AD group in the “Available For” field it will mount correctly in the users all files, but also for everyone else.
Server configuration
Operating system:
Web server:
Database:
PHP version:
ownCloud version: (see ownCloud admin page)
Updated from an older ownCloud or fresh install:
Where did you install ownCloud from:
Signing status (ownCloud 9.0 and above):
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.
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.
List of activated apps:
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/...
Are you using encryption: yes/no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
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
ownCloud log (data/owncloud.log)
Insert your ownCloud log here
Browser log
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...
Notes
By default, LDAP will use the "entryuid" attribute ("objectguid" for AD) as groupname. This happens for new installations.
Updated installations should have the "cn" attribute as groupname for backwards compatibility with previous app versions.
The external storage configuration gets both the configured groupname and displayname for the groups, BUT it sends only the displayname when the data is saved. This means that the displayname is saved as applicable.
We consider whatever is saved as groupname in order to search it in the LDAP server. Of course, we can't find the displayname as groupname.
It's possible to setup whatever the displayname attribute is set (usually the "cn") as groupname. That could be a workaround. HOWEVER, the groupname MUST be unique across all the groups in the system. This guarantee might not be possible, it will cause problems if there are name collisions.
In addition, note that changing either the username or groupname fields in the LDAP's expert tab can cause issues once ownCloud starts running, so it isn't recommended.
The text was updated successfully, but these errors were encountered:
Copied from https://central.owncloud.org/t/owncloud-10-13-1-stable-not-mount-external-share-using-ad-group/45615
Steps to reproduce
Expected behaviour
Have LDAP authenticating correctly in User Authentication and I am mounting using SMB Personal and verifying permissions using AD groups. The expected behavior would be that when a user logs in, if they are apart of the AD group the external share mounts to their all files folder, and if not it doesn’t.
Actual behaviour
Instead the Storage tab will say that the “External mount has been added successfully”, but will not mount to users all files folder. If I remove the AD group in the “Available For” field it will mount correctly in the users all files, but also for everyone else.
Server configuration
Operating system:
Web server:
Database:
PHP version:
ownCloud version: (see ownCloud admin page)
Updated from an older ownCloud or fresh install:
Where did you install ownCloud from:
Signing status (ownCloud 9.0 and above):
The content of config/config.php:
List of activated apps:
Are you using external storage, if yes which one: local/smb/sftp/...
Are you using encryption: yes/no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
LDAP configuration (delete this part if not used)
Client configuration
Browser:
Operating system:
Logs
Web server error log
ownCloud log (data/owncloud.log)
Browser log
Notes
It's possible to setup whatever the displayname attribute is set (usually the "cn") as groupname. That could be a workaround. HOWEVER, the groupname MUST be unique across all the groups in the system. This guarantee might not be possible, it will cause problems if there are name collisions.
In addition, note that changing either the username or groupname fields in the LDAP's expert tab can cause issues once ownCloud starts running, so it isn't recommended.
The text was updated successfully, but these errors were encountered: