RoboCopy supports Copying Files over SMB with Compression on Windows Server 2019, and beyond

Windows Server

Microsoft is working hard to add features to Windows Server vNext, but is not forgetting about the vast majority of organizations that run Windows Server 2019 and might like the same functionality.

The feature that I want to discuss with you today is SMB compression with robocopy.exe.

SMB Compression with Robocopy

The announcement for Windows Server vNext Insider Preview version 20206 mentions that Microsoft added the /compress command switch to robocopy.exe.

When using this switch, If the destination computer supports SMB compression and the files being copied are compressible, you should see significant performance improvements.

When the command switch is used, the SMB Compression functionality adds inline whitespace compression to file transfers, removing congestion and copy time. Depending on the (in)efficiency of file formats and the IO pattern, the performance increase in copies can be up to fourfold.

SMB Compression uses a negotiation mechanism, so multiple compression algorithms are possible, and vendors can add their own. Currently the list is XPRESS (also known as LZ77), XPRESS Huffman (LZ77+Huffman) and LZNT1.

Concluding

Ironically, Microsoft released Windows Server vNext Insider Preview version 20206 on September 2nd, 2020 and released KB4571748, for Windows Server 2019 on August 20th, 2020. This means that Windows Server 2019 gained the functionality even earlier than the Preview build.

Windows 10 hasn’t got the SMB Compression functionality rolled out yet, but is slated to have support for it through updates, too.

0  

What’s New in Azure Active Directory in August 2020

Azure Active Directory

Azure Active Directory is Microsoft's Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following planned, new and changed functionality for Azure Active Directory for August 2020:

What’s Planned

Updates to Azure Multi-Factor Authentication Server firewall requirements

Service category: Multi-Factor Authentication (MFA)
Product capability: Identity Security & Protection

Starting October 1st, 2020, Azure MFA Server firewall requirements will require additional IP ranges.

If you have outbound firewall rules in your organization, update the rules so that your MFA servers can communicate with all the necessary IP ranges. The IP ranges are documented in Azure Multi-Factor Authentication Server firewall requirements.

Upcoming changes to user experience in Identity Secure Score

Service category: Identity Protection
Product capability: Identity Security & Protection

Microsoft is updating the Identity Secure Score portal to align with the changes introduced in Microsoft Secure Score’s new release.

The preview version with the changes will be available at the beginning of September. The changes in the preview version include:

  • “Identity Secure Score” renamed to “Secure Score for Identity” for brand alignment with Microsoft Secure Score
  • Points normalized to standard scale and reported in percentages instead of points

In this preview, admins can toggle between the existing experience and the new experience. This preview will last until the end of November 2020. After the preview, admins will automatically be directed to the new experience.

What’s New

New Restricted Guest Access Permissions in Azure AD Public Preview

Service category: Access Control
Product capability: User Management

Microsoft has updated the directory level permissions for guest users.

These permissions allow administrators to require additional restrictions and controls on external guest user access. Admins can now add additional restrictions for external guests' access to user and groups' profile and membership information. With this public preview feature, organizations can manage external user access at scale by obfuscating group memberships, including restricting guest users from seeing memberships of the group(s) they are in.

delta queries for service principals and OAuth2PermissionGrant General Availability

Service category: MS Graph
Product capability: Developer Experience

Microsoft Graph Delta Query now supports the Service Principal and OAuth2PermissionGrant resource type in v1.0.

Now organizations can programmatically track changes to these resources efficiently and provides the best solution to synchronize changes to those resources with a local data store.

New Federated Apps available in Azure AD Application gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In August 2020, Microsoft has added the following new applications in the App gallery with Federation support:

Resource Forests for Azure AD Domain Services General Availability

Service category: Azure AD Domain Services
Product capability: Azure AD Domain Services

The capability of resource forests in Azure AD Domain Services is now generally available. Organizations can now enable authorization without Password Hash Synchronization (PHS) to use Azure AD Domain Services, including smart-card authorization.

Regional replica support for Azure AD DS managed domains General Availability

Service category: Azure AD Domain Services
Product capability: Azure AD Domain Services

Admins can expand a managed domain to have more than one replica set per Azure AD tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD Domain Services. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline.

Azure AD My Sign-Ins General Availability

Service category: Authentications (Logins)
Product capability: End User Experiences

Azure AD My Sign-Ins is a new feature that allows enterprise users to review their sign-in history to check for any unusual activity. Additionally, this feature allows end-users to report “This wasn’t me” or “This was me” on suspicious activities.

SAP SuccessFactors HR driven user provisioning to Azure AD General Availability

Service category: App Provisioning
Product capability: Identity Lifecycle Management

Organizations can now integrate SAP SuccessFactors as the authoritative identity source with Azure AD and automate the end-to-end identity lifecycle using HR events like new hires and terminations to drive provisioning and de-provisioning of accounts in Azure AD.

Custom Open ID Connect MS Graph API support for Azure AD B2C

Service category: B2C – Consumer Identity Management
Product capability: B2B/B2C

Previously, Custom Open ID Connect providers could only be added or managed through the Azure portal. Now the Azure AD B2C customers can add and manage them through Microsoft Graph APIs beta version as well.

Assign Azure AD built-in roles to cloud groups Public Preview

Type: New feature
Service category: Azure AD roles
Product capability: Access Control

Organizations can now assign Azure AD built-in roles to cloud groups with this new feature. For example, the SharePoint Administrator role can be assigned to the Contoso_SharePoint_Admins group. Organizations can also leverage their investments in Azure AD Privileged Identity Management (PIM) to make the group an eligible member of the role, instead of granting standing access.

Insights Business Leader and Insights Administrator built-in roles now available

Service category: Azure AD roles
Product capability: Access Control

Microsoft introduces two new built-in roles:

  1. Insights Business Leader
    Users in the Insights Business Leader role can access a set of dashboards and insights via the M365 Insights application. This includes full access to all dashboards and presented insights and data exploration functionality. However, users in this role don't have access to product configuration settings, which is the responsibility of the Insights Administrator role.
  2. Insights Administrator
    Users in the Insights Administrator role can access the full set of administrative capabilities in the M365 Insights application. A user in this role can read directory information, monitor service health, file support tickets, and access the Insights administrator settings aspects.

What’s Changed

Application Admin and Cloud Application Admin can manage extension properties of applications

Service category: Azure AD roles
Product capability: Access Control

Previously, only the Global Administrator could manage the extension property. Microsoft has now enabled this capability for the Application Administrator and Cloud Application Administrator as well.

MIM 2016 SP2 hotfix 4.6.263.0 and connectors 1.1.1301.0

Service category: Microsoft Identity Manager
Product capability: Identity Lifecycle Management

A hotfix rollup package (build 4.6.263.0) is available for Microsoft Identity Manager (MIM) 2016 Service Pack 2 (SP2). This rollup package contains updates for the MIM CM, MIM Synchronization Manager, and PAM components. In addition, the MIM generic connectors build 1.1.1301.0 includes updates for the Graph connector.

1  

On-premises Identity updates & fixes for August 2020

Windows Server

Even though Microsoft’s Identity focus moves towards the cloud, they are not forgetting their on-premises roots. Windows Server 2016 and Windows Server 2019 still receive updates. These are the updates and fixes we saw for August 2020:

 

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4571694 August 11, 2020

The August 11 update for Windows Server 2016 (KB4571694), updating the OS build number to 14393.3866 is a security update that includes quality improvements.

This update addresses a critical Netlogon Elevation of Privilege Vulnerability (CVE-2020-1472). This vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a Domain Controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could connect to a domain controller to obtain domain administrator access. Addresses this vulnerability has started by flagging insecure connections to Netlogon with Event ID 5829.

This update also addresses an important Local Security Authority Subsystem Service (LSASS)Elevation of Privilege Vulnerability (CVE-2020-1509). This vulnerability exists in the Local Security Authority Subsystem Service (LSASS) when an authenticated attacker sends a specially crafted authentication request. A remote attacker who successfully exploited this vulnerability could cause an elevation of privilege on the target system's LSASS service.

If you’re using Windows Backup to create backups of Domain Controller, than this update is of importance, because is addresses an Elevation of Privilege vulnerability in the Windows Backup Service (CVE-2020-1534).

It includes the following Identity-related quality improvements:

  • It addresses an issue that causes Remote Server Administration Tools (RSAT) to stop working on Windows 10 machines. This occurs when you create or edit a Group Policy Object that contains a Scheduled Task.
  • It addresses an issue in Universal Windows Platform (UWP) apps that allows single sign-on authentication when an app does not have the Enterprise Authentication capability. With the release of CVE-2020-1509, UWP applications might begin prompting the user for credentials.
  • It updates the message users receive that tells them to check their phone for notifications from the Microsoft Authenticator application. This message only appears when authentication is done using the AD FS Azure Multi-Factor Authentication (MFA) adapter.

 

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4565349 August 11, 2020

The August 11 update for Windows Server 2019 (KB4565349), updating the OS build number to 17763.1397 is a security update that includes quality improvements.

This update addresses a critical Netlogon Elevation of Privilege Vulnerability (CVE-2020-1472). This vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a Domain Controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could connect to a domain controller to obtain domain administrator access. Addresses this vulnerability has started by flagging insecure connections to Netlogon with Event ID 5829.

This update also addresses an important Local Security Authority Subsystem Service (LSASS)Elevation of Privilege Vulnerability (CVE-2020-1509). This vulnerability exists in the Local Security Authority Subsystem Service (LSASS) when an authenticated attacker sends a specially crafted authentication request. A remote attacker who successfully exploited this vulnerability could cause an elevation of privilege on the target system's LSASS service.

If you’re using Windows Backup to create backups of Domain Controller, than this update is of importance, because is addresses an Elevation of Privilege vulnerability in the Windows Backup Service (CVE-2020-1534).

It additionally addresses an issue in Universal Windows Platform (UWP) apps that allows single sign-on authentication when an app does not have the Enterprise Authentication capability. With the release of CVE-2020-1509, UWP applications might begin prompting the user for credentials.

 

KB4571748 August 20, 2020

The August 20 update for Windows Server 2019 (KB4571748), updating the OS build number to 17763.1432 is a non-security update. It includes the following Identity-related fixes:

  • It addresses an issue that prevents a delegated user from importing a Group Policy object (GPO) even though the user has the required privilege.
  • It addresses an issue that sometimes prevents AppLocker from running an application whose publisher rule allows it to run.
  • It addresses an issue in which AppLocker publisher rules might sometimes prevent applications from loading software modules; this can cause partial application failure.
  • It addresses an issue that causes the configuration of the “Minimum Password Length” Group Policy with more than 14 characters to have no effect. For more information, see KB4557232.
  • It addresses classification failures caused by the wrong User Principal Name (UPN).
  • It addresses an issue that fails to log events 4732 and 4733 for Domain-Local group membership changes in certain scenarios. This occurs when you use the “Permissive Modify” control; for example, the Active Directory (AD) PowerShell modules use this control.
  • It addresses a Security Assertion Markup Language (SAML) Scoping support issue in the Active Directory Federation Service (AD FS) that is related to entityID and IDPList. For more information, see section 3.4.1.2 of the SAML Core specification.
  • It addresses an issue that prevents Account activity cmdlets from executing when you specify an identity that is not in a UPN format.
0  

KnowledgeBase: The Device Administrator Role is not available on the Roles and Administrators pane in the Azure Portal

Azure Active Directory

Swimming against the stream of all Azure Roles being available in the Roles and administrators pane of the Azure AD Portal, the Device administrator role is missing here.

Now, let’s explore how to add additional administrators to Azure AD-joined devices.

 

About Azure AD Join

Organization-owned Windows-based devices used to be joined to Active Directory. This is called domain-join. Now, in the age of cloud, organizations can opt to join devices to Azure AD, instead… or have Azure AD Connect synchronize domain-joined device objects to Azure AD, where these synchronized objects can be attached.This latter process is called Hybrid Azure AD Join, but went by the ‘Domain-join ++’ moniker for quite a while.

When Azure AD-joining a Windows 10-based device, a trust relationship is formed between the device and the Azure AD tenant of the organization. The Primary Refresh Token (PRT) that is configured for the Local Security Authority (LSA) provides single sign-on access to Azure AD-integrated resources, including Azure and Office 365.

 

About the Device administrator role

When Azure AD-joining a Windows 10-based device (not Hybrid Azure AD-joining a device) the user account for the person that performs the join is automatically configured with local administrator privileges.

By assigning the Device administrator role to other people, their user accounts also gain local administrator privileges when they sign into Azure AD-joined devices. This role is useful for service desk personnel and other persons who are responsible for all device-oriented support within the organization.

The Device administrator role used to be available in the Roles and administrators pane of the Azure AD Portal, but it is no longer there.

 

To assign Device administrator role privileges

The new way to assign Device administrator role privileges is on the Device Settings pane. Follow these steps to assign Device administrator role privileges:

  • Navigate your browser to the Azure AD Portal.
  • Sign in with an account that has Global administrator privileges.
    Perform multi-factor authentication, when prompted.
  • In the left navigation pane, click Azure Active Directory.
  • In Azure Active Directory's navigation pane, click Devices.
  • In the Devices navigation pane, click Device settings.

Azure Active Directory Portal - Device Settings - Additional local administrators on Azure AD joined devices (click for original screenshot)

  • Change the selection for the Additional local administrators on Azure AD joined devices option from None to Selected.
  • Click the No member selected text below the option.
    The Local administrators on devices blade appears.
  • On the Local administrators on devices blade, click the + Add button.
    The Add members blade appears.
  • Type the name of the person whose account you want to have local administrator privileges on all Azure AD-joined devices. Click the Select button at the bottom of the blade to select the account to select the user object and close the blade.
  • On the Local administrators on devices blade, click the + Add button to add additional user accounts to the role and repeat the previous step to do so.
  • Click OK at the bottom of the Local administrators on devices blade to save your selection and close the blade.
  • At the top of the Device Settings pane, click Save to save your settings.

 

Concluding

There is a very good reason why the Device administrator role is not in the Roles and administrators pane of the Azure AD Portal: this functionality is Premium functionality and only available in Azure AD tenants with at least one Azure AD Premium P1 and/or Azure AD Premium P2 subscription license (or a license suite that includes either of these licenses). In non-Premium Azure AD tenants, the Additional local administrators on Azure AD joined devices option is not available.

Adding this role to the Roles and administrators pane would make it too easy to circumvent the license restriction. The downside however, is that you cannot assign a group to the Device administrator role. Sad smile

0  

Azure Multi-Factor Authentication Server 8.0.5.1 is here

Microsoft Azure Multi-Factor Authentication

Roughly 6 months ago, on February 26th, 2020, we saw the release of Microsoft Multi-factor Authentication Server (MFA Server) version 8.0.4. Now it’s time for an update to Microsoft’s product that allows organization to add multi-factor authentication to RADIUS-, AD FS-, IIS-based and other on-premises authentication scenarios. This week, Microsoft released version 8.0.5.1.

 

What’s New

The release notes mention the following changes:

 

Added Cross Site Request Forgery (CRSF) prevention to User Portal

Cross-site request forgery (CSRF) is a type of malicious exploit of a website where unauthorized commands are submitted from a user that the web application trusts.

In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

CSRF attacks are now prevented in MFA Server’s User Portal. The User Portal is where end-users and service desk personnel can register (end-users only) and make changes to the MFA settings, stored in the MFA Server database.

As MFA Server’s User Portal, by default, shows the User Portal version on the sign-in page, and MFA Server User Portals are easy to find, even with a simple Bing search, organizations should really upgrade their MFA Server implementations to avoid propagating a vulnerable MFA Server User Portal.

 

Added compatible Content-Security-Policy headers to the User Portal’s Web.Config

Cross-Site Request Forgery Prevention can be achieved in many ways. While MFA Server’s User Portal obviously added CSRF tokens, a double submit cookie and value,  or an encrypted token, Microsoft didn’t stop there.

Microsoft also changed the Content-Security-Policy header.

To prevent malicious attacks, many new protections for websites utilize security headers. Through security headers, you can prevent malicious scripts from running in browsers visiting your AD FS infrastructure, prevent the acceptance of forged TLS certificates and prevent clickjack attacks. Through security response headers, the information security level of the MFA Server’s User Portal is upgraded to a higher level.

The CSP response header is used to prevent cross-site scripting, clickjacking and other data injection attacks by preventing browsers from inadvertently executing malicious content.

 

Known Issues

Windows Authentication for Remote Desktop Services (RDS) is not supported for Windows Server 2012 R2.

 

Upgrade considerations

You must upgrade MFA Server and Web Service SDK before upgrading the User Portal or AD FS adapter. Read the guidance in the How to Upgrade section in this blogpost for more information.

 

Download

You can download Azure Multi-Factor Authentication Server 8.0.5.1 here.
The download weighs 128 MB.

 

Version information

This is version 8.0.5.1 of Azure Multi-Factor Authentication Server.
It was signed off on August 25th, 2020.

0  

Windows Server vNext Preview build 20201 is now available

Windows Server

Microsoft is working on the next version of Windows Server, beyond Windows Server 2019. Now, we can all enjoy the first preview version of what’s to come.

 

About Windows Server vNext build 20201.1000

Windows Server vNext is the successor to Windows Server 2019. It is a Long-Term Servicing Channel (LTSC) release that contains both the Desktop Experience and Server Core installation options for Datacenter and Standard editions.

Note:
A Windows Server vNext Semi-Annual Channel (SAC) Preview is also released. SAC releases, like Windows Server, version 2004, are shipped without the Desktop Experience and released every 6 months, where LTSC releases are released every 2-3 years.

This is the first Preview build of Windows Server vNext and includes improvements around UDP, SMB, VM affinity, vSwitch, BitLocker in Failover cluster scenarios. This version introduces new features like MsQuic and support for Direct Server Return (DSR) for Windows containers and Kubernetes networks.

Everyone thought it couldn’t be done… but with this release Server Core container images are even smaller than ever, by roughly 20%.

 

Get started with Windows Server vNext

Windows Server vNext Preview build 20201 is now available to Windows Server Insiders.

Note:
If you are not a Windows Insider, yet, you can register to become one, for free.

Windows Server vNext Preview build 20201 x64 is available for download as a 4,3 GB ISO in the Brazilian Portuguese, Chinese Simplified, Chinese Traditional, Czech, Dutch, English, French, German, Hungarian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Swedish and Turkish language.

After downloading, you can activate Standard installations with product key
MFY9F-XBN2F-TYFMP-CCV49-RMYVH.

Activate Datacenter installations with product key
2KNJJ-33Y9H-2GXGX-KMQWH-G6H67.

Windows Server vNext Preview build 20201 x64 is also available for download as a pre-activated 7.7 GB virtual hard disk (VHDX) file. The VHDX is available in English, only.

 

Expiration

Windows Server vNext Preview build 20201 expires on January 31st, 2021.

 

Enjoy! Thumbs up

 

FURTHER READING

Announcing Windows Server vNext Preview Build 20201
Windows Insider Preview Downloads
Windows Server build 20201

0  

Ten things you need to know about Assigning Groups to Azure AD Roles

Azure Active Directory

Last week, Alex Simons announced on behalf of his team the Public Preview of assigning groups to Azure AD roles with a blogpost titled Assigning groups to Azure AD roles is now in public preview! on the Microsoft Tech Community.

Ten things you need to know

Assigning groups to Azure AD Roles sounds perfect, but in reality, there are a couple of things you’ll want to know before deploying it to address your organizations’ needs:

Assigning Roles to Azure AD Roles Public Preview

Assigning groups to Azure AD Roles is currently in Public Preview. This means that Microsoft doesn’t really want you to deploy in production, just yet.

Looking back at Conditional Access Baseline Policies, you might want to hold off on embracing Public Preview functionality, as they might change at any moment: the granular Conditional Access Baseline Policies became rigid Security Defaults.

Also, looking at Azure MFA’s Hardware Token functionality, some functionality stays in Public Preview for an awful long time. As you lock your organizations’ strategy on these features, you might face architectural debt.

Requires an Azure Premium P1 license

Assigning a user to one or more Azure AD roles is available in every Azure AD tenant, including the Azure AD free tenants. However, assigning a group to one or more Azure AD roles, requires at least one Azure AD Premium P1 license.

Microsoft previously held off on requiring licenses on features in Public Preview. This time, though, Microsoft wants organizations to benefit from this security feature only when a paid licensing plan is activated.

Support for Azure AD Groups, but not on-premises groups

In Public Preview, the Assign Groups to Azure AD Roles feature is supported only for groups that live in Azure AD. Groups that are synchronized from an on-premises directory, like one or more Active Directory forests or LDAP v3 compatible directories are not supported at this time. However, the feature is planned.

As backup and restore of Azure AD is currently a pain, many organizations are looking at assigning a synchronized group to Azure AD roles, removing yet another configuration stored exclusively in Azure AD.

Requires new groups

Azure AD roles can only be assigned to groups that have the Azure AD roles can be assigned to the group (Preview) setting enabled.

This setting configures the isAssignableToRole property. It is set to true.

However, the setting can only be set at the time of creation of a group. This means that the groups you want to use the assign groups to Azure AD roles functionality with need to be new groups.

No support for Dynamic Groups

When you create a new group to use use the Assign groups to Azure AD roles functionality with, it must be created with the Assigned membership type. Dynamic Groups are not supported with the functionality at this point.

No support for nested groups

Of course, you might be tempted to create new groups to use with the new Assign groups to Azure AD roles functionality and simply specify existing groups as members of the new group.

However, group nesting is not supported for the functionality at this point.

A maximum of 200 role-assignable groups per Azure AD tenant

Before you go ahead and create all the groups you might ever need to assign Azure AD roles to, be aware that there is a maximum of 200 role-assignable groups per Azure AD tenant. Up to 200 groups can have the isAssignableToRole property set to true.

A matter of scope

As true administrators, you want to scope the administrative privileges assigned to people. The Assign Groups to Azure AD Roles functionality is currently 100% scoped to groups.

This means, that once a group has the isAssignableToRole property set to true, it can be used to assign any Azure AD role to the built-in Azure AD roles. However, the available roles can’t be scoped down. Additionally, there is no support for custom Azure AD roles or Azure AD Administrative Units (AUs).

Group Ownerships woes

Complexity is the enemy of security.

By default, only people with the Global administrator and Privileged role administrator role can create groups with the isAssignableToRole property set to true. By default, they are the only ones that can manage the memberships of a role-assignable group, but you can delegate the management of role-assignable groups by adding group owners.

There are many scenarios in which I can see a group owner be able to elevate privileges. I would refrain from using group owners with the Assign Groups to Azure AD Roles functionality, unless you consider these group owners the equivalent to Global admins.

Integration with Privileged Identity Management (PIM) Preview

Microsoft provides integration with Azure AD Privileged Identity Management (PIM) for the Assign Groups to Azure AD Roles functionality. For instance, this integration enables approval workflows for adding members to a role-assigned group.

However, you must be on the updated version of PIM to be able to assign a group to an Azure AD role via PIM. You could be on older version of PIM because your Azure AD organization leverages the PIM API.

You’ll need to reach out to pim_preview@microsoft.com to move your organization and update your API, in this case.

Concluding

For small cloud-only organizations with Azure AD P1 subscription licenses, the current Public Preview for the Assign Groups to Azure AD Roles functionality is good news. Without the on-premises integration, these organizations can be sufficiently agile to cope with any changes to the functionality in the future.

However, organizations with complex delegation needs, privileged identity management challenges and stringing along an on-premises directory, might have more problems putting the feature to effective use. The maximum of 200 groups without nesting might even put them off indefinitely.

0  

KnowledgeBase: You receive “the mS-DS-ConsistencyGuid attribute is already in use” when you change the source anchor on a Staging Mode Azure AD Connect installation

Azure AD Connect

In environments with multiple Azure AD Connect installations, sometimes, you experience unexpected behavior. For instance, when you want to change the source anchor from objectGUID to mS-DS-ConsistencyGuid for your Hybrid Identity implementation.

The situation

An organization leverages multiple Azure AD Connect installations. One installation is the actively synchronizing Azure AD Connect installation, the other installations are Staging Mode installations. Only the actively synchronizing installation performs exports to the connected Active Directory and Azure AD directories.

All Azure AD Connect installations were initially configured with the objectGUID attribute as the source anchor. The source anchor was not migrated to the mS-DS-ConsistencyGuid attribute till date.

The issue

Changing the source anchor requires running the Configure Source Anchor task in an Azure AD Connect installation. Then, you need to make the same changes on the Staging Mode servers as well.

However, when running the Configure Source Anchor task on the (first) Azure AD Connect Staging Mode server, you receive the following error:

"Your source anchor configuration cannot be changed because the mS-DS-ConsistencyGuid attribute is already in use" error on an Azure AD Connect Staging Mode server (click for original screenshot)

The cause

The error is caused, because Azure AD Connect checks the contents of the mS-DS-ConsistencyGuid attribute of objects in scope to see if no other application, system or service uses the attribute. Overwriting these values could potentially be catastrophic for these solutions.

The solution

The actively synchronizing Azure AD Connect installation is the service that writes values in the mS-DS-ConsistencyGuid attribute. As a Staging Mode Azure AD Connect installation doesn’t perform export actions, it does not actually write to the mS-DS-ConsistencyGuid attribute.  Therefore, the issue can be safely ignored, and Azure AD Connect can be instructed to do so.

On the Staging Mode server(s) we need to start Azure AD Connect differently. Instead of starting AzureADConnect.exe from the Desktop or Start Screen, we need to start it from an elevated Command Prompt window with the following two commands:

cd C:\Program Files\Microsoft Azure Active Directory Connect

AzureADConnect.exe /SkipLdapSearch

Then, we can run the Configure Source Anchor task without the error.

Concluding

A Staging Mode server checks the contents of the mS-DS-ConsistencyGuid attribute, as it has no knowledge of any actively synchronizing Azure AD Connect installation. This information is not provided from the endpoints that Azure AD Connect communicates with, although they could…

Further reading

Using ms-DS-ConsistencyGuid as sourceAnchor
Explained: User Hard Matching and Soft Matching in Azure AD Connect  
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1    
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2    
Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3  
Azure AD Connect v1.5.18.0 brings mS-DS-ConsistencyGUID as source anchor for Groups

0  

Getting to know the devices that people in your organization use App Passwords on

Azure Multi-factor Authentication

On this blog, and in several other places, I’ve shared my experiences with Azure Multi-Factor Authentication. In the early days of Azure MFA, a lot of organizations, a lot of client applications and a lot of 3rd party services were not able to perform multi-factor authentication. For these situations, Microsoft provided the App Passwords functionality.

In IT, temporary solutions tend to become the most permanent solutions. As you’d guess, most of the people, devices and services that were initially configured with an app password, and not with true multi-factor authentication, still use these app passwords.

The question now is:

Who still uses App Passwords, and where?

About App Passwords

If you have multi-factor authentication turned on and a less secure client application or device isn't prompting you for multi-factor authentication, you may be able to sign in with an app password instead.

An app password is a long, randomly generated password that you provide only once instead of your regular password when signing in to an app or device that doesn't support multi-factor authentication.

Getting to know the devices and people

To answer the question on who (or what service account) still uses App Passwords, I look at the Sign-in logs for Azure AD in Azure Log Analytics. The below three steps provide a means to get the information on App Password usage.

   

STEP 1: SET UP A LOG ANALYTICS WORKSPACE

As the first step, set up a Log Analytics Workspace. As Azure subscriptions, by default, do not get configured with a Log Analytics workspace, the first step is to create a Log Analytics Workspace.

If you already have an Azure Log Analytics workspace, you can skip this step.

Perform these steps:

  • Sign into the Azure Portal with an account that has one or more of the roles mentioned in the above requirements paragraph.
  • In the Azure portal, click All services. In the list of resources, type Log Analytics. As you begin typing, the list filters based on your input. Select Log Analytics workspaces from the list.
  • Click + Add.
    The Log Analytics workspace blade appears.
  • Fill in the required information to add a Log Analytics workspace.
  • Click OK on the bottom of the blade to create the Log Analytics workspace.

 

STEP 2: INTEGRATE AZURE AD Sign-in LOGS INTO LOG ANALYTICS

If you’ve already integrated your Azure AD sign-in logs with an Azure Log Analytics workspace, you can skip this step.

Perform the following steps to route audit activity logs and sign-in activity logs from Azure Active Directory to the Log Analytics Workspace:

  • While still logged on in the Azure AD Portal, click on Azure Active Directory in the left navigation menu.
  • Select Diagnostic settings in Azure AD’s navigation menu.
  • In the main pane, click Add diagnostic setting.
    The Diagnostic settings blade appears.
  • On the Diagnostic settings blade, provide a name for the diagnostic settings.
  • Select the Send to Log Analytics workspace check box.
  • Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
  • To send sign-in logs to the Log Analytics workspace, select the SignInLogs check box.
  • Select Save on top of the blade to save the diagnostic settings.

Allow for ample time for the diagnostic settings to apply and the data to be streamed to the Log Analytics workspace.

   

Step 3: Get information on App Password Usage

Now, let’s get the information out of the Azure Log Analytics workspace to report on the people still using App Passwords and the information that is available on the devices they use these App Passwords on:

  • While still logged on in the Azure AD Portal, search for the Azure Log Analytics workspace where you stream the sign-in logs to.  Click on the name of the workspace from the search results.
  • In the left navigation menu of the Log Analytics workspace, click Logs.
  • Close the Example queries dialog window, if it appears.
  • In the main pane, on the New Query 1 tab, in the field underneath the blue Run button, type the following query:

SigninLogs
| where AuthenticationDetails contains "MFA requirment skipped due to app password"
| distinct Identity, tostring(split(UserAgent, "/", 0))
| sort by Identity asc

  • Select an appropriate time range in the Time range : field next to the Run button.
  • Run the query by pressing the blue Run button. The names of the people and their device types appear in the Results field underneath.

Tip!
You might be tempted to pick a large time range, but what you’ll notice is that this makes little sense. Your results may include devices that are no longer in use, devices that have been upgraded to a newer version or configuration and services that have been converted to use API access since the beginning of the time frame.

Concluding

App Passwords are remnants of old ways of dealing with multi-factor authentication. While you might still encounter some client applications, devices and services that are not capable of using multi-factor authentication, these distinct exceptions can be excluded from multi-factor authentication, if the organization’s security measures allow for it.

At least now, you have a list of exceptions to work with and minimalize.

Further reading

App Passwords are only available with a non-Conditional Access MFA requirement  
HOWTO: Set an alert to notify when an Azure AD emergency access account is used  
HOWTO: Set an alert to notify when an additional person is assigned the Azure AD Global Administrator role

0  

vSphere 7’s vMotion interface notifies for time differences between vSphere hosts

Virtualizing Domain Controllers

In the series Virtualizing Domain Controllers on vSphere, I explained the importance of proper time synchronization for virtualized Active Directory Domain Controllers and how to keep these Domain Controllers on trusted vSphere hosts only. Recent versions of the VMware Tools have time synchronization disabled by default. This means the reliance on proper time on vSphere hosts increases and confusion among Active Directory might increase, too.

In vSphere 7.0, VMware therefore introduced a new feature to help administrators make the right choices when vMotion’ing virtualized Domain Controllers, and other VMs.

 

Recommendations when vMotion’ing virtualized Domain Controllers

Using vMotion with virtualized Domain Controllers is fully supported by VMware. All the normal recommendations apply to virtualized Domain Controllers when comparing them to other virtual machines. However, a couple more recommendations apply:

  • Time differences between the vSphere hosts should be as little as possible.
  • Time differences between the vSphere hosts should be less than 5 minutes to avoid Kerberos errors.

These recommendations apply regardless if the option to Synchronize guest time with host is enabled or not in VMware Tools. The option only governs periodic time synchronization and not when you perform specific actions, like a vMotion. I explained this here.

 

Impact of vMotion’ing a virtualized Domain Controller to a vSphere host with incorrect time

As vSphere has no knowledge of the functionality of a virtual machine, it may not know the impact of the time difference on every specific virtual machine, but when you vMotion a virtualized Domain Controller between vSphere hosts with time differences exceeding five minutes:

  • Domain Controllers may provide member servers and domain-joined devices wrong time,, resulting in Kerberos authentication failures when these devices communicate to other Domain Controllers that have the correct time.
  • In environments with high volumes of changes to objects in Active Directory, replicating changes might fail from the Domain Controller with incorrect time as these changes are indicated as losing last writes, due to incorrect time stamps (when incorrect time is later than the correct time) or changes from other Domain Controllers failing (when the incorrect time is earlier than the correct time).

 

What’s New in vSphere 7.0

In vSphere 7.0, VMware introduced a notification in the vMotion interface notifies for time differences between vSphere hosts, when these time differences exceed 5 minutes, in the Compatibility field:

vMotionCompatibility

Now, when you vMotion a virtualized Domain Controller from a vSphere host with correct time to a vSphere host with incorrect time, the interface will notify you.

 

Recommendation

I recommend administrators to keep an eye out in the improved vMotion interface for detected time differences between vSphere hosts.

If correct time cannot be restored simply on the vSphere hosts with incorrect time and the time difference exceeds 5 minutes, refrain from vMotion’ing a virtualized Domain Controller to the vSphere host with incorrect time to avoid the above issues.

Further reading

Managing Active Directory Time Synchronization on VMware vSphere
Keeping virtual Domain Controllers apart on trusted VMware vSphere hosts

0