The gotchas of Azure AD Domain Services in ARM

Not too awful long ago Azure Active Directory Domain Services moved over to the ARM portal from the Azure Classic portal.

Yea! the world said.  And there was much rejoicing.

Now, the real world impacts of this.

There are a few scenarios with Azure AD that folks commonly run in to.

I have not blogged about the relationships of an Azure Tenant and Azure AD.  So let me briefly mention the relationship between these two.
(I will be repeating this all in future posts, as this relationship is important to grok)

An Azure Tenant is the Account that you or your company has in Azure.  It is divided into Subscriptions. 
Each Subscription is where you 'consume' in Azure; and it also serves as an isolation boundary (as in, resources in different services can only talk to each other through public entry points - they cannot directly touch each other).
Below that you have Resource Groups, which are management containers (not isolation).
And then you have the actual resources that you get billed for consuming.

All of this together is an Azure Tenant - your phrased another way, you are a Tenant of Azure and this is your playground and thus billing entity.
I will keep using the phrase Azure Tenant in this way.
(I run across MSFT folks that use the word Subscription when referring to the Tenant, and it is just plain incorrect and thus confusing as to the ramifications)

Azure AD is an entirely separate thing.  It is this huge multi-tenant cloud based identity provider, with a number of cool features and touch points.
An Azure Tenant must have an associated Azure AD, but an Azure AD has no dependency on an Azure Tenant (or an Office365 tenant - which is yet another entity).

A single company can have multiple Azure AD's (which is highly likely), they could also have multiple Azure Tenants (which is not very likely, but possible).

A single Azure Tenant can only be associated with one Azure AD.  Nuance here; the tenant has one Azure AD, but people from other Azure ADs can be granted access.  But the invited accounts are foreign accounts.

Now.  Some background into the processes that get us into the strange places that folks end up in.

When an Azure Tenant is created an Azure AD is created for it.
So you end up with some Azure AD such as you@tenantName.onmicrosoft.com

This is fine.  It gets you up and running and then you add your admins which might be your.admin@yourcomapny.com  and they get invited.  Everything in the Azure Portal works.  Now, lets get into the cases that won't work in this scenario.

This actually puts you in a very common scenario, the scenario where the Azure AD associated with your Azure Tenant is not the same Azure AD where your corporate user accounts reside.

Now, if you only want to use Azure AD RBAC to add your IT folks to the Azure Tenant for administrative purposes, this is fine.  And thus, a more common scenario than most folks want to realize.

Now, lets get to Azure AD Domain Services in ARM.  There is a security boundary here.  The Azure Tenant.  Therefore, when you enable AAD DS in ARM you are restricted to the Azure AD that is associated with the Azure Tenant.

Oh, your Azure Tenant Azure AD is not the one with your users?  Oh my!  How do we resolve this?
(trust me, the sarcasm is real here, I can't tell you how many times I have spoken to folks about this and it takes a while for all the dots to connect before they realize the dilemma).

There are three ways to resolve this:

1. 're-parent' the Azure Tenant.  What does this mean?  It means that you make some other Azure AD the primary Azure AD for your Azure Tenant.  There is an option in the Azure Portal "Move to another Directory".  The impacts:  If you had any RBAC set up, you will break it, and therefore need to set it up all over again.
2. Use a vNet.  When logged on to the Azure AD where the users are, create a new Azure Tenant and subscription.  Turn on AAD DS there.  Then set up a gateway between the vNet in this subscription where your AAD DS and user accounts are, and a vNet in a subscription of the Azure Tenant where your workloads are that require the domain services provided by AAD DS.
3. Don't use AAD DS.  Stand up a Windows Server Domain Service VM (more than one for a proper deployment) and use Azure AD Connect to sync the users with the AD domain.

In the end, this is about your user accounts, the reasons why you wanted AAD DS in the first place (you need NTLM or Kerberos for any reason).

Yes, AAD DS is convenient, but the security models that forced it into this particular assumption is not always in line with reality.

NetJoinDomain failed with error code 8557

This was an interesting little one that happened in my Azure Service while using Azure Connect to join my Role instances to my on-premise domain controller.  Let me lay out the scenario..

Trying to apply some best practice to my environment I an using a regular domain user account in my Role configuration for Azure Connect (why would you ever embed a domain administrator account in a static configuration file ?!?!).

DomJoiner is simply a regular user, users can join machines to a domain.

Everything was working along perfectly fine until yesterday.  I applied the Roles to my Virtual Network group in the Azure Portal and nothing happened.  My machines did not reboot (domain join), they did not appear in the domain, nothing.

Finally I ran across a specific Azure Connect log file “integrator.log” found at %programfiles%\Windows Azure Connect\Endpoint\Logs

Within this log I could see the configuration being received, Azure Connect linking up and my error:

RRAS interface connected

DNS server configured on RRAS interface

NetJoinDomain failed with error code 8557. Target domain......

Oh, an error code, lets go trolling.  Search was letting me down.  All the error references were for Server 2000 Active Directory and I am using Server 2008 R2.  Also, no references to the error and Azure.  I can’t image I am the only one that has seen this.

Finally, the details of two articles had the knowledge:  KBs 251335 and 314462.  A user has a default (out of the box) limit of being able to join 10 computers to a domain.

I opened ADSIEDIT.msc, selected the properties of the correct naming context, then cleared the setting ms-DS-MachineAccountQuota.

This all happened because I am using the prudent practice of using a regular user account ( not a domain administrator) to join my Azure Role instances to my domain with Connect.  But then most developers I know would only be using a Domain Administrator account and may never see this issue.