We are trying to configure an AD account to only be used from an Outlook connector of a Logic App. We are interested that this account cannot be used in any other way; for example, it cannot be used to log in from a machine or access other services. We have been trying to do it with Conditional Access but couldn't find the correct settings. Maybe someone has been able to configure this or has some other way to do it?
I really appreciate any ideas.
Using Conditional Access it is not possible to Configure an AD account that can used only for outlook connector for a logic app and restrict like login to machine or other services. we are not sure about other ways to achieve it but through CA policies it is not possible.
Related
I have an existing IdentityServer4 installation that is used to federate users between things like Google & Microsoft into a single login identity. In my situation, there are no local user credentials/passwords. Just the identity with an associated external provider. I'm trying to migrate to using Azure B2C and am hitting some roadblocks.
I've found that if I use the same ClientId and ClientSecret that IdentityServer is configured with, then I get the same IDs for users when signing in via an external identity provider. Which is great because I need them to be the same in order to try and migrate accounts over by reading them from the existing MSSQL database, and importing into Azure B2C using MS Graph.
I need to allow both Microsoft work accounts, as well as personal ones. So I need to use custom policies to allow for a multi-tenant configuration, since the built in provider doesn't support this.
However as soon as I flip my implementation over from the built in user flows and provider, to using custom policies, I don't get the expected issuerAssignedId anymore. Originally, the IDs looked something like AAAAAAAAAAAAAAAAAAAAAHGFdaj94jfdsgjifdh4ngd (made up, but you get the idea). Now with the custom policies, the issuerAssignedId being recorded in the B2C user looks like a GUID. So not just a different value, but a total different format. Am I missing something here? What would happen if someone has an fully operational AzureB2C install with built in functionality, and later identified a need to move to custom policies. How would users ever be able to look into their existing accounts with an external identity provider?
My TechnicalProfile for the multi-tenant sign is is essentially copy/pasted from their documentation, so I'm not sure what the deal is here?
I have a dotnet 5 Blazor Server-Side website deployed to Azure App Service. I've followed the tutorial at https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service to provide Authentication. Now, any attempt to reach my site requires a login from a user of the Azure AD.
Unfortunately, I haven't been able to find any guidance on how to manage Authorization though. For example, I'd like to restrict access to pages to members of specific groups within the Azure AD. I seem to remember years ago, there was some kind of membership provider database that the site would check.
The kind of thing I'm looking for is to be able to decorate the razor page with the name of an Azure AD group of which anyone attempting to load the page must be a member. Does anyone know of a link that describes the "official" way to achieve this?
Role-based access control (RBAC) a way to authorize applications based on the role permissions granted by the administrator to individual users/groups. Please refer this link for the detailed documentation on how to create/manage roles for an application in Azure AD.
Please refer this link for more details on how you can access the razor pages base on the roles assigned to the users/groups.
I'm following a guide online to generate an access token to access Microsoft Dynamics 365 Customer Engagement: https://eax360.com/dynamics-365-online-connect-using-postman/.
All of it works fine, however I am wondering why delegated Admin permissions need to be supplied in Azure Active directory during app registration. I have seen a lot of guides explain that permissions must be delegated but the above site documents the process well. As a general rule, I thought that starting with the lowest security permissions was the norm. I am new to Azure AD so thoughts are very much welcome.
If your app will be a client which allows the authenticated user to perform operations, you must configure the application to have the Access Dynamics 365 as organization users delegated permission.
Application permission means that you want your app to access Common Data Service without a user.
So whether to use delegated permission in Azure app registration depends on your needs. It is not mandatory.
But we can see that the Application permissions in Azure app registration is gray out. This is because Microsoft provides a different way to implement it.
We need to create a Common Data Service application user an then bound it to the registered app. After that, we could connect using the application secret. See the details here: Connect as an app.
I have crawlers running on VMs in Azure. After work is finished the Data crawled needs to be distributed to users across the internet depending on their access level. What I need help with:
1. How to onboard users? My idea was to use Azure AD
2. How to organize pipeline from the crawlers to end users but some access rules and data filters need to be applied before using. What is the most effective way? My idea was to use Azure Functions and then Azure siglalR so my clients (desktop, mobile) can get data very fast. All that would be organized as a Logical app?
Please help. I am just starting my programming experience so sorry if my question is naive.
How to onboard users?
Azure AD would be a good choice for you. With Azure AD, it will be convenient to manage the users.
How to organize pipeline from the crawlers to end users but some access rules and data filters need to be applied before using.
Based on the description you provided, you will expose the data crawled as rest api, right? If so, you can integrate your api with Azure AD, then you can control the user access as you need. You can add app roles in your application and assign users and groups to roles, then different users will have different roles to access your api.
Reference:
How to: Add app roles in your application and receive them in the token
Integrating with Azure Active Directory
I've been investigating some cloud vendors and the ability to implement single sign-on with them, especially when it comes to AD (Active Directory) integration.
So far I've learned that with Azure this is possible through ADFS and the AppFabric Access Control offer.
In AWS, since it is possible to create a VPN and see EC2 instances as a natural extension of a private datacenter, I believe implementing SSO would be rather simple (not sure if I'm right on this one... Please correct me if I'm wrong).
With App Engine though, even though there is some documentation on AD synchronization (not full integration) for Google Apps, I'm struggling to find out whether AD integration would be possible... Is there any strategy for that?
Any bit of information on cloud apps and AD integration will be appreciated!
App engine apps can only call out to other services using HTTP or HTTPS, so you could not directly query an AD server. Of course, I'm sure you could build a simple HTTP/LDAP bridge if one does not already exist.
UPDATE: oops, I forgot about SDC,or Secure Data Connector. It is not exactly a HTTP/LDAP bridge, but can provide a bridge between your intranet and your Google App Engine app.
You typicially don't need communication between the application (in this case running in GAE) and AD.
You would, instead, get a security token from and STS (ADFS) and then send the token to the app that is would be configured to accept and trust those tokens.
I'm not familiar w/ GAE but assuming it accepts SAML tokens and understands WS-Federation, you can achieve SSO without ever exposing AD or synchronizing any information between AD and GAE (using ADFS for example)
This is a classic identity federation scenario.