nextcloud
[Bug]: Win/iOS Client syncs SMB-Share with option “Log-in credentials, save in session”
⚠️ This issue respects the following points: ⚠️
- [X] This is a bug, not a question or a configuration/webserver/proxy issue.
- [X] This issue is not already reported on Github (I've searched it).
- [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
- [X] I agree to follow Nextcloud's Code of Conduct.
Bug description
My Nextcloud: Version 24.0.4 User auth over LDAP/MS-AD Access over NGINX reverse proxy (User-->NGINX: https/letsencrypt, NGINX-->Nextcloud: http)
I added a SMB-share to my nextcloud and used the option “Log-in credentials, save in session” for credentials. The documentation says: "The Log-in credentials, save in session mechanism uses the Nextcloud login credentials of the user to connect to the storage. These are not stored anywhere on the server, but rather in the user session, giving increased security." and "Desktop and mobile clients that use tokens to authenticate can not access those shares"
This is exactly what I want, I don't want to store credentials of users permanently on my server.
But I noticed, as soon as I added the external storage, my Nextcloud Windows client started to sync the whole smb-share. I also have access to my smb-share over my Nextcloud-iOS-App. Both apps, Windows and iOS, use token authentification as far as I can tell. How is it possible that my apps can access my smb share? Where are the credentials stored (I guess they must be stored somewhere, because otherwise the apps would have no access?)
Here someone else experienced the same problem, but no one could help https://help.nextcloud.com/t/external-storage-credentials-save-in-session-and-desktop-sync-how-does-this-work/92602/2
Steps to reproduce
- add external SMB storage with option “Log-in credentials, save in session” 2a. connect iOS app with token/QR-code 2b. access SMB share over iOS app 3a. alternatively, connect Windows desktop app with token 3b. access SMB share over windows app
Expected behavior
Expected behavior as described in official documentation: "Desktop and mobile clients that use tokens to authenticate can not access those shares"
Installation method
Community Manual installation with Archive
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
- [X] Default user-backend (database)
- [X] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Configuration report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"localhost",
"CENSORED"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "24.0.4.1",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"loglevel": 2,
"default_phone_region": "DE",
"trusted_proxies": "***REMOVED SENSITIVE VALUE***",
"overwritehost": "CENSORED",
"overwrite.cli.url": "CENSORED",
"overwriteprotocol": "https",
"forcessl": true,
"overwritewebroot": "\/",
"overwritecondaddr": "^10\\.43\\.43\\.100$",
"htaccess.RewriteBase": "\/",
"memcache.local": "\\OC\\Memcache\\APCu",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtpsecure": "tls",
"mail_smtpauth": 1,
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "587",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"maintenance": false,
"theme": "",
"default_language": "de",
"default_locale": "de_DE",
"defaultapp": "files",
"knowledgebaseenabled": false,
"allow_user_to_change_display_name": false,
"remember_login_cookie_lifetime": 2592000,
"session_lifetime": 172800,
"session_relaxed_expiry": true,
"auth.webauthn.enabled": false,
"skeletondirectory": "\/var\/www\/nextcloud\/core\/skeleton_new",
"lost_password_link": "mailto:CENSORED",
"trashbin_retention_obligation": "30,30",
"ldapUserCleanupInterval": 16,
"sort_groups_by_name": true,
"profile.enabled": false
}
}
List of activated Apps
Enabled:
- activity: 2.16.0
- admin_audit: 1.14.0
- bruteforcesettings: 2.4.0
- cloud_federation_api: 1.7.0
- comments: 1.14.0
- dav: 1.22.0
- federatedfilesharing: 1.14.0
- files: 1.19.0
- files_external: 1.16.1
- files_pdfviewer: 2.5.0
- files_rightclick: 1.3.0
- files_sharing: 1.16.2
- files_trashbin: 1.14.0
- files_videoplayer: 1.13.0
- logreader: 2.9.0
- lookup_server_connector: 1.12.0
- notifications: 2.12.0
- oauth2: 1.12.0
- password_policy: 1.14.0
- provisioning_api: 1.14.0
- quota_warning: 1.14.0
- serverinfo: 1.14.0
- settings: 1.6.0
- systemtags: 1.14.0
- tasks: 0.14.4
- text: 3.5.1
- theming: 1.15.0
- twofactor_backupcodes: 1.13.0
- updatenotification: 1.14.0
- user_ldap: 1.14.1
- viewer: 1.8.0
- workflowengine: 2.6.0
Disabled:
- accessibility: 1.8.0
- circles: 24.0.1
- contactsinteraction: 1.5.0
- dashboard: 7.2.0
- encryption
- federation: 1.12.0
- files_versions: 1.17.0
- firstrunwizard: 2.11.0
- nextcloud_announcements: 1.11.0
- photos: 1.6.0
- privacy: 1.8.0
- recommendations: 1.3.0
- sharebymail: 1.14.0
- support: 1.5.0
- survey_client: 1.10.0
- user_status: 1.2.0
- weather_status: 1.2.0
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
No response
Additional info
No response
Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
Problem/behavior is still the same on 25.0.3
Share is set up like this:
Windows- and iPhone-Client are connected with device password, they don't know my LDAP-login credentials.
Still I can access the SMB-shares with mit iPhone- and my WIndows-Nextcloud-client.
I still don't know why this is possible, documentation says: "Desktop and mobile clients that use tokens to authenticate can not access those shares"
Today I synced this external share with nextclouds official client on macOS. The sync client is connected with device password, it does not know the LDAP credentials. On first try, the sync did not succeed. There was an error message saying that I try to sync an external mounted storage (which is correct, that's exactly what I did) and that this is not possible. But on second try, after un-checking the external folder and checking it again, the client started to sync the external storage.
I still wonder why this is possible and if user credentials are somewhere stored on the nextcloud server even if I use “Log-in credentials, save in session” for mounting external storage. I really don't want that my nextcloud server knows the LDAP credentials of all my users.
Is there any update to this? Latest documentation https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage/auth_mechanisms.html still says
The Log-in credentials, save in session mechanism uses the Nextcloud login credentials of the user to connect to the storage. These are not stored anywhere on the server, but rather in the user session, giving increased security. This method has some important drawbacks, since Nextcloud has no access to the storage credentials and therefore cannot perform any background tasks on the storage: (...) Desktop and mobile clients that use tokens to authenticate can not access those shares
I think the docs need some updating and clarity here, at a minimum. That line was added as a result of a discussion in #19561 but I'm not sure it was accurate after #2044. I'm not going to have time to look at this any time soon, but noting for the future.
