-
Notifications
You must be signed in to change notification settings - Fork 78
Application stopped to work due to recent Azure AD changes #26
Comments
I'm also receiving this error today. |
Hey folks. Sorry for the issue. Can you report this issue on StackOverflow please? Can you provide more details like a timestamp and correlationId/requestId so we can track down the problem? Any further details would be appreciated - thanks! |
Done. See SO question here I think I've identified the problem but can't figure out how to fix it - see the question and sample responses - default auth token scope became very narrow and it's just "UserProfile.Read". Which explains almost everything, except - why it suddenly changed on the server-side ( I suspect some Portal or AzureAD 'defaults' were updated, which is almost a WTF...) and how to pass extra scopes to that request using the library call. |
Our code works this morning; the error resolves from "Insufficient Privileges" to "Nickname is required" - the same code gives a different error this morning. Correctly adding a Nickname now makes our code resolve. So it could be that our issue was separate and transient (consistency of permissions? hard to say from outside) and not related to @centur |
By the Nickname you mean MailNickname property of user object ? that was always mandatory and unique. As you can see in my LinqPad sample - I'm setting it properly. So it might be that your issue is unrelated. I've spotted the cause - Native client app scope is very narrow, I just can't find any way to workaround the problem. And MS is pretty unresponsive about that, not mentioning the lack of documentation about possible scopes... |
added some extra details to SO question. |
@dkershaw10 I think I narrowed the problem down to a level when I have 2 raw http requests in Fiddler - one is to get token and one is to create user with this token, both are written according to latest GraphAPI documentation and it looks valid from Oauth2 perspective too. But fist one is working fine, and the second one is failing. You can see shadow copy of the SO thread in a Azure Talk Yammer group. There is some sensitive information that I can't put in SO question, so if you have a chance - can you take a look on it there or ping me on alexey at shcherbak-dot-me and I can send you small sample to experiment. The current state of the problem - REST API call to Graph API endpoint to create user according to GraphAPI interactive documentation failing, even if I have these scopes in my access token :
There is no way to obtain Directory.ReadWrite.All scope as per current azure portal interface. As an admin I've checked in all possible permissions for all possible Microsoft applications there, including preview ones. |
I think no-one really interested in solving this issue. We gave up on Azure AD so far because of this showstopper and this problem not affecting us anymore. Good luck to others who relies on these "samples". Stackoverflow question is also has lack of attention so it's unclear to me what was the point to move shit from one silo to another. |
Really sorry about this. I was hoping the SO posting was going to get more attention. I'm responding there. Let's see if we cannot resolve this issue for you. I have some clarifying questions that should hopefully get to the bottom of this. And again - many apologies for the unresponsiveness here. |
Hi.
Seems that some recent updates break application clients.
The code that was working perfectly is now broken, all user update\delete operations are returning
Error creating new user. One or more errors occurred. Insufficient privileges to complete the operation.
This happens even if I'll grant all possible permissions to my registered Native Client application (as per readme.md guide).
This is pretty bad problem, as we can't create\register users from native client anymore
The text was updated successfully, but these errors were encountered: