Let's say I have two Microsoft accounts:
MicrosoftAccount1#outlook.com
MicrosoftAccount2#outlook.com
And I log into the Azure Account Center and create two subscriptions for each account:
MicrosoftAccount1#outlook.com
Subscription1a
Subscription1b
MicrosoftAccount2#outlook.com
Subscription2a
Subscription2b
Each account has an account administrator and a service administrator, and the account administrator can change the service administrator. So I could, for example, give control of all subscriptions to one service administrator, and in the Management Portal, it would LOOK like that account owns all the subscriptions:
MicrosoftAccount1#outlook.com
MicrosoftAccount2#outlook.com
Subscription1a
Subscription1b
Subscription2a
Subscription2b
But the account administrator didn't change, so really, each account still owns its original two subscriptions. The account administrator can always take back control of a subscription by changing its service administrator back to himself.
Then I log into the Azure Management Portal and create some storage accounts, web apps, SQL databases, and other Azure resources. Each resource belongs to one subscription, and each subscription is owned by one account:
MicrosoftAccount1#outlook.com
Subscription1a
storage accounts
web apps
SQL databases
Subscription1b
storage accounts
web apps
SQL databases
MicrosoftAccount2#outlook.com
Subscription2a
storage accounts
web apps
SQL databases
Subscription2b
storage accounts
web apps
SQL databases
So I could say that, ultimately, each Azure resource is owned by its subscription's account administrator.
Azure also created an active directory for each account, which is shared by both subscriptions. When I look at the management portal, the active directory LOOKS like it's just another Azure resource, except that it belongs to both subscriptions:
MicrosoftAccount1#outlook.com
Subscription1a
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook.onmicrosoft.com (shared)
Subscription1b
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook.onmicrosoft.com (shared)
MicrosoftAccount2#outlook.com
Subscription2a
storage accounts
web apps
SQL databases
MicrosoftAccount2outlook.onmicrosoft.com (shared)
Subscription2b
storage accounts
web apps
SQL databases
MicrosoftAccount2outlook.onmicrosoft.com (shared)
I can even create more active directories in the management portal, which is where I created the storage accounts, web apps, and SQL databases, so it REALLY looks like an active directory is just another Azure resource that can belong to multiple subscriptions:
MicrosoftAccount1#outlook.com
Subscription1a
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook.onmicrosoft.com (shared)
MicrosoftAccount1outlook2.onmicrosoft.com (shared)
Subscription1b
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook.onmicrosoft.com (shared)
MicrosoftAccount1outlook2.onmicrosoft.com (shared)
MicrosoftAccount2#outlook.com
Subscription2a
storage accounts
web apps
SQL databases
MicrosoftAccount2outlook.onmicrosoft.com (shared)
MicrosoftAccount2outlook2.onmicrosoft.com (shared)
Subscription2b
storage accounts
web apps
SQL databases
MicrosoftAccount2outlook.onmicrosoft.com (shared)
MicrosoftAccount2outlook2.onmicrosoft.com (shared)
However, I play with it some more, and I realize that I've got it backwards. The active directories don't belong to the subscriptions; the subscriptions belong to the active directories. I can change which subscriptions are assigned to which directories. Then, in the Management Portal, I select a directory, and it shows me that directory's subscriptions and their resources:
MicrosoftAccount1#outlook.com
MicrosoftAccount1outlook.onmicrosoft.com
Subscription1a
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook2.onmicrosoft.com
Subscription1b
storage accounts
web apps
SQL databases
MicrosoftAccount2#outlook.com
MicrosoftAccount2outlook.onmicrosoft.com
MicrosoftAccount2outlook2.onmicrosoft.com
Subscription2a
storage accounts
web apps
SQL databases
Subscription2b
storage accounts
web apps
SQL databases
So now it looks like the account administrator owns the active directories, and the active directories own the subscriptions. However, I play with it some more, and I don't think that's right, either. I can make the first account the service administrator for all four subscriptions. The second account can add the first account as a user in each directory and make him a Global Admin. Then the first account can remove the second account from each directory. So now, the first account can manage the subscriptions for all four directories and is the one and only user and global admin in all four directories, and the second account can't even log into the management portal anymore, so it looks like the first account owns everything:
MicrosoftAccount1#outlook.com
MicrosoftAccount1outlook.onmicrosoft.com
Subscription1a
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook2.onmicrosoft.com
Subscription1b
storage accounts
web apps
SQL databases
MicrosoftAccount2outlook.onmicrosoft.com
MicrosoftAccount2outlook2.onmicrosoft.com
Subscription2a
storage accounts
web apps
SQL databases
Subscription2b
storage accounts
web apps
SQL databases
MicrosoftAccount2#outlook.com
The second account still really owns two of the subscriptions because he's the account administrator, but there's nothing anymore that says that he owns two of the directories. The second account administrator can take back control of his two subscriptions, but I don't see how he can take back control of his two directories. Furthermore, as long as he's not a member of any active directory, he can't even create any more subscriptions; Azure won't create another directory like it created the first one. So, at this point, who owns the active directories MicrosoftAccount2outlook.onmicrosoft.com and MicrosoftAccount2outlook2.onmicrosoft.com?
I can even make one directory own subscriptions that belong to different account administrators:
MicrosoftAccount1#outlook.com
MicrosoftAccount1outlook.onmicrosoft.com
Subscription1a
storage accounts
web apps
SQL databases
Subscription1b
storage accounts
web apps
SQL databases
Subscription2a
storage accounts
web apps
SQL databases
Subscription2b
storage accounts
web apps
SQL databases
MicrosoftAccount1outlook2.onmicrosoft.com
MicrosoftAccount2outlook.onmicrosoft.com
MicrosoftAccount2outlook2.onmicrosoft.com
MicrosoftAccount2#outlook.com
To make things even more fun, I can create a user in a directory that is not a Microsoft account; it's just a directory account. Then I can log into the Management Portal as the directory account AND CREATE ANOTHER DIRECTORY. The only user and global admin in the new directory is the directory account that created it; it doesn't have a Microsoft account owner. Who owns THAT directory?
It could even be argued that the active directories own the original Microsoft accounts, because the Microsoft accounts are users in the active directories. So if the active directory owns the Microsoft account, and the Microsoft account owns the subscription, then who owns the active directory? (EDIT: On second thought, it doesn't make sense for the directory to own the Microsoft account, because one Microsoft account can be a user in multiple directories, and that would mean the account has multiple owners. Scratch that. A HUMAN owns the Microsoft account. Either the Microsoft account owns the subscription, or the active directory owns the subscription. Who owns the active directory?)
I don't think that the concept of "owner" for an Azure AD tenant (synonym of directory, but a more common moniker in literature) makes sense.
When you sign in the Azure portal, you'll see all the tenants in which the user you are currently signed in is a member. That is true regardless of whether the user is an MSA (microsoft account) or an organizational account (#.onmicrosoft.com or #). That is also true regardless of how the tenants came to be. Somebody might have created a new Office 365 subscription, which comes with its onw Azure AD tenant, then added to that tenant as a new user the MSA that you use for your Azure subscription. The next time you'll sign in the Azure portal, among your directories you will see that new tenant as well - just in virtue of the fact that you are a user in that tenant and that entitles you to do stuff with it (like creating new apps).
Bottom line: Azure AD tenants exist independently of Azure subscriptions. Azure AD tenants are automatically provisioned when you sign up for Azure, and your subscription admin (or any portal user) will automatically be added to any new Azure AD tenant created while operating the portal, but I hope that the O365 example showed how that is just one of the ways in which Azure AD tenants are created. The only thing that does not fit neatly in the above is the fact that you do have a default directory in your subscription, which has special properties - but still, I don't think I'd talk of ownership. HTH
Related
Scenario: AADDS deployed, Azure hosted Windows servers are domain joined. Using Azure Bastion to RDP into the domain joined servers. However, it seems the only user accounts who are part of the AAD DC Administrators group can successfully RDP to the servers.
Question: Is it possible to add security groups other than AAD DC Administrators to the local administrators group on domain joined joined servers as to allow RDP access for remote administration?
TIA,
Matt
Remote access to virtual machines (VMs) that run in an Azure Active Directory Domain Services (Azure AD DS) managed domain requires a user account that's a member of the Azure AD DC administrators group in your Azure AD tenant. This is one of the prerequisites.
Once you join a machine to the AADDS domain, you can treat it like a standalone AD DS domain in regards to GPO's and login, etc..
I tested this scenario yesterday and verified that you can add both individual users and AAD groups to the local Administrators group (or any group that allows login to a server) and those users will be able to login with both RDP and via Bastion.
I have mounted an azure file share on an azure VM using access keys ,the VM is not doman joined with the azure active directory instance.Please let me know if below scenario's will work out:-
If i apply acl's on the folders and sub folders will the acl's be
enforced in the mounted drive on the VM?
Will AZURE RBAC apply if someone tries to upload a file from the VM?
Note:- The Azure VM is on a VNET which has access to azure active directory.
Any information/answer/suggestion on the above questions would be greatly appreciated.
ACLs can exist for domain or non-domain accounts. Having a machine that is not domain joined, can obviously not set domain ACLs. So in that case local-server ACLs is all you can hope to get.
If another server mounts the share, and there is not another local user account + SID mapping, then there is no way these ACLs have any meaning on the second machine. But they will be enforced.
So that one will work albeit questionable in terms of usefulness.
RBAC is really a management plane construct. Meant to govern who can manage which Azure resource --> not access which data planes. Now in the case of AD / AAD DS support for Azure file shares, the team has decided to "stretch" the meaning of RBAC to govern share-level ACLs via Kerberos (where normal RBAC is OAuth only!)
Enough of the backend: What this basically means, is that there can be no support for local server accounts.
THese accounts only exist on a local server, not in AAD and certainly not DIRSYNC'ed from on-prem AD into AAD. So that means RBAC cannot work for local accounts, only for domain accounts.
I'm unclear what your scenario is.
A user coming into the server with some sort of local user credential?
Then creating/copying a file into a mounted Azure file share to that VM? --> That can work because there is no RBAC and since this is all happening through that single server that has that local user account, ACLs for these local accounts work natively.
A user coming into the server with a domain cred? --> will not work as the server isn't domain joined.
A user coming in with a local-server account and then using the Azure file share not via SMB mount but by going to the Azur file share directly: Cannot work because it's not a domain account and non-dimain accounts cannot work against Azure file shares. You'd use the srtorage access key to mount the file share to the VM, then you have access and leave auth. to the server with the set of local accounts.
Before you enable Azure AD over SMB for Azure file shares, make sure you have completed the following prerequisites:
Select or create an Azure AD tenant.
You can use a new or existing tenant for Azure AD authentication over SMB. The tenant and the file share that you want to access must be associated with the same subscription.
To create a new Azure AD tenant, you can Add an Azure AD tenant and an Azure AD subscription. If you have an existing Azure AD tenant but want to create a new tenant for use with Azure file shares, see Create an Azure Active Directory tenant.
Enable Azure AD Domain Services on the Azure AD tenant.
To support authentication with Azure AD credentials, you must enable Azure AD Domain Services for your Azure AD tenant. If you aren't the administrator of the Azure AD tenant, contact the administrator and follow the step-by-step guidance to Enable Azure Active Directory Domain Services using the Azure portal.
It typically takes about 15 minutes for an Azure AD DS deployment to complete. Verify that the health status of Azure AD DS shows Running, with password hash synchronization enabled, before proceeding to the next step.
Domain-join an Azure VM with Azure AD DS.
To access a file share by using Azure AD credentials from a VM, your VM must be domain-joined to Azure AD DS. For more information about how to domain-join a VM, see Join a Windows Server virtual machine to a managed domain.
Note:Azure AD DS authentication over SMB with Azure file shares is supported only on Azure VMs running on OS versions above Windows 7 or Windows Server 2008 R2.
Select or create an Azure file share.
Select a new or existing file share that's associated with the same subscription as your Azure AD tenant. For information about creating a new file share, see Create a file share in Azure Files. For optimal performance, we recommend that your file share be in the same region as the VM from which you plan to access the share.
Verify Azure Files connectivity by mounting Azure file shares using your storage account key.
To verify that your VM and file share are properly configured, try mounting the file share using your storage account key. For more information, see Mount an Azure file share and access the share in Windows.
We have an AD in MS AZURE cloud and IBM Access Manager in our in house datacenter.
I like to know what is the best way to synch users between these 2 system?
But that I mean, user will be added to AD in cloud. at the same time I want the same user to be added in Tivoli Access Manager. I am looking for the best approach
Thanks
Microsoft Azure Active Directory Adapter is an interface between a managed resource and the IBM® Security Identity server. The Microsoft Azure Active Directory (Azure Active Directory Adapter) uses the Tivoli® Directory Integrator functions to facilitate communication between the IBM Security Identity server and Microsoft Azure Active Directory (Azure Active Directory).
Adapters can be installed on the managed resource. The IBM Security Identity server manages access to the resource by using the security system. Adapters function as trusted virtual administrators on the target operating system. The adapter creates, suspends, restores user accounts, and other functions that administrators run manually. The adapter runs as a service, independently of whether you are logged on to the IBM Security Identity server.
The adapter automates several administrative and management tasks.
You can use the adapter to automate the following tasks:
Create, modify, suspend, restore, change password, and delete a user.
Create, modify, and delete group.
Reconcile user and user attributes.
Reconcile group and group attributes.
Reference - IBM Security Identity Manager: Microsoft Azure Active Directory Adapter Installation and Configuration Guide
Helo all,
I am trying to setup Azure AD connect for an Enterprise. They have local active directory on "internal.theirdomain.com", with local server DNS being setup for that too.
However in their Azure AD they have some accounts already under "theirdomain.com". This active directory has 3 domains associated with it: theirdomain.com, internal.theirdomain.com and theridomain.onmicrosoft.com where the first one is the primary.
I installed the Azure AD connect and set it up on the local server handling internal.theirdomain.com and after sync this happens:
local accounts go to Azure with ".internal.theirdomain.com", but accounts in the cloud are not downloaded.
Also, upon assigning a license to the accounts uploaded their email address is sent from "#theirdomain.onmicrosoft.com" while emails sent from their cloud accounts is sent from "#theirdomain.com". Do you happen to have any ideas on how to fix these:
have cloud accounts synced to local AD
have default email domain be "theirdomain.com" for all accounts
The one problem I can see for now is that "internal.theirdomain.com" is not resolvable from internet. I am adding that into their internet DNS but was wondering if you have any other tips.
Thanks a lot
My small company (about 100 users) is currently using Office 365. There have previously not been any domain controller. I am building an on premise domain controller and want to sync it with Azure Active Directory (Office 365). I used the sync service, with a small subset of users to no avail.
My main question: Can you sync FROM an Azure Active Directory to a new on premise Active Directory? My understanding is that it's the opposite - the on premise Active Directory is the "master" if you will. Is there a way to set it up the opposite? As in, Office 365 being the "master" or "seed" for an on premise?
At present, the Azure AD connect support the Password writeback, Group writeback and Device writeback.
You can refer the options features of Azure AD Connect from here.
At this point in time, synchronizing users FROM Azure AD to on-premises AD is NOT possible.
As Fei Xue pointed out, there are certain things (such as user passwords, groups and devices) that can be synchronized back to on-prem AD, but not users.
Depending on what you are trying to achieve, Azure Active Directory DS might be worth exploring as it allows you to create a VNet in Azure which has a AD-like support (LDAP, Active Directory domain join, NTLM, and Kerberos authentication).
More info on Azure AD DS: https://azure.microsoft.com/en-us/services/active-directory-ds/