Thursday 25 February 2021

First Look at Azure Active Directory Connect Cloud Sync

New schools setting out on the Microsoft 365 platform can look forward to a future without on-premise servers, using Azure AD as the directory service and InTune (Microsoft Endpoint Manager) for device management. 

For existing schools, moving to the cloud while maintaining on-premise Active Directory isn't quite so easy.   Local resources such as printers and file shares are protected by local AD while cloud resources require Azure AD accounts. This means two different user databases that have to be maintained and updated.

Fortunately Microsoft has always provided an application to make this job easier. 

The best known is Azure Active Directory Connect (AADC), a tool that has been ‘rebranded’ several times over the years.  Administrators may also know this utility as the Directory Synchronization tool, Directory Sync tool or just DirSync.

Basically AADC is an application that synchronizes the on-premises Active Directory Domain Services (AD DS) users to the Azure AD tenant. As well as account provisioning it can also transfer a password hash that delivers a seamless logon experience for the user across both platforms. Although it's possible for changes to move in the opposite direction (password updates in the cloud are reflected in local AD) for most setups this is a one way trip - changes in on-premises Active Directory are reflected in Azure AD.

Azure Active Directory Connect has been a workhorse for Azure deployments but it has a number of limitations, some of which are particularly relevant for schools.

First, only one instance of AADC can be attached to a single Azure AD tenant. For larger educational trusts that are planning to consolidate multiple sites, each having their own Office365 organization, this provides quite a challenge. Currently the only solution is to ensure network level connectivity between the domain controllers in each forest so that the sync requests can be channelled through a single AADC instance. For medium sized companies that have a corporate WAN in place this isn’t a problem but for an educational trust trying to incorporate a dozen small primary schools, all using different internet providers, it’s a major headache.

Second, AADC requires a hosting device and in some cases that means dedicated server. If the school requires resilience or some degree of fault tolerance you now need two servers. For schools running a virtual infrastructure that requirement can be absorbed but for smaller sites it’s an unwelcome burden

Lastly although the ease of setup has improved over the years some expertise is still required to install and configure AADC which is largely managed through the onsite application rather than the cloud.

In response, Microsoft has rewritten Azure Active Directory Connect (AADC) from the ground up to create Azure Active Directory Connect Cloud Sync (AADCC).  Disregarding the confusing naming convention this new addition is a real winner for education

Lets run through a few of the new features.



First, AADCC can work alongside existing installations of AADC, This is because multiple instances of AADCC can connect to a single Azure organization, each managing a separate domain namespace, a killer feature which removes one of the biggest limitations of AADC. In the new model a fully detached AD forest with AADCC installed can feed into a single centralised tenancy, no WAN required.

Second most of the configuration and logic has been moved into the cloud meaning that the local install is extremely light. The only requirement is domain-joined Windows 2012 Server with SQL Server 2012 Express LocalDB (a smaller version of SQL Server Express) installed.

Lastly the software has no additional licencing requirements and has a simple deployment model. Installing multiple active agents provides high availability

How does this help the adoption of Modern Management techniques in a Trust or District model?

Up until now amalgamation of schools into unified tenancy model has been hampered by the fact that only one site can host the AADC. A second site that wished to run with hybrid identity would need ‘line-of-site’ of the hosting sites domain controllers. 

So long as all the other sites only used ‘cloud only’ user accounts you didn’t have a problem but if two large schools, both with a detached AD forest wanted to move to Modern Management while maintaining access to local file shares through hybrid identities, you had a problem - until now.


So what's the drawback to using AADC over AADCC ?

The new tool does not allow Pass-Through Authentication. Currently passwords are checked against a password hash stored on Azure. Also there’s no support for writeback for passwords, devices or groups but other than those two items the functionality is much the same. 

This video from the recent Ignite Conference gives a good overview which includes some configuration and install instructions.

It’s hard to overestimate the importance of this new capability to the adoption of Microsoft Endpoint Manager as a viable management platform.


Tuesday 2 February 2021

Managing Local Groups with InTune

For most IT administrators control over local user groups is an important part of the management process. Unfortunately for Windows devices that are Azure joined this has always been a bit of a challenge.

Working with InTune there was a CSP Policy - RestrictedGroups that you could use but it had a number of limitations.

  • It didn’t support groups, only user accounts.
  • It had an overwrite feature – it simply replaced the original user list with users in the policy set so the results were a little unpredictable. If a user account had been added to the Local Admins group to support a legacy application it would be removed when the new policy set was applied. You couldn’t create policies that layered accounts into the group.
  • It only controlled the local Admin group, not any of the other in-built local groups.

However with Windows 10, version 20H2 you get a new feature – the ability to control access to local groups by nesting an Azure AD security group.

The initial setup is a bit of a challenge but once done it’s a useful tool to have at your disposal.

The first job is to create a Azure AD security group to contain your new local admins, let's call it  - All Additional Local Device Admins.

The second task is to find the SID of your new group.

Unfortunately you can’t read the information from the web UI because it doesn’t display the SID.  However it can be found with the Graph API/ Explorer using the Group Object ID which is presented as part of the Group properties page.


With the Object ID recorded, login to the Graph API/ Explorer and run a GET query using the form of the request below.

https://graph.microsoft.com/v1.0/groups/<your Group ID>


 

The group metadata will be displayed in the results window and this will include the SID. Record this value.

This next task is to create a policy that uses the SID to embed your AD Azure group into the local Admins Group.

Navigate to 

        Microsoft Device Management (Intune) - Devices - Windows - Configuration Profiles

Create a new Configuration Profile - type Custom. Provide an appropriate name and description.

Add a new OMA-URI setting using the ID below for the OMA-URL identifier.

       ./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

 

The payload for this policy is in the Value field.

It contains a snippet of XML that defines the action. The options that you can incorporate can provide a lot of flexibility allowing you to add or overwrite the contents of any local group but for the moment let's keep to the original requirement to update the local Admin group.


<GroupConfiguration>

<accessgroup desc = "Administrators">

<group action = "U"/>

<add member = "S-1-12-1-3360748891-1147449691-4205429123-2160019913"/>

<remove member = ""/>

</accessgroup>

</GroupConfiguration>


The code contains the instructions to update “U” the “Administrators” group by adding the SID “S-1-12-1-3360748891-1147449691-4205429123-2160019913” which we already know references the Azure Group All Additional Local Device Admins

The XML has a number of different action types including Restrict “R” which provides the same functionality as the RestrictedGroups/ConfigureGroupMembership policy setting.

You can get full list of actions and options here.

Save the policy and assign it to a suitable Device security group. There’s no option to select a single device so it’s best to test it out on a test group first before trusting your luck (and job) to All Devices.

You will now find that adding an Azure AD user account to the All Additional Local Device Admins group will grant admin rights on a policy refresh. Even better, removing the user will remove admin rights on the next login.

If you use the local MMC to view the members of the Admin group you can see the new Group account added, but only as the SID.The name is not resolved.

Of course there’s no reason why you couldn’t use the same technique to control the membership of other local groups such as Backup Operator. Just be aware that although this works with all Windows 10 editions, other than Home you need to be on version 20H2 to get this new feature