[User Management] Disable a User

[LukasReschke]

As an admin, I want to be able to disable a user in ownCloud, so that this user can no longer access ownCloud. Later, I may want to enable the user, or delete the user, depending on the situation.

Acceptance Criteria: When you have a user and hit the x button, the system asks if you want to 1) disable or 2) delete the user, with a check box to add that their data should also be permanently deleted. Local and external auth (LDAP / AD / SAML, etc) users can be disabled

Remarks by Engineering: Depends upon https://github.com/owncloud/core/issues/12593

[LukasReschke]

@MorrisJobke @craigpg FYI

[disy-mk]

As this seems to be work in progress already it might not be too late to add that it would be at least as useful as to be able to do the same with groups.

I.e., i have a group of >50 users. Back then, when the group was smaller (~6), I changed the pw for every user/login, so data won't get changed, while investigating some issue. Currently I'm in the exact same situation but would have to change more than 50 passwords and afterwards revert the changes, which is very prone to failure.

Of course after the first time changing and reverting passwords I created sql queries to change and revert the passwords. This still is not only inconvenient - it also does not instantly apply its purpose, as the users still have a working auth session. So I additionally have to restart the webserver to ensure everybody is "locked out".

Really would appreciate to be able to use this feature.

[DeepDiver1975]

well - your situation can be best handled with the single-user-mode which can be set via the console

https://github.com/owncloud/documentation/blob/master/admin_manual/configuration/occ_command.rst#maintenance-commands

[disy-mk]

well - your situation can be best handled with the single-user-mode which can be set via the console

https://github.com/owncloud/documentation/blob/master/admin_manual/configuration/occ_command.rst#maintenance-commands

Thank you very much for pointing that out. In my special case this will kind of work for me.

For every client I have an account (company users) which is used for calendar sync only. I - in addition - have another account, which contains all shared client's calendars (company admin). In my specific case I want to prevent the clients from logging in. Well, to be honest , I could change the password for the master account, add this account to the admin group and then use it for what I intend to do. This indeed would work for the case that I have a single instance for that company. In this case this really holds true. But I also have other instances that are shared by different companies. As sharing is disabled, this setup works for me and keeps maintenance lower than having a single instance for every company. In that different case, your solution would not be very nice to the clients which are not affected by a certain problem. Hence, extending the proposed feature to also be applicable for single groups, would be very nice.

[progfou]

Thinking about having removed a user without removing its data, how would you manage that after then? One would probably need a way to access this “orphaned data”, either to remove it or to re-attribute it to another account to manage… (just some thoughts about real life problems ;-) )

[slonkak]

I am highly disappointed that this seemingly basic feature has been pushed to the backlog to be forgotten about. Every single enterprise system or software package that offers user accounts offers a way to disable those user accounts. My company has been waiting for this feature for months/years. If Microsoft, of all companies, can let you disable users you'd think the swift development of OSS could do the same.

[LukasReschke]

If Microsoft, of all companies, can let you disable users you'd think the swift development of OSS could do the same.

You're welcome to contribute this feature swiftly. Thanks :smile:

[slonkak]

I would love to contribute this feature, however the almighty ownCloud gods are working their black magic. Maybe some other eyes can see what I can't.

I edited the user array that gets sent to the template that displays the whole user list when logged in as admin so it contains a new element, uidEnabled. The backend code for disabling a user is already there, you just need a row in oc_preferences for uid,core,enabled,false. That works if manually entered, my account can no longer login.

My problems start when attempting to use that field in the template. I verified that in the template (settings/templates/users/part.userlist.php) it can see my new field. I printed it to a file to ensure that for my account core,enabled->false. It's there. What I'm attempting to do is put a checkbox to the left of each user that is checked if the account is enabled (core,enabled->true, which is the default return from the getValue function because ownCloud doesn't put the core,enabled->true db row for any users) and unchecked when the account is disabled (core,enabled->false).

The black magic is that the foreach loop that supposedly goes through all users to produce the list on the screen seems to jump around. It always showed my account as being enabled even though it's not. Here is what my list looks like now (just for my user):

When I saw that the checkbox was checked and it shouldn't be, I manually printed out $user["displayName"] to make sure it was working on my user (which, if the foreach was acting the way it should the $user array shouldn't have access to any other info at that point). Instead of printing my displayName, it printed "admin". This is also confirmed by looking at the HTML. Each TR should be labelled with the user account shown in that row, however for me I'm seeing "admin" as the user for about half of the rows.

You can see that the TR has admin's displayName and not mine like it should.

My initial assumption is that whatever AJAX is building the screen is breaking this, but at this point I'm not sure. I'm just annoyed.

[cdamken]

@MorrisJobke

00003501

[bboule]

@MTRichards seems like a feature request, @cdamken it would appear you have rec this request from an EE user can you please be sure this in in SFDC as a feature request for @MTRichards to review

[MTRichards]

This has been out there for a long time, so it is a good idea to finally implement it. Will consider it for 9.1 if we have demand. That, and we have 2 years of interest and related issues.

[michel-thomas]

Hello, this feature interest me a lot. Would be great if implemented. Thanks a lot.

[boltronics]

There is demand. I demand it. :)

Use case: Once or twice people have left my workplace without much notice, but possibly have a bunch of important files shared from their account which could be in use by someone else. Ideally I should just be able to disable the user account so files shared from that account aren't immediately deleted as well (which might cause an unpleasant surprise for somebody).

Bonus points for providing the option to disable/enable file sharing on disabled accounts. That way I could disable the account and sharing at the same time. If somebody complains files are missing, I can re-activate sharing without re-reactivating the account and have someone else copy (and optionally re-share) any useful files so nothing of importance is lost. I would then re-disable sharing again, and (after an arbitrary period of time) safely delete the account.

[cdamken]

@bboule my FR is about 6 months old.

A good example is how to administrate some users that works in the ownCloud platform during a project and you know that their information is needed for other users or members from a group after that project or working period. The user account is disable while he is not in the project anymore, but he probably will come back to the company in the future.

Another use could be if a mobile phone is lost and the administrator can disable the sync until the pasword is changed (local, LDAP or Shib).

[pako81]

@MTRichards also required here. Having a Service Provider who is forced to delay the launch of their ownCloud project because of the lack of this specific feature. Do we have now any info around when this feature will be available? Thanks!

[DeepDiver1975]

@MTRichards @cmonteroluque @karlitschek this is 9.1 story as discussed last week - right?

[MTRichards]

Yes. It would be part of the new authentication mechanisms, I think - keep me honest though, I can't remember if disable a user was in or not, because that was in the context of the user table. @cmonteroluque @LukasReschke

@cdamken Great to hear the use cases customers are asking for. The lost phone will be covered in the new authentication app for 9.1 (though not full remote wipe, just stop syncing and invalidate password).

The project case is useful, just needs the user table - I think this is 9.2.

[DeepDiver1975]

@MTRichards we need to have the basic mechanism to lock/disable a user within 9.1 - the ui update can follow in a later stage

[MTRichards]

Works for me, just verifying the plan and schedule. That answers that question, so this would be in 9.1 then?

Matt Richards VP Products & Markets ownCloud, inc.

On Apr 7, 2016, at 5:42 PM, Thomas Müller notifications@github.com wrote:

@MTRichards we need to have the basic mechanism to lock/disable a user within 9.1 - the ui update can follow in a later stage

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[ghost]

yeah, definitely, the way I understood it. Zero day de-provisioning was in the conversation.

[PVince81]

@DeepDiver1975 new ticket for UI update or move ticket to 9.2 ?

[ShamimIslam]

What a wonderful boondoggle. You've all been talking about this for 2 years. I've been USING THIS FEATURE for 2 years in ownCloud 6 and 7 and is the reason I have not upgraded my users to 8 and 9. And yet you guys have discussed it to death.

HR and most enterprises work in LDAP. That means that permissions are controlled by group policy. Group policy implies group membership When a user is disabled, they are attached to a group that specifically designed to have no permissions. In our case, that group should fail all login attempts.

The issue here is three-fold which have not been thought through at the enterprise level - and yes - there is a DEMAND for this solution - you just can't hear us roar because we've got laryngitis from shouting.

1. Pre-X events in every event based system allow pre-failure of an action - not just "let me let you know something happened". This has not been present in the ownCloud event system. The ownCloud Hook emit functions do not return success or failure like normal message handling procedures in every other system - they return nothing. So - EITHER we make emit return true in all default cases, OR we add a pass-by-reference parameter that can retrieve success or failure. But this does not work, so this was a bust too.
2. Everyone thinks "disabled" = user attribute. But the reality is that all disabled users are the same and are a class of users. Therefore, this should be a group and not an attribute. Groups make it easy to manage externally as well as internally and is less a hidden attribute but rather a collection of users. Policies should be easy to audit and validate - groups make it so. Hidden groups become a maintenance item. It ain't broke so don't fix it. Also, having it be a group means you can check just the user_group table to see if the user combination exists - more likely to be fully read from memory since it would be the primary key anyway. The only issue with this table is that it does not track creation/update events which are required for a proper audit. So I never got to doing it this way because the table didn't suit.
3. The login itself needs to respond to the success or failure of the pre-login hook. But that means the pre-login hook must always fire - again something that has escaped implementation. Again - this wasn't working so I had to opt for something else.

So for everyone that has read this far, this is how I solved in 7.0 and I am still trying to figure out how to solve it in 9.x.

1. I created a table called "oc_disabled" which columns uid, created (not null), voided (null), author (not null)
2. for each user to be disabled, I add them to this table. If a deletion is to be voided, we mark it voided.
3. I altered "checkPassword" to check if the user is in this table and not voided. If so, password validation fails. No matter what.

Now, the preferred way would be to do this with groups, and a pre-login hook and settings in the admin screen. I did try but for the problems mentioned above, was not worth the work. In the interim, this just works. It's just not persistent-across upgrades, so I have to recreate the solution each time.

But MY maintenance debt up until v8 was low.

Recommendation: fix the ownCloud pre-event emits to expect values first that decide whether the pre-event requested failure and the rest becomes child's play.

[DeepDiver1975]

Fixed with 9.1

[ShamimIslam]

Can you please provide clarity on what the fix was? Do we have a feature for this or is the 9.1 event system better at recognizing pre-event fires triggering "fail" conditions?

A little clarity goes a long way to how we handle things going forward.

Thank you in advance.

[DeepDiver1975]

Can you please provide clarity on what the fix was?

In 9.1 a user can now properly be disabled using an occ command. A disabled user can no longer log in and session information is properly purged.

[ShamimIslam]

Are the users files preserved? If not, then this is still going to create problems. We do not want to lose IP when a worker leaves our organization or is suspended.

Does disabled affect any other aspects other than login?

On Thu, Aug 25, 2016 at 10:01 AM, Thomas Müller notifications@github.com wrote:

Can you please provide clarity on what the fix was?

In 9.1 a user can now properly be disabled using an occ command. A disabled user can no longer log in and session information is properly purged.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-242397242, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTkUHttmoRc8Q0Pide6w4_klk5OmCks5qjaAwgaJpZM4DEJ7d .

[ShamimIslam]

Wait - what? It is a manual OS command to disable a user?

This is then only an interim solution as it treats this change as an exception and not a par-for-the-course update. At the enterprise level, only infrastructure engineers login to the machine.

Admins can only interact with the application through the application interface. When an HR rep wants to disable a user in LDAP, they login to the HR portal, and disable the user by changing a setting on the screen. There is no "command" that they execute.

On a regular basis, I have 5-50 users that are no longer allowed access per month as users cycle on and off projects that require and then no longer require access to our specialized ownCloud instance compared to the company-wide instance.

Please do not mark this as complete if the only solution is a command line intervention but rather as a stepping stone to the proper admin interface.

Also, is the "disabling" logged? For HR purposes at the enterprise level, authorization changes like this have to be logged in a readily auditable format (hence why I used my table).

Thanks!

On Thu, Aug 25, 2016 at 10:04 AM, Shamim Islam shamim.islam@gmail.com wrote:

Are the users files preserved? If not, then this is still going to create problems. We do not want to lose IP when a worker leaves our organization or is suspended.

Does disabled affect any other aspects other than login?

On Thu, Aug 25, 2016 at 10:01 AM, Thomas Müller notifications@github.com wrote:

Can you please provide clarity on what the fix was?

In 9.1 a user can now properly be disabled using an occ command. A disabled user can no longer log in and session information is properly purged.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-242397242, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTkUHttmoRc8Q0Pide6w4_klk5OmCks5qjaAwgaJpZM4DEJ7d .

[DeepDiver1975]

... and there is a provisioning api call to disable a user

@carlaschroder we need to document this call :wink:

https://github.com/owncloud/core/blob/master/build/integration/features/provisioning-v1.feature#L319-L325

[slonkak]

I am with @ShamimIslam. The only way this should be marked as Closed is when a GUI option is present that an admin can click to disable/enable a user. Adding the backend code, while obviously necessary, does not solve anyone's problem as only a select few people have access to run such commands. This needs to be a GUI option, perhaps a checkbox or a button that toggles a user's enabledness.

[ShamimIslam]

Does the "disabling" retain all the users content? Just making sure.

Does the "disabling" record an audit trail (as well as the "enabling"?)

A checkbox might be too easy but I agree with the GUI approach.

On Thu, Aug 25, 2016 at 10:16 AM, Thomas Müller notifications@github.com wrote:

... and there is a provisioning api call to disable a user

@carlaschroder https://github.com/carlaschroder we need to document this call 😉

https://github.com/owncloud/core/blob/master/build/integration/features/ provisioning-v1.feature#L319-L325

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-242402453, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTqLW7cVarG5N9nO4GnYROI7MNUDJks5qjaO5gaJpZM4DEJ7d .

[DeepDiver1975]

@slonkak @ShamimIslam pull requests are welcome to integrate this into the ui.

Does the "disabling" record an audit trail (as well as the "enabling"?)

there is no auditing in the community edition

Does the "disabling" retain all the users content? Just making sure.

disabling is not deleting - any content will remain

[ShamimIslam]

One last question and this may be the wrong thread to ask this on. Is there a "admin" status that allows a particular administrator to retrieve/re-assign content from a disabled user to a new owner? E.g. Share with read-only, or completely transfer content from one user to another (prior to deletion)? (I'm asking here because it relates directly to disabled users)

On Thu, Aug 25, 2016 at 10:43 AM, Thomas Müller notifications@github.com wrote:

@slonkak https://github.com/slonkak @ShamimIslam https://github.com/ShamimIslam pull requests are welcome to integrate this into the ui.

Does the "disabling" record an audit trail (as well as the "enabling"?)

there is no auditing in the community edition

Does the "disabling" retain all the users content? Just making sure.

disabling is not deleting - any content will remain

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-242413343, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTn7Zhj-oRJ-VMgshkZM_AwHTbDeDks5qjaopgaJpZM4DEJ7d .

[ShamimIslam]

Or does a disabled users shares remain shared at least?

On Thu, Aug 25, 2016 at 11:49 AM, Shamim Islam shamim.islam@gmail.com wrote:

One last question and this may be the wrong thread to ask this on. Is there a "admin" status that allows a particular administrator to retrieve/re-assign content from a disabled user to a new owner? E.g. Share with read-only, or completely transfer content from one user to another (prior to deletion)? (I'm asking here because it relates directly to disabled users)

On Thu, Aug 25, 2016 at 10:43 AM, Thomas Müller notifications@github.com wrote:

@slonkak https://github.com/slonkak @ShamimIslam https://github.com/ShamimIslam pull requests are welcome to integrate this into the ui.

Does the "disabling" record an audit trail (as well as the "enabling"?)

there is no auditing in the community edition

Does the "disabling" retain all the users content? Just making sure.

disabling is not deleting - any content will remain

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-242413343, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTn7Zhj-oRJ-VMgshkZM_AwHTbDeDks5qjaopgaJpZM4DEJ7d .

[michaelstingl]

@ShamimIslam This might help: occ files:transfer-ownership (check docs)

[cdamken]

The only way this should be marked as Closed is when a GUI option is present that an admin can click to disable/enable a user.

@slonkak @ShamimIslam All contributions are accepted, do you want to implement it?

[ShamimIslam]

That depends. Do we now have a skeleton app that contains basic files as well as comments on where to add our features and our fields (such as fields for administrative settings)?

In the past, it was very trial and error, and it was very time consuming to even reverse-engineer where to inject things to make things work right.

It's not obvioius where you guys want to trigger things on the front end and how those things map to the back end.

If we had a clear skeleton that could move basic data from the front to the back in app mode and in admin mode, this would be something anyone could take on.

The logic is not the hard part. Fitting it into the framework correctly is the barrier to entry.

On Mon, Aug 29, 2016 at 3:25 PM, Carlos Damken notifications@github.com wrote:

The only way this should be marked as Closed is when a GUI option is present that an admin can click to disable/enable a user.

@slonkak https://github.com/slonkak @ShamimIslam https://github.com/ShamimIslam All contributions are accepted, do you want to implement it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-243228099, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTrRwWHnGS7jxTeL-eqjTki3e74x8ks5qkzI7gaJpZM4DEJ7d .

[ShamimIslam]

I will look at file:trasnfer-ownershp. Thank you.

On Mon, Aug 29, 2016 at 3:24 PM, Michael Stingl notifications@github.com wrote:

@ShamimIslam https://github.com/ShamimIslam This might help: files:transfer-ownership (check docs https://doc.owncloud.com/server/9.0/admin_manual/configuration_server/occ_command.html#file-operations )

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-243227679, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTjiDI1OshkF-XSqmlF8xnl5IJ4rnks5qkzHagaJpZM4DEJ7d .

[slonkak]

It's not obvioius where you guys want to trigger things on the front end and how those things map to the back end.

@ShamimIslam You are correct. If you read farther back in this thread I did try to implement such a feature to no avail. After looking through the code (I've had to modify this app to add in HIPAA audit trails for my employer) it seems that the authors wrote it in such a way that only they are meant to modify it. I can't make heads or tails of most of it.

[cdamken]

I will look at file:trasnfer-ownershp. Thank you.

Great! :+1:

[ShamimIslam]

@slonak I had the same experience EXCEPT that in ownCloud 5, I was able to decipher how the branding worked and swapped it out. But the apps - not so much. I got lucky cuz I found "restricted_access" which worked up to ownCloud 7 - that's what I patterned my Disabled_Access on - but even then I had to clobber the login to fail anyone in the disabled group because the pre-login hook wouldn't always fire and even when it did, it didn't allow me to PREVENT the action - it was a "notify only". After v7, v8 broke everything and now I'm stuck but at least I know how to clobber the login if I have to.

But the only other problem to upgrading to 9 is that restricted_access is a must have - I have 2 groups of people - one group can craete new content in their own workspace and others can only share what's been given to them. So until I get that working, I'm stuck at v7.0.2. I don't need a "read-only" group. I need to be able decide if someone can OWN files instead of creating them.

Let's see what happens next. Maybe someone will post an updated skeleton like in v4.

On Tue, Aug 30, 2016 at 8:43 AM, Kevin J. Slonka, Sc.D. < notifications@github.com> wrote:

It's not obvioius where you guys want to trigger things on the front end and how those things map to the back end.

@ShamimIslam https://github.com/ShamimIslam You are correct. If you read farther back in this thread I did try to implement such a feature to no avail. After looking through the code (I've had to modify this app to add in HIPAA audit trails for my employer) it seems that the authors wrote it in such a way that only they are meant to modify it. I can't make heads or tails of most of it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-243425924, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTpsZtnPmrxFwqtNG5zg73FyFZKiGks5qlCVZgaJpZM4DEJ7d .

[michaelstingl]

@ShamimIslam I think this GitHub issue isn't the right place for this discussion. I would suggest using https://central.owncloud.org/ instead… (should be back in a few minutes)

[ShamimIslam]

Apologies. Will move discussion as requested. When I get a chance.

On Wed, Aug 31, 2016 at 5:19 AM, Michael Stingl notifications@github.com wrote:

@ShamimIslam https://github.com/ShamimIslam I think this GitHub issue isn't the right place for this discussion. I would suggest using https://central.owncloud.org/ instead… (should be back in a few minutes)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/12601#issuecomment-243707106, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6oTjdtAYBkqreuxIWHIFocAF0aQsVCks5qlUcTgaJpZM4DEJ7d .

[PVince81]

GUI checkbox for enabling/disabling in the users page will be released in 10.0, thanks to @AlexLaroche for implementing it in https://github.com/owncloud/core/issues/27333

[PVince81]

Note, the checkbox is hidden by default like other columns and need to be enabled by going to the cog icon on the bottom left. Once the column is enabled it will stay visible for that user. (user preference about visible columns)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.