I created a new AAD user without any special permissions (no admin, just a user). Now, when I login using the Connect-MSOLService cmdlet and retrieve all users using Get-MSOLUser I can see every user within that directory.
Why and am I able to change that?
Background: I want to use a single AAD instance for multiple SAAS applications and want to prevent that a user can browse all users.
Actually, there is a way to disable user browsing in an AAD using the Set-MsolCompanySettings from the MSOnline module:
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $false
In Azure AD, Users and groups are created in a flat structure without OU and GPO. You can't restrict the user's permission to a specific scope. The user can view all the user information in Azure AD.
To isolate the users from different scopes, you can create multiple directories for Azure AD, and configure the SaaS applications as multi-tenant application for AAD.
You can refer to the article below for more details about Azure AD Directory role.
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles
If you connect to an Active Directory you usually want to read some data. As such if you're authorized to do that you can easily access information that is available and particularly "sensitive" (e.g. you can't read private keys of user objects easily). If you look at the history of Active Directory and it's typical usage within companies, it's likely that only single tenant (company) using it at a given time. As such there were even less reason to restrict the access.
If you want to have multiple tenants use the same AD you will have to figure out a scheme that works for you and setup the proper permissions yourself.
Helpful articles for this could be:
Build a multi-tenant SaaS web application using Azure AD & OpenID Connect
Question: Creating a multi-tenant AD environment
Related
I have a tenant admin account for a SharePoint online tenant. I am tasked with looking at all the sites on the tenant and all the SharePoint groups on each site. Getting a list of sites is easy using PNP libraries (Get-PnPTenantSite). My next step is to loop through each site and get all the security groups associated with each site - also easy using Get-PnPGroup commandlet.
The problem I'm running into is that my tenant admin is not added to some sites - not Site Admin, Not Site Owner, not even Site Reader - and so when my script executes against one of these sites, I'm getting a 403 Forbidden when asking for the groups on the site. Yes, I could avoid this by just adding my tenant admin as an owner on every single site in the tenant, and could probably even do this using a fairly simple powershell script.
However, my question is, why is this necessary? Shouldn't I be able to just run a script with some kind of "tenant admin super-read-permissions" or something that will just temporarily give me all access to everything without having to go through the middle step of adding myself everywhere?
Depending on the needs of your business with SharePoint, it may seem like an unnecessary or extra layer of security. After all, why not allow an administrator to access all the things?
The answer lies in the fact that SharePoint security is designed to allow separation of roles. These roles may not necessarily match exactly how responsibilities are defined in your company.
From Microsoft:
Global Administrators and SharePoint Administrators don't have
automatic access to all sites and each user's OneDrive, but they can
give themselves access to any site or OneDrive.
See https://learn.microsoft.com/en-us/sharepoint/sharepoint-admin-role
Tenant admins have several responsibilities:
Create sites
Delete sites
Manage sharing settings at the organization level
Add and remove site admins
Manage site storage limits
To perform these responsibilities, very little access to the actual sites and their content is required.
Management of access to a site collection and its content is the responsibility of the site collection administrator and site owners.
It sounds like in your company, you wear both hats. You might be creating and deleting sites, and also getting involved in access control or auditing at the site collection level. In these cases, you must use the privilege of the tenant admin (e.g., add and remove site admins) to grant yourself the site collection privileges required to access the information you need.
I recommend not granting yourself these privileges forever. It is helpful to consider that having constant administrative access to all sites is undesirable for a few reasons. For instance:
Search is supposed to be filtered to content that is relevant to the user. If the user is an admin with access to all content, search will not be filtered in a useful way.
While an administrator may certainly grant themselves access to a site, some collaborators would prefer that their content remain private to their team until or unless they require technical support.
All of this addresses the "why" part of your question. As for the technical question, there is currently no "tenant admin super-read-permissions" role that you can use for the data you want to collect.
If we scope the Application access Policy to specific mail enabled group and grant access only to the member of the group there are chances for any userid can be added to the group and leverage full access to the mailbox. What level of security controls can be added to prevent this??
Use the New-ApplicationAccessPolicy cmdlet to restrict or deny access to a specific set of mailboxes by an application that uses APIs (Outlook REST, Microsoft Graph, or Exchange Web Services (EWS)). These policies are complementary to the permission scopes that are declared by the application.
While scope-based resource access like Mail.Read or Calendar.Read is effective to ensure that the application can only read email or events within a mailbox and not do anything else, application access policies allow admins to enforce limits that are based on a list of mailboxes. For example, apps developed for one country shouldn't have access to data from other countries. Or, or a CRM integration application should only access calendars in the Sales organization and no other departments.
Reference: New-ApplicationAccessPolicy (ExchangePowerShell) | Microsoft Docs
When I create a service principal it also creates an App in Active Directory.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/123456a1-a1b2-1234-12ab-12a3b4cdef67"
If I go to the Azure Portal - Active Directory - App registrations it shows all the applications registered.
I have managed to find the service principal I use for terraform by matching the terraform client_id with the Azure "Application (client) ID". It also had a human readable display name (although not the best since I still had to look via client id!)
However, there are several others where the display name is just "project_subscription".
They look like they must have been generated automatically when setting up a pipeline registering a web app in the portal or something.
I can't tell if they are actually used or if they were just created for experimenting and are then left over.
How do I know what they are for and if they are still used or not?
Is it possible to search Azure for the id or anything?
Is it possible to add a description to these to identify what they are used for beyond just the display name?
e.g. I only identified the terraform one by matching up the id with my code
App registration can be used for many scenarios, the app registrations in your AAD tenant should be created by different users. There is no such thing as a description of them.
To see if they are used, it needs to combine the context, as in AAD, there are different usages for them. For example, there are no sign-in logs of the AD App's corresponding service principal, but you cannot make sure if it was used as a client app. For the details, you may need to check the Audit logs.
For more details about AD App(App Registration) and service principal, you could check this doc - https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
I have an existing application with a few thousand users using SqlAzureMembershipProvider for authentication.
I am interested in creating an Azure Active Directory for the application and migrating the existing membership profiles into it.
Is it technically possible to export/import the membership profiles?
The only approach I can think of is creating a PowerShell script that gets user details from the app one by one and creates a new user for each of those in the new AD.
Yes it is possible but there are no tools to do this.
For AD e.g. there is DirSync.
Probably easiest to use the Graph API - refer: Azure AD Graph API - samples Microsoft Azure Active Directory Samples and Documentation.
As you say, you will have to cycle through the users one by one. The password is going to be a problem. You may have to give each user a dummy password to start.
I have an MVC2 site that now allows access to it via windows authentication and uses ASP.net Role provider to provide authorization. I am trying to come up with a way for the site to allow the user access to the site if his username is a member of certain groups so I won't have to sign up user in sql, but just sign up a group with access. Anybody have any idea how to do this? Is there a quick and dirty way? So far in my internet perusals I haven't found a quick and dirty way to do this? Any help would be great.
Thanks
Looking up Role/Group information for a User
ASP.NET provides a useful “Role Management” capability, which allows developers to map users into logical “Roles” that can then be used to better control end-user capabilities and authorization access. For example, as a developer I could create a role called “managers” for my web application, and then limit access to portions of the site to only those users within the “managers” role (note: I will be posting additional recipes in the future that discuss how to fully use the Role Management authorization and capabilities features more).
When using Windows Authentication, ASP.NET allows developers to create and populate roles from multiple sources. For example, a developer could setup the built-in ASP.NET 2.0 SqlRoleProvider to map Windows users to custom application roles that are store within a database. This approach is very useful for scenarios where there might be application-specific role mappings that don’t make sense to push into a centralized Active Directory tree/store.
ASP.NET also makes it easy to access central Windows and Active Directory group mappings from within an application as well. For example, if there is a Windows group on the Active Directory network called “DOMAIN\managers”, an ASP.NET application could lookup whether the current Windows authenticated user visiting the ASP.NET site belongs to this group by writing code like this:
If User.IsInRole("DOMAIN\managers") Then
Label1.Text = User.Identity.Name & " is a manager"
Else
Label1.Text = User.Identity.Name & " is not a manager"
End If
Note that the role/group look-up is done via the “User.IsInRole(rolename)” method that is a peer of the User.Identity.Name property.
src
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx