Protecting virtual Domain Controllers on vSphere with VM Encryption

This entry is part 8 of 8 in the series Virtualizing Domain Controllers on vSphere

Virtualizing Domain Controllers

In the previous post in this series, we looked at Virtualization-based Security and how it may benefit virtualized Domain Controllers. However, VMware vSphere 6.5 and newer versions of vSphere, offer one more feature to virtualized Domain Controllers that you might want to look into from both an Active Directory as a Virtualization Platform management point of view: VM Encryption.

 

About VM Encryption

VM Encryption is a security mechanism that allows certain virtual machines to run on trusted hosts only. Trusted hosts are defined through encryption keys obtained from a KMIP 1.1-compliant Key Management Server (KMS) through manually enrolled vCenter Servers.

Two types of keys are used for encryption.

  1. A vCenter Server requests keys from the KMS. These keys are used as the key encryption key (KEK) and are AES-256 keys. vCenter Server stores only the ID of each KEK, but not the key itself.
  2. ESXi uses the KEK to encrypt the internal keys. These keys are used as data encryption keys (DEKs) and are XTS-AES-256 keys. ESXi stores the encrypted internal keys on disk. ESXi does not store the KEK on disk.

If a host reboots, vCenter Server requests the KEK with the corresponding ID from the KMS and makes it available to ESXi. ESXi can then decrypt the internal keys as needed.

VM Encryption encrypts the VM configuration files. The virtual machine gains access to the configuration files when it boots through the KEK, if it’s running on a trusted ESXi host. The ESXi host gains access to the KEK through the DEK that it requests from the vCenter Server. It is only able to do this, if vCenter Server grants it access.

If a virtual machine cannot read its configuration files, it won’t be able to power on.

You cannot associate an encrypted virtual disk with a virtual machine that is not encrypted.

 

Benefits of using VM Encryption

The benefits of using VM Encryption for virtual Domain Controllers are threefold:

  • The virtualized Domain Controllers that are protected with VM Encryption are only able to run on trusted hosts.
  • The virtual disks of the virtualized Domain Controllers that are protected with VM Encryption cannot be reused as disks for another virtual machine.
  • Only administrators that have the highest permissions in vSphere are able to manage and access the virtualized Domain Controllers that are protected with VM Encryption.

Basically, VM Encryption delivers on the promise of virtualization, without the need to worry about VMDKs getting stolen.

The Key Management Server (KMS) itself can be an on-premises virtual machine, but it can also be a hosted highly-available service off-premises

VM encryption and DC Cloning

Virtualized Domain Controllers that are protected with VM Encryption can be cloned towards Domain Controller cloning. The clone inherits the parent encryption state including keys. You can encrypt the full clone, re-encrypt the full clone to use new keys, or decrypt the full clone. However, for Domain Controller clones, it’s fastest to perform a shallow re-encrypt while the virtual machine is powered on.

 

Drawbacks and non-benefits of using VM Encryption

VM Encryption does not necessarily entail encryption of the virtual disk. VM Encryption does not automatically enable BitLocker Drive Encryption, either.

Backend storage features such as deduplication and compression might not be effective for encrypted virtual machines.

Not all backup solutions that use VMware vSphere Storage API – Data Protection (VADP) for virtual disk backup are supported, because VADP SAN backup solutions are not supported with encrypted virtual machines. Backup solutions that take backups from within the virtual machine, like Veeam’s Agent for Windows, will be able to make unencrypted backups. These backups of encrypted Domain Controllers should be stored with the same level of information security measures as the Domain Controllers themselves.

 

Getting Ready

To use the VM Encryption functionality, you’ll need to meet the following requirements:

  • At least one ESXi host running VMware vSphere 6.5, or up
  • vCenter Server version 6.5, or up, managing the ESXi host(s) above
  • A KMIP 1.1-compliant Key Management Server (KMS) like Hytrust’s KeyControl

 

Configuring VM Encryption

Configuring VM Encryption for virtualized Domain Controllers consists of the following steps:

  • Enabling Hytrust KeyControl;s KMIP Service
  • Creating a Certificate Signing Request from vSphere
  • Creating a user certificate for VM Encryption
  • Establishing the trust between the KMS and vCenter

 

Enabling Hytrust KeyControl’s KMIP Service

First, we need to make sure Hytrust KeyControl acts as the Key Management Interoperability Protocol (KMIP) 1.1-compliant Key Management Server that we need. Perform the following steps:

  • Sign in to the Hytrust KeyControl web console with an account that has Security Admin privileges (the secroot account has these permissions, by default).
  • Click on KMIP in the top navigation bar.
  • Click the State drop-down box and change it to ENABLED.
  • Click the Protocol drop-down box and change it to Version 1.1.

Enabling KMIP 1.1 on Hytrust KeyControl (click for original screenshot)

  • Save the settings by clicking the Apply button at the bottom of the screen.
    A modal screen appears asking to Overwrite all existing KMIP Server settings?
  • Click the Proceed button in the modal screen.

You will notice a new alert confirming the KMIP server is now started.

 

Creating a Certificate Signing Request from vSphere

To build a certificate trust relationship, we’ll start with creating a certificate signing request (CSR) from vSphere. That way, when we create the certificate at the Key Management Server, we can use the information in the CSR to populate the values. Perform these steps:

Note:
For this walkthrough, vCenter 6.7 was used.

  • Start the vSphere Web Client and sign in with an account that has administrator permissions.
  • In the left navigation pane, select the vCenter Server (Appliance)
  • In the main pane, from the tabs, click the Configure tab.
  • In the main pane, in the navigation menu, select the Key Management Servers node.
  • Click ADD.
    The Add Key Management Server modal screen appears.
  • Specify to create a new cluster or to add the KMS host to an existing cluster.
  • Specify the name, address and port of the KMS Server.
  • Click the OK button at the bottom of the modal screen to add the server and close the modal screen.
    The Make vCenter Trust KMS modal screen appears.
  • Click the Trust button to trust the certificate of the Key Management Server and close the modal screen.
    The KMS host is now added to the list of Key Management Servers in vCenter. You can see it in the main pane, but in the Connection Status column, it will issue a warning Not connected (trust not established).
  • In the main pane, select the Key Management Server from the list.
  • Click ESTABLISH TRUST and then select Make KMS
    Trust vCenter
    from the context menu.
  • The Make KMS trust vCenter modal screen appears.

VMEncryption2

  • On the Choose a method screen, select the New Certificate Signing Request (CSR) option to submit a vCenter-generated CSR to the KMS then upload the new KMS-signed certificate to vCenter.
  • Click the Next button.
  • On the Submit CSR to KMS screen, click the DOWNLOAD button at the bottom of the certificate request to download it as a *.pem file.
  • Click the DONE button.

 

Creating a user certificate for VM Encryption

For the connection between the vCenter Server and the Hytrust KeyControl implementation, we’ll create a new user certificate in the following steps, while still sign in to the Hytrust KeyControl web console:

  • In the Hytrust KeyControl web console, while still in the KMIP section of the console, switch to the Client Certificates tab.
  • From the Actions menu, choose the Create Certificate option.
    The Create a New Client Certificate modal screen appears.
  • Provide a meaningful certificate name, for instance the name of the vCenter Server.
  • Specify the previously downloaded certificate signing request (CSR) as the CSR.
  • Provide a password for the client certificate twice.
  • Click the Create button at the bottom of the modal screen to create the client certificate and close the modal screen.
  • Select the newly created certificate in the main pane.
  • Click Actions again. This time, select Download Certificate from the menu.

You now download a client certificate in *.pem format in a zip file. Be sure to extract the certificates from the *.zip file before you continue.

 

Establishing the trust between the KMS and vCenter

Now, we can create the connection between the KMS and vCenter. Perform these steps to do so:

  • Switch back to the vSphere Web Client.
    It should still be at the Key Management Servers part of the Configuration of the vCenter Server. If not, navigate back to it.
  • Select the KMS Host from the list of Key Management Servers.
  • In the main pane, select the Key Management Server from the list.
  • Click ESTABLISH TRUST and then select Make vCenter Trust KMS from the context menu.
  • Click the Trust button at the bottom of the modal screen.
  • Click ESTABLISH TRUST again. This time select Upload Signed CSR Certificate from the context menu.
    The Upload Signed CSR Certificate modal screen opens.
  • Click the UPLOAD A FILE button.
  • Select the *.pem file you downloaded from the Hytrust KeyControl implementation and click Open.
  • Click the UPLOAD button at the bottom of the Upload Signed CSR Certificate modal screen to use this certificate and close the modal screen.

The Key Management Server should now show the Connected status in the Connection Status column.

Repeat the above steps for every Key Management Server of a possible highly-available KMS cluster have been configured and trusted.

 

Encrypting a new virtual machine

The last step towards encrypted Domain Controllers is to create Domain Controllers as encrypted virtual machines. In the vSphere Web Client, take care of the following setting:

VMEncryption3

On the Select storage page of the New Virtual Machine wizard, select the Encrypt this virtual machine option.

Specify any other settings, for instance the right settings for Virtualization-based Security for the virtual machine, too.

 

Concluding

VM Encryption provides the level of assurance that Active Directory admins need from the virtualization platform that their virtualized Domain Controllers cannot be run outside of the trusted vCenter scope.

Further reading

Virtual Machine Encryption
Virtual Machine Encryption Best Practices
How to install HyTrust KeyControl 5.1 in vSphere 6.7
New steps to use HyTrust KMIP with vSAN Encryption

0  

Group Policy Elevation of Privilege Vulnerability (CVE-2020-1317, Important)

Windows Server

This Tuesday, Microsoft released updates for all supported versions of Windows and Windows Server to address an elevation of privilege vulnerability in Group Policy, marked as important. Its official common vulnerabilities and exposures (CVE) id is CVE-2020-1317.

 

About the vulnerability

An elevation of privilege vulnerability exists when Group Policy improperly checks access. An attacker who successfully exploited this vulnerability could run processes in an elevated context.

To exploit the vulnerability, an attacker would first have to log on to the system, and then run a specially crafted application to take control over the affected system.

The security update addresses the vulnerability by correcting how Group Policy checks access.

The vulnerability was discovered and reported responsibly to Microsoft by Cyberark on June 17th, 2019. They have provided the following infographic on this vulnerability:

CyberArkCVE20201317InfoGraphic

 

AFFECTED OPERATING SYSTEMS

All Windows versions and Windows Server versions are affected. Both Full installations and Server Core installations of Windows Server are affected.

MITIGATIONS

Microsoft has not identified any mitigating factors for this vulnerability.

WORKAROUNDS

Microsoft has not identified any workarounds for this vulnerability.

 

About the fix

Microsoft has fixed this vulnerability with updates that were part of the June 2020 Patch Tuesday on Tuesday June 9th, 2020.

  1. Windows 10 RTM (version 1511)
  2. Windows 10 version 1607
  3. Windows 10 version 1709
  4. Windows 10 version 1803
  5. Windows 10 version 1809
  6. Windows 10 version 1903
  7. Windows 10 version 1909
  8. Windows 10 version 2004
  9. Windows 7 with Service Pack 1
  10. Windows 8.1
  11. Windows Server 2008 R2 with Service Pack 2
  12. Windows Server 2008 R2 with Service Pack 1
  13. Windows Server 2012
  14. Windows Server 2012 R2
  15. Windows Server 2016
  16. Windows Server 2019
  17. Windows Server, version 1803
  18. Windows Server, version 1903
  19. Windows Server, version 1909
  20. Windows Server, version 2004

 

Call to Action

Noticeably, Microsoft has issued updates for Operating Systems (OSs) that are out of support per January 14th, 2020. This indicates that this update is deemed important enough to roll out in all Active Directory-oriented networking environments.

I urge you to install the necessary security updates on Windows and Windows Server installations in a test environment as soon as possible, assess the risk and possible impact on your production environment. Then, roll out this update to Windows and Windows Server installations in the production environment.

Further reading

Group Policies Going Rogue
Microsoft June 2020 Patch Tuesday fixes 129 vulnerabilities
Microsoft June 2020 Patch Tuesday: largest ever with 129 fixes
CVE-2020-1317 | Group Policy Elevation of Privilege Vulnerability

0  

KnowledgeBase: You can’t manage AD FS with non-domain-joined Azure AD Connect installations

Azure AD Connect

Azure AD Connect is Microsoft's free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments and LDAP v3-compatible directories to Azure Active Directory.

One of the neat tricks Azure AD Connect has up its sleeve is the ability to implement Active Directory Federation Services (AD FS) as part of the configuration wizard.

 

AD FS Management through Azure AD Connect

An admin can implement the first AD FS server, implement the first Web Application Proxy server and federate a custom domain name from Azure AD during the initial configuration of Azure AD Connect. Alternatively, an existing AD FS farm can be pointed to.

On subsequent runs, an admin can:

  • View the configuration of the AD FS farm, including the Federation service name, service account, primary server (when using WID), the AD FS farm behavioral level (FBL) and information on the SSL certificate and token signing certificate
  • Federate additional Azure AD custom domain names
  • Manage the Azure AD trust
  • Update the SSL certificate
  • Update the token-signing and token-decrypting certificates
  • Add AD FS servers
  • Add Web Application Proxy servers
  • Specify the AD FS primary server (when using WID)
  • Verify federated login

The AD FS management possibilities in Azure AD Connect makes the life of an admin easier in organizations with AD FS.

 

The issue

There are some requirements to managing AD FS with Azure AD Connect. Many of these requirements are documented as the Prerequisites for Azure AD Connect. It mentions specifically that the Azure AD Connect must be domain-joined, but this is not the case for most deployment scenarios.

However, it is when you want to manage AD FS through Azure AD Connect.

'You must be logged in as a domain user to configure federation with AD FS' error when you select 'Federation with AD FS' in the Azure AD Connect configuration wizard, when the Windows Server is not domain-joined (click for original screenshot)

When you select the Federation with AD FS as sign-in option on the User sign-in page of the Azure AD Connect configuration wizard, the Next button remains greyed out and the following message appears:

You must be logged in as a domain user to configure federation with AD FS.

Note:
You may also experience this message when you’re signed in to a domain-joined Windows Server running Azure AD Connect with a local user account.

 

Why would you not domain-join Azure AD Connect?

One of the questions you might ask yourself is why you wouldn’t domain-join the Windows Server running Azure AD Connect. There can be several reasons:

  • The way Azure AD Connect sets up outbound connections to Azure AD can be considered as a back-end system setting up connections to the Internet. From a regulatory perspective, this might permit the Windows Server running Azure AD Connect in a perimeter network only. From that network, domain-join may not be available or permitted.
  • When synchronizing an LDAPv3-compatible directory service to Azure AD, instead of Active Directory, you may not want or be permitted to join the Windows Server running Azure AD Connect to the same Active Directory domain as the AD FS farm.

 

The alternative way

Of course, you can domain-join the Windows Server running Azure AD Connect, but you can also continue with Azure AD Connect without the Windows Server being domain-joined.

If the Windows Server running Azure AD Connect is not domain-joined, you’ll have to select the Do not configure sign-in option on the User sign-in page of the Azure AD Connect configuration wizard.

Run through the remaining part of the Azure AD Connect configuration wizard.

Then, create the ‘Microsoft Office 365 Identity Platform’ Relying Party Trust manually and use the claim rules from ADFSHelp for your ‘Office 365 Identity Platform’ Relying Party Trust to provide the same functionality as you would get on a domain-joined Azure AD Connect installation.

You will not be able to enjoy the management of AD FS through Azure AD Connect, this way, but you will have AD FS as sign-in method.

Note:
Keep in mind that you will experience a heavier management burden to implement renewed certificates, add additional Azure AD custom domain names and verify federated sign-ins.

0  

An overview of Azure AD Connect’s PowerShell Modules and Cmdlets

Azure AD Connect

Azure AD Connect is Microsoft’s free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments and LDAP v3-compatible directories to Azure Active Directory.

Azure AD Connect needs to be installed on a Windows Server with Desktop Experience, but this does not mean there aren’t some tools available to automate.

This blogpost features the built-in and extra PowerShell modules and cmdlets available with Azure AD Connect.

              

Azure AD Connect’s Built-in PowerShell modules

The following Windows PowerShell modules and cmdlets are available as part of Azure AD Connect:

          

ADSync

The core PowerShell functionality for Azure AD Connect can be found in the ADSync Windows PowerShell module, It offers the following Windows PowerShell cmdlets:

  • Add-ADSyncAADServiceAccount

  • Add-ADSyncAttributeFlowMapping
  • Add-ADSyncConnector
  • Add-ADSyncConnectorAnchorConstructionSettings
  • Add-ADSyncConnectorAttributeInclusion
  • Add-ADSyncConnectorHierarchyProvisioningMapping
  • Add-ADSyncConnectorObjectInclusion
  • Add-ADSyncGlobalSettingsParameter
  • Add-ADSyncJoinConditionGroup
  • Add-ADSyncRule
  • Add-ADSyncRunProfile
  • Add-ADSyncRunStep
  • Add-ADSyncScopeConditionGroup
  • Add-AgentToResourceGroup
  • Disable-ADSyncConnectorPartition
  • Disable-ADSyncConnectorPartitionHierarchy
  • Disable-ADSyncExportDeletionThreshold
  • Enable-ADSyncConnectorPartition
  • Enable-ADSyncConnectorPartitionHierarchy
  • Enable-ADSyncExportDeletionThreshold
  • Get-ADSyncAADCompanyFeature
  • Get-ADSyncAADPasswordResetConfiguration
  • Get-ADSyncAADPasswordSyncConfiguration
  • Get-ADSyncADConnectorSchemaDsml
  • Get-ADSyncAutoUpgrade 
  • Get-ADSyncConnector
  • Get-ADSyncConnectorHierarchyProvisioningDNComponent
  • Get-ADSyncConnectorHierarchyProvisioningMapping
  • Get-ADSyncConnectorHierarchyProvisioningObjectClass
  • Get-ADSyncConnectorParameter
  • Get-ADSyncConnectorPartition
  • Get-ADSyncConnectorPartitionHierarchy
  • Get-ADSyncConnectorRunStatus
  • Get-ADSyncConnectorStatistics
  • Get-ADSyncConnectorTypes
  • Get-ADSyncCSObject
  • Get-ADSyncCSObjectLog
  • Get-ADSyncDatabaseConfiguration
  • Get-ADSyncExportDeletionThreshold 
  • Get-ADSyncGlobalSettings
  • Get-ADSyncGlobalSettingsParameter 
  • Get-ADSyncMVObject
  • Get-ADSyncPartitionPasswordSyncState
  • Get-ADSyncRule
  • Get-ADSyncRunProfile
  • Get-ADSyncRunProfileResult
  • Get-ADSyncRunStepResult
  • Get-ADSyncScheduler
  • Get-ADSyncSchedulerConnectorOverride
  • Get-ADSyncSchema
  • Get-ADSyncServerConfiguration
  • Invoke-ADSyncCSObjectPasswordHashSync
  • Invoke-ADSyncGarbageCollection
  • Invoke-ADSyncRunProfile
  • New-ADSyncConnector
  • New-ADSyncJoinCondition
  • New-ADSyncRule
  • New-ADSyncRunProfile
  • New-ADSyncScopeCondition
  • Register-Agent
  • Remove-ADSyncAADPasswordResetConfiguration
  • Remove-ADSyncAADPasswordSyncConfiguration
  • Remove-ADSyncAADServiceAccount
  • Remove-ADSyncAttributeFlowMapping
  • Remove-ADSyncConnector
  • Remove-ADSyncConnectorAnchorConstructionSettings
  • Remove-ADSyncConnectorAttributeInclusion
  • Remove-ADSyncConnectorHierarchyProvisioningMapping
  • Remove-ADSyncConnectorObjectInclusion
  • Remove-ADSyncGlobalSettingsParameter
  • Remove-ADSyncJoinConditionGroup
  • Remove-ADSyncRule
  • Remove-ADSyncRunProfile
  • Remove-ADSyncRunStep
  • Remove-ADSyncScopeConditionGroup
  • Search-ADSyncDirectoryObjects
  • Set-ADSyncAADCompanyFeature
  • Set-ADSyncAADPasswordResetConfiguration
  • Set-ADSyncAADPasswordSyncConfiguration
  • Set-ADSyncAADPasswordSyncState
  • Set-ADSyncAutoUpgrade
  • Set-ADSyncConnectorParameter
  • Set-ADSyncDirSyncConfiguration
  • Set-ADSyncGlobalSettings
  • Set-ADSyncScheduler
  • Set-ADSyncSchedulerConnectorOverride
  • Set-ADSyncSchema
  • Set-ADSyncServerConfiguration
  • Set-MIISADMAConfiguration
  • Start-ADSyncAADPasswordResetEndpoint
  • Start-ADSyncPurgeRunHistory
  • Start-ADSyncSyncCycle
  • Stop-ADSyncAADPasswordResetEndpoint 
  • Stop-ADSyncRunProfile
  • Stop-ADSyncSyncCycle
  • Sync-ADSyncCSObject
  • Test-AdSyncAzureServiceConnectivity
  • Test-ADSyncGetDirectoryReplicationChanges
  • Test-AdSyncUserHasPermissions
  • Update-ADSyncConnectorPartitions
  • Update-ADSyncConnectorSchema
  • Update-ADSyncDirectoryObject
  • Update-ADSyncDRSCertificates

                   

AzureADConnectHealthSync

Azure AD Connect Health for Sync is installed by default on each Azure AD Connect installation. To manage Azure AD Connect Health, the AzureADConnectHealthSync Windows PowerShell module offers the following Windows PowerShell cmdlets:

  • Enable-AzureADConnectHealth
  • Get-AzureADConnectHealthProxySettings
  • Register-AzureADConnectHealthSyncAgent
  • Set-AzureADConnectHealthProxySettings
  • Test-AzureADConnectHealthConnectivity

          

ADSyncDiagnostics

On the system where Azure AD Connect in installed, the ADSyncDiagnostics Windows PowerShell module is also installed by default, offering the Invoke-ADSyncDiagnostics diagnostics tool to troubleshoot object synchronization, troubleshoot password hash synchronization and collect general diagnostics.

               

Azure AD Connect’s tools

Apart from all the functionality that Azure AD Connect brings, Azure AD Connect offers several useful tools shaped as PowerShell modules:

               

ADSyncPrep

The ADSyncPrep Windows PowerShell module includes the following Windows PowerShell cmdlets:

  • Initialize-ADSyncDomainJoinedComputerSync
  • Initialize-ADSyncDeviceWriteBack
  • Initialize-ADSyncNGCKeysWriteBack

The ADSyncPrep Windows PowerShell module can only be used if you also have the Active Directory Module for Windows PowerShell installed on the system.

        

ADSyncConfig

The ADSyncConfig Windows
PowerShell module includes the following Windows PowerShell cmdlets:

  • Set-ADSyncBasicReadPermissions
  • Set-ADSyncRestrictedPermissions
  • Set-ADSyncPasswordHashSyncPermissions
  • Set-ADSyncPasswordWritebackPermissions
  • Set-ADSyncUnifiedGroupWritebackPermissions
  • Set-ADSyncMsDsConsistencyGuidPermissions
  • Set-ADSyncExchangeMailPublicFolderPermissions
  • Set-ADSyncExchangeHybridPermissions
  • Get-ADSyncObjectsWithInheritanceDisabled
  • Show-ADSyncADObjectPermissions
  • Get-ADSyncADConnectorAccount

                         

ADConnectivityTool

The ADConnectivityTool Windows PowerShell module includes the following Windows PowerShell cmdlets:

  • Get-DomainFQDNData
  • Confirm-ValidEnterpriseAdminCredentials
  • Get-ForestFQDN
  • Confirm-ValidDomains
  • Confirm-FunctionalLevel
  • Confirm-NetworkConnectivity
  • Confirm-DnsConnectivity
  • Confirm-TargetsAreReachable
  • Confirm-ForestExists
  • Start-ConnectivityValidation
  • Start-NetworkConnectivityDiagnosisTools

                        

ADSyncTools

The ADSyncTools Windows
PowerShell module includes the following Windows PowerShell cmdlets:

  • Confirm-ADSyncToolsADModuleLoaded
  • Get-ADSyncToolsADuser
  • Get-ADSyncToolsConsistencyGuid
  • Set-ADSyncToolsConsistencyGuid
  • Clear-ADSyncToolsConsistencyGuid
  • Get-ADSyncToolsObjectGuid
  • Import-ADSyncToolsImmutableIdMigration
  • Export-ADSyncToolsConsistencyGuidMigration
  • Update-ADSyncToolsConsistencyGuidMigration
  • Get-ADSyncToolsRunHistory
  • Get-ADSyncToolsSourceAnchorChanged
  • Remove-ADSyncToolsExpiredCertificates
  • Restore-ADSyncToolsExpiredCertificates
  • Trace-ADSyncToolsADImport
  • Trace-ADSyncToolsLdapQuery
  • Repair-ADSyncToolsAutoUpgradeState
  • Connect-AdSyncDatabase
  • Invoke-AdSyncDatabaseQuery
  • Resolve-ADSyncHostAddress
  • Test-ADSyncNetworkPort
  • Get-ADSyncSQLBrowserInstances 

                                

AzureADKerberos

The AzureADKerberos Windows PowerShell module includes the following Windows PowerShell cmdlets:

  • Get-AzureADKerberosServer 
  • Remove-AzureADKerberosServer
  • Set-AzureADKerberosServer

Concluding

Azure AD Connect offers a vast array of Windows PowerShell modules and cmdlets to configure and troubleshoot almost every aspect of it.

With 155 available Windows PowerShell cmdlets, there’s always something you can automate!

0  

Veeam Backup for Office 365 v4c build 4.0.1.519 offers support for disabled legacy protocols

Veeam Backup for Office 365

Six weeks ago, we looked at how Veeam Backup for Office 365 works in tenants with multi-factor authentication required for admin roles. With Security Defaults being the norm in newly created Azure AD tenants and their respective Office 365 tenants, it’s a good time to look at how Veeam Backup for Office 365 can work without using legacy authentication protocols.

This is a new feature in Veeam Backup for Office 365 version 4c (build 4.0.1.519).

 

API-only Mode

Veeam Backup for Office 365 version 4c (build 4.0.1.519) is the first version of Veeam Backup for Office 365 that is able to work without a user account. Instead of user credentials it only leverages the application registration in Azure Active Directory to communicate with Microsoft’s Application Programming Interfaces (APIs).

When you create a new organization in Veeam Backup for Office 365, on the Office 365 connection settings page, a new option is introduced labeled Allow for using legacy authentication protocols. By default, the option is not selected:

Veeam Backup for Office 365 - Add Organization - Allow for using legacy authentication protocols

 

This means that with these default settings Veeam Backup for Office 365 can be used with tenants that have Security Defaults enabled.

 

Benefits of using API-only mode

The big benefit of using API-only mode is that admins can successfully disable legacy authentication protocols and/or enable the Security Defaults feature in their organization’s Azure AD tenant if Veeam Backup for Office 365 was the last system, service or application that uses it.

 

Drawbacks of using API-only Mode

Veeam has long used an user account to offer full coverage of the backup and restore needs that Office 365 admins have. Meanwhile, Microsoft has been busy improving their APIs to offer more functionality, but it doesn’t offer full coverage, today.

In API-only mode, the following tasks are not supported, when compared to using Veeam Backup for Office 365 with both the application registration and user credentials:

  • Discovery Search and Public Folder mailboxes are not supported.
  • Dynamic Distribution groups are not supported.
  • The type property for shared and resource/equipment mailboxes cannot be resolved. Such mailboxes will be available for backup with a general ‘User’ type.
  • SharePoint Web Parts can only backed up if their ‘exportmode’ property is enabled. Non exportable Web Parts are not supported.
  • OneNote restore is not supported.
  • SharePoint Web Part customized template cannot be preserved upon a restore. All Web Parts will be restored with the default template.
  • The ‘Allow multiple responses’ setting in survey lists within team modern sites is not preserved upon a restore.
  • The ‘Measure-VBOOrganizationFullBackupSize’ cmdlet is not supported.

Additionally, application registration are harder to audit than user accounts, which might lead to a different approach to auditing of the Azure AD tenant.

 

Concluding

Leaving both legacy authentication (non Multi-factor Authentication-capable authentication) and legacy protocols behind, Veeam Backup for Office 365 is a shining example of an application that adheres to the quickly changing realities of cloud computing.

Further reading

Release notes for Veeam Backup for Microsoft Office 365 4c
Download Veeam Backup for Office 365 4c

0  

On-premises Microsoft Identity-related updates and fixes for May 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 May 2020:

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4556813 May 12, 2020

The May 12, 2020 update for Windows Server 2016 (KB4556813) updating the OS build number to 14393.3686 includes both security and quality improvements, but none of these updates are Identity-related.

When running virtualized Domain Controllers on top of Hyper-V, then you might be concerned with CVE-2020-0909. However, as per Microsoft recommended practices, Hyper-V hosts should not be placed on network segments that are accessible to non-administrator endpoints.

The three Print Spooler vulnerabilities are also causes for alarm, but I hope that by now everyone has hardened their Domain Controllers by not allowing printer redirection through remote desktop and stopping the spooler service…

ADV200009 May 19, 2020

Microsoft is aware of a vulnerability involving packet amplification that affects Windows DNS servers. An attacker who successfully exploited this vulnerability could cause the DNS Server service to become nonresponsive.

Admins of edge-facing authoritative DNS Servers should enable Response Rate Limit (RRL), using the Set-DnsServerResponseRateLimiting PowerShell Cmdlet.

There is currently no update available to address the vulnerability.

                          

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4551853 May 12, 2020

The May 12, 2020 update for Windows Server 2019 (KB4551853) updating the OS build number to 17762.1217 includes both security and quality improvements.

This update addresses a cross-site scripting vulnerability in Active Directory Federation Services (AD FS) (CVE-2020-1055). This cross-site-scripting (XSS) vulnerability exists when AD FS does not properly sanitize user inputs. An unauthenticated attacker could exploit the vulnerability by sending a specially crafted request to an affected AD FS server. When successful, the attacker could then perform cross-site scripting attacks on affected systems and run scripts in the security context of the current user. This security update addresses the vulnerability by ensuring that AD FS properly sanitizes user inputs.

When running virtualized Domain Controllers on top of Hyper-V, then you might be concerned with CVE-2020-0909. However, as per Microsoft recommended practices, Hyper-V hosts should not be placed on network segments that are accessible to non-administrator endpoints.

The three Print Spooler vulnerabilities are also causes for alarm, but I hope that by now everyone has hardened their Domain Controllers by not allowing printer redirection through remote desktop and stopping the spooler service…

ADV200009 May 19, 2020

Microsoft is aware of a vulnerability involving packet amplification that affects Windows DNS servers. An attacker who successfully exploited this vulnerability could cause the DNS Server service to become nonresponsive.

Admins of edge-facing authoritative DNS Servers should enable Response Rate Limit (RRL), using the Set-DnsServerResponseRateLimiting PowerShell Cmdlet.

There is currently no update available to address the vulnerability.

0  

What’s New in Azure Active Directory in May 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 May 2020, on top of the announcements made at Build 2020:

                   

What’s Planned

New email address for MFA admin notifications

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

Microsoft is planning changes to the multi-factor authentication (MFA) email notifications for both cloud MFA and MFA server. E-mail notifications will be sent from  azure-noreply@microsoft.com.

Additionally, Microsoft is updating the content of fraud alert emails to better indicate the required steps to unblock uses.

                  

New self-service sign up for users in federated domains who can't access Microsoft Teams because they aren't synced to Azure AD

Service category: Authentications (Logins)
Product capability: User Authentication

Currently, users who are in domains federated in Azure AD, but who are not synced into the tenant, can't access Microsoft Teams.

Starting at the end of June, this new capability will enable them to do so by extending the existing email verified sign up feature. This will allow users who can sign in to a federated IdP, but who don't yet have a user object in Azure ID, to have a user object created automatically and be authenticated for Microsoft Teams. Their user object will be marked as "self-service sign up."

                

The OIDC discovery document for the Azure Government cloud is being updated to reference the correct Graph endpoints

Service category: Sovereign Clouds
Product capability: User Authentication

