Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-1015

Unable to deactivate or delete unverified accounts

      Issue Summary

      • Similar to but not the same as: ACCESS-819 - "Allow account deactivation for unverified accounts"
      • Since ACCESS-617 - "Unverified email addresses does not appear under Managed Accounts" was shipped, unverified Atlassian accounts are now surfaced to the Managed accounts page in the organization UI
      • There are buttons to delete or deactivate the unverified account within the UI, but when clicked, admins receive an error message(see below)

      Steps to Reproduce

      1. Navigate to an unverified Atlassian account in the organization UI
      2. Try to delete or deactivate the account

      Expected Results

      • The account is deactivated or is marked for deletion(14 day grace period)

      Actual Results

      • 403 response:
        {"errorKey":"forbidden","errorDetail":"Error: Principal cannot manage account of non-managed user"}
        

      Workaround

      • Verify the account first, and then you'll be able deactivate or delete the account

          Form Name

            [ACCESS-1015] Unable to deactivate or delete unverified accounts

            Hi automation+test1833198924 ,

            I agree with you from experience that rest-api cannot delete accounts,  it is not seeing users at the org level  when I tried.    I also had an Atlassian engineer on and we tried using a javascript  code from the Chrome tools without success.

             

            Atlassian admins can delete for you if you have a lot of users to delete, and this is immediate as opposed tp waiting for 14 days if you do this yourself fron the GUI.

             

            kayode.faith added a comment - Hi  automation+test1833198924  , I agree with you from experience that rest-api cannot delete accounts,  it is not seeing users at the org level  when I tried.    I also had an Atlassian engineer on and we tried using a javascript  code from the Chrome tools without success.   Atlassian admins can delete for you if you have a lot of users to delete, and this is immediate as opposed tp waiting for 14 days if you do this yourself fron the GUI.  

            REST API still broken. Can you re-open this issue please?

            Test Automation {Appfire} added a comment - REST API still broken. Can you re-open this issue please?

            Theo van Arem added a comment - - edited

            Hi,

            We can deactivate users via the UI, but are unable to use API (org admin account) to deactivate and delete the account.

            When using the API to check if we can manage the user (https://api.atlassian.com/users/\{id}/manage) we get the error: Error: Cannot perform action on unverified account.

            I'm adding this comment on request from Support as I have also raised a Support ticket regarding the API issue.

             

            Theo van Arem added a comment - - edited Hi, We can deactivate users via the UI, but are unable to use API (org admin account) to deactivate and delete the account. When using the API to check if we can manage the user ( https://api.atlassian.com/users/\ {id}/manage) we get the error: Error: Cannot perform action on unverified account. I'm adding this comment on request from Support as I have also raised a Support ticket regarding the API issue.  

            We are able to deactivate these accounts via the member details page but not through the org API. The error message that we get is "Error: Caller must be an org admin of targeted account or be the targeted account"

            Does the Atlassian org API support deactivation of these accounts yet?

            Rishi Dhar added a comment - We are able to deactivate these accounts via the member details page but not through the org API. The error message that we get is " Error: Caller must be an org admin of targeted account or be the targeted account" Does the Atlassian org API support deactivation of these accounts yet?

            Hi all,

            I am excited to share that it is now possible to deactivate any unverified account that is managed by your organization from the Member Details page. The change has been rolled out to all users.

            Thank you for your patience in waiting for this to get resolved, and please don't hesitate to reach out with any feedback or questions!

            Best regards,

            Ilya Bagrak
            Principal Product Manager, Enterprise Cloud

            Ilya Bagrak added a comment - Hi all, I am excited to share that it is now possible to deactivate any unverified account that is managed by your organization from the Member Details page. The change has been rolled out to all users. Thank you for your patience in waiting for this to get resolved, and please don't hesitate to reach out with any feedback or questions! Best regards, Ilya Bagrak Principal Product Manager, Enterprise Cloud

            Rory Tarabay added a comment - - edited

            We're in a situation where we can now deactivate unverified accounts through the GUI, but the API still reports them as active so we don't know which to believe!

            If we try to deactivate the account from the API we get the following error (the API account is an Org admin, and retrieved their details from an Org API):

            {
            ?? "context": "Error: Caller must be an org admin of targeted account or be the targeted account",??
            ?? "errorDetail": "Error: Caller must be an org admin of targeted account or be the targeted account",??
            ?? "errorKey": "forbidden",??
            ?? "key": "forbidden"??
            }

            Rory Tarabay added a comment - - edited We're in a situation where we can now deactivate unverified accounts through the GUI, but the API still reports them as active so we don't know which to believe! If we try to deactivate the account from the API we get the following error (the API account is an Org admin, and retrieved their details from an Org API): { ?? "context": "Error: Caller must be an org admin of targeted account or be the targeted account",?? ?? "errorDetail": "Error: Caller must be an org admin of targeted account or be the targeted account",?? ?? "errorKey": "forbidden",?? ?? "key": "forbidden"?? }

            Kai Girke added a comment -

            Hope your investigation include the deletion of unverified accounts.

            At the moment we cannot delete them.

            Thank you.

            Kai Girke added a comment - Hope your investigation include the deletion of unverified accounts. At the moment we cannot delete them. Thank you.

            I think the steps that @Connor listed depends on how many unverified addresses you wish to delete.     I have a ton of addresses and it is not imaginable how much time it would take to change the email addresses and verify them and then delete.     When I tried REST API,  there is a limitation in that it cannot see addresses or accounts at the site level, just the org level.  I was working with Atlassian support and the agent suggested I open a new service request with the Org team.     The Org team asked me to supply the .csv file with the unverified email addresses including the account id.    I have done this and by Monday it should all be deleted.  I believe this can be deleted using the account id from the database.   

            kayode.faith added a comment - I think the steps that @Connor listed depends on how many unverified addresses you wish to delete.     I have a ton of addresses and it is not imaginable how much time it would take to change the email addresses and verify them and then delete.     When I tried REST API,  there is a limitation in that it cannot see addresses or accounts at the site level, just the org level.  I was working with Atlassian support and the agent suggested I open a new service request with the Org team.     The Org team asked me to supply the .csv file with the unverified email addresses including the account id.    I have done this and by Monday it should all be deleted.  I believe this can be deleted using the account id from the database.   

            Connor added a comment -

            @Ashish, I followed Rob's advice to delete a bunch of unverified/deactivated accounts. I'll list my exact steps below using 2 example emails, for me and an unverified/deactivated account. My example email is connor.example@mydomain.com, the unverified/deactivated user's example email is user.example@mydomain.com

            1. Login to admin center --> Directory --> Managed accounts
            2. View details page of an unverified/deactivated account
            3. Edited their email address so it was connor.example+user.example@mydomain.com. That email is the equivalent to my personal email of connor.example@mydomain.com
            4. After you edit a user's email, a verification email is sent to the new email address.
              • With a few users I ran into an issue where my email provider, Exchange Online, failed to deliver the email verification email. When that happened I reactivated the user, which sends a reactivation email with a link to login, which is effectively the same the email verification email. Exchange Online never had a problem delivering this 2nd email.
            5. When I received the verification email, I clicked the Verify your email link which took me to the Atlassian login page. I did not have to login.
            6. I refreshed the user's details page, and they were now verified. After verification I now had the option to delete the user.
            7. I selected to delete the user, and I did not run into any errors when doing that.

            Note: For those using Exchange Online, Plus Addressing must be enabled within your organization before you do this. Read how to enable it here: https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online

             

            Connor added a comment - @Ashish, I followed Rob's advice to delete a bunch of unverified/deactivated accounts. I'll list my exact steps below using 2 example emails, for me and an unverified/deactivated account. My example email is connor.example@mydomain.com, the unverified/deactivated user's example email is user.example@mydomain.com Login to admin center --> Directory --> Managed accounts View details page of an unverified/deactivated account Edited their email address so it was connor.example+user.example@mydomain.com. That email is the equivalent to my personal email of connor.example@mydomain.com After you edit a user's email, a verification email is sent to the new email address. With a few users I ran into an issue where my email provider, Exchange Online, failed to deliver the email verification email. When that happened I reactivated the user, which sends a reactivation email with a link to login, which is effectively the same the email verification email. Exchange Online never had a problem delivering this 2nd email. When I received the verification email, I clicked the  Verify your email link which took me to the Atlassian login page.  I did not have to login. I refreshed the user's details page, and they were now verified. After verification I now had the option to delete the user. I selected to delete the user, and I did not run into any errors when doing that. Note: For those using Exchange Online, Plus Addressing must be enabled within your organization before you do this. Read how to enable it here:  https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online  

            @Rob, Can you elaborate the trick you mentioned. I did what was mentioned yet I have not received any verification email on my side.

            Ashish Dalvi added a comment - @Rob, Can you elaborate the trick you mentioned. I did what was mentioned yet I have not received any verification email on my side.

            Rishi Dhar added a comment -

            Looks like its possible to deactivate these using the console but I can't seem to use the Atlassian User Management Rest API to do the same action (deactivate unverified accounts)

            https://developer.atlassian.com/cloud/admin/user-management/rest/intro/

            Rishi Dhar added a comment - Looks like its possible to deactivate these using the console but I can't seem to use the Atlassian User Management Rest API to do the same action (deactivate unverified accounts) https://developer.atlassian.com/cloud/admin/user-management/rest/intro/

            Jack Kora added a comment -

            @rob - genius! 

            Jack Kora added a comment - @rob - genius! 

            @Rob, genius idea with the gmail trick; I had forgotten that was a thing.

            CV Service Desk added a comment - @Rob, genius idea with the gmail trick; I had forgotten that was a thing.

            Rob Brown added a comment -

            Changing to a bogus email address as Vitor A claims above, does not work: has to be an address that can receive the verification email.

            I used the old "gmail plus" trick to set them to:

            {{ <myrealemail>+<theirbademail>@<mydomain>}}

            and click the verify button when I get the email and was able to delete the accounts.

            This is a PITA! Please fix.

            Rob Brown added a comment - Changing to a bogus email address as Vitor A claims above, does not work: has to be an address that can receive the verification email. I used the old "gmail plus" trick to set them to: {{ <myrealemail>+<theirbademail>@<mydomain>}} and click the verify button when I get the email and was able to delete the accounts. This is a PITA! Please fix.

            Ryan Pesta added a comment -

            @Jack You don't have to pay if you don't have them assigned to a product. They can live in your user directory but not be assigned anything.

            For others reading this, I worked around this issue by renaming the users email and changing back for each unverified user. This then allowed me to deactivate.

            Ryan Pesta added a comment - @Jack You don't have to pay if you don't have them assigned to a product. They can live in your user directory but not be assigned anything. For others reading this, I worked around this issue by renaming the users email and changing back for each unverified user. This then allowed me to deactivate.

            Jack Kora added a comment -

            So we end up having to pay for these extra users? Not cool...

            Jack Kora added a comment - So we end up having to pay for these extra users? Not cool...

            Fabian Eichenberger added a comment - - edited

            Sadly the workaround from comment-2689955 doesn't work anymore, so I'm unable to verify an unverified account (and therefore deactivate or delete it).

            Fabian Eichenberger added a comment - - edited Sadly the workaround from comment-2689955  doesn't work anymore, so I'm unable to verify an unverified account (and therefore deactivate or delete it).

            Justin Couto added a comment - - edited

            For some reason, I can't put a screenshot into your tool.  Here is what the messages says:

            You can't delete this account

            The account for SoCreate can't be deleted because:

            • This account is the primary billing contact for one or more products.
            • This account is a technical contact for one or more products.
            • To continue deleting this account the account owner needs to visit my.atlassian.com and designate a different user as a billing and technical contact.
            • Read our support documentation for more help and instructions: https://confluence.atlassian.com/x/pTgoPQ

            Justin Couto added a comment - - edited For some reason, I can't put a screenshot into your tool.  Here is what the messages says: You can't delete this account The account for SoCreate can't be deleted because: This account is the primary billing contact for one or more products. This account is a technical contact for one or more products. To continue deleting this account the account owner needs to visit my.atlassian.com and designate a different user as a billing and technical contact. Read our support documentation for more help and instructions: https://confluence.atlassian.com/x/pTgoPQ

            I was able to use the technique you described for all but this one one below.  I have gone into everywhere and I don;t see it being used anywhere like it describes in the message below.  Can you help me delete this one?:

            Justin Couto added a comment - I was able to use the technique you described for all but this one one below.  I have gone into everywhere and I don;t see it being used anywhere like it describes in the message below.  Can you help me delete this one?:

            A previous administrator in our organization had configured user provisioning via Azure AD (now disabled). Since ACCESS-617 was released, our managed accounts list doubled in size with dozens of old accounts for users who are no longer with the company. It's a mess, and raises lots of questions / concerns. From our perspective, ACCESS-617 was a non-issue, but this is now a big problem. Please consider reverting 617 until you've worked out the kinks.

            Desmond Cox added a comment - A previous administrator in our organization had configured user provisioning via Azure AD (now disabled). Since  ACCESS-617 was released, our managed accounts list doubled in size with dozens of old accounts for users who are no longer with the company. It's a mess, and raises lots of questions / concerns. From our perspective, ACCESS-617 was a non-issue, but this is now a big problem. Please consider reverting 617 until you've worked out the kinks.

            Hi Vitor, thanks for your clarification. It actually works though it's a lot of work to be done by hand.

            Pierangelo

            Pierangelo Repetti added a comment - Hi Vitor, thanks for your clarification. It actually works though it's a lot of work to be done by hand. Pierangelo

            John Funk added a comment -

            Confused as to why this is Highest priority but in the Long Term Backlog. 

            John Funk added a comment - Confused as to why this is Highest priority but in the Long Term Backlog. 

            Gerald Pit added a comment - - edited

            This is REALLY bad, we have users reappear who have left the org years ago and its not possible to delete them? GDPR issue?

            Gerald Pit added a comment - - edited This is REALLY bad, we have users reappear who have left the org years ago and its not possible to delete them? GDPR issue?

            Hi p.repetti,

            We are sorry for not having a scalable solution at the moment. I would just like to inform two points that may help you while we are still working on this:

            • The new email address applied on the account doesn't necessarily need to be a valid one: Just by performing the email change, the account will get verified. That being said, you can simply add a -old before the @ (for example), and it should do the trick.
               
            • After updating the account's email address to verify it, you can change it back to the previous one if desired. 

            I hope this helps you to handle this scenario, while we work on the permanent fix. 

            Kind regards!
            Stay safe.
            Vitor Á.
            Atlassian Cloud Support

            Vitor A (Inactive) added a comment - Hi p.repetti , We are sorry for not having a scalable solution at the moment. I would just like to inform two points that may help you while we are still working on this: The new email address applied on the account doesn't necessarily need to be a valid one: Just by performing the email change, the account will get verified. That being said, you can simply add a -old  before the @ (for example), and it should do the trick.   After updating the account's email address to verify it, you can change it back to the previous one if desired.  I hope this helps you to handle this scenario, while we work on the permanent fix.  Kind regards! Stay safe. Vitor Á. Atlassian Cloud Support

            If I may comment, the workaround you suggest can only go so far. It's true that the unverified address can be turned to a real one, so that the account can be deactivated. But then the redirected address gets burnt, and cannot be used for recovering another unverified one. It would get the famous error "That address is already taken". Moreover, it'll take 30 days to actually delete the burnt address and be able to use it again. If you happen to have 50+ unverified accounts to purge, like us, you should be creating 50+ email aliases, one for each account. Not quite a cup of coffee.

            So please: when is this going to be solved ?

            Pierangelo Repetti added a comment - If I may comment, the workaround you suggest can only go so far. It's true that the unverified address can be turned to a real one, so that the account can be deactivated. But then the redirected address gets burnt, and cannot be used for recovering another unverified one. It would get the famous error "That address is already taken". Moreover, it'll take 30 days to actually delete the burnt address and be able to use it again. If you happen to have 50+ unverified accounts to purge, like us, you should be creating 50+ email aliases, one for each account. Not quite a cup of coffee. So please: when is this going to be solved ?

            We invite users centrally. If we make a mistake, we need to create an actual email address, log in and to validate the account. This is a ridiculous amount of work to fix a simple mistake 

            Peter Fjelsten added a comment - We invite users centrally. If we make a mistake, we need to create an actual email address, log in and to validate the account. This is a ridiculous amount of work to fix a simple mistake 

            xliu3@atlassian.com - Related HOT was mitigated, we also did PIR for this issue. Can you please update status of this bug?

            Shilpa Kulkarni added a comment - xliu3@atlassian.com  - Related HOT was mitigated, we also did PIR for this issue. Can you please update status of this bug?

            For instances that authenticate via Active Directory and/or OKTA, the Administrator has no capability to edit the user Profile and change the email address as described in the workaround.  Can we request deletion of impacted accounts via support ticket until a correction is in place?

            David Scanlon added a comment - For instances that authenticate via Active Directory and/or OKTA, the Administrator has no capability to edit the user Profile and change the email address as described in the workaround.  Can we request deletion of impacted accounts via support ticket until a correction is in place?

              c6c23291180e Ilya Bagrak
              dnguyen4 Derrick Nguyen
              Affected customers:
              105 This affects my team
              Watchers:
              139 Start watching this issue

                Created:
                Updated:
                Resolved: