- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe to Topic
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Connect-AzAccount module doesn't work with Secure Application Model framework
Hello,
I'm trying to connect to Azure AzAccount PowerShell module using Partner Center refresh token.
I'm using the following syntax:
$azureToken = New-PartnerAccessToken -ApplicationId $Creds.UserName -Credential $creds -RefreshToken $Token.RefreshToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Tenant $CustomerTenantID
$graphToken = New-PartnerAccessToken -ApplicationId $Creds.UserName -Credential $creds -RefreshToken $Token.RefreshToken -Scopes 'https://graph.microsoft.com/.default' -ServicePrincipal -Tenant $CustomerTenantID
Connect-AzAccount -AccountId $graphToken.Account.Username -AccessToken $azureToken.AccessToken -GraphAccessToken $graphToken.AccessToken -TenantId $CustomerTenantID
$Creds contains my Application ID and the secret from my Partner Center tenant
$CustomerTenantID contains my Partner Center tenant ID. I tried with a specific customer tenant ID too, but it makes no difference.
After a lot of research and investigation, I manged to make the above commands to work.
But after executing Connect-AzAccount command, nothing really happens. When I try to execute
Get-AzSubscription -TenantId $Customertenant or Get-AzContext -ListAvailable I get nothing. No subscriptions listed and no cmdlets work in any of my customers tenants. I don't know why Secure Application Model is so purely documented or why things that should work actually doesn't.
Any help on this would be truly appreciated.
Thanks.
- Labels:
-
CSP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@ClaudioStallone Then I would recommend to raise a support ticket, e.g. there are specific topics for GDAP requests in Partner Center:
I did also reach internally and can update this thread once I learn more, still it would be good if all Partners that experience this raise tickets as well so there is some traction on this problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello @JanoschUlmer
Support ticket was opened: Your support request 2210110040002662 has been created
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@ClaudioStallone Hello! I checked on your support ticket and it shows you had a call later this morning. Can you confirm? Have you been able to resolve your issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@ClaudioStallone I have heard that were some problems with GDAP last week, but I don't know any specifics.
Regarding this specific problem there were two Partners I talked to that had the same error, and it could be resolved by ensuring the service principal (the app registration) is also a member of the security group where GDAP permission are being mapped.
For DAP/Secure App Model the documentation described exactly the same - "preconsent" required that the service principal/app was added to AdminAgents group, for GDAP you would additionally need to add it to a group that inherits customer permission. I can't tell why it did work initially and why it suddenly failed.
At least one option to try/check out before raising a support ticket 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
thank you for your reply, we have already made sure that the service principal (the app registration) is a member of the security group where the GDAP permission is mapped.
Unfortunately without success...
What can we do next?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello @sansbacher and @JanoschUlmer ,
since this week we have the problem that this command works only for customers with active DAP:
$graphTok = New-PartnerAccessToken -ApplicationId $ApplicationId -Credential $credential -RefreshToken $refreshToken -Scopes "https://graph.microsoft.com/.default" -ServicePrincipal -Tenant $Customer.CustomerContextId
For customers with active GDAP we get the following error:
We have already checked the Graph permissions and Admin Consent on the Azure AD application with the print screens above. Also these were removed and set again unfortunately without success.
We appreciate any ideas or help you can give us.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hi @ClaudioStallone ,
Your New-PartnerAccessToken command looks correct, and to confirm:
- It used to work for clients with GDAP, but only in the last week it stopped?
- It works for clients with DAP still?
- You are renewing the RefreshToken at least every 90 days?
- Nothing has changed on your end? Consent granted (and MFA was prompted), the account used to do Consent is still active, with MFA enabled, and IS a member of the AdminAgents Group and whatever GDAP Group has the Roles you need?)
From the other posts in the forums here I would guess you're not alone in experiencing the problem, perhaps there is an issue with GDAP vs DAP just now?
Unfortunately (well fortunately for me 🙂 we have not yet transitioned to GDAP, since MS announced they are extending the GDAP transition deadline, we have remained on DAP - so I can't easily test for you (without setting up a GDAP relationship, removing DAP for that client, and testing - which I did in the past and it worked). I don't know when the new deadline will be, but maybe these issues are contributing to it? @JanoschUlmer do you know when the new GDAP transition deadline will be announced? (it wasn't in the October announcement)
Perhaps @v-jillarmour can look into the GDAP permission problems if they are happening widely and can report back? Hopefully it's a temporary problem!
What happens if you add DAP back for one of the failing GDAP clients, does it start working again? Is the problem just GDAP itself, or is it just certain clients who happen to be on GDAP?
--Saul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hi @sansbacher
Thanks for your feedback.
- It used to work for clients with GDAP, but only in the last week it stopped?
- Yes, it used to work for GDAP customers as well.
- It works for clients with DAP still?
- Yes currently it works only for DAP customers
- You are renewing the RefreshToken at least every 90 days?
- Yes, I renew the refresh token every 40 day
- Nothing has changed on your end? Consent granted (and MFA was prompted), the account used to do Consent is still active, with MFA enabled, and IS a member of the AdminAgents Group and whatever GDAP Group has the Roles you need?)
- No, nothing has changed for us since the last time.
- What happens if you add DAP back for one of the failing GDAP clients, does it start working again? Is the problem just GDAP itself, or is it just certain clients who happen to be on GDAP?
- Yes it working gain, when we add DAP
Are you aware of anything that says this is a general problem at Microsoft? Or is there something specific that needs to be considered for GDAP customers?
We are currently completely blocked until this is resolved!
Best Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
I unfortunately am not part of the support or technical team, so am unable to look into any problems. I'm tracking this string and I'll do what I can do find resources to share. Apologies I don't know more! 🌻
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Noticed this:
When I try
$azureTok = New-PartnerAccessToken -ApplicationId $Creds.UserName -Credential $Creds -RefreshToken $refreshToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Tenant $CustomerTenantID
I get
New-PartnerAccessToken : AADSTS65001: The user or administrator has not consented to use the application with ID 'xxxx-xxxx-xxxxx' named 'App Name'. Send an interactive authorization request for this user and resource.
Then I did the client consent using the following URL
https://login.microsoftonline.com/<Customer Tenant ID>/oauth2/v2.0/authorize?client_id=<Application ID>&response_type=code&response_mode=query&scope=https://management.azure.com//user_impersonation&state=12345&prompt=consent
I consent with Global Admin account from the customer's tenant.
After that I get Azure Management Token.
And this is not expected - since you have DAP/GDAP you are not required to explicitly consent in the end customer tenant for this app, it should just work.
That said, I don't see an obvious reason - app permissions you describe look correct, the cmdlet looks correct, and dont see any difference to what works for me.
Hoping @sansbacher has additional ideas.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
I agree, you shouldn't need to do anything from a Customer Global Admin - I hope this is a typo "I consent with Global Admin account from the customer's tenant." You should be consenting with a Global Admin from your CSP/Partner Tenant.
No need to do anything with any accounts from any Customer tenants. In order to Consent you must use a Global Admin (since you are consenting on behalf of your entire organization - the CSP Partner). The UPN account (used for some of the connections) needs to be an AdminAgent (since it needs Delegated permissions to your Customers' tenants). These can be different accounts, but the UPN account needs to remain an AdminAgent (if you are using DAP).
I have tested with GDAP and confirmed that: removing a Customer from DAP, but adding them to GDAP, and then adding that UPN account to one of the GDAP Security Groups (eg. one with Global Admin role) works.
I'm not sure what the issue is. Have you tried with multiple Customers? If some work and some don't, can you see their Subscriptions when logged in to the Azure management web GUI from the Partner Center? If not, you may need to wrest control back.
You said "I managed to successfully connect to Partner Center, Exchange Online, AzureAD and MSOL" -- meaning you can connect to multiple Customers (one at a time) and access their data using, say, Get-Mailbox and Get-AzureADUser?
If the issue is just with the 'https://management.azure.com/user_impersonation' scope then I suspect some permission is missing from your Azure AD App Registration. Did you add the permissions for Azure Service Management and Microsoft Graph as "Delegated" (not Application) and they show as Status = Granted for YourTenantName with green check marks?
Like:
If so, maybe there are other ones that need to be added I had already added, but didn't know I needed. Here's the rest of mine:
Maybe add those too? I mainly use: Azure, Azure AD, MSol, and Exchange Online.
@JanoschUlmer I have used MgGraph module, you can connect with a new MS Graph Token:
$graphToken = New-PartnerAccessToken -ApplicationId $applicationId -Scopes ‘https://graph.microsoft.com/.default’ -RefreshToken $refreshtoken -Credential $credential -Tenant $tenantID
and:
Connect-MgGraph -AccessToken $graphToken.AccessToken
Then something like (or any Mg cmdlet):
Invoke-GraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/Groups/'
But I find it easier to just do direct API calls since all the many (MANY!) MgGraph cmdlets are just thin wrappers for every API endpoint and every REST verb, and don't provide much actual "value" in terms of wrapping up useful functions into PowerShell functions.
Anyway, @igor-stajcic you could try re-creating your Azure AD app, the official process is listed here, which has a section for Azure PowerShell.
But my money is on A) you need to double check the API permissions on the App Registration, and B) do all Consents with your Global Admin + AdminAgent accounts - not Customer ones. (AdminAgent if DAP, or whatever group with the correct Roles -> Group mapping you have set up for GDAP)
In looking at my code:
- I always connect to MY CSP Partner Tenant first, grab all the Customers/Clients, then disconnect.
- Then use a foreach ($Customer in $AllCustomers) { ... } loop
- In that loop I connect to the Customer's Azure AD (because I invariably need to) which involves getting all new Customer Azure AD and Graph tokens, and then Connect-AzureAD with them and the UPN account (which has AdminAgent permissions)
- I can then do things like: Get-AzureADUser, and not need to specify any -Tenant or -TenantID, etc.
- Then connecting to the Customer's Azure which involves getting all new Customer Graph and Azure tokens, running Clear-AzContext, then Connect-AzAccount with the Tokens and the UPN account.
- I can then do Azure things, like Get-AzContext or Get-AzVm without needing to add any -Tenant or -TenantID, it just works.
- When done I disconnect both before looping again. (if processes take longer than 60 mins you'll need to renew your AccessTokens...)
I'm using AzureAD module 2.0.2.135. For the Az module I'm using version 7.5.0. I think version 7 is the minimum version now. (it has Az.Accounts 2.9.0 and Az.Resources 6.0.1 - those are the critical ones to connect)
I hope some of that helps!
--Saul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@rigo : Adding to @sansbacher - It is really important to get $azureToken & $graphToken against the end customer tenant ID.
If you are using GDAP already, and the AdminAgent user you have used for connecting/creating the token is also subject to a GDAP permission, make sure you implement the documented approach of assigning GDAP permission to a nested group under AdminAgents - and make the user a member of this group. See the esection for Azure portal here for more information: Workloads supported by granular delegated admin privileges (GDAP) - Partner Center | Microsoft Learn
Also, for the AZ module, it is important that you use -tenantid parameter for connecting, not -tenant (not the domain name) - otherwise you land in the wrong context (Learned this myself the hard way). Since you mentioned "nothing" happened it seems you are in the wrong tenant context, and in your Partner tenant there is no subscription you have access to.
It might be too late now since you have already invested in research, but if you need assistance in getting this up and going my team can provide a consultation on this - you can raise a request via https://aka.ms/technicalservices. We are not doing troubleshooting though - maybe the problem you have can be solved by discussing the overall approach.
@sansbacher btw - Using MgGraph powershell also works with using the similar Graph token created against the customer tenant, just tested this last week - since this replaces most of MSOL and AzureAD cmdlets I thought I mention it here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello @igor-stajcic ,
I use the Secure App Model to connect to Azure (and Azure AD, Msol, and Exch Online). I would suggest reading through the threads in this Secure App Model community, especially my reply in this one: https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/Exchange-Online-and-the-Secure-App-Model/m-p/15421/highlight/true#M125
(It's not about Azure, but ensure you can connect to Azure AD first)
You will need to ensure that you have the Partner Center Native App set up, which is detailed in Kelvin's blog. You may need to add some additional permissions to your App Registration in AAD:
Azure Service Management:
user_impersonation
Microsoft Graph:
Directory.AccessAsUser.All
offline_access
openid
Then you'll need to do the CSP Partner Connection first in order to get your Customers/Clients using Get-AzureADContract, see my reply I linked to above. Then you need to connect to that specific Customer. For Azure resource management this should work:
# Need Azure token and a new Graph token:
$graphTok = New-PartnerAccessToken -ApplicationId $ApplicationId -Credential $credential -RefreshToken $refreshToken -Scopes "https://graph.microsoft.com/.default" -ServicePrincipal -Tenant $Customer.CustomerContextId
$azureTok = New-PartnerAccessToken -ApplicationId $ApplicationId -Credential $credential -RefreshToken $refreshToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Tenant $Customer.CustomerContextId
Clear-AzContext -Force
Connect-AzAccount -AccessToken $azureTok.AccessToken -AccountId $Upn -GraphAccessToken $graphTok.AccessToken -TenantId $Customer.CustomerContextId
# Especially if there's multiple Subscriptions
Get-AzContext -ListAvailable | where {$_.Subscription.Name -eq 'Microsoft Azure'} | Select-AzContext
# Can now do:
Get-AzVM
You do connect using YOUR TenantID (to get all Customer details), but then you disconnect and re-connect using Customer's Tenant ID, getting all NEW AccessTokens. (and a new one if connecting to Azure vs Azure AD). Azure access requires an Azure token and a Graph token. Azure AD access requires Azure AD and Graph.
Disconnect one Customer's Azure before connecting to another, with:
Get-AzContext | Disconnect-AzAccount
Clear-AzContext -Force
I hope that helps or at least points you in the right direction. There's probably not much use in connecting to Msol these days (except for MFA info), and if you don't need ExO then you can skip that. But definitely get things working with Azure AD first (connect to your tenant, get all customers, disconnect, and then connect to each Customer's Azure AD), and then add in Azure to the mix.
--Saul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello @sansbacher
Thank you for such a detailed reply.
Here is what I did:
My Partner Center account in MFA enabled and has Global Admin and Admin Agent permissions in Partner Center. This will not stay that way, but for now, I want to eliminate the permissions problem at this stage of troubleshooting.
I created the application in my Partner Center tenant using the script from the link you posted. https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/Exchange-Online-and-the-Secure-App-Model/m-p/15421/highlight/true#M125
I ran the script with PowerShell 5.1, did all the consents and authentication prompts using my Partner Center account. The script ran without issues.
After the application was created I moved urn:ietf:wg:oauth:2.0:oob redirect URI from Web to Public client/native (mobile & desktop).
I added the additional permissions as you suggested and Granted Admin Consent
Azure Service Management:
user_impersonation
Microsoft Graph:
Directory.AccessAsUser.All
offline_access
openid
Then I tried to connect to Partner Center, Exchange Online, AzureAD, MSOL and AzAccount modules using the application ID/Secret and the tokens generated by the script.
I manged to successfully connect to Partner Center, Exchange Online, AzureAD and MSOL.
But AzAccount module is still not working.
When I try
$graphTok = New-PartnerAccessToken -ApplicationId $Creds.UserName -Credential $Creds -RefreshToken $refreshToken -Scopes "https://graph.microsoft.com/.default" -ServicePrincipal -Tenant $CustomerTenantID
I get the Graph token
When I try
$azureTok = New-PartnerAccessToken -ApplicationId $Creds.UserName -Credential $Creds -RefreshToken $refreshToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Tenant $CustomerTenantID
I get
New-PartnerAccessToken : AADSTS65001: The user or administrator has not consented to use the application with ID 'xxxx-xxxx-xxxxx' named 'App Name'. Send an interactive authorization request for this user and resource.
Then I did the client consent using the following URL
https://login.microsoftonline.com/<Customer Tenant ID>/oauth2/v2.0/authorize?client_id=<Application ID>&response_type=code&response_mode=query&scope=https://management.azure.com//user_impersonation&state=12345&prompt=consent
I consent with Global Admin account from the customer's tenant.
After that I get Azure Management Token.
Then I ran
Connect-AzAccount -AccessToken $azureTok.AccessToken -AccountId $UPN -GraphAccessToken $graphTok.AccessToken -TenantId $CustomerTenantID
I get connected, but I still can’t set the context. The customer tenant that I'm working with has two active subscriptions and running get-azcontext -ListAvailable comes empty as before, so I'm not able to set the Subscription and therefore I'm unable to use the AzAccount module against the customer's tenant.
What am I missing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello @igor-stajcic
we currently have the same problem.
Do I understand correctly that new, the Admin Consent at the customer tenant also be set?
What is the solution here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Just wanted to add that @ClaudioStallone is correct, what he found works. I was able to work out the exact steps based on what Janosch posted, and confirmed it works with Connect-AzAccount and bypasses the AADSTS65001 error. You can see my steps and info in the same thread Claudio linked to here:
I hope that helps!
--Saul