Starting in June, the OIDC discovery document Microsoft identity platform and OpenID Connect protocol on the Azure Government cloud endpoint, will begin to return the correct National cloud graph endpoint (https://graph.microsoft.us or https://dod-graph.microsoft.us), based on the tenant provided. It currently provides the incorrect Graph endpoint msgraph_host field.

This bug fix will be rolled out gradually over approximately 2 months.

        

Azure Government users will no longer be able to sign in on login.microsoftonline.com

Service category: Sovereign Clouds
Product capability: User Authentication

On 1 June 2018, the official Azure Active Directory Authority for Azure Government changed from https://login-us.microsoftonline.com to https://login.microsoftonline.us. If you own an application within an Azure Government tenant, you must update your application to sign users in on the .us endpoint.

Starting May 5th, Azure AD will begin enforcing the endpoint change, blocking Azure Government users from signing into apps hosted in Azure Government tenants using the public endpoint. Impacted apps will begin seeing the following error:

AADSTS900439 USGClientNotSupportedOnPublicEndpoint

There will be a gradual rollout of this change with enforcement expected to be complete across all apps June 2020.

               

What’s New

Report-only mode for Conditional Access generally available

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

Report-only mode lets admins evaluate the result of a Conditional Access policy without enforcing access controls. Admins can test report-only policies across their organization and understand the impact of policies before enabling them, making deployment safer and easier.

Over the past few months, Microsoft has seen strong adoption of report-only mode—over 26M users are already in scope of a report-only policy. With the announcement today, new Azure AD Conditional Access policies will be created in report-only mode, by default. This means admins can monitor the impact of policies from the moment they’re created.

        

Conditional Access Insights and Reporting workbook  generally available

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

The insights and reporting workbook gives admins a summary view of Azure AD Conditional Access in their organization’s tenant. With the capability to select an individual policy, admins can better understand what each policy does and monitor any changes in real-time. The workbook streams data stored in Azure Monitor. To make the dashboard more discoverable, Microsoft has moved it to the new insights and reporting tab within the Azure AD Conditional Access menu.

                    

Policy details blade for Conditional Access public preview

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

The new policy details blade displays the assignments, conditions, and controls satisfied during conditional access policy evaluation. Admins can access the blade by selecting a row in the Conditional Access or Report-only tabs of the Sign-in details.

                   

SAML Token Encryption Generally Available

Service category: Enterprise Apps
Product capability: Single Sign-on (SSO)

SAML token encryption allows applications to be configured to receive encrypted SAML assertions. The feature is now generally available in all clouds.

                      

Group name claims in application tokens Generally Available

Service category: Enterprise Apps
Product capability: Single Sign-on (SSO)

The group claims issued in a token can now be limited to just those groups assigned to the application. This is especially important when users are members of large numbers of groups and there was a risk of exceeding token size limits. With this new capability in place, the ability to add group names to tokens is generally available.

             

Self-service sign up for guest users public preview

Service category: Business to Business (B2B)
Product capability: Azure AD B2B/B2C

With External Identities in Azure AD, you can allow people outside the organization to access your organization’s apps and resources while letting them sign in using whatever identity they prefer.

When sharing an application with external users, admins might not always know in advance who will need access to the application. With self-service sign-up, admins can enable guest users to sign up and gain a guest account for line of business (LOB) apps. The sign-up flow can be created and customized to support Azure AD and social identities. Your organization can also collect additional information about the user during sign-up.

                          

The Hybrid Identity Administrator role is now available with Cloud Provisioning

Service category: Azure AD Cloud Provisioning
Product capability: Identity Lifecycle Management

Azure AD admins can start using the new Hybrid Administrator role as the least privileged role for setting up Azure AD Connect Cloud Provisioning. With this new role, admins no longer have to use the Global Admin role to setup and configure Cloud Provisioning.

          

New Federated Apps available in Azure AD Application gallery

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

In May 2020, Microsoft has added the following 36 new applications in the Azure AD App gallery with Federation support:

       

New provisioning connectors in the Azure AD Application Gallery – May 2020

Service category: App Provisioning
Product capability: 3rd Party Integration

Admins can now automate creating, updating, and deleting user accounts for these five newly integrated apps:

               

Workday Writeback now supports setting work phone number attributes

Service category: App Provisioning
Product capability: Identity Lifecycle Management

Microsoft has enhanced the Workday Writeback provisioning app to now support writeback of work phone number and mobile number attributes. In addition to email and username, admins can now configure the Workday Writeback provisioning app to flow phone number values from Azure AD to Workday.

                   

Publisher Verification Public preview

Service category: Other
Product capability: Developer Experience

Publisher verification (preview) helps admins and end-users understand the authenticity of application developers integrating with the Microsoft identity platform.

        

New query capabilities for Directory Objects in Microsoft Graph Public Preview

Service category: Microsoft Graph
Product capability: Developer Experience

New capabilities are being introduced for Microsoft Graph Directory Objects APIs, enabling Count, Search, Filter, and Sort operations. This will give developers the ability to quickly query Microsoft’s Directory Objects without workarounds such as in-memory filtering and sorting.

              

Configure SAML-based single sign-on using Microsoft Graph API Beta

Service category: Enterprise Apps
Product capability: Single Sign-on (SSO)

Support for creating and configuring an application from the Azure AD Gallery using Microsoft Graph APIs in Beta is now available. If an admin or developer needs to set up SAML-based single sign-on for multiple instances of an application, time can be saved by using the Microsoft Graph APIs to automate the configuration of SAML-based single sign-on.

                  

What’s Changed

Authorization Code Flow for Single-page apps

Service category: Authentication
Product capability: Developer Experience

Because of modern browser 3rd party cookie restrictions such as Safari ITP, single-page apps (SPAs) will have to use the authorization code flow rather than the implicit flow to maintain single sign-on (SSO). MSAL.js version 2.x will now support the authorization code flow.

                  

Improved Filtering for Devices Public Preview

Service category: Device Management
Product capability: Device Lifecycle Management

Previously, the only filters admins could use were Enabled and Activity date. In this public preview, admins can filter the list of devices on more properties, including OS type, Join type, Compliance, and more. These additions should simplify locating a particular device.

         

The new App registrations experience for Azure AD B2C generally available

Service category: Consumer Identity Management (B2C)
Product capability: Identity Lifecycle Management

The new App registrations experience for Azure AD B2C is now generally available.

Previously, admins had to manage their B2C consumer-facing applications separately from the rest of their apps using the legacy 'Applications' experience. That meant different app creation experiences across different places in Azure. The new experience shows all B2C app registrations and Azure AD app registrations in one place and provides a consistent way to manage them. Whether admins need to manage a customer-facing app or an app that has access to Microsoft Graph to programmatically manage Azure AD B2C resources, they only need to learn one way to do things.

                 

What’s Fixed

SAML Single Logout request now sends NameID in the correct format

Service category: Authentications (Logins)
Product capability: User Authentication

When a user clicks on sign-out (e.g., in the MyApps portal), Azure AD sends a SAML Single Logout message to each app that is active in the user session and has a Logout URL configured. These messages contain a NameID in a persistent format.

If the original SAML sign-in token used a different format for NameID (e.g. email/UPN), then the SAML app cannot correlate the NameID in the logout message to an existing session (as the NameIDs used in both messages are different), which caused the logout message to be discarded by the SAML app and the user to stay logged in. This fix makes the sign-out message consistent with the NameID configured for the application.

0  

Protecting virtual Domain Controllers on vSphere with Virtualization-based Security

This entry is part 7 of 8 in the series Virtualizing Domain Controllers on vSphere

Virtualizing Domain Controllers

VMware vSphere 6.7 offers the ability to enable virtualization-based security (VBS) for virtual machines. Let’s find out what kind of protection this setting provides, what’s needed to get it going and how to configure a virtual Domain Controller to use it.

 

About Virtualization-based Security

Virtualization-based Security (VBS) uses virtualization features to create and isolate a secure region of memory from the normal Operating System. Windows Server can use this "virtual secure mode" to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat protections.

 

Benefits of using Virtualization-based Security

Virtualization-based Security (VBS) uses the Windows hypervisor to create this virtual secure mode, and to enforce restrictions which protect vital system and Operating System resources, or to protect security assets such as authenticated user credentials.

With the increased protections offered by Virtualization-based Security, even if malware gains access to the Operating System’s kernel, the possible exploits can be greatly limited and contained because the hypervisor can prevent the malware from executing code or accessing platform secrets.

For Active Directory Domain Controllers, specifically, Virtualization-based Security offers:

Secure Boot

The Secure Boot feature in Windows Server 2016, and up, is designed to protect the virtual machine from malicious boot loaders. In traditional Basic Input/Output System (BIOS)-based systems, a rootkit may replace the Windows boot loader, remaining invisible and undetectable on the Domain Controller.

With Secure Boot, a virtual machine no longer boots with BIOS, but with Unified Extensible Firmware Interface (UEFI). UEFI checks the signature of the boot loader before launching, detecting any malware impersonating, replacing or tampering with the Windows boot loader.

Direct Memory Access (DMA) Protection

Direct Memory Access (DMA) attacks try to grab the memory of a running Operating System to gain access to BitLocker keys and other information from the memory. In vSphere, you can take advantage of an Input/Output Memory Management Unit (IOMMU) to connect a DMA-capable I/O bus to the main memory.

With IOMMU, memory of Windows Server 2016 installations, and  up, is protected from malicious devices that are attempting DMA attacks and faulty devices that are attempting errant memory transfers because a device cannot read or write to memory that has not been explicitly allocated (mapped or re-mapped) for it.

Hypervisor-enforced Code Integrity (HVCI)

Kernel-mode Code Integrity enforces kernel-mode memory protections by protecting the Code Integrity validation path with Virtualization-based Security. All drivers in the virtual machine must be compatible with virtualization-based protection of code integrity; otherwise, the virtual machine fails.

Code Integrity (CI) Policies

Historically, most malware has been unsigned. Simply by deploying code integrity policies, organizations can get immediately protection against unsigned malware. By using Code Integrity policies, an enterprise can also select exactly which binaries can run in both user mode and kernel mode. When completely enforced, it will only load specific applications or software with specific signatures.

Note:
Code Integrity policies are independent of Hypervisor-enforced Code Integrity (HVCI). However, when using CI policies without HVCI, the enforcement will not be as strong as when using CI Policies with HVCI.

Note:
Windows Server 2019 expands on the CI policies feature in Windows Server 2016 by offering built-in CI policies for robust yet quick deployment of Code Integrity.

 

Other features like Application Guard, Credential Guard and Windows Sandbox, operating in their separate memory spaces are features targeted towards Windows-based devices and are not applicable to Domain Controllers. Well… when you adhere to the rule of thumb not to browse the Internet and install all kinds of software on your Domain Controllers, that is.

Note:
Do not configure Credential Guard on Domain Controllers.

 

Getting Ready

For Virtualization-based Security (VBS) you’ll need to meet the following requirements:

  • At least one ESXi host running VMware vSphere 6.7, or up, managed by vSphere
  • At least one virtual machine running hardware version 14 (Compatible only with ESXi 6.7 and later), or up, configured with Virtualization Based Security. and installed with Windows Server 2016, or a later version of Windows Server in this virtualization state.

Note:
The Virtualization Base Security option enables CPU virtualization extensions, IOMMU, EFI firmware and Secure Boot.

 

Configuring Virtualization-based Security

Configuring Virtualization-based Security consists of three steps:

  1. Configure the right virtual machine settings on vSphere 6.7
  2. Configure the right security settings in the virtual Domain Controller
  3. Install the Hyper-V feature on the virtual Domain Controller

Configure the right virtual machine settings

First, we need to create a virtual Domain Controller that meets the requirements.

ESXi 6.7

When creating a new virtual machine for a Domain Controller, on the 2 Select a name and guest OS page of the New virtual machine wizard, make sure as a Compatibility level you pick ESXi 6.7 virtual machine (or up), resulting in hardware version 14. Pick Microsoft Windows Server 2016 or later (64-bit) as the Gues OS version. Then, make sure you select the option Enable Windows Virtualization Based Security:

Enable Virtualization Based Security on the Select a name and guest OS page when creating a virtual machine in ESXi 6.7 (click for original screenshot)

vSphere 6.7

In the vSphere Web Client, when creating a new virtual machine, take care of the following settings:

  • On the Select compatibility page of the New Virtual Machine wizard, select ESXi 6.7 and later. The accompanying text below this settings will then indicate that This virtual machine uses hardware version 14, which provides the best performance and latest features available in ESXi 6.7.
  • On the Select a guest OS page of the New Virtual Machine wizard, specify Microsoft Windows Server 2016 or later (64-bit) as the Guest OS Version and select the option Enable Windows Virtualization Based Security:

Enable Virtualization Based Security on the Select a guest OS page when creating a virtual machine in vSphere Web Client 6.7 (click for original screenshot)

 

Configure the right security settings in the virtual Domain Controller

After installing Windows Server 2016, or up, on the new virtual Domain Controller and configuring it as a Domain Controller for (one of) your Active Directory domain(s), perform the following actions in the virtual machine or on any other domain-joined machine that has the Group Policy Management Console feature installed:

  • Sign in with an account that has sufficient permissions in Active Directory to create Group Policy objects and link them to the Domain Controllers Organizational Unit (OU). Typically, a member of the Domain Admins group has these permissions.
  • Open the Group Policy Managment console, by either:
    • Picking it from the Tools menu in Server Manager.
    • Selecting it in the Start Menu from the Windows Administrative Tools folder.
    • Clicking the Start button and typing gpmc.msc followed by a press of the Enter button on the keyboard.
    • right-clicking the Start button and typing gpmc.msc followed by a click on the OK button.
  • The Group Policy Management window appears.
  • In the left navigation pane, expand the forest node, then the Domains node, than your domain. Select the Domain Controllers Organizational Unit (OU).
  • Right-click Domain Controllers and select the Create a GPO in this domain, and Link it here… menu option.
    The New GPO pop-up window appears.
  • In the New GPO pop-up window, type a name for the Group Policy object.
  • Click the OK button.
  • In the left navigation pane, expand the Domain Controllers OU and select the newly created Group Policy object.
  • Dismiss the Group Policy Management Console pop-up telling you that You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other locations where this GPO is linked. by clicking the OK button, if it pops up.
  • Right-click the Group Policy object and select Edit… from the context menu.
    The Group Policy Management Editor window appears.
  • In the left navigation pane of the Group Policy Management Editor window, expand the Computer Configuration node, then the Policies node, the Administrative Templates node, the System, and finally the Device Guard node.

The Device Guard settings in Group Policy Management (click for original screenshot)

  • In the main pane, double-click the Turn on Virtualization Based Security group policy setting.
    The Turn on Virtalization Based Security window appears
  • In the top part of the Group Policy setting, select the Enabled option.
  • At the left Options: pane, select the following options:
    • For Virtualization Based Protection of Code Integrity:, select Enabled without lock from the drop-down list. As we are configuring Virtualization-based Security through Group Policy, we’d want Group Policy to be able to remove the settings remotely as well, if need be.
    • Enable the Require UEFI Memory Attributes Table option.
    • For Secure Launch Configuration:, select Enabled from the drop-down list.
  • Click the OK button at the bottom of the Turn on Virtualization Based Security window to save the Group Policy settings and close the Turn on Virtualization Based Security window:

Turn on Virtualization Based Security Group Policy Settings (click for original screenshot)

  • Close the Group Policy Management Editor window.
  • In the left navigation pane of the Group Policy Management window, right-click the Domain Controllers OU. Select Group Policy Update… from the context menu.
    The Force Group Policy update window appears.
  • Click the Yes button to answer the question Are you sure you want to update policy for these computers?
    The Remote Group Policy update results window appears.
  • Click the Close button to close the window.
  • Close the Group Policy Management window.

 

 

Install the Hyper-V feature on the virtual Domain Controller

If you’ve managed the Group Policy settings from another machine than the virtualized Domain Controller running Windows Server 2016, or up, sign into the Domain Controller with an Active Directory account that has administrative privileges on the Domain Controller.

Run the following lines of Windows PowerShell in an elevated PowerShell window on each Domain Controller that you want enabled with Virtualization-based Security:

Install-WindowsFeature Hyper-V

Restart-Computer

  

Concluding

Virtualization-based Security offers benefits for virtualized Domain Controllers running Windows Server 2016, and up. It uses nested virtualization, where Microsoft Hyper-V offers the secure memory regions and vSphere offers the virtualization platform as it would do for any virtual machine.

Further reading

Virtualization-based Security (VBS)
Introducing support for Virtualization Based Security in vSphere 6.7
Overview of Device Guard in Windows Server 2016
Enabling Windows 10 Virtualization Based Security with vSphere 6.7

0  

Identity-related Features in Windows 10 version 2004 build 19041

Windows 10

Microsoft has released Windows 10 version 2004 build 19041 (or ‘Windows 10 May 2020 Update’) through Windows Server Update Services (WSUS) and Windows Update for Business. It was previously already available as download from Visual Studio Subscriptions, the Software Download Center (via Update Assistant or the Media Creation Tool), and the Volume Licensing Service Center.

It’s time to look at the new Identity-related features in this version of Windows 10:

FIDO2 for hybrid environments

FIDO2 security key support has been expanded to include hybrid Azure Active Directory-joined devices, enabling even more organizations to take an important step in their journey towards passwordless environments.

Before Windows 10 version 2004, the use of FIDO2 security keys was only available for Azure AD-joined devices. These devices are typically joined to Azure AD from the Out-of-the-Box experience. Hybrid Azure AD Join occurs through a Group Policy assigned to Active Directory domain-joined Windows-based devices.

Next to Windows 10 version 2004, FIDO2 security keys also require:

  • Windows Server 2016-based Domain Controllers and/or Windows Server 2019-based Domain Controllers with the January 23 2020 Feature update.
  • Azure AD Connect version 1.4.32.0, or a newer version of Azure AD Connect with the user objects in scope for synchronization and Hybrid Azure AD Join enabled.
  • FIDO2 security keys enabled on the Authentication Methods blade in the Azure AD Portal.

                     

Windows Hello

Windows Hello for Microsoft accounts

Starting in Windows 10 version 2004 you can enable passwordless sign-ins for Microsoft accounts to strengthen device access by switching all Microsoft accounts on the device to modern multi-factor authentication with Windows Hello Face, Fingerprint, or PIN, and eliminating passwords from Windows.

Windows Hello PIN added to Safe mode

For added security when troubleshooting an issue on a device, Microsoft has enabled the Windows Hello experience for devices started in Safe mode.

1  

Five things I wish I knew before ‘Next-Next-Finish’ing my Veeam Backup for Office 365 v4 installation

Veeam Backup for Office 365

Veeam Backup for Office 365 is an awesome product with a lot of possibilities and features. Just like Active Directory, it is a product that you can typically ‘next, next, finish’-install in about 10 minutes.

However, is that the best approach to implementing Veeam Backup for Office 365? Here’s my list of five things I wish I knew before ‘Next-Next-Finish’-ing my first Veeam Backup for Office 365 v4 installation roughly six months ago:

                        

Office 365 Sizer Tool

There is an awesome web-based tool by Veeam’s Senior Solution Architect Hal Yaman. The Microsoft Office 365 Backup Sizing tool, version 2 is a very efficient tool on how to estimate the storage requirements for Veeam Backup for Office 365. It takes all the guess work out of storage. I highly recommend it.

Read how to analyze your Office 365 Backup requirements with ease.

                      

Domain-Join

In recent months, Veeam is recommending to run Veeam Backup and Replication (VBR) on non-domain-joined boxes to make backups more resilient to ransomware attacks. However, you need to install Veeam Backup for Office 365 on a domain-joined box.

                                  

Modern Authentication is the way to go

The Security Defaults are in full swing for Azure AD tenants created after March 16th, 2020. Many other organizations using Azure AD without Azure AD Premium functionality are adopting the Security Defaults. Security Defaults are good from an information security point of view, as they require multi-factor authentication for privileged roles.

The Veeam Backup for Office 365 service account holds two highly-coveted privileged roles -Exchange Administrator and SharePoint Administrator- that both require multi-factor authentication.

Veeam Backup for Microsoft Office 365 offers a complete multi-factor authentication-proof installation. Here’s how to configure Veeam Backup for Microsoft Office 365 with Modern Authentication.

                                          

Default repository

Admins with some experience with setting up Veeam products know the first-run experiences. They offer great value if you need default settings.

When you first start Veeam Backup for Office 365, it offers a default schedule and a default repository with a default retention period. If one year of retention on a local disk is your preferred way to go, then you’d be done.

But are these the right settings for your repository? If not, than the consequence is that you’ll need to create a new repository, increasing the amount of storage needed for Office 365 backups on-premises to meet your goals in terms of retention and restore.

                                  

Offload to Object Storage is only available for new repositories

Many of the organizations I help have onboarded to Veeam Backup for Office 365 when it was version 1.5. We’ve been in-place upgrading these installations for years and have been able to take advantage of new and expanded features without a hitch.

However, the new option to offload Veeam Backup for Office 365’s backup repository to object storage, like Amazon S3 and Azure Storage, is not so easy to onboard; existing backup repositories can’t be transformed into offloaded repositories. The only right thing to do is to make a second (offloaded) repository and backup into that repository until the retention policy is reached for the objects in the original repository.

                                  

Concluding

I believe in a growth mindset. I believe that I should be ashamed of how I was doing things two years ago. This is how I learn. How I grow. How I heal. The other side of my approach is that I revisit old designs and approaches and thinking to myself: “I wish I knew then, what I know now…”. That’s perfect for sharing in blogposts like this one. Winking smile

0