[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 #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 😄

[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

[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
#12601 (comment),
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
#12601 (comment),
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 😉

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
#12601 (comment),
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
#12601 (comment),
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
#12601 (comment),
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
#12601 (comment),
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
#12601 (comment),
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! 👍

[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
#12601 (comment),
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
#12601 (comment),
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 #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]

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.