Today I was trying to add an external user to VSTS and got below error message.
You are trying to invite a user from outside your directory, but
something went wrong. Please try again later. If the issue persists,
please contact support.
I have followed the step mentioned in below link and "External guest access" is enabled.
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/add-external-user?view=azure-devops&viewFallbackFrom=vsts&tabs=new-nav
Not sure where I am going wrong with this and looking for a solution.
After signing-out and sign-in again it works.
It seems this happened after password reset for my AAD account.
The reason was a missing refresh of the user AAD token. After
completely signing out from Azue DevOps (deleting all browser caches)
it was working.
Source: https://developercommunity.visualstudio.com/t/you-are-trying-to-invite-a-user-from-outside-your/395999
Before this will work, you need to have the external domain added as an approved domain for collaboration. Then you will be able to invite them to your Office 365/Azure tenant. I had to have this approved through Global Security and then the work was done for our organization.
For future reference, I had a similar issue and discover that Project Collection Administrators/Owners manage the policy: Allow team and project administrators to invite new users.
Source Azure DevOps Documentation
Related
The problem: I'm getting errors from Google while attempting SSO through Azure AD and can't even begin to guess why or how to go about debugging the issue.
The story:
My org is looking at leveraging Microsoft's nonprofit benefits by setting up Azure for web hosting and Sharepoint to start with, which also entails using Active Directory. As it stands right now, we've successfully gotten our website running and accessible to the world on our custom domain, and our AD is populated with a copy of what's in our Google Workspace directory so we can use Active Directory as our authoritative directory.
We've been trying to implement SSO with the Azure/Gsuite connector, to have them auth with their Azure credentials to get into GMail, Docs, Drive, etc, but Google Workspace seems to choke. I have gone over the setup instructions repeatedly, ensured we're using all of the proper URLs in the Connector's SAML settings and in Workspace's "SSO with third party IDPs" settings, the proper certificate is in place... Provisioning is set up but not active, and I have successfully provision-on-demanded my account and an unprivileged test account.
Here are my settings in Azure:
Here are my settings in Google:
And to test this here's what I've done:
I open up a fresh InPrivate/Incognito window.
I go to https://myapplications.microsoft.com/ and am prompted to login. I use my unprivileged test account credentials.
Upon auth I click on the Connector app to attempt to go to my Gmail inbox.
After a wait on a white screen, I get a Google error screen with "Invalid Email - We are unable to process your request at this time, please try again later."
If I disable the SSO settings for my org in Google Admin, I'm able to log into the account just fine with Google, get to the gmail inbox, etc.
Conversely, if I attempt the same steps with my admin account, I get a similar page with a slightly different message, "Server Error - We are unable to process your request at this time, please try again later."
I have been bashing my head against this for two whole nights and can't make any headway. What gives? I can't even figure out how to debug these errors.
Somebody (me) failed their perception check repeatedly because the problem was that the Unique User Identifier SAML claim in Azure was set to user.mail instead of user.userprincipalname as it should have been as per the tutorial.
I'll see myself out now.
I'm trying to access sharepoint site lists with MS Graph.
I've got application permissions Sites.Selected admin consent.
The global admin is getting a 403 when doing post to add permission to the specific site in graph explorer
POST https://graph.microsoft.com/v1.0/sites/{siteId}/permissions
I signed up to microsoft 365 developer account and got a sandbox AAD and sharepoint site.
The permissions POST worked for the main account I got when creating the sandbox.
Sites.Selected works fine for my test app.
Now I'm trying to figure out if maybe the global admin is not the person who has access to granting site permissions.
I gave global admin to a user and got a 403 trying to get permissions from the specific site.
I gave sharepoint admin to a user and got 403 trying to get permissions from the specific site.
Would anyone know what role is needed to do the POST (or
GET)
https://graph.microsoft.com/v1.0/sites/{siteId}/permissions
EDIT
Well after paying closer attention to my sandbox global admin...he was indeed missing the permission Sites.FullControll.All in graph explorer.
I saw a checkmark besides it and quickly thought "he's got it already!!" but the checkmark is in the column "Admin consent required", just can't see the column title after scrolling down to sites. It needs to say "Consented".
EDIT2
So the POST to grant permission to read or write only seems to work in the sandbox. This was brought up to Microsoft and they didn't really explain why it worked in the sandbox, only that the only supported way it works is if an application with Sites.FullControll.All makes the POST.
If you come across posts/websites saying it works with graph explorer, they probably only tried it with a sandbox. I assume this will also fail with the 3rd method of granting the read/write permission to a site with powershell.
According to the documentation list permissions API supports only Application permission type and requires Sites.FullControl.All permission.
I have recently Registered a Keycloak Application on my Azure AD B2C tenant, one of my colleagues accidentally deleted the registration, so i have restored the application on the Azure portal, Later i tried changing the Redirection URI, but the Azure portal doesn't allow me to do so and shows the below error
"Failed to update KeyCloak application. Error detail: Encountered an internal server error."
I have tried to change the same in the Manifest and tried to upload file, even it shows the same error.
Did my application restore made any difference here, if it was so please suggest me some check points to solve this.
Note : The other applications in this tenant allow me to do same changes, I have issue only with this application registration.
A bug has been filed and the product team is working on it. In the mean time for the work around Please re-create another app if possible.
You could also try to change "SignInAudience" to "AzureADMultipleOrgs" (if it works) - than you'll be able to modify reply urls and switch "SignInAudience" back.
I am currently developing a service that would be able to sync data between workforce management systems (like Kronos WFC) and Microsoft Shifts. In order to sync the data, I have to register a Workforce Integration. I have established the necessary permissions, but I am not able to add permissions and I'm returned a message on the Azure Portal that permissions are not supported. The tenant that I'm using for development has also been whitelisted. Ideally whitelisting should be solving all problems when it comes to adding Graph API scopes, but in this instance, the whitelisting does not seem to resolve. Any ideas as to why such thing is happening?
Some Graph permissions are not allowed on applications that support Microsoft accounts authentication (e.g. Skype, Xbox, Hotmail). The WorkforceIntegration permissions are one of them.
The idea is that some O365 enterprise services are not available to consumer Microsoft accounts. Unfortunately I don't know where these permissions are documented but please comment if you find the list.
Sometimes, it could be a temporary error. You may have another try at a later time.
Please do not add too many permissions at one time. I tried to add that permission and got a success:
By the way, as Azure AD V2 supports to grant permission dynamically. You may directly add and grant permission to a new scope.
Note: I just want to show you the detailed flow, but in fact all the
following steps can be done with ADAL or MSAL.
For example:
I did not have https://graph.microsoft.com/Chat.ReadWrite permission at first. But I can request that permission dynamically through Azure AD OAuth2 authorization code flow:
A. Make a request call to
https://login.microsoftonline.com/<your_tenent_id_or_name,hanxia.onmicrosoft.com>/oauth2/v2.0/authorize?response_type=code
&client_id=88b1****-***-****-****-f64c****9f8a
&redirect_uri=https://localhost/
&scope=https://graph.microsoft.com/Chat.ReadWrite
B. Grant the permission
C. Check the permissions in Enterprise Application
You can see that a new permission was added. And then uses in the tenant can use that permission scope.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.