Setting Up Azure – The Three Permissions You Will Need

You need to have rights to configure certain things in Microsoft Azure when you are setting it up for the first time. I will list those three permissions and the reasons for them in this post.

1. Global Admin Rights

You are going to need rights to configure things in Azure AD. For example, you should be creating security groups and using those for role-based access control of things like management groups, subscriptions, and maybe even resource groups – the higher in the hierarchy, the better, in my opinion.

This will require that you have Global Admin Rights. This is the equivalent of being a domain admin in Azure AD, and will impact all services attached to your directory such as Office 365. This right should be limited to just a few people. In a very large organisation, someone else might be doing these tasks for you because you will not be granted the necessary rights.

This role is easily added to the user account in Azure AD, either at the time of creation or later by opening the user account and selecting Assigned Roles.

2. Access Management For Azure Resources

This is an easy right to miss! It is also known as Elevated Access. This right gives you access to all subscriptions and management groups in your directory (tenant) and therefore grants you superuser powers that should be limited to a very small group of capable people. Here’s how I learned about the right: I was cleaning up management groups that I created using a service principal. I knew the management groups were there, and I could see them, but my Global Admin user couldn’t remove them. It was only when I elevated my account that I was able to move the subscriptions and remove the management groups.

Part of the reason this right is so hidden is that it is not configured in the user account screen in the Azure Portal. Instead, sign in to the Portal with your Global Admin-enabled user, open Azure AD, and then go to Properties. Now click “Yes” under Access Management For Azure Resources. Now you will have rights to everything in Azure even if you weren’t granted them originally – this is why this superpower should be tightly controlled!

3. Role-Based Access

The typical person working with Azure should have only the rights that they need to do their job. The two big reasons are:

  • External threats: Prevent someone from compromising a dev/ops employee’s account and using their rights to compromise the entire system.
  • Internal threats: Limit access that a single employee has, either for security or compliance reasons.

For example, one should not be made a subscription owner just “because”. Typically, being made a Contributor will give you more than enough rights to do your job in a subscription. And maybe a lesser right is necessary – an auditor might only be made a Reader or you might use/create a more specialised role.

One should start the RBAC design using management groups. As with organisational units in Active Directory Domain Services, management groups should model the administrative model, not the HR org chart. Permissions and policy association should start at the top and become more granular as you work your way down. Eventually, you will grant dev/ops rights often at the subscription or even resource group level.

Another Consideration: Privileged Identity Management

PIM is a solution in the Azure AD per-user licensing SKUs that is sometimes used in large enterprises. It allows you to deploy just-in-time access to Azure resources/rights. There are a bunch of features in PIM that make it a useful feature to limit any one person’s access to what they need, when they need it, and for only as long as they need it, with MFA, oversight, and auditing.

How To Remove Orphaned “Synced” Users/Groups From Azure AD

In this post, I will explain how to remove users or groups from Azure AD that were synchronized into Azure AD (your tenant) but are left behind after removing Azure AD Connect – typically this is a lab scenario.

Production Environment

Almost every search result you will find discusses this scenario, where you want to remove users/groups from Azure AD without removing Azure AD Connect. The solution is pretty simple:

  1. Create an OU(s) in the “on-premises” using Active Directory (Azure AD Users & Groups). This OU will be used to store objects that won’t be synchronized to Azure AD.
  2. Modify the sync configuration of Azure AD Connect to sync only required OUs – exempt your new OU(s).
  3. Move the unwanted objects to the new OU(s).
  4. Wait for the next Azure AD Connect sync cycle (every 30 minutes by default), or force it yourself.

The users/groups in the exempted OU(s) will automatically be removed from Azure AD.

But what about orphaned objects when Azure AD Connect has already been uninstalled/disconnected?

Removing Orphaned Synced Users/Groups

You are going to need Azure AD PowerShell to make this work. I tried it using the v1 cmdlets, it worked, and I haven’t tried the v2 cmdlets, which might also work. Basically, you cannot do this in the Azure Portal, but you can do it using Azure AD PowerShell.

First I signed into Azure AD using a tenant administrator (global admin):

Connect-MsolService

Then I queried my groups:

Get-MsolGroup

I removed the unwanted groups one at a time:

Get-MsolGroup -SearchString "DisplayNameOfGroup" | Remove-MsolGroup

I confirmed deletion using PowerShell – note that the Azure Portal will take a few minutes to realise that the groups were removed!

Get-MsolGroup

My example is done using groups, but the user version of the cmdlets should work too.

Remove-MsolUser -UserPrincipalName <userprincipalname>

Did you Find This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in London on July 5-6, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.

Disable Already Removed Azure AD Connect

It’s possible that someone removes your Azure AD Connect server(s), and you then want to remove Azure AD Connect synchronisation from Azure AD. However, the Azure Portal does not give you that option to remove synchronisation. To get around this, you can use Azure AD PowerShell. In my example, I used the v1 cmdlets, but it’s also possible that the v2 cmdlets will work too.

I logged into Azure AD:

Connect-MsolService

Then I checked the current configuration:

Get-MsolDirSyncConfiguration

I disabled Azure AD Connect synchronisation:

Set-MsolDirSyncEnabled –EnableDirSync $false

I then checked my work:

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Straight over to the Azure Portal (Azure Active Directory > Azure AD Connect), and I verified that synchronisation was disabled:

image

Did you Find This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in London on July 5-6, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.

Azure AD Domain Services

 

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

  1. You provision a VNet.
  2. Then you activate Azure AD Domain Services in Azure AD on that VNet
  3. You can manage the domain using RSAT.
  4. 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

27-09-2017 16-13 Office Lens

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

27-09-2017 16-39 Office Lens

 

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

Webinar Recording: Defending Today’s Threats With Tomorrow’s Security By Microsoft

MicroWarehouse has posted the recording of our last webinar, which explained why the security solutions of the 1990s that some companies are still relying on, are being easily defeated by attackers today.

The post explains what is happening now, based on 2015 survey information from multiple sources. And I explain how a number of cloud-based security services from Microsoft can protect both your on-premises and cloud infrastructures from these modern attack methods, that your firewall and anti-malware scanning will let pass right through or never see.

In fact, I just saw a support request on a security issue that 2 of the solutions in this webinar would have prevented.

image

We have also shared the slides and a hand-out with some follow-up reading/watching.