Today Visual Studio Team Services (VSTS) is releasing an update to our service which will bring more of Office 365 and Azure Active Directory (AAD)’s user lifecycle management capabilities to VSTS. With this update, customers using AAD to secure VSTS accounts can be confident that whenever a user is disabled or deleted within their AAD tenant, that user will lose all access to VSTS resources shortly thereafter, usually within an hour.
Why are we making this change?
We know that our customers rely on VSTS to provide a secure environment for source code, work items and other aspects of their software development projects. We introduced support for Azure Active Directory integration in order to provide even better levels of security for customers of all sizes. By updating our service to better align with AAD and Office 365, we are allowing you to secure user access (account creation and deletion) in one place, without needing to take additional steps to secure Visual Studio Team Services.
I am a developer working inside of a VSTS account. How will this change impact me?
As long as your user object is active (not disabled, not deleted) within AAD & O365, you won’t see significant changes. However, you may notice additional web redirects to AAD’s various authentication pages, even if your account is not disabled or deleted, since we are revalidating access tokens more frequently in order to implement this change.
I am the AAD administrator for my organization. What will someone see within VSTS after I’ve disabled or deleted their account?
If someone is not actively using VSTS at the time that you disable or delete their account (no active browser windows or IDE sessions, no active Personal Access Tokens), a disabled or deleted user will be unable to open a new session with VSTS. This will usually take place within an hour.
If someone is actively using VSTS at the time that you disable or delete their account, they will continue to have access to the service for up to an hour, after which they will see a 403-Not Authorized error page like the one shown here:
I am the AAD administrator for my organization. I temporarily disabled a user account but have re-enabled it. Do I need to do anything to give this person access to VSTS again?
A re-enabled user will regain access to all of their old VSTS resources automatically. However, it may take up to an hour for their access to be restored.
I am the AAD administrator for my organization. I accidentally deleted a user account in AAD and need it back. What do I do?
In order for a deleted user to seamlessly regain access to their previous cloud resources, including VSTS, you need to undelete the user with the Restore-MSOLUser PowerShell cmdlet. You can undelete an AAD user for up to thirty (30) days after they’ve been deleted. You can find instructions for installing and running the Azure AD PowerShell cmdlets here. Specific guidance on the Restore-MSOLUser cmdlet is located here.
Note: Creating a new user, even if it has the same name, UPN, email address, etc., will not restore the user’s access to VSTS , since it will be seen as a different Identity from the one that was deleted. Even though they look the same to the human eye, AAD and VSTS will see them as a new user, and will act accordingly to protect your important resources! Only the cmdlet will allow you to undelete a user so that they retain access to all of their old resources.
Does this change affect only web-based logins?
No. Personal Access Tokens (PATs), Alternate Credentials, SSH, and access to VSTS through the Visual Studio IDE will also be blocked within an hour of a user being disabled or deleted within.
Does this change affect VSTS accounts secured by Microsoft Account (MSA)?
No. The change only impacts VSTS accounts secured by AAD.
I’m seeing a “403-Not Authorized” page and I don’t think I should be. What should I do?
If you’re seeing an error message showing that your account has been disabled or deleted and you don’t believe this is correct, please contact your AAD administrator to assist you. You’ll see your AAD User Principal Name (UPN) and Object Identifier (OID) in the “Here are some additional tips” section to help you troubleshoot (shown below).
If you are the AAD administrator for your tenant and you think you’ve spotted a problem with this behavior, you should first check the AAD or O365 user management console to confirm that the user in question is not disabled or deleted. Remember that the user’s UPN and OID will appear in the error page in the “Here are some additional tips” section.
If this doesn’t resolve the issue, you can open a new support case and our Customer Support team will help. To do that:
- Click the “Visual Studio Team Services technical support” tile:
If you have additional questions or feedback for us regarding VSTS and AAD integration, please feel free to let us know in the comments, or leave us a suggestion on User Voice here.
0 comments