Options when Moving to The Cloud
- Switch to using SaaS versions of the s/w
- Rewrite the app
- Lift and shift: the focus today.
How Organizations Handle AD Requirements Today
- They set up site-site VPN and deploy additional domain controllers in the cloud.
- They deploy another domain/forest in the cloud and provision a trust, e.g. ADFS.
Imagine a Simpler Alternative
- Simpler
- Compatible
- Available
- Cost-effective
Introducing Azure AD Domain Services
- You provision a VNet.
- Then you activate Azure AD Domain Services in Azure AD on that VNet
- You can manage the domain using RSAT.
- You can optionally sync your Windows Server AD with Azure AD to share accounts/groups.
Managed Domains
- Domain controllers are patched automatically.
- Secure locked down domain, complaint with AD deployment best practices
- You get 2 DCs, so fault tolerant
- Automatic health detection and remediation. If a DC fails, a new one is provisioned.
- Automatic backups for disaster recovery.
- No need to monitor replication – done as part of the managed service.
Sync
If you deploy sync, e.g. Azure AD Connect, then it flows as follows: Windows Server AD <-> Azure AD <-> Azure AD Domain Services
Features
- SIDs are reused. This means things like file servers can be lifted and shifted to Azure without re-ACLing your workloads.
- OUs
- DNS
Pricing
Based on the number of objects in the directory. Micro-pricing.
Decisions
New Features
- Azure Portal AD Experience is GA
- ARM virtual network join is GA
Demo
He creates an AADS domain. THere are two OUs by default:
- AADC Users
- AADC Computers
Back to the PowerPoint
Notes
- You cannot deploy AADDS in the classic Azure portal any more.
- The classic deployment model will be retired – the ARM deployment is better and more secure.
- The classic VNet support is ending (for new domains) soon.
- Existing deployments will continue to be supported
Questions
- Is there GPO sync? No. This is a different domain, so there is no replication of GPO from on prem to AADDS
- Can you add another DC to this domain? No. There will be (in the future) the ability to add more AADDS “DCs” in other VNets.
- What happens if a region goes down? The entire domain goes down now – but when they have additional DC support this will solve the problem
- Is there support in CSP? No, but it’s being worked on.
Manage Azure IaaS VMs
You can join these machines to AADDS. You can push GPO from AADDS. You’ll sign into the VMs using AADDS user accounts/passwords.
GPO
Members of AADDC Administrators can create OUs. You can target GPO to OUs.
Move Servers to the Cloud
Sync users/passwords/SIDs to the cloud, and then lift/shift applications/VMs to the cloud. THe SIDs are in sync so you don’t need to change permissions, and there’s a domain already for the VMs to join without creating DC VMs.
LDAP over SSL
I missed most of this. I think you can access applications using LDAP over SSL via the Internet.
Move Server Applications To Azure
User AADDS to provision and manage service accounts.
Kerberos Constrained Delegation
Cannot work with AADDS using old methods – You don’t have the privileges. The solution is to use PowerShell to implement resource-based KCD.
Modernize Legacy Apps with Application Proxy
You can get users to sign in via AAD and MFA into legacy apps. A token is given to the app to authorize the user.
SharePoint Lift and Shift
A new group called AAD DC Service Accounts. Add the SharePoint Profile sync user account to this group.
Domain Joined HDIsnight Cluster
You can “Kerber-ize” a HD cluster to increase security. This is in preview at the moment.
Remote Desktop Deployments
Domain-join the farm to AADDS. The licensing server is a problem at the moment – this will be fixed soon. Until then, it works, but you’ll get licensing warnings.
Questions
- Schema extensions? Not supported but on the roadmap.
- Logging? Everything is logged but you have to go through support to get at them at the moment. They want to work on self-service logging.
- There is no trust option today. They are working on the concept of a resource domain – maybe before end of the year.
- Data at rest, in ARM, is encrypted. The keys (1 set per domain) are managed by MS. MS has no admin credentials – there’s an audited process for them to obtain access for support. The NTLM hashes are encrypted.
Deciding When to DIY Your Own AD Deployment
Features Being Considered
- Cloud solution provider support – maybe early 2018.
- Support for a single managed domain to space multiple virtual networks
- Manage resource forests
- Schema extensions – they’ll start with the common ones, and then add support for custom extensions.
- Support for LDAP writes – some apps require this
Any questions/feedback to aaddsfb@microsoft.com