SOLVED

Access denied for Set-AzureADApplicationProxyApplicationCustomDomainCertificate

Copper Contributor

I am automating binding a custom certificate to an application published with the Azure AD Application Proxy. I can upload and bind the certificate in the Azure Portal.

 

Logged on with Global Administrator role in PowerShell, I use the AzureAD module with Set-AzureADApplicationProxyApplicationCustomDomainCertificate. After entering the password for the Pfx, the response is "Access Denied".

 

Any idea why this is not allowed via script?

 

 

3 Replies

Have you looked at our guidance on certificate to make sure you have the appropriate format: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-cust....

 

best response confirmed by nextxpert (MVP)
Solution

Yes, I did use that article and the documentation on the cmdlet as the source to use the cmdlet. 

 

The article doesn't mention that unlike when using the Azure Portal, this cmdlet requires you to run in an elevated PowerShell session with local administrator rights.

 

When not run elevated, the response is "Access Denied".

 

I am clueless what the local administrator rights are for when uploading a certificate to Azure.

 

I proposed a change in the documentation at docs.microsoft.com to mention the requirement for an elevated PowerShell session.

Thanks Raymond! I will make sure the doc change is also made.
1 best response

Accepted Solutions
best response confirmed by nextxpert (MVP)
Solution

Yes, I did use that article and the documentation on the cmdlet as the source to use the cmdlet. 

 

The article doesn't mention that unlike when using the Azure Portal, this cmdlet requires you to run in an elevated PowerShell session with local administrator rights.

 

When not run elevated, the response is "Access Denied".

 

I am clueless what the local administrator rights are for when uploading a certificate to Azure.

 

I proposed a change in the documentation at docs.microsoft.com to mention the requirement for an elevated PowerShell session.

View solution in original post