Hello Everyone,
First of all a big thanks to the Nextcloud Team that Created a fantastic system and a really great alternative to close systems and made it freely available to everyone.
I have a use case scenario may be someone faced before.
Is there a way to force a user to login to a specific device and that specific device only?
I thought of using 2FA, enroll the user and copy the Key into a custom TOTP authentication device (locally installed on the machine) setup with such key “encrypted” (so they could not be copied to other devices without help from admin).
But, 2FA allows users to go into Personal - Security and pretty much change all of the security options, including resetting the 2FA device (or even adding alternative methods).
Is there any way to disable the Personal → Security section for a specific user group?
Users would be authenticated using LDAP (so no need for a user to use the Security Page to reset his password).
Assuming above is possible, is there any way to “batch” enroll users into 2FA (so the Admin can centrally retrieve the 2FA secret keys to be encrypted into the Custom Authenticator and make sure 2FA is massively deployed easily on such devices by pushing each key to each user’s device?
I hope I explained myself correctly and that I am not the only one having this requirement.
I’m not sure what you are trying to achieve. 2FA is part of user authentication process, so in general it should be handled by the user himself. I assume you want to avoid users have multiple 2FA instances - I don’t think there is a good reason e.g. if 2FA is on smartphone the user needs a way to move it to a new device… In case the idea is to prevent access once the user leaves then you should better check how you can disable/remove the user from the database fast enough - once LDAP user has no login right 2FA becomes useless… AFAIK there is no way to stop already active sessions - depending on you data protection directives “impersonate” app would allow the admin to login as such user and disconnect all running sessions if this is important enough.
@alessandrodimarco
I think you have not understand 2FA. 2FA is a security feature for the user. The user could also simply give the password and the 2FA device to a third party. Also, the user could share all files with the Internet or if sharing is not allowed (because of security reason) put them somewhere on the Internet. You can not prevent this. Perhaps the greater risk is if the user disables 2FA altogether. Maybe you can search the database for user with not 2FA enabled. But also that makes less sense. Write a guideline and hopefully all users will follow it or fire them.
If the users only use Nextcloud clients (Windows, MacOS, Linux, Android, iOS) and not the web gui, you could finish configuring the client (login with username/password) and then change the password (without telling the user) The clients do not use the password. Unfortunately, I don’t know if at some point the password will be needed again on the clients. Advantage is that you also do not need a 2FA and the connection to your LDAP server.
What I am trying to achieve is the following (I hope below is clearer)
Prevent user to login to Nextcloud from any device except ONE and do not allow user to bypass the setup.
2FA could be a potential solution for the above.
You are correct when you said the idea was to quickly disable users that “leave” (we do that already) but in this case we are talking about a “shared” account for people on “rotation”.
When guy on rotation 1 goes home he should lose the ability to login and vice versa.
Cannot have individual accounts due to the sheer number of people on rotation pool.
That is why the idea of using 2FA so that you need to use the “Token” stored, hidden and encrypted inside the device where Nextcloud is setup (using the help of a custom authenticator).
devnull,
I do know what 2FA is, but I want to limit the number of “devices” the user “HAS” to ONE and I want to control centrally which device it is (and I don’t want end users to change that).
I hope the above explanation is easier to understand otherwise check my answer to wwe, may be that will be clearer.
As for your proposal:
Same LDAP account is shared among several users in “Rotation”
(so your solution would not work).
They need this to login to the assigned device (a windows machine) or log on to other systems using LDAP (plus they use the web gui).
In Nextcloud you can force 2FA on specific groups so the risk you mention should not exist
but of course having the ability to deactivate Personal-> Security is always good to have (which is one of the items I was looking for).
I am looking at 2 other potential solutions
Identity Portal (outside of Nextcloud based on “Physical” Tokens).
Fork the code with Custom CSS to collapse/hide the personal security settings and a PHP shell file to cycle through public function createSecret(IUser $user) in the totp library of the 2FA app to batch create secrets in background and pass them over to a custom authenticator setup locally on those devices.
The second one is a lot of work so I was hoping that there was something baked in already.
@alessandrodimarco
Thank you for the detailed answer. But my idea was a little different.
All people get only one device (Windows, macOS, Linux, iOS, Android) where Nextcloud app is configured with Nextcloud address, Nextcloud shared user (e.g. name “rotation”). Only for installation/configuration a password is temporarily used (or assigned) and then changed again from admin. The user does not know the password (highest during configuration) . This can be repeated (in my opinion) for any number of people/devices. This has nothing to do with LDAP. The user “rotation” has got no LDAP account.
The disadvantage is that the user - if he/she has the device - he/she can access the Nextcloud account. For more security in case of loss, force a user login to the operating system (Windows ) or a screen lock (Windows, iOS, Android). A really security risk is web access to Nextcloud (not possible with unknown password) in this setting.
The disadvantage of your 2FA idea is that as far as I know 2FA can only be used for web access and not Nextcloud clients. You don’t want that, do you?
Additional information
I have thought about it again. You can also create an app password for a Nextcloud client at https://cloud.server.tld/settings/user/security and either scan the QR code with the device or enter it manually. Then you don’t need to change the password at all.
Sorry for my complicated instructions above. With app password it is actually much easier.
was my idea as well - but the drawback is the admin needs to create/approve/revoke every session. Maybe 2FA using hardware token (e.g. FIDO2) goes into right direction - such tokens are easy to use and if you register only few access to the system is physically limited, without additional interaction with “admin”. “Inside” attack vectors still exist - e.g. if the user register another 2nd factor device he can carry home…
maybe it better to build your scenario around the client device - e.g. login to the shared client is performed by an admin (additionally protected with 2FA to prevent external access by changing password), so the shift personnel has no knowledge about credentials and “just works”. Terminals logged into the system stay in your location, access to the system limited to this devices.
That’s not possible when using TOTP, because of how TOTP works.
Sorry but account sharing is bad practice and should never be done. Create one account for each user, even if this person only needs to do something with that account once a year for 5 minutes. If you want to share data between these users, you can use the app Groupfolders, and put all these users in one group. If you don’t want them to be able to store files, limit the storage for these accounts to 0 MB.
No it could not. It’s the wrong tool for the job.
Sorry if that comes across as a bit harsh. But 2FA, no matter what method, is simply not suitable for what you are trying to do, and you shouldn’t do it that way in the first place anyway.
Do it the way I explained in the first section of this post and enforce a specific 2FA method in order to keep the accounts safe, but you cannot use 2FA devices for managing access to user accounts, because that’s not what 2FA was designed for.
Thanks everyone for the Valuable feedback.
The suggested approaches are still too manual for my Lazy character
We managed to hide the Security 2FA portion by commenting out most of the PHP Code in
/var/www/nextcloud/apps/settings/templates/settings/personal/security/twofactor.php
That solved the issue of having users potentially changing what’s set centrally and it’s more secure than hiding the section with custom css.
So now, it seems we have to roll up our sleeves and create some function that cycles through users and populates oc_twofactor_providers and oc_twofactor_totp_secrets for LDAP users that don’t have an entry there and pass this to the configuration file of a custom totp we can push to individual machines.
That way, we don’t need to ship Physical Tokens and since we have an agent on each machine to automatically deploy software, we can push the configuration around automatically too.
In theory it does not even have to be “custom” for each device and we can just check current logged Windows LDAP user and Hash match the secret it to an encrypted table of users/secrets to display the correct TOTP Validation Code.
Sorry but account sharing is bad practice and should never be done. Create one account for each user, even if he or she only needs to do something with that account once a month for 5 minutes. If you want to share data between these users, you can use the app Groupfolders, and put all these users in one group. If you don’t want them to be able to store files, limit the storage for these accounts to O MB.
Understood and agreed in principle. Unfortunately following the book at the letter is not always possible. Imagine a site with 10 people x position and 30 to 45 positions.
That’s 450 individual accounts. Now multiply this by 10. That’s 4500 accounts.
Now add turnover of people moving between sites (requiring different access) or people coming and leaving the company at relatively high frequency (due to sites been “mobile” and going from West Africa to South East Asia).
You can understand from above, that having individual accounts is “Canon” but a nightmare to manage in this situation.
As make use of TOTP to restrict access to a single device, it is possible indeed as long as you have an option to HIDE the secret / QR Code from the end user. He can use the one registered on the token / desktop but he can’t register another device.
This is what I am about to be doing now since it looks like there’s nothing baked in.
I doubt that you need 4500 accounts. You could have 450 Users in 10 Groups and then move them arround between these groups as needed. Moving around physical 2FA devices seems more tedious to me.
I doubt that you need 4500 accounts. You could have 450 Users and 10 Groups and then move arround the users between these groups as needed. Moving around physical 2FA devices seems more tedious to me.
Not moving any physical 2FA device. The idea is to create a custom “software” TOTP authenticator that contains an encrypted table of “users/secrets”. When a user opens the custom TOTP, it will check the current windows logged user and fetch/decrypt the correct secret from the table and display the correct activation code for that user.
The number of users is real. I either use a named user or a “role” user. With named users in our scenario it would involve continuous alteration of access rights x user. Instead of that I keep a bunch of static “role” users that don’t need AD Role changes and control access to Nextcloud via 2FA. A user goes home? He can no longer login as he loses access to the device.
At some point I was thinking using Geolocking too.
Remember that users have other items at play (Email for example) and having individual account would make migrating Email done in each rotation back and forth between users in the same group (or you would need to have distribution groups in Exchange to push emails to all those accounts massively duplicating storage and cost). I can’t go with named accounts.
Sure he can, he can add another device when he is logged in.
Also you would have to log into the account and change the 2FA secret every time you pass the account to another person, otherwise you would have to rotate the physical devices where the 2FA app is installed. Btw. most TOTP apps like andOTP or Aegis can backup and export the TOTP secrets and even display them on the screen as text or as a QR code.
no it doesn’t - given the fact the system allows external access user could pass valid TOTP code outside and register his own device using valid TOTP code. Using FIDO2 key and “device login” can limit new logins to the owner of the key (further enhancing security as no password is involved).
both sounds very failure-prone and definitely not future-proof - potentially you have to review and adopt your solution with every system upgrade. this is definitely lot of work - doesn’t sound very lazy to me
I don’t get the math… and you have major logic fault - there is no need to create an account for every position the person could hold - you only need one account per person and change access rights on demand (e.g. via group membership).
you have some HR process which manages physical site access - it’s not hard to attach some user management (through occ or API) to create/change users account. Which would be more stable in my eyes and keep working throughout updates.
That’s what group mailboxes are for. If your mail provider doesn’t support that, you probably have to upgrade to a suitable solution. Not sure how well such a solution would interact with Nextcloud though…
no it doesn’t - given the fact the system allows external access user could pass valid TOTP code outside and register his own device using valid TOTP code. Using FIDO2 key and “device login” can limit new logins to the owner of the key (further enhancing security as no password is involved).
I think we missed the point that the “Secret” would be hidden from the user and only the TOTP validation code will be shared (like 123456). No QR code or secret must be visible (that’s why I needed to hide the Personal->Security Page at least for TOTP.
both sounds very failure-prone and definitely not future-proof - potentially you have to review and adopt your solution with every system upgrade. this is definitely lot of work - doesn’t sound very lazy to me
Yeah you are correct both on the system upgrade and the non lazy (at the beginning). But then it would run completely automatic (that’s the lazy part )
I don’t get the math… and you have major logic fault - there is no need to create an account for every position the person could hold - you only need one account per person and change access rights on demand (e.g. via group membership).
you have some HR process which manages physical site access - it’s not hard to attach some user management (through occ or API) to create/change users account. Which would be more stable in my eyes and keep working throughout updates.
Okay, say I have an Equipment Supervisor. I can either do a “SITE.ES” user or a bunch of “first.name.lastname” and link them all to the same group access. Now I have to keep deactivating those users every single time they go home (that happens every 28 days but not always). I hope the math makes more sense now
You can’t get the secret from the the Personal->Security Page after the device/app was added. You can only remove and add the device again, and you can of course add more devices. But even more important is, that you can get the secret on the device itself if you are using an app like andOTP.
That’s what group mailboxes are for. If your mail provider doesn’t support that, you probably have to upgrade to a suitable solution. Not sure how well such a solution would interact with Nextcloud though…
haha yes, but Group Mailboxes are not exactly the same as user mailboxes (for one they can’t have subfolders). You could use Shared Mailboxes but there are other considerations there (cost for example where I now use a Device CAL I would need several Users CAL with named accounts) without going too much OT, there are many reasons why we ended up with “role” based accounts although I do understand it’s not falling in the perfect world in terms of “security”.
You can’t get the secret from the the Personal->Security Page after the device/app was added. You can only remove and add the device again, and you can of course add more devices. But even more important is, that you can get the secret on the device itself if you are using an app like andOTP.
That’s why I was talking about using a custom TOTP application.
A TOTP that does not show secrets (keeping them encrypted inside its own database).
That probably takes about a day to build.
Without any place to show a QR code and with a pre-configured TOTP setup on each machine (which would be the only TOTP that can display the Security Code as it’s the only one containing the encrypted secret key the problem of sharing secrets is removed).
The custom TOTP would come with a small file that would be an export of the oc_twofactor_totp_secrets table (that can be generated by scheduling an sql).
We have done something similar to Audit Users that left the Company leaving behind potentially dangerous Public Shared Links (intentionally or not). We export those in excel, CURL it back into Nextcloud and mail the report automatically if we forget to remove them /re-assign them when we deactivate him in AD.
The clients do not use the password. Unfortunately, I don’t know if at some point the password will be needed again on the clients. Advantage is that you also do not need a 2FA and the connection to your LDAP server. 