Unable to reactive an inactive user

[AyushPandey]

Hi all,
I am facing an issue with reactivating an inactive user i tried the following json with databricks cli 

run_update = {

  "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ],

  "Operations": [

    {

      "op": "replace",

      "path": "active",

      "value": [

        {

          "value": "true"

        }

      ]

    }

  ]

}
But the user status still remains inactive. Any leads would be helpful.

[AyushPandey]

Hi Kaniz,
Can you tell me how can I use the request library, I tried using python but I was unable to activate the user. 
Thanks for your help.

[FunkyBunches]

We are getting this same issue.  Somehow two days ago two of our users got set to "Inactive".  We've tried the scripts mentioned in the API but they will not reactivate.

We also even got our Azure Owner to run the scripts and generate a pat to try, and it doesn't work for them either.

There needs to be a better way to reactivate users, and there should be some kind of confirmation to deactivate them as no one in our org knows how these two users got set to inactive.

[Jürg]

Hi there, 

We are facing exactly the same issue over here. Two users suddenly set to inactive, reactivation with python script does not work... even with PAT of account admin...

Help is much apprechiated!

[Jürg]

@AyushPandey @FunkyBunches 
just found a dirty workaround for inactive users.
1. delete the user on the workspace
2. delete the user on the account console
3. add the user on the account console
4. add the user on the workspace again

if it's a user without any dependency, so not owning jobs, clusters etc. this should do the trick...

[bencsik]

This does not work for me. The user is recreated with the same ID as before and remains inactive. Any resolution?

[FunkybunchOO]

In our case it was because of the Azure SCIM.  We needed to remove and add the user in Azure due to the way the Active Directory works without federated identity.  It took us a week to figure it out.

[bencsik]

@FunkybunchOO Thank you for your response! I will look into other connections, but we are not currently using SCIM. There must be something similar blocking the activation.

[FunkyBunches]

To be transparent, we didn't know we were using SCIM either, which was one of the reasons it took us a bit to figure it out.  Basically what happened, is that an update to one group removed access from people who weren't part of that group, even though they were under another group that should have had access.  Basically Azure Databricks doesn't work with nested groups properly.  So to fix it, we removed the nested groups, and added only the specific groups to the relevant permissions.  There were only two of us who weren't a member of the second group, so it seemed like a specific permission setting, instead of a group setting.