I have this dilemma where i need to grant a non-admin domain user permissions to start/stop multiple services that start with a specific ID. Originally I could have used service control or mmc to create a template to give one user non-admin rights to start/stop a service and it works just fine but they have many different services that they need access to. Many of the services start with two letter ex. MX-service-name. I was thinking maybe i can create a group and give it permissions to start/stop services, but there are multiple services and this also needs to be done on multiple servers as well. Is there a way i can create a security template that applies my security group to any service that specifically starts with MX. Maybe there is a way to make each server apply a security rule to a a group that enables the users in said group to have non-admin privs to the services they need. Sorry if its confusing :)
Related
I need to build a solution that utilizes Azure B2B Collaboration to on-board customers from different organizations to use my system.
Each customer may have 100's or 1000's of users, where some may have Azure AD and other don't.
The application will have different user roles/groups structure that controls access to my API's.
What is the best way to design this and can you provide references?
Option 1: Create a separate Azure AD for each customer
Each customer will have their own Azure AD and I can use Azure Groups to control access.
What is the limit of Azure AD's per subscription? (can't find a
definitive answer in MS docs) https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-service-limits-restrictions
Is this a good "Azure" practice? can you provide references?
Any info about structuring/organizing this for easy maintinance.
Any complications that I need to be aware of?
Option 2: Create a single Azure AD for all customers/users
All users for all customers will be added to a single Azure AD and for users segregation, each customer's users belong to a separate Azure Security Group.
In this scenario, I will probably need to maintain each customer groups in a local database since they may have different groups.
Any concerns from having all customer's users in the same directory?
Options 3:???
In my opinion single tenant is better. Creating a tenant for each customer makes management much harder (also login becomes harder to implement). Limit of Azure AD per subscription probably does not exist since directories are above subscriptions in the hierarchy. Yes, you can setup a group for each customer and keep the id of the group in your database.
The users will be added as Guests to your directory, make sure that the setting Guest user permissions are limited is enabled in the external collaboration settings.
That will make it so that they cannot access the user or group list at all in your tenant.
I have four Azure AppServices which are complete independent applications. I want to provide a kind of a portal that aggregates those four. When a user logs in he sees all applications he has access to depending on his scope. From the portal he can navigate to the other applications and do the user management stuff like adding new users and grant access to a specific application.
Is the picture above a good pattern to do it?
If I would start from scratch, what would be a better idea?
App services don't have access to different app's directories, so I do not think this is possible.
Your best bet might be to make a feature request to the product team on User Voice. https://feedback.azure.com/forums/169401-azure-active-directory
In Microsoft Azure, I can add an application from the marketplace to my Active Directory. For example let's say 'Salesforce'.
I can enable SSO and Provisioning and particularly Self Service.
The steps to setup self service are here:
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-self-service-application-access
Those steps are for the old portal, but I used the new portal, it's mostly the same.
Some applications, like Salesforce, have multiple roles that can be assigned, and when you add a user or group an assignment you select a role. As far as I can tell, you can only enable self service features to put a user directly into a single specific group, and that group dictates the role that is assigned.
My question is:
Is there a way to allow the end user, when requesting an application, to pick the role they want? Even if it is a bit round-about, like picking a group that assigns the role. Or is azure self-service limited to granting access to one specific role?
My organization has On Premises Active Directory and many AD Security groups and also has Azure presence (AD Sync up). Is it possible for me to write a code and run in Azure that can check if a specific user/logged in user is part of AD Security Group (On Prem)?
Thanks
It can be achieved by setting up Azure AD connect service. Once this is successfully done the synchronization component makes sure that the identity information for your on-premises users and groups is matching the cloud.
Once the sync is done you can query and get the user information one of which is the user's group information.
https://azure.microsoft.com/en-in/documentation/articles/active-directory-aadconnect/
SharePoint does integrate active directory accounts, of course, but how about security groups? Have a few sites where I'm fairly confident access is going through an existing Active Directory (AD) security groups (i.e. only an AD security group has been granted permissions through the 'People and Groups') In another situation, where I created the AD group and granted it permissions to a site, the customers were not able to access immediately. Eventually had to fast-track it and add the individuals to the People and Groups to keep the project going, but hoping not to have to maintain it that way.
Any specific requirements of the security group in AD? Universal, Global, or domain local? Is there any time delay between modifying group members in AD and having that take effect in SharePoint?
Any AD group type is usable by SharePoint so long as that group is usable by the server SharePoint is running on. Said another way, if you were using the OS level tools on the server and the OS recognizes your group, then you can use it in SharePoint.
As for when group memberships changes become effective, it has always been near real time for me but I can't say that I can speak to all possible AD topology deployments.