Does Azure AD support hierarchy of departments? Is it possible to create a department inside another department and then add users to both the departments?
Related
We are looking at moving a number of applications from on prem SQL Servers upto Azure as a Paas offering, what would be the best way to grant the Database team access to these databases? They'll be under one tenant but spread across a couple of subscriptions and multiple resource groups.
Moving forward i'd also like for them to have permissions automatically for any new SQL database added to any resource group within our tenant.
Little bit confused on the best approach?
Thanks in advance
Dave
You need to perform below mentioned tasks to achieve your requirement.
create an Azure Active Directory user
create an Azure Active Directory group and assign the user group
add an Azure Active Directory user/group as an Azure SQL
Administrator
add Azure Active Directory users to Azure SQL Database
Follow this third-party tutorial to implement the same.
Additionally, you can have Database-level role for each user for more safety of the data. Please check this official document from Microsoft.
I have created a number of new users in AAD but it's for the sole purpose of accessing Power BI. I don't want them to be able to use Outlook, Sharepoint or ANY other resource/application.
Is there a way I can configure this in AAD? Ideally using a group setting so that it applies to all users in the group.
Create a group, add the users into the group.
When you assign O365 subscription to the group, only select Power BI license.
Don't assign other licenses to them. Except for Power BI, they cannot use other resources.
You can also assign the Power BI license one by one.
How to join a system into AzureAD programatically? Can anyone recommend commands or powershell option through which we can join AzureAD
At present there are no PowerShell scripts for joining devices to Azure AD.
You can upvote the feature request here and subscribe to keep track of updates from the product team.
There are lot of ways you can bring your devices to azure ad join directly like users can go through the Azure AD join process either during Windows Out of Box Experience (OOBE)
Similarly bulk enrollment and Autopilot) which provide a richer experience to join devices to Azure AD
We are looking to sync a multi-value attribute from on-prem AD to Azure AD. I read an article in which it's mentioned, its not yet supported but i would like to confirm from the experts.
My questions are:
1) Do multi-valued attributes synch from on premises AD to Azure AD is supported?
2) In Azure AD Connect, in Directory Extensions, how do I know from the available attributes if the attribute is Single or Multi-Value?
Thanks in advance
1) AD Connect supports synchronizing multi-valued attributes to AAD.
However, AAD doesn't support multi-valued attributes synchronized from on premises AD.
See this feedback, Azure AD Team replied below:
We are investigating what it would take to add support for multi-value attributes in Dynamic Groups to enable this and related scenarios.
2) Looks we could not check if the attribute is Single or Multi-Value in the Directory Extensions, we could just know which are valid candidates.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-directory-extensions#customize-which-attributes-to-synchronize-with-azure-ad
My company is currently planning to reconfigure security and we are currently arguing over which way to go, storing everything in Active Directory or in SQL Server?
So setting up Active Directory groups and use it to create a read and a read/write group and just move users in and out of these security groups and manage security for SQL Server from Active Directory or use SQL Server and move all users into security and create groups in SQL Server and manage the
security from there?
AD is the way to go in my opinion, for a number of reasons.
Security doesn't just cover access to databases. It covers access to files, folders etc. Anything in SQL is irrelevant to the question 'Should they have access to this spreadsheet?'. AD is the way to go there. Why not integrate everything into the same mechanism?
AD is more flexible than SQL. An AD Group can contain other AD groups. If you have an AD group called e.g. 'Power Traders' then the Power Traders are added to that group. There would also be groups which give access to individual securables (files, folders, databases, apps etc); 'Power Traders' would be added to those groups and inherit the access to the individual things. If another job also needs access to one of these, that job group can be added to the necessary individual group.
If an individual needs access to something outside his normal job, just add them to the individual groups necessary.
A full solution would actually have multiple levels of groups. How many would be down to the company and how it wishes to organise itself.