I would like to register multiple tenants on the same purview account. Is this possible?
No, currently in order to scan another tenant's data source, you need to create a separate Azure Purview account in that tenant.
Related
I was "david.corbin#companyA.com" now I am "boogie.woogie#companyB.com". Both are AAD backed identities.
The goal is to change how I authenticate to Azure DevOps so that I have one consistent history without "fracturing" or "historical user".
I have tried (in a playpen environment) various items, but I always end up with there being two distinct identities.
In the past during migrations, Microsoft Support was able to alter identities, but I am looking for a solution that does not involve opening a bunch of support tickets.
Azure DevOps Change User Identity
I am afraid there is no such solution that you could resolve this issue by yourself.
If you have already add the new account boogie.xxxx#companyB.com in the organization, we could not map that old david.xxxx#companyA.com to their Azure AD identities.
That is because it will be treated as a new account and assigned a unique VSID when you add the account account boogie.xxxx#companyB.com to organization.
That is also the reason why you always end up with there being two distinct identities.
To resolve this issue, we need to contact the support team to map two account as one in the backend. You could submit the ticket on the Developer Community if you do not want open a support ticket. Or you could create a technical support ticket from Azure Portal if you have Azure support plans.
I happened to notice that a data factory (ADFv2) is owner of one of our Azure subscriptions. This is a typical ADF and not doing anything out of ordinary. I am guessing this was done by mistake -- but just want to ask here in the forum if there can be a genuine scenario where data factory needs to be owner of a given subscription?
Yes, what #Nandan said is basically correct, more specifically, essentially the Owner is assigned to the MSI of your ADFv2, when you need to use the MSI(managed identity) of your ADFv2 to auth to Azure resources/call Azure REST APIs, the RBAC role(in your case, it is Owner) is needed, to do most of the things, some other roles are enough e.g. Contributor, to do something like create role assignment, you need the role has the higher privilege, e.g. Owner.
Three specific cases I answered to help you understand:
How to call a REST API using Azure Data Factory Pipelines
How can I use this API in Azure Data Factory
Azure Data Factory pipeline to start SSIS Integration Runtime authorization error
Is the Azure data factory used for any automation purposes using REST APIs, etc ?
Like scaling resources or pausing/resuming resources across RGs?
If that is the case, then the ADF might have been given owner access on subscription for MSI in all the objects within RGs present in the subscription.
If this ADF is specific to data ingestion use cases, then there is no need to provide the ADF owner access on the entire subscription.
All tenants can use accounts info.(Head office is a tenant)
All accounts can use branch office data
Branch office admin only use self data
Head office can use all branch office's data
In AspNet Boilerplate, tenants are not hierarchical. Theoretically, a tenant's data must be isolated from another tenant's data. If your "tenants" share data with each other so it shouldn't be the tenant. You can use Organization-Units for this purpose. Organization units can be used to hierarchically group users and entities.
I'm using cloudformation to create one admins group for my aws account, and I need to add a custom tag to all of them in order to save their e-mail for notification purpouse. There's no info in aws docs about it.
Is possible tag an IAM resource? I know that is possible to do it for a EC2 instance.
No, currently no IAM objects can be tagged, in cloudfront or using administration console.
I suppose that since Tags are mostly used for billing and resource grouping, and IAM objects are free of charge and represent authority, roles and permissions and not a resource or a general purpose database.
I think the best alternative for your scenario would be something like DynamoDB to store this configuration.
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