I need to know if there is a possibility to get all Azure AD users using PowerApps or not.
You cannot get all Azure Ad users using PowerApps, whereas you can list the details of a single user or users within a group.
Make use of Azure Ad connector that needs administrative permissions for your account like below:
Group.ReadWrite.All
User.ReadWrite.All
Directory.ReadWrite.All
Connect Azure AD in the app,
Go to the Data tab -> Add data-> Search Azure AD -> Select Azure Ad connector -> Connect
To get users within a group, make use of below query:
Users= AzureAD.GetGroupMembers("Your_Group_ID").value
To get details of a User, make use of below query:
OnSelect = ClearCollect( colAzureUserDetails, AzureAD.GetUser(txtAzureID.Text) )
To know more details, please refer below links:
Power Apps Azure AD Group - SPGuides
Power Apps : Get users from Azure AD to Power Apps view to list table and refresh button for table - Stack Overflow
AAD complains about errors in the sync process.
But I don't understand what the duplicate is there.
Already tried a full import, delta import, full sync etc.
How do I find the duplicate?
There are three attributes mainly checked during azure ad connect: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID in Azure AD Connect.
You can make use of IDFix tool to identify the duplicate objects.
Please Check below scenarios if they are the cause:
If you/ User is Global Admin
Try to remove the role and sync the user without admin role or by adding user role.After the sync then you can add the role again.
Or
If it is already in sync ,Disable the directory sync process ,then delete the user
from domain (on-prem directory) and then do the azure ad sync and then add the
user role to admin back if required.
During Azure ad connect , we must take care of SMTP Soft match and ImmutableID hardmatch. soft-vs-hard-match
$credential = Get-Credential
Connect-MsolService -Credential $credential
$ADUser = "username"
$AzureADUser = "username#emaildomainname.com"
$guid =(Get-ADUser $ADUser).Objectguid
$immutableID=[system.convert]::ToBase64String($guid.tobytearray())
Set-MsolUser -UserPrincipalName "$AzureADUser " -ImmutableId $immutableID
This can take care of mismatch .See error-type-attributevaluemustbeunique & this
Note : Please do resync after any changes.
Other references:
Azure AD Sync, duplicate user - Server Fault
Troubleshoot directory synchronization errors | Microsoft Docs
diagnose sync errors (github.com)
AAD connect design concepts
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
We support multiple clients on a single Snowflake instance and I setup Azure Ad with the Snowflake app to enable SSO about a year ago. Today I was asked how one of our clients who uses Okta for their authentication how they would go about setting that up. I sent them the documentation but I want to be sure when I get down to step 3 that the Alter statement doesn't blow out my Azure Active Directory configuration.
Step 3:
ALTER ACCOUNT SET SAML_IDENTITY_PROVIDER =
'{ "certificate": "<Certificate_body>", -- Paste Certificate string with removed EOL charachters here
"ssoUrl": "https://my_okta_account.okta.com/app/snowflake/exhsddg0n8dixjoTjO0h7/sso/saml"", -- Okta SSO URL you captured in Step 1
"type" : "OKTA",
"label" : "MYSSO" -- Label of SSO button on Snowflake Web Login dialog
}';
Currently, only one SAML_IDENTITY_PROVIDER can be configured for the Snowflake account. I verified with my test account that running the ALTER ACCOUNT SET SAML_IDENTITY_PROVIDER statement you've shown would replace your Okta IdP configuration with Azure AD IdP.
I have an Azure Active directory with SSO and provisioning enabled. Users from my company can SSO into snowflake just fine, but when I invite a user from GMail or another domain into our AD they get the SAML error. The Snowflake AD app has provisioned the user to Snowflake correctly from what I can see.
How do I troubleshoot this?
Thanks,
Phil
#suzy_lockwood It was the NameID attribute giving me the problem. I linked it back to the Snowflake Application in my Azure AD. The fix was to go to Manage > Single-Sign On > User Attributes and Claims. Under Required Claim I opened the claim "Unique User Identifier (Name ID) and changed the source attribute from UPN to be user.mail.
This error is due to unable to identify the user. Please specify the complete name if the user while authenticating:
snowsql -a mytest.us-east-1 -u xyz#abc.com