When I execute Get-AzureAccount, I see the Azure account of the domain account I am logged into Windows with. So, when I run Get-AzureSubscriptions, I see the associated subscriptions. I want to get the subscriptions associated with a different account (one with which I cannot login into Windows) but I cannot figure out how this is done. Of course, Add-AzureAccount would seem to be the way to go but despite reading the TechNet help page on it, I don't see how another account can be added.
Thanks!
-Rohan.
Azure subscriptions are stored in "C:\Users\%username%\appdata\Roaming\Windows Azure Powershell" (or "%AppData%\Windows Azure Powershell) per user. The contents of that dir is an xml file containing the user's subscriptions. Each subscription is linked to a certificate that needs to reside in the same user's cert store in order to connect.
Anyways, using
Get-AzureSubscription -SubscriptionDataFile <path to the other user's xml file>
you should be able to read those subscriptions, if you have access to his/her profile folder (which would require local admin permissions on a normal system).
Related
I have an Azure Active Directory app and it has various reply URLs. I've being adding reply URLs manually in the Azure portal AAD-> register-app-> settings-> reply-URLS.
My goal is to be able to run an azure pipeline task that can retrieve the reply URL I need from an azure app service( which I know how to do) and add it to the reply URL list from the register app in AAD with a command. Using either Azure-cli, Azure-powershell or Powershell from azure pipeline task list.
If there's another way of doing it with another task I'm open to suggestions.
This is what i tried:
This is what the log/debug output:
I guess that a better questions is:
How Can I give privileges to an Azure CLI task from Azure DevOps to achieve the task from previous problem?
Your question has changed a bit after your edit, so I've tried to revise and answer both parts.. i.e. adding reply URLs through script and something to possibly help with privileges issues:
Adding Reply URLs to your application through PowerShell script
Make use of application object's ReplyUrls list and Set-AzureADApplication command. Here's a quick sample script:
# ObjectId for application from App Registrations in your AzureAD
$appObjectId = "<Your Application Object Id>"
$app = Get-AzureADApplication -ObjectId $appObjectId
# reply URL to add
$newURL = "https://mynewurl"
# Existing reply URLs list
$replyURLList = $app.ReplyUrls;
$replyURLList.Add($newURL)
Set-AzureADApplication -ObjectId $app.ObjectId -ReplyUrls $replyURLList
Assigning correct privileges for execution of script
To execute your script as part of pipeline, this article provides very detailed step-by-step instructions: Set up continuous deployment in Azure Pipelines
I would point you to option 1 in the article, which talks about creating a separate application/service principal for executing the script. Once you do that, you can assign the required privileges to this service principal that will be used to execute the script and resolve your current issue of insufficient privileges.
Screenshot for important parts from article:
For step h, you can follow the first link to register application from Azure Portal.
Once you have the separate application/service principal created for executing script, please go to it's settings > Required Permissions
"Windows Azure Active Directory" should already be available in list of APIs (if not, you can click Add button to add it)
Pick the appropriate privilege under application permissions.
Make sure you go through Admin consent at the end of this process by clicking on the "Grant permissions" button at the end of this process.
When you adding a user to Azure Active Directory via the old portal you see this screen:
It allows you to add a user with an existing microsoft account.
I need to import many users with existing microsoft accounts. I'm planning on writing a powershell script to achive that.
How do I add an exising microsoft account to Azure AD with a powershell script?
New-AzureADUser complains that "userPrincipalName" is invalid, as can be seen in this question. Is there another way?
Unfortunately, Azure PowerShell modules do not support adding Microsoft accounts to Azure Active Directory. The only way to utilize this feature is to use the old Azure Portal https://manage.windowsazure.com/
This works using New-AzureADMSInvitation.
> Install-Module AzureAD
> Import-Module AzureAD
> Connect-AzureAD
> New-AzureADMSInvitation -InvitedUserEmailAddress 'test#test.com' -InviteRedirectUrl 'https://portal.azure.com'
Your output will contain an InviteRedeemUrl that the invitee should open in a browser which is already logged in with their Microsoft Account. There are other optional parameters that can be passed to New-AzureADMSInvitation. See the documentation here.
Are you sure you want to import all of the accounts? Azure Active Directory supports B2B model.
B2B is based on invitation model which lets you enable access to your corporate applications from partner-managed identities. You can provide email along with the applications you want to share and send invitation to your partners, customers or anyone else who have account in Azure Active Directory. Azure AD sends them an email invite with a link. The partner user follows the link and is prompted to sign in using their Azure AD account or sign up for a new Azure AD account.
In my opinion you don't have to import users. More info here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2b-collaboration-overview/
I want to get details of Azure Subscription of my client. But I do not want to ask for special permission from client.
What I need is the bare minimum things from my client so that I can login from powershell or rest api and read status of runbook jobs.
If i login from admin account of the subscription than I can easily get those details. But you understand it is not possible to have admin account credential of my client.
Please suggest some workaround.
What you need to do is create a user in Azure Active Directory and grant that user specific rights using either the Azure Portal or PowerShell\Cli\SDK.
Say read all, or read properties of desired automation account. If you would want like a super minumim, you would need to create a custom role first.
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
If your client placed specific resources within a Resource Group, they may grant you permissions on just that Resource Group (including read-only permissions). This would allow you to have access to needed resources, without having access to other areas of their subscription.
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
I created a KeyVault in my Azure subscription and a client application in one of my Azure AD directories. However, the client application is not registered in the default directory of the subscription.
When I run the following PowerShell cmdlet, it tries to look up the service principal in the default directory of the subscription and fails to find it.
PS > Set-AzureKeyVaultAccessPolicy -VaultName <vaultname>
-ServicePrincipalName <principal guid> -PermissionsToSecrets Get
I found an article describing how to change the default directory for a subscription in the management portal, but was wondering how to do the same using PowerShell.
The 'Select-AzureSubscription' cmdlet does not seem to support changing the default directory.
Nor does the 'Set-AzureKeyVaultAccessPolicy' support a parameter to indicate in which directory it should look.
Key Vault can only authorize applications (clients) registered in the directory associated with the Azure subscription, and the only way (currently) to change the 'home' directory associated with a subscription is through the Azure management portal.
I would imagine this is as designed behaviour, and can't imagine how / why it would change.
An Azure subscription has an Azure Active Directory attached to it, this is the directory it will use to authenticate against whenever someone tries to access resources.
While you can create trusts to other Active Directories simply creating an new AAD does not automatically enable that domain to be trusted by Azure.
Key Vault is designed to only be accessible to authenticated users, it is designed to provide secure data to those users. Since there is no authentication mechanism between the multiple directories you have created, there is no mechanism for Key Vault to determine who those directories belong to.
Key Vault needs to resolve a service principle through the Active Directory attached to the subscription it is running under (whether that is directly through that directory, or through another domain that it trusts). Anything else would create additional attack vectors and considerably weaken the product.