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
Related
I am building an application which will use Azure B2C as the identity system. It will include some local accounts, and some federated accounts for Enterprise SSO logins.
The application will have “application tenants”, representing customer organization/company.
I’d like a user to be able to grant users access to one or more application tenants (in case some users will manage multiple company accounts within the app).
There will also be multiple roles within the app (e.g. read only, full admin).
What is the recommended way to map a B2C User to “app tenants” and roles?
Create AAD group per tenant and role and check membership?
Custom attribute for tenantid(s)?
Or must I map users to tenants & roles in app DB/ outside of B2C?
Is this scenario described in any docs that might point me in the right direction?
Thanks!
I'm trying to setup a user lifecycle flow that will allow me to create an Azure Active Directory user (Member, not Guest) when an employee is created in our HRIS tool (HiBob). There is a pre-existing integration which is enabled and allows us to get basic information (name, location, etc.).
In the HRIS system we also store some more unique data that I would like to be added to the users AAD profile (maybe an emergency contact for example) that we can then use to provision other applications (like Slack).
My issue is trying to create these custom property fields. I have read about Azure B2C as well as directory schema, custom security extensions and using MS Graph. None of these seem to be totally relevant to my situation.
FYI we are fully cloud, so Azure AD Connect is also not an option.
To store custom data in Azure AD objects such as users you can leverage Azure AD Directory Extensions in tandem with Azure AD Provisioning trough SCIM.
We implemented SSO on Snowflake and with SCIM, we're able to provision users in Snowflake
Now, I want it to work like SQL Server authentication where I can add users to the same AD group and create a single login on SQL Server for this AD group. To revoke login permissions I just remove the user from the AD group. To give a new person access I just add them to it.
I would like also to map a role to a group, so, for instance, if I could link an Azure AD Group to a Snowflake Role [Read-Only User for Database X], as soon as I'm adding a user Y in Azure AD Group, this user Y will have automatically read-only access to Database X
Is it possible ?
Regards,
This same concept is possible in Snowflake as well with SAML SSO (for authorization) and SCIM (to sync users and their corresponding roles to SF). The details for this are here:
https://docs.snowflake.com/en/user-guide/admin-security-fed-auth-configure-idp.html
https://community.snowflake.com/s/article/HOW-TO-Setup-SSO-with-Azure-AD-and-the-Snowflake-New-URL-Format-or-Privatelink
https://docs.snowflake.com/en/user-guide/scim-azure.html
Both these together will ensure that the user created on Azure AD will be possible to login with the AAD credentials and the SCIM will ensure that the relevant role management is on the AAD side which is reflected exactly as-is on the SF side.
we have a screen in our application that is used to update Azure AD users through Graph API. If users are created using Azure Portal or Graph API, I'm able to updated user profile using this screen.
But if the user is Created/Sync using AD Connect(e.g in case of O365 Users) while updating these Users Microsoft Graph returns following error:
Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration
I have following queries:
Is it possible to update a user through Graph API that is created from on-premises to Azure AD?
Is there any settings on azure portal or Ad connect that allow user to be
updated through Graph API?
Also How to tell the difference between if a user is created on-premises or on Azure AD through Microsoft Graph API. Any attribute in Microsoft.Graph.User Class?
To answer your questions:
No this isn't possible because of the way they are synced. If Microsoft would allow changes on both sides, it would have to implement some kind of duplicate change resolution system. So they just blocked changing properties except for some cloud only properties like licenses.
No there isn't because of the above reason
Yes there is, but it's kinda hacky.
To see if a Graph user is created through the sync you should request the User.Read.All scope for your application and then do a request to the Get user endpoint with the select all properties querystring ?$select=*.
The synced users should have the OnPremisesSamAccountName property amongh others that don't appear on a non-synced user.
Once you found out the user is an on-premise user, your application could do an update straight to your AD with the System.DirectoryServices.AccountManagement api.
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,