Azure AD Domain Services (AADDS) - some thoughts

I thought i'd share some thoughts on 'domain services' inside Azure - some good things and some bad following on from our implementation and now we have got to know some of its benefits and limitations.

For those of you from a non AD background (which was me until very recently) you are probably only aware of the domain as something you log in to with your corporate username/password - you know machines are 'joined' to the domain and the domain does lots of good stuff but the inner workings of forests/trust etc are a bit of a mystery.

I still haven't installed a full AD setup myself but from everything i see this is a specialized job - you have to know what you are doing - in some organisation just doing AD admin is a role in itself.

Inside Azure you are offered another approach - one of the additional features of Azure AD (which is a PaaS service for managing users/groups in a 'modern' way) is the ability to activate domain services for this - this is termed Azure AD domain services (or AADDS for short - there are way too many A's and D's in this whole area of technology). Again this is a PaaS extension to a PaaS service - you can see/activate this from the domain services option in the portal - see the screenshot below of an already activated one.

When you activate this in the background 2 machines are spun up with the role of domain controllers - now as this is a PaaS offering you can't log on to these machines directly (i.e. no RDP is possible) and you are not able to have the domain admin or enterprise admin roles within the domain - this is restricted to limit the functionality you can mess around with so MS can guarantee the PaaS service.

All users/groups that have been created in Azure AD are replicated down to domain services - this means Azure AD is the source of truth - if you need a new user or a password reset - this has to be done in Azure AD. The changes are replicated down every 10 minutes or so - so be aware of that. Also be aware that the domain service vnet/subnet has to be able to reach the public ip of Azure AD for the sync to be possible - it seems to be a pull from domain services rather than be a push but the connection has to be possible.

Now the great thing about this setup is that you don't have to manage the AD machines or the replication etc - this is all done for you - no patching etc - MS handle all of that.

Once you've spun this service up the commonly used things for most environments are possible - for example we use:

1) domain join (this is essential for us to manage multiple machines without having individual logins on them all)
2) DNS extension - this is possible using the dns client and connecting remotely into the domain controllers (the PaaS allows this) - for example we added new forward/reverse zones and aliases for machines etc
3) GPO can be managed - not completely fully - but enough to cover most functionality

Now for most use cases that is enough - but there are some things where the PaaS offering is not enough - for example we needed to make some changes for an application using adsiedit - this is not supported - it just opens in a read only mode. If you want to make changes around kerberos settings for machines in AD you can view everything but any changes are blocked with 'access denied'.

The other big thing lacking is cross region DR - there is HA within  region (there are 2 domain controllers spun up) - but it's not possible (well not yet at least) to have it replicated to another region - so you create dependencies between regions - for example if you want a machine in UK South to be domain joined - that has to be to where domain services is provisioned - which could be US East - this creates a dependency you don't want - and likely introduces performance problems.

In summary i would say this is a really good fit for small/medium companies who want to manage many machines easily - for larger companies with possibly more requirements of AD it's maybe not so good a fit and actually a full domain is probably what is required here.

Honestly though - if you're moving to the cloud you should really get away from VM's - get into PaaS and serverless deployment models wherever you can as then you remove the need for the 'traditional' domain in the first place - this is of course far easier said than done - and for many 3rd party apps this may be a long way off.

For reference here is a link to the Microsoft docs that show what the limitations are - this is well worth a read before you commit to it.

https://docs.microsoft.com/en-gb/azure/active-directory-domain-services/active-directory-ds-admin-guide-administer-domain#administrative-privileges-you-do-not-have-on-a-managed-domain