I have followed the steps on https://learn.microsoft.com/en-us/vsts/accounts/connect-account-to-aad?view=vsts to get my VSTS instance to use Azure Active Directory. When I click "Connect" I get the error:
Account [VSTS instance name] connection to an AAD Tenant failed due to
the error : Aad guest user cannot be made an owner of the account.
Owner identity: (id: [id]; mid: [id]; cuid: [id])
Looking through the list of users I can see that I am logged in as a user that is present on both VSTS and AAD, and that the AAD user has a User Type = Member
Originally the user was setup as Guest, and using powershell I changed them to Member. This seemed to change the user type immediately, but I still get the error above, even after waiting approx. 36 hours so far.
Is there something else I need to do here?
As per my comment above:
I have managed to fix this by dropping the user completely and creating a brand new MSA account and starting again. I don't know what I did wrong the first time round, but it is working now with the brand new user.
Related
I'm trying to connect Azure DevOps to Azure Active Directory (which is being synced to an on premise AD server) and I keep getting the following error:
Connection Failed Your organization #### failed to connect to the ####
Azure Active Directory.
User: ##AADGUID##\##USER#####DOMAIN## of 1 total users has multiple
active identities with the same UPN. Please either remove the
duplicates or change the UPNs to be unique.
I've looked at the user's account and don't see anything obviously misconfigured compared to any other user's account but that might not be saying much. Any help would be greatly appreciated.
Turns out when our Azure DevOps instance was first set up, all our users set up Microsoft accounts with their company emails. Later when we finally stood up Azure AD but before we connected it to DevOps we added a new project and set the permissions for a few existing employees. For some reason the user permissions on the new DevOps project were listed as "aaduser" type instead of the standard "user" type (ms account) that all the users in other projects in DevOps had. In other words duplicate UPNs but different accounts (but sort of the same). What's weird is that DevOps managed to find the Azure AD user account before we even connected the two together services together.
We removed the offending users with the standard "user" type and re-added them so they were now all listed as "aaduser." We were then able to connect Azure AD. To be clear, this was all done on the DevOps side and had nothing to do with AD.
Not sure why it was finding Azure AD users when we weren't even connected to it yet.
It sounds like you have multiple users in your azure ad tenant with the same UPN.
maybe you created a cloud account with the same UPN before sync'ing the on premise with azure ad connect? or something else of that nature.
try to go to graph explorer https://developer.microsoft.com/en-us/graph/graph-explorer
log in with a azure ad admin account
and type in a query like this
https://graph.microsoft.com/v1.0/users?$filter=startswith(UserPrincipalName,'##UPNHavingIssues##')
That should get you users with a UPN of whatever it having problems. There should only be entry, but if there are multiple, then that's where the problem is.
The other option is to remove the user having issues from devops completely, then try to connect, then re-add him. because when you try to connect devops to an azure ad domain it will try to match the UPNs of users in your devops with users in your tenant.
According to this doc:
During the connect process, we map existing users to members of the Azure AD tenant, based on their UPN, which is often known as sign-in address. If we detect multiple users with the same UPN, we don't know how to map these users.
The cause of this issue is that the target user has the same UPN as other user. A UPN must be unique among all security principal objects within a directory forest.
The UPN contains UPN prefix (the user account name) and a UPN suffix (a DNS domain name).
For example:someone#example.com
You can compare the target account with other user accounts. Then you could find the duplicate UPN.
You could try to remove the duplicate one or change the UPN as unique.
Hope this helps.
I am trying to connect an existing MS-based DevOps organisation to our AAD (O365). I have a user account nnn#outlook.com in DevOps that is both Organization Owner and a Collection Administrator.
The same outlook.com account is a Member of the target Tenant directory. I can login to portal.azure.com using that account and see all the details of the AAD. I have made the account a Global Administrator.
When I click Connect Directory, I get a list of the tenants that account has access to. My target is there and I have confirmed that the Tenant ID matches.
When trying to connect I get the error message:
"User: nnnn#outlook.com is not allowed to link organization: xxxx to AAD tenant: zzzzz. Only active members of the AAD tenant are allowed to perform the link."
I tried creating a clean guest account, PS'd it to become a Member, but get the same result.
Any suggestions greatly appreciated.
We are trying to connect our existing VSTS account to AAD following the instructions at: https://learn.microsoft.com/en-us/vsts/accounts/connect-account-to-aad?view=vsts
When we try to perform the step at: 'Connect your VSTS account to your organization directory' #6, we receive the following error:
Account ****** connection to an AAD Tenant failed due to the error : Account entitlement not found in the dictionary for source identity 'dffde1b5-5781-4c53-bbb2-5ff5792383dc'.
We have tried this with 2 separate MSA accounts; one was existing, one we create from scratch. The MSA accounts are added as a guest to AAD. We have made it owner on the subscription, is there a permission that I am missing?
One answer said they just had to wait 12 hours, we have waited 24 with no change.
Any help would be appreciated.
Edit
Hopefully this helps:
Request is to:
PATCH https://peprodscussu2.portalext.visualstudio.com/_apis/AzureTfs/Account/b7615ac7-c2f6-466c-9f73-b8ed37258259?tenantId=f1295c9e-6264-403f-a42b-5be8fd3266fa HTTP/1.1
Response shows 500 Internal Server Error:
{"$id":"1","innerException":null,"message":"Account entitlement not found in the dictionary for source identity 'dffde1b5-5781-4c53-bbb2-5ff5792383dc'.","typeName":"Microsoft.VisualStudio.Services.Licensing.TransferUserLicenseException, Microsoft.VisualStudio.Services.WebApi","typeKey":"TransferUserLicenseException","errorCode":0,"eventId":3000}
Let me know if there is additional information from Fiddler that you need.
The issue was on Microsoft's end. Apparently there was duplicate orphaned user entries for a user that had been deleted 3 years ago from the VSTS account. They had to manually correct it. Thanks for your help.
I'm following this guide to create an application in my Azure B2C active directory.
I have created a new local user called admin#{mytenant}.onmicrosoft.com which is set as a global user. I am using this user to manage my active directory with PowerShell.
It seems that the application (service principal) gets created successfully. There are no errors returned and when I run Get-MsolServicePrincipal the newly created app appears in the list.
However it is nowhere to be found in the old Azure portal (http://manage.windowsazure.com) nor the new one (http://portal.azure.com). Am I doing something wrongly with creating it?
The answer of the question below could be useful for you : Azure AD B2C Connected user change password with Graph AD API
I don't know if it's possible in the old portal.
There are good instructions available here on changing the VSTS connection from one Azure AD to another: Change VSTS AD.
But what if you just want to remove the Azure AD integration, and just revert to using Microsoft Accounts?
I successfully performed all the steps in the instruction, up to the point of attaching a new target Azure AD. You'd think when the VSTS account was unlinked in Azure, it would no longer show up in VSTS.
But going to https://[AccountName].visualstudio.com/_admin/_home/settings still shows account being backed by the source directory.
Attempting to add a Microsoft Account based user at https://[AccountName].visualstudio.com/_user fails to find the account, presumably because it is looking the the Source Azure AD.
This is an important capability when transferring ownership of an account. Thanks for taking a look!
You can follow the steps here: Disconnect your Team Services account from Azure AD.
To stop using Azure AD and revert to using Microsoft accounts, you can
disconnect your Team Services account from its directory.
Here's what you'll need:
Microsoft accounts added to your Team Services account for all users.
Team Services account owner permissions for your Microsoft account.
Directory membership for your Microsoft account as an external user
and global administrator permissions. Azure AD members can't
disconnect Team Services accounts from directories.
With the help of Microsoft Premium Support, we did manage to get this worked out.
The problem was the Team Services was not disconnected from the associated Azure AD before it was unlinked. Then once it was unlinked, it appeared gone from Azure, leaving no way to disassociate Azure AD.
The documentation does show to first disconnect the VSTS account from Azure AD, and then “unlink” the account. Where I got into trouble was by using the new portal. It's pretty hard to even find the old portal anymore BTW).
The new portal has this nice handy unlink button, which is practically irresistible. If clicking it, then it declares success. There is nothing in the UI that prevents you from unlinking while still leaving the AD association. There is no option at all in the new UI portal, as far as I could find, to disconnect Team Services from Azure AD.
Once unlinked, the only fix is to relink, and then redo it all in the old portal as is indicated by the documentation.
This is much more difficult than it should be because it seems like something that should be simple to achieve through the web UI. These posts helped me, but I wanted to add my 2 cents:
In order to disconnect VSTS from AAD you need to be able to use the disconnect button on the configure tab in the old portal seen here. However, you can only use that button if you're the VSTS account owner and if your account is not sourced from the currently linked active directory (i.e. - a MS Account). But you can't make the VSTS account owner a MS account if you've used the portal's interface to add the MS Account to your AAD as an external user. This is because external users are added as Guest account type by default (rather than Member type). If you try to set the MS account as VSTS owner you get the "AAD guest users are not allowed to be collection owners" message seen here.
It's a chicken/egg thing which is made more difficult by the fact that the official documents for this process make no mention of the conflict you'll face. They read as if this should just work.
The answer is that (as of today) you can't do this without using Powershell or an AAD API to convert the MS Account from a "Guest" to a "Member" user type. There are a number or articles out there which walk through the older APIs to do this. Here is what I did with the latest PS:
First, log in to the directory you wish to unlink with an account which has permissions to modify members. Ideally an admin or owner.
Connect-AzureAD
Next, find the account you want to modify using this command:
Get-AzureADUser
Find the ObjectID of the user you want to convert from Guest to Member and then run this command:
Set-AzureADUser -ObjectId [ObjectID GUID Here] -UserType Member
This will convert the MS Account in the AAD you want to unlink to a 'member' type. In my situation I found that I had to remove the MS Account from VSTS and re-add it in order to trigger a refresh which allowed me to set it as account owner.
Now you just follow the documented steps:
set MS account as project owner. Save.
log in to old portal, go to configure tab, and disconnect
log back in everywhere to see the changes