- last edited on
We have a on premise app published on Azure and when I try to access the to the app API's I always get below error. User already have the access to App proxy and the app behind the proxy.
What access I need add in addition to proxy & App access. I am generating the token using client credentials flow.
Azure AD Application Proxy
Status code: Unauthorized
Timestamp: 3/6/2018 9:54:11 AM
Authorization failed. Make sure to assign the user with access to this application.
03-08-2018 02:58 AM
The error message suggests that you didn't authorize the user to the specific application. If you go to Azure Active Directory => Enterprise Applications => "Application Name".
Is the user visible under Users and Groups there?
If that's not the problem, do you see any additional error messages in the eventlog on the Application Proxy?
03-08-2018 04:59 AM
03-08-2018 05:40 AM
If you logon to the server where the Azure AD Application Proxy is installed, you can examine the Eventlogs with Eventviewer: Start => CMD => eventvwr.
Under Application and Services Logs => Microsoft => AadApplicationProxy => Connector => Admin you can see the events regarding your application proxy. Search for errors or warnings regarding your application..
If there aren't any logs generated, that means that there's something wrong with the configuration of the specific app in Azure AD and that the traffic never lands on the Azure AD Application Proxy.
05-30-2018 10:51 PM - edited 05-30-2018 10:55 PM
I had the same problem with proxy app registrations, in our own domain and in a customer domain. The 401 error already occurs when acquiring a token, before trying to read or write any data.
I found a solution, hinted by a remark in this StackOverflow answer:
Your problem have something to do with the valid audiences.
The problem is that the "audience" of a proxy app is not in the active directory domain, but in msappproxy.net. Hence, it fails the audience check and a 401 eror is raised when attempting to get an access token relating to the AD domain.
My solution: create a second app registration for API access. In my case, the API part of the software just needed to read directory groups and member lists, that is possible independent from whoever is logged in through the web user interface if Microsoft graph is used.
When creating the second app, I use any name and a random Sign-on URL in my AD domain:
A second inclarity in the Azure Portal user interface is in granting the API application access.
When you go to Settings > Required permissions, you add some categories and click Save. However, the permissions are not effective until you also clicked "Grant access" on top of the main "Required permissions" panel. As it is counter-intuitive that you have to click in two different places to save one setting, that is often overlooked by admins configuring our web API.