Given two independent organizations Ciccio and Pierino, Ciccio has an AAD of which bepi#pierino.com is a guest user with the role of global administrator, Ciccio wants bepi#pierino.com to create the first Azure Sphere tenant... it is possible for bepi#pierino.com do the first "azsphere login" inside the Ciccio Active Directory? Such as?
this is the error message encountered
azsphere login
error: You could not be authenticated: AADSTS650051: Using application 'Azure Sphere API' is currently not supported for your organization pierino.com because it is in an unmanaged state. An administrator needs to claim ownership of the company by DNS validation of pierino.com before the application Azure Sphere API can be provisioned.
Trace ID: 3a0aad18-5fe6-45cc-89ea-6989317a1400
Correlation ID: 9852e07b-73f5-4b62-a710-258c1bbaa740
Timestamp: 2019-09-11 14:45:25Z
error: Command failed in 00:00:45.7810542.
Azure Sphere team is making a few improvements to this area soon. Hope you can wait for a few more weeks on this issue.
Related
I'm unable to create a Cloud Function in my GCP project using GUI, but have admin roles for GCF, SA and IAM.
Here is the error message:
Missing necessary permission iam.serviceAccounts.actAs for
cloud-client-api-gae on the service account
serviceaccountname#DOMAIN.iam.gserviceaccount.com. Grant the role
'roles/iam.serviceAccountUser' to cloud-client-api-gae on the service
account serviceaccountname#DOMAIN.iam.gserviceaccount.com.
cloud-client-api-gae is not an SA nor User on my IAM list. It must be a creature living underneath Graphical User Interfrace.
I have Enabled API for GCF, AppEngine and I have Service Account Admin role.
I had literally 0 search results when googling for cloud-client-api-gae.
I've contacted GCP support and it seems my user was missing single role:
Service Account User - that's it.
PS: Person from support didn't know what this thing called "cloud-client-api-gae" is.
Saw the same thing. You need Service account user on the SA you plan to deploy the CF onto. The same incorrect identity was shown.
The user account attempting to create cloud function, need to be given "Service account user" role on the Service account they are using for this cloud function to run on.
I have registered APP in Azure Portal and successfully generated credentials in Microsoft Graph API. after outlookmail.init Operation in WSO2 EI, i am getting below ERROR.
ERROR:
{"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier 'a4935017-80e8-4413-a762-780b32d8f968' was not found in the directory 'e5e67d60-adf4-40b4-883c-351dc2feef4e'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.\r\nTrace ID: 4ecb19d5-e66b-40c1-9a15-7237a0d4c801\r\nCorrelation ID: 818ba54d-f5e5-43df-9201-96d71f598b1f\r\nTimestamp: 2021-07-08 10:14:35Z","error_codes":[700016],"timestamp":"2021-07-08 10:14:35Z","trace_id":"4ecb19d5-e66b-40c1-9a15-7237a0d4c801","correlation_id":"818ba54d-f5e5-43df-9201-96d71f598b1f","error_uri":"https://login.microsoftonline.com/error?code=700016"}
CODE:
<outlookmail.init>
<accessToken>{$ctx:accessToken}</accessToken>
<apiUrl>{$ctx:apiUrl}</apiUrl>
<apiVersion>{$ctx:apiVersion}</apiVersion>
<refreshToken>{$ctx:refreshToken}</refreshToken>
<clientSecret>{$ctx:clientSecret}</clientSecret>
<clientId>{$ctx:clientId}</clientId>
<redirectUri>{$ctx:redirectUri}</redirectUri>
<resource>{$ctx:resource}</resource>
<registryPath>{$ctx:registryPath}</registryPath>
<intervalTime>{$ctx:intervalTime}</intervalTime>
</outlookmail.init>
<log level="full"/>
Application in Azure Portal:
I have seen error code in this site which says like below.
This usually occurs when the client application isn't registered in Azure AD or isn't added to the user's Azure AD tenant. The application can prompt the user with instruction for installing the application and adding it to Azure AD
Can anyone please help me to resolve this?
Not sure if it helps, but I had a lot of similar problems with graph / wso2. Here a few things to check.
1.) check that the access/api is created by an administrator
2.) check that the api has "admin consent"
3.) i had to add a "access key" and use that one
4.) check that you use the ConfidentialClientApllication builder if you use JAVA SDK
Beside that there were a few pages that helped me to get it working.
https://blogs.aaddevsup.xyz/2020/04/implement-client-credentials-flow-for-graph-java-client/
https://learn.microsoft.com/en-us/graph/tutorials/java
Regards
Martin
As the title says, I have a user "User1" in a group "Techs" and "Techs" is a Role Enabled Azure AD, Cloud Only, Security Group that is assigned both the Exchange Administrator, Helpdesk Administrator and Exchange Recipients Administrator roles.
User1 is able to powershell and use most cmdlets for mailbox management, but is unable to access the EAC. Attempting to access EAC sends User1 to a mailbox management page for their own mailbox, and attempting to Edit Mailbox Properties for a user in the Microsoft 365 Portal greets User1 with a 403 forbidden page.
Direct assignment of exchange admin role works, but defeats the purpose of using a group. Anyone else experience this or know how I can fix it?
Currently, it is possible to switch back to the existing EAC (often called the "classic" EAC), but at a future date, the classic EAC will be retired.
But I suggest not to use "classic" EAC for work because according to my test, the methods listed here cannot allow the exchange admin to manage the mailboxes in the tenant.
It's recommended to access new EAC using these 2 methods.
Sign in to Microsoft 365 or Office 365 using your work or school account.
In the left navigation pane, navigate to Admin centers > Exchange.
You can also get to the new Exchange admin center directly by using
the URL https://admin.exchange.microsoft.com and signing in using your
credentials.
As the document suggests, Be sure to use a private browsing session (not a regular session) to access the Exchange admin center using the direct URL. This will prevent the credential that you are currently logged on with from being used.
In this way, your user which is assigned Exchange Admin role with Group inherit way should be able to access EAC successfully.
How can I find out what admin permissions are blocking the user from signing in to an Azure AD app?
I am setting up an App Registration in the Azure AD portal to be used with my Service Fabric cluster. The app registration does basic auth and only has one Required Permission configured: Sign in and read user profile (which does NOT require admin permission).
My tenant has the "Users can consent to apps accessing company data on their behalf" setting to "Yes", so it's not that.
Also, the /authorize request doesn't have any resource parameter, so it's implicitly asking for the permission I configured: Azure AD's Sign in and read user profile.
However when an non-admin user attempts to sign it, I still get the error:
AADSTS90094: The grant requires admin permission
I reproduced the scenario and this is what I observed. Found a workaround, hope it helps.
First I created a Service Fabric (SF) cluster secured with AAD authentication using the steps described here, using an AAD tenant where I am not a global admin.
Then I tried to login to Service Fabric Explorer (SFX) and I got this error:
AADSTS50105: The signed in user is not assigned to a role for the
application 'f8c79129-deb7-4a21-a6e0-ec29e88298ef'
This is expected, because the user must be assigned to a role (Admin or ReadOnly) in the SF application that represents the cluster. So I went to AAD > Enterprise Applications > found my cluster app and under Users and Groups I added myself to the Admin role. Notice that the fact that a regular user can administer the roles of an application that the user owns is something new, it's available since a month or so -- before that, a regular user couldn't administer the roles of an application.
Then I tried to login again to SFX and I got a different error:
AADSTS65005: Invalid resource. The client has requested access to a
resource which is not listed in the requested permissions in the
client's application registration. Client app ID:
f8c79129-deb7-4a21-a6e0-ec29e88298ef. Resource value from request: .
Resource app ID: 00000002-0000-0000-c000-000000000000. List of valid
resources from app registration: .
00000002-0000-0000-c000-000000000000 is Windows Azure Active Directory. For some reason SetupApplications.ps1 doesn't assign the Sign in and Read User Profile permission to the SF cluster application. So I edited the application and I assigned that permission, just like you showed in your print screen. Notice that SetupApplications.ps1 has a parameter AddResourceAccess (not mentioned in the doc) that adds that permission, not sure why it doesn't add it by default. Perhaps it isn't needed when you run SetupApplications.ps1 as a global admin, and the scripts/doc assumes that you are a global admin.
Then I tried to login to SFX again and I got the same error that you observed:
AADSTS90094: The grant requires admin permission.
So I checked the SF application under AAD > Enterprise Applications > found the SF cluster app > Properties. User assignment required is configured "Yes". I changed it to "No" and tried to login to SFX. This time it worked OK, I could consent and access the SFX console. Then I changed User assignment required again to "Yes".
One can argue if the SF app really needs User assignment required > Yes because anyway if a user is not assigned to the Admin or ReadOnly role, SFX will try to fallback to client certificate authentication.
In either way, the AAD behavior is confusing. At least, the error should be more descriptive and point to the User assignment configuration. Perhaps the current behavior has to do with what I mentioned before, that regular users can now administer roles. Perhaps the behavior is being improved.
I configured a AD FS 3.0 server an proxy and federated this with Office 365.
The active directory domain name is domain.local, the users email address is domain-plus.be. It's not an option to change the users UPN so I chose to configure the alternative login ID for Office 365. I also changed the Microsoft Office 365 Identity Platform claim following this post.
That way users would be able to login to adfs with there email address user#domain-plus.be without changing the upn.
Now i'm experiencing the following situation:
When I login to a domain joined computer and add the AD FS signin page URL in the internet sites of the user. The user navigates to https://portal.office.com, enters his emails address and is redirected and automatically logged on to the Office 365 portal. No password is requested, as it should be.
When I use the same domain joined computer and use Chrome instead of IE, i'm redirected to the AD FS signin page after entering the email address on https://portal.office.com. But when I enter the password in there I get the following error in the AD FS logs:
Protocol Name:
wsfed
Relying Party:
urn:federation:MicrosoftOnline
Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8013: CanonicalName:'' of the user:'CN=Testmailmigration,OU=Users,OU=Bio,DC=BIO,DC=local' is in bad format.
The user is still the same user that was logged on to the Office 365 portal minutes ago. There users are working internally so the AD FS proxy is not used.
When I try to login external I experience the same issues as the 2nd
scenario.
The username and password are correct, that we can conclude from scenario 1.
Does someone also experienced this error when configuring a simular setup?
Thanks in advance,
Gijs.
We were able to resolve the issue with Chrome by expanding the SupportedUserAgents on ADFS with the following command:
Set-AdfsProperties –WIASupportedUserAgents #("MSAuthHost/1.0/In-Domain","MSIE 6.0","MSIE 7.0","MSIE 8.0","MSIE 9.0","MSIE 10.0","Trident/7.0", "MSIPC","Windows Rights Management Client","Mozilla/5.0","Edge/12")
Regarding the authentication issues, we noticed that there were special read permissions on the OU were the users existed. These permissions were changed on purpose or because of a software installation (like a cpsm portal).
Authenticated users were not able to do a full read on the OU anymore, so a LDAP query wasn't possible.
We gave our service accounts full read rights on the necessary OU's which solved the issue.
So in our case the following error wasn't about receiving data in bad format, we couldn't read the data at all.
Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8013: CanonicalName:'' of the user:'CN=Testmailmigration,OU=Users,OU=Bio,DC=BIO,DC=local' is in bad format
Regards,
Gijs