Skip to content
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.

Application stopped to work due to recent Azure AD changes #26

Open
centur opened this issue Sep 1, 2015 · 9 comments
Open

Application stopped to work due to recent Azure AD changes #26

centur opened this issue Sep 1, 2015 · 9 comments

Comments

@centur
Copy link

centur commented Sep 1, 2015

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

@AndyCross
Copy link

I'm also receiving this error today.

@dkershaw10
Copy link

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!

@centur
Copy link
Author

centur commented Sep 2, 2015

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.

@AndyCross
Copy link

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

@centur
Copy link
Author

centur commented Sep 2, 2015

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...

@centur
Copy link
Author

centur commented Sep 2, 2015

added some extra details to SO question.
I'm trying to work on raw https level using fiddler. it's either graph.api oauth2 is broken or something is broken in admin consent flow - I granted all possible permissions to my app, can aquire token with many scopes but post to /users endpoint still gives me "insufficient privileges".

@centur
Copy link
Author

centur commented Sep 3, 2015

@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 :

Calendars.Read
Calendars.ReadWrite
Contacts.Read
Contacts.ReadWrite
Directory.AccessAsUser.All
Directory.Read
Directory.Write
Files.Read
Files.Read.Selected
Files.ReadWrite
Files.ReadWrite.Selected
Group.Read.All
Group.ReadWrite.All
Mail.Read
Mail.ReadWrite
Mail.Send
offline_access
openid
Sites.Read.All
Sites.ReadWrite.All
User.Read
User.Read.All
User.ReadBasic.All
User.ReadWrite
User.ReadWrite.All
user_impersonation
UserProfile.Read

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.

@centur
Copy link
Author

centur commented Nov 12, 2015

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.

@dkershaw10
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants