Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Note:
This blogpost assumes all Web Application Proxies, AD FS servers and Azure AD Connect installations run Windows Server 2016.

Why harden

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Protocols, cipher suites and hashing algorithms are used to encrypt communications in every Hybrid Identity implementation. Typically, ciphers and algorithms to use are based on a negotiation between both ends of a communications channel. The purpose is to use the most secure protocols, cipher suites and hashing algorithms that both ends support. To use the strongest ciphers and algorithms it’s important to disable the ciphers and algorithms you no longer want to see used.

Microsoft recommends organizations to use strong protocols, cipher suites and hashing algorithms. For Azure Active Directory, they are changing the negotiation settings on their systems regularly, to avoid downgrades in encryption standards.

Possible negative impact (What could go wrong?)

When the systems of an Hybrid Identity implementation are improperly hardened, there will be no communication between Azure Active Directory and the systems of the implementation, and/or between the systems of the Hybrid Identity implementation.

This may affect authentications directly when using Active Directory Federation Services (AD FS) or Pass-through Authentication as authentication method in the Hybrid Identity implementation. This may cause diminished functionality, when Password Hash Sync (PHS) is used as the authentication method. Also, this may cause certificates to expire, monitoring to halt and/or backups to fail. It may also mean admins will no longer be able to (remotely) manage the systems.

When using the Remote Desktop Protocol (RDP) to manage the Windows Server installations of the Hybrid Identity implementation, the default security layer in RDP is set to Negotiate which supports both SSL (TLS 1.0) and the RDP Security Layer. Open Remote Desktop Session Host Configuration in Administrative Tools and double-click RDP-Tcp under the Connections group. If it is set to SSL (TLS 1.0) and you are running Windows Server 2008, make sure that you have installed TLS 1.1 and 1.2 support.

For Hybrid Identity implementations featuring Azure AD Connect’s Seamless Single Sign-on (3SO), do not disable RC4_HMAC_MD5 at this time, as this may break.

Getting Ready

To disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect, make sure to meet the following requirements:

System requirements

Make sure all systems in scope are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

Privilege requirements

Make sure to sign in with an account that has privileges to create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the systems in scope reside.

Who to communicate to

When intending to make changes to systems in the Hybrid Identity implementation, make sure to send a heads-up to these people and/or teams in your organization:

Load balancers and networking guys and gals
The Active Directory team
The people responsible for backups, restores and disaster recovery
The people going through the logs, using a SIEM and/or a TSCM solution
The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

Determining weak protocols, cipher suites and hashing algorithms

Encryption methods are comprised of:

A protocol, like PCT, SSL and TLS
A key exchange method, like ECDHE, DHE and RSA
A cipher suite, like AES, MD5, RC4 and 3DES

Protocols

For the purpose of this blogpost, I’ll stick to disabling the following protocols:

PCT v1.0
SSL v2
SSL v3
TLS v1.0
TLS v1.1

Note:
PCT v1.0 is disabled by default on Windows Server Operating Systems.
SSL v2 is disabled, by default, in Windows Server 2016, and later versions of Windows Server.

Cipher suites and hashing algorithms

For the purpose of this blogpost, I’ll stick to disabling the following ciphers suites and hashing algorithms:

RC2
RC4
MD5
3DES
DES
NULL
All cipher suites marked as EXPORT

Note:
NULL cipher suites provide no encryption.

Note:
The above list is a snapshot of weak ciphers and algorithms dating July 2019. Please consult the SSL Labs Documentation for actual guidance on weak ciphers and algorithms to disable for your organization.

Protocols, cipher suites and hashing algorithms and the negotiation order to use

For the purpose of this blogpost, I’ll stick with the following protocols, cipher suites and hashing algorithms, in the following negotiation order:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

This list provides a preference to Perfect Forwarding Secrecy (PFS) with the elliptic curve Diffie-Hellman key exchange (ECDHE_*) cipher suites.

How to disable weak protocols

As the systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools, but in all cases you can disable weak protocols using Windows PowerShell with the following scripts:

Note:
As SSL v2 is disabled and removed from Windows Server 2016, and up, and SSL v3 is disabled by default in Windows Server 2016, and up, these protocols do not need to be disabled on Windows Server 2016, and newer versions of Windows Server.

Enable TLS 1.2

To enable TLS 1.2, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations in scope of the Hybrid Identity implementation:

Note:
The DisabledByDefault registry value doesn’t mean that the protocol is disabled by default. It means the protocol isn’t advertised as available by default during negotiations, but is available if specifically requested.

$SChannelRegPath = “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols”

New-Item $SChannelRegPath+”\TLS 1.2\Server” -Force

New-Item $SChannelRegPath+”\TLS 1.2\Client” -Force

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.2\Server” `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.2\Server” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.2\Client” `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.2\Client” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

Disable TLS 1.0 and TLS 1.1

To disable TLS 1.0 and TLS 1.1, run the following Windows PowerShell script in the same elevated PowerShell window as the previous Windows PowerShell script on each of the Windows Server installations in scope of the Hybrid Identity implementation:

New-Item $SChannelRegPath -Name “TLS 1.0”

New-Item $SChannelRegPath+”\TLS 1.0″ -Name SERVER

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.0\SERVER” `
-Name Enabled -Value 0 -PropertyType DWORD

New-Item $SChannelRegPath+”\TLS 1.1\Server” –force

New-Item $SChannelRegPath+”\TLS 1.1\Client” –force

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.1\Server” `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.1\Server” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.1\Client” `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath+”\TLS 1.1\Client” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

Restart each server after these configuration changes.

How to disable weak ciphers and algorithms

The systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools. In all cases you can disable weak cipher suites and hashing algorithms by disabling individual TLS cipher suites using Windows PowerShell.

Note:
The below lines of PowerShell do not change the negotiation order of the cipher suites and hashing algorithms. It merely disables individual combinations of unwanted cipher suites and hashing algorithms. This also eliminates the need to keep up with the cipher suites in Windows Server between Windows Server version releases and even between updates.
A win-win situation if you’d ask me!

Tip!
To get an overview of the current negotiation order, use the following line of PowerShell:

Get-TlsCipherSuite | Format-Table Name

Use the following lines on Windows Server 2016 installations to remove weak cipher suites and hashing algorithms:

Disable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_256_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_128_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_GCM_SHA384“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_GCM_SHA256“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA256“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA256“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_3DES_EDE_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA256“
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA256“
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_SHA“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_MD5“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA256“
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_GCM_SHA384“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_GCM_SHA256“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_CBC_SHA384“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_CBC_SHA256“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA384“
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA256″“

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server. When testing the hardening of the functionality behind the load balancer, make sure that the load balancer points you to the hardened system, not another one. In an environment with a Staging Mode Azure AD Connect installation, the hardening can be performed on this Windows Server installation and tested with the normal Staging Mode (imports only) synchronization cycles. When hardening is approved upon, the actively synchronizing Azure AD Connect installation can be switched, or hardened, too.

Note:
The registry changes are step 2 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to Enforce Azure AD Connect to use TLS 1.2 only on the Windows Servers running Azure AD Connect, before testing.

Rolling Back Hardening

To roll back hardening, use the following lines of Windows PowerShell:

$SChannelRegPath = “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols”

Remove-Item –Name “TLS 1.0” –Path $SChannelRegPath
Remove-Item –Name “TLS 1.1” –Path $SChannelRegPath
Remove-Item –Name “TLS 1.2” –Path $SChannelRegPath

Enable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_256_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_128_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_GCM_SHA384“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_GCM_SHA256“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA256“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA256“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_3DES_EDE_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA256“
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA256“
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_SHA“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_MD5“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA256“
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_GCM_SHA384“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_GCM_SHA256“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_CBC_SHA384“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_CBC_SHA256“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA384“
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA256“

Concluding

Get rid of old protocols, cipher suites and hashing algorithms in your Hybrid Identity implementation, so they cannot be used to negotiate the security of the connections down.

Why harden AD FS Servers

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Active Directory Federation Services (AD FS) servers are typically placed on the internal network, close to Active Directory Domain Controllers. In a typical Hybrid Identity Implementation, the AD FS Servers is published using Web Application Proxies.

It is imperative that endpoints that are offered by AD FS Servers do not allow for nefarious possibilities. This is why Microsoft has started to disable several endpoints by default on Windows Server 2016-based AD FS Servers, like the IdP-initiated Sign-on page.

Possible negative impact (What could go wrong?)

When endpoints on AD FS servers are disabled, while they are needed, certain functionality may be lost, until the endpoint is enabled again.

The Windows Transport endpoints mentioned in this blogpost are needed for several purposes, including Hybrid Azure AD Join, in the internal network. However, it is a recommended practice to remove these endpoints for the extranet (The Internet in AD FS terms). If the endpoints are completely disabled, the internal functionality may be lost (until the endpoint is enabled again).

Getting ready

To disable unnecessary endpoints on AD FS servers, make sure to meet the following requirements:

System requirements

Make sure the AD FS servers are installed with the latest cumulative Windows Updates.

Privilege requirements

Make sure to sign in with an account that has privileges to manage the AD FS Farm. In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS Server.

Who to communicate to

As the AD FS servers operate as part of a chain, notify all stakeholders in the chain. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery.

Unnecessary AD FS Endpoints

IdP-Initiated Sign-On endpoint

In Windows Server 2016-based AD FS Farms, the IdP-initiated Sign-on page is disabled, by default. However, since many admin tricks rely on this page, this endpoint is often temporarily enabled to allow for:

Testing the correct functionality of AD FS Servers.
Testing branding of the sign-in pages for situations where Single Sign-On is not available.

For the first purpose, use the /adfs/probe endpoint over HTTP to see if an AD FS Server is actually responding and runs the AD FS service. Use the /adfs/trust/mex endpoint over HTTPS to test issues with the TLS certificate. There is no need to abuse the /adfs/ls/idpinitiatedsignon.aspx endpoint for that…

For the second purpose, I’d like to remind you that in many environment nothing is as permanent as temporary solutions. Once the IdP-initiated Sign-on page is enabled, it’s hard to keep in mind to disable it again, when done.

Windows Transport Endpoint

In Windows Server 2016-based AD FS Farms, the windows transport endpoints are enabled, by default. It is recommended that the endpoint be disabled from the extranet due to a known security vulnerability; these endpoints allow NTLM logins to be processed from the extranet. As a result, it will bypass AD FS lockout protections and allow brute force password attacks or account lockouts on the user account.

Note:
Azure AD Connect Health for AD FS prompts for security warnings about WS-Trust endpoints since the last week of July 2019.

The Windows Transport endpoints need to be immediately disabled from being exposed to the extranet.

How to disable unnecessary AD FS endpoints

Please run the following lines of Windows PowerShell to configure the AD FS Farm:

Set-AdfsProperties –EnableIdpInitiatedSignonPage $False

Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/13/windowstransport -Proxy $false

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the AD FS servers. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

As endpoints apply to all AD FS servers in the farm, there is no need to isolate an AD FS server in the load-balancer; the above lines of PowerShell apply to all AD FS Servers within a timeframe of about 5 minutes.

Rolling back hardening

To roll back hardening of the endpoints to Windows Server 2016’s default state, run the following lines of Windows PowerShell:

Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/2005/windowstransport -Proxy $true

Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/13/windowstransport -Proxy $true

Concluding

Disable the IdP-initiated Sign-on page and Windows Transport endpoints on the AD FS farm to harden AD FS Servers.

The post HOWTO: Disable unnecessary AD FS endpoints appeared first on The things that are better left unspoken.

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 July 2019:

What’s Planned

Application Proxy service update to support only TLS 1.2

Service category: App Proxy
Product capability: Access Control

To help use strongest encryption, Microsoft is going to begin limiting Application Proxy service access to only TLS 1.2 protocols. This limitation will initially be rolled out to organizations who are already using TLS 1.2 protocols, so admins won’t see the impact. Complete deprecation of the TLS 1.0 and TLS 1.1 protocols will be complete on August 31, 2019. Organizations still using TLS 1.0 and TLS 1.1 will receive advanced notice to prepare for this change.

To maintain the connection to the Application Proxy service throughout this change, Microsoft recommends that admins make sure their client-server and browser-server combinations are updated to use TLS 1.2. Microsoft also recommends that admins make sure to include any client systems used by employees to access apps published through the Application Proxy service.

Design updates are coming for the Application Gallery

Service category: Enterprise Apps
Product capability: SSO

New user interface changes are coming to the design of the Add from the gallery area of the Add an application blade. These changes will help admins more easily find apps that support automatic provisioning, OpenID Connect, Security Assertion Markup Language (SAML), and Password single sign-on (SSO).

Removal of the MFA server IP address from the Office 365 IP address

Service category: MFA
Product capability: Identity Security & Protection

Microsoft is removing the MFA server IP address from the Office 365 IP Address and URL Web service. If organizations currently rely on these pages to update their firewall settings, they must make sure they’re also including the list of IP addresses documented in the Azure Multi-Factor Authentication Server firewall requirements section of the Getting started with the Azure Multi-Factor Authentication Server article.

What’s New

New passwordless sign-in to Azure AD using FIDO2 security keys

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

Organizations using Azure AD can now set policies to manage FIDO2 security keys for their organization’s users and groups. End-users can also self-register their security keys, use the keys to sign in to their Microsoft accounts on web sites while on FIDO-capable devices, as well as sign in to their Azure AD-joined Windows 10 devices.

New Federated Apps available in Azure AD App gallery

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

In July 2019, Microsoft has added these 18 new apps with Federation support to the app gallery:

Automate user account provisioning for these newly supported SaaS apps

Service category: Enterprise Apps
Product capability: Monitoring & Reporting

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

New Azure AD Domain Services service tag for Network Security Group

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

If admins are tired of managing long lists of IP addresses and ranges, they can use the new AzureActiveDirectoryDomainServices network service tag in their Azure network security group to help secure inbound traffic to their Azure AD Domain Services virtual network subnet.

New Security Audits for Azure AD Domain Services Public Preview

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

Microsoft is pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security auditing helps provide admins with critical insight into authentication services by streaming security audit events to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the Azure AD Domain Service portal.

New Authentication methods usage & insights Public Preview

Service category: Self Service Password Reset
Product capability: Monitoring & Reporting

The new Authentication methods usage & insights reports can help admins understand how features like Azure Multi-Factor Authentication and self-service password reset are being registered and used in their organization, including the number of registered users for each feature, how often self-service password reset is used to reset passwords, and by which method the reset happens.

New security reports are available for all Azure AD administrators Public Preview

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

All Azure AD administrators can now select the banner at the top of existing security reports, such as the Users flagged for risk report, to start using the new security experience as shown in the Risky users and the Risky sign-ins reports. Over time, all of the security reports will move from the older versions to the new versions, with the new reports providing admins the following additional capabilities:

Advanced filtering and sorting
Bulk actions, such as dismissing user risk
Confirmation of compromised or safe entities
Risk state, covering: At risk, Dismissed, Remediated, and Confirmed compromised

New Security Audits for Azure AD Domain Services Public Preview

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

Microsoft is pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security auditing helps provide admins with critical insight into their authentication services by streaming security audit events to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the Azure AD Domain Service portal.

New B2B direct federation using SAML/WS-Fed Public Preview

Service category: B2B
Product capability: B2B/B2C

Direct federation helps to make it easier for organizations to work with partners whose IT-managed identity solution is not Azure AD, by working with identity systems that support the SAML or WS-Fed standards. After admins set up a direct federation relationship with a partner, any new guest user invited from that domain can collaborate with users in their organization using their existing organizational account, making the user experience for guests more seamless.

New check for duplicate group names in the Azure AD portal

Service category: Group Management
Product capability: Collaboration

Now, when admins create or update a group name from the Azure AD portal, Microsoft will perform a check to see if they are duplicating an existing group name in their resource. If Microsoft determines that the name is already in use by another group, admins will be asked to modify the name.

Azure AD now supports static query parameters in reply (redirect) URIs

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

Azure AD apps can now register and use reply (redirect) URIs with static query parameters (for example, https://contoso.com/oauth2?idp=microsoft) for OAuth 2.0 requests. The static query parameter is subject to string matching for reply URIs, just like any other part of the reply URI. If there’s no registered string that matches the URL-decoded redirect-uri, the request is rejected. If the reply URI is found, the entire string is used to redirect the user, including the static query parameter.

Dynamic reply URIs are still forbidden because they represent a security risk and can’t be used to retain state information across an authentication request. For this purpose, use the state parameter.

Currently, the app registration screens of the Azure portal still block query parameters. However, admins can manually edit the app manifest to add and test query parameters in their app.

Activity logs (MS Graph APIs) for Azure AD are now available through PowerShell Cmdlets

Service category: Reporting
Product capability: Monitoring & Reporting

Microsoft is excited to announce that Azure AD activity logs (Audit and Sign-ins reports) are now available through the Azure AD PowerShell module. Previously, admins could create their own scripts using MS Graph API endpoints, and now Microsoft has extended that capability to PowerShell cmdlets.

Updated filter controls for Audit and Sign-in logs in Azure AD

Service category: Reporting
Product capability: Monitoring & Reporting

Microsoft has updated the Audit and Sign-in log reports so admins can now apply various filters without having to add them as columns on the report screens. Additionally, admins can now decide how many filters they want to show on the screen. These updates all work together to make reports easier to read and more scoped to needs.

What’s Fixed

App-only tokens now require the resource application (Web API) to exist in the resource tenant

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

On July 26, 2019, Microsoft changed how they provide app-only tokens through the client credentials grant. Previously, apps could get tokens to call other apps, regardless of whether the client app was in the tenant. Microosft has updated this behavior so single-tenant resources, sometimes called Web APIs, can only be called by client apps that exist in the resource tenant.

If an app isn’t located in the resource tenant, you’ll get an error message:

The service principal named <app_name> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

To fix this problem, admins must create the client app service principal in the tenant, using either the admin consent endpoint or through PowerShell, which ensures the tenant has given the app permission to operate within the tenant.

The post What’s New in Azure Active Directory for July 2019 appeared first on The things that are better left unspoken.

Virtualizing Domain Controllers

Active Directory utilizes a multi-master replication model. It’s great that each Domain Controller provides read and write access to the Active Directory database, but it comes with a big drawback: Domain Controllers need to be in sync to provide consistent data to clients, independent of the Domain Controller communicated to. A big question to ask when virtualizing Domain Controller is:

What’s the impact of virtualizing Domain Controllers on VMware vSphere in terms of replication?

Let’s find out…

Active Directory replication

Active Directory utilizes a multi-master replication model. This means that changes (called ‘writes’) to the database can originate from every Domain Controller.

Note:
Read-only Domain Controllers are special, as they refer write operations to (read/write) Domain Controllers.

However, some writes are special. For instance, schema update operations, targeting the schema partition happen only on the Schema Master, or to be exact: the Domain Controller holding the Schema Master Flexible Single Master Operations (FSMO) role. Another examples are changes to passwords. A password can be changed on every Domain Controller, but is replicated to the Domain Controller holding the PDC Emulator (PDCe) FSMO role and then replicated out from there.

In multi-domain environments, replication is extended through the infrastructure master and Global Catalog servers.

Components of Active Directory replication

There are a couple of main components of Active Directory replication:

The Directory Service Agent GUID
The InvocationID
The Update Sequence Number
Timestamps

The Directory Service Agent GUID

The Directory Service Agent (DSA) globally-unique identifier (GUID) is unique to a Domain Controller. This value is created during promotion of the Windows Server installation to Domain Controller and persists over the life of the Domain Controller. The DSA GUID is used with USNs and is, therefore, useful to track the Domain Controller on which the update originated.

The InvocationID

The InvocationID is used by replication partners of Domain Controller to identify the Domain Controller’s instance of the Active Directory database. That’s right! Domain Controller don’t have replication partnerships based on hostnames or IP addresses. These can be changed, and (when performed properly) will have no negative impact on Active Directory replication.

Unlike the DSA GUID, the InvocationID can change over time. For instance, when a Domain Controller is properly restored from a backup, the InvocationID is reset to trigger replication as a new replication partner, allowing to replicate changes in that might have originated from the Domain Controller, but were lost.

Update Sequence Numbers

Update Sequence Numbers (USNs) can be seen as Domain Controllers’ internal logical clocks. Every time a write occurs to the Active Directory database on a Domain Controller, it adds the number of writes to the USN.

Domain Controllers can have different USNs. This is logical; a Domain Controller that has been around for a longer period of time might have seen a lot of password changes for a user, resulting in separate writes, whereas a relatively new Domain Controller might not yet have seen any password changes for the user and would only have written the object once.

Every Domain Controller keeps records of the last-seen USN with the InvocationIDs of its replication partners. This information is stored in the high watermark table, as depicted below:

Timestamps

As mentioned in the previous blogpost on Managing Active Directory Time Synchronization on VMware vSphere, only when two writes in Active Directory cross replication, the time stamp is used to make the last write win.

If you experience replication problems for objects, check the time stamps: The version of the object plus the originating time and the originating DSA GUID will show you which Domain Controller to check first.

Replication types

There are two replication types:

Intra-site replication, within Active Directory sites, and;
Inter-site replication, between Active Directory sites.

Intra-site replication

Intra-site replication works with change notifications. Building upon the previous picture, when 12 objects are created on DC1, its UPN is upped by 12, going from 400 to 412:

Now, DC1 will notify its replication partners that writes were made and that these changes may be replicated. DC2 performs replication, performs 12 writes in the database too, and updates its high watermark table with the last seen USN for the InvocationID for DC1, as depicted below:

Now, when we create an object on DC2, its UPN is upped after the write, a change notification is sent, DC1 would perform replication, and its USN is upped by the same number during this replication, and the USN is updated in the high watermark table for the InvocationID of DC2 on DC1, too:

As DC1 knows the write it performed in its database is for an object that didn’t originate from itself, it will not send a change notification to DC2. Yes, there is a gap that remains between USNs on Domain Controllers and USNs in high watermark tables on its replication partners. That’s fine.

Inter-site Replication

Active Directory sites govern access and replication. They can be used to define locations of high interconnectivity. In organizations with multiple locations and low (available) bandwidth between these locations, authentication traffic doesn’t have to travel across the low bandwidth connections, but stays within the location. Active Directory site links connect Active Directory sites.

Note:
Connections with bandwidth below 10Mbit/second and unreliable connections are considered reasons to create Active Directory sites.

Inter-site replication is different from intra-site replication. It doesn’t use change notifications to initiate replication (unless you enable the Inter-site Change Notification feature). Instead, it uses a replication schedule.

Another big difference is the functionality of the Bridgehead Server as the only Domain Controller taking care of replication to a Domain Controller on the other side of an Active Directory sitelink.

Challenges with Active Directory Replication

The virtualization platform hosting virtualized Domain Controllers offers new functionality to admins, including easy snapshots. When using these features with virtualized Domain Controllers, two challenges typically emerge:

USN Rollbacks
Lingering Objects

USN Rollbacks

Update Sequence Numbers (USNs) assume linearity of time. With non-virtualized Domain Controllers, the popular Varonis imaging products caused a lot of problems for Active Directory admins. That’s because when you reimage a Domain Controller to a previous state, without telling Active Directory, you reset the USN to a previous state. As the USN is logged in the high water mark table by its replication partners, they’ll know something is wrong:

Starting with Windows Server 2003 Service Pack 1, or when you install KB875495, the replication partners of the improperly reset Domain Controller will:

Stop replicating to the improperly reset Domain Controller
Log Event ID 2095

This prevents writes inside the USN ‘bubble’ that will not replicate out from the improperly reset Domain Controller.

Lingering Objects

Lingering objects are another challenge. Reverting to a previous state is the cause of this problem, too. However, in the case of lingering objects, the previous state is a state that is beyond Active Directory’s tombstone lifetime.

Up till this point in this blogpost, we’ve discussed creating objects. Lingering Objects have to do with deleting objects. Contrary to what you may expect, when an object is deleted on a Domain Controller, the object is not deleted. Instead, it is marked as deleted. This allows all replication partners of the Domain Controller to replicate this change; it is tombstoned. After the tombstone lifetime has expired, the object is actually deleted (and its Distinguished Name Tag and Security Identifier cannot be reused).

Note:
When the Active Directory Recycle Bin is enabled, a separate state for object is introduced, allowing for a recycle lifetime period, identical to and preceding the tombstone lifetime period.

The tombstone lifetime is enforced per Domain Controller through the Garbage Collection Process. This process, that runs every 12 hours, is responsible for ‘cleaning up’ deleted objects, as shown below:

When a Domain Controller is improperly restored to a point in time exceeding the tombstone lifetime, a deleted object may reappear and remain, because the deletion was already fully processed by its replication partners.

However, the replication partners will not have knowledge of the object and do not have the logic to update the object. (the object’s originating DSA. This might leave to integrity problems where a person may or may not be able to log on using a user object, depending on the Domain Controller that is used as the logon server:

It gets awkward when the lingering object is the user object for a domain admin that was escorted off the premises, but suddenly regains administrative privileges in the environment…

Recommendations

Design for replication

Active Directory site links allow for directing replication traffic. Schedules and cost allow for further customization and minimizing of replication traffic between Active Directory sites.

Designing the Active Directory sites and site links from the start offers the best results. Processes in which Active Directory admins are kept up-to-date by networking admins on changes in the networking infrastructure aid in keeping the replication topology in the best shape.

Apply the defaults

Many people talk of the ‘tyranny of the defaults”, but in case of Active Directory replication, the default settings provide a robust mechanism for keeping Domain Controllers in synchronization.

Make sure to keep the following default settings:

The Bridge all site links option allows for the complete demise of an Active Directory site in a fully-routed networking environment.
The Knowledge Consistency Checker (KCC) and Inter-site Topology Generator (ISTG) allow for automatically generated and automatically updated replication partnerships between Domain Controllers and for automatically assigned BridgeHead Servers.
Strict Replication Consistency prohibits replication of Active Directory objects beyond the Tombstone Lifetime.

Take advantage of new features

Make sure to make the following changes if the Active Directory environment has been running Windows Server 2003 Domain Controllers in the past:

Set the Tombstone Lifetime period value to 180 days, as it might still be interpreted as 60 days, allowing for a timeframe in which to introduce Lingering Objects.
Migrate SYSVOL replication from NTFRS to DFS-R.
Enable the Active Directory Recycle Bin feature

Monitor Active Directory replication

By monitoring Active Directory replication, replication problems can be identified fast and effortlessly. Historical data might prove instrumental in pinpointing root causes of replication problems and moments in time when Lingering Object creation happened. You can use the following tools:

Repadmin.exe (built-in)
Active Directory Replication Status Tool

Don’t revert Domain Controllers to snapshots

Use Active Directory-aware Disaster Recovery solutions, use them to make Active Directory-aware backups of Domain Controllers and use them to restore Domain Controllers properly. Upon restore, these solutions will:

Invalidate the RID Pool for the Domain Controller
Create a new InvocationID for the Domain Controller, effectively proposing it as a new replication partner to its former replication partners
Perform an initial replication to guarantee Active Directory object integrity

Don’t restore Domain Controllers beyond the Tombstone Lifetime

When you restore Domain Controllers beyond the tombstone lifetime period, lingering objects may be introduced. The tombstone lifetime period is 60 days, by default, for environments originally set up with Windows Server 2003 R2, or older and is 180 days, by default for environments originally set up with Windows Server 2008, or up.

Get rid of lingering objects

Use the Lingering Objects Liquidator (LoL) to discover and remove lingering objects.

Concluding

This blogpost now features a pretty good primer on Active Directory replication. It’s not the most fun stuff to read, but it helps in explaining the replication considerations for Domain Controllers running on VMware vSphere to avoid USN rollbacks and lingering objects.

Why enable auditing on AD FS Servers

Auditing and logging allow for examining the processes and services running on Windows Server installations. They allow for organizations to check the default behavior and get notified of unauthorized changes and requests.

Reasons why

It is imperative that events are logged and that AD FS Servers are audited, as their capabilities can be misused in quite the same way Domain Controllers can be misused. As AD FS Servers are connected to the Internet (through Web Application Proxies), this functionality is available from the Internet as well.

Possible negative impact (What could go wrong?)

When logging and auditing information from AD FS servers is incomplete, an organization might not have the necessary information to retrace steps of misuse and sources of origin of this misuse.

When logging and auditing information from AD FS servers is overcomplete, an organization may be swamped in irrelevant information that is not useful and may hinder the effectiveness of the admins who want to hunt misuse.

Getting ready

To enable auditing and logging on AD FS servers, make sure to meet the following requirements:

Information requirements

Make a risk analysis of the ways Active Directory Federation Services (AD FS) can be misused.

AD FS Server Auditing level

Based on the risk to mitigate, determine the level of auditing information that is needed. for AD FS in Windows Server 2016, there are three levels:

None; This auditing level results in zero events to be logged.
Basic; This is the default auditing level in AD FS in Windows Server 2016. No more than 5 events will be logged for a single request.
Verbose; At this auditing level all events are logged. This will log a significant amount of information per request.

AD FS Farm Logging Level

The events from the auditing levels are independent of the default options on the Events tab of the Federation Service properties, that are AD FS Farm-wide, as shown below:

It is considered to be a recommended practice to enable Success audits and Failure audits on the AD FS Farm. For this to work, auditing should also be enabled using the Local Security Policy MMC Snap-in.

Note:
Both the above user interface to enable types of events nor the Local Security Policy MMC Snap-in are available on Server Core installations of Windows Server 2016. Therefore, we will enable these settings through Windows PowerShell.

System requirements

Make sure the AD FS Servers are installed with the latest cumulative Windows Updates.

Privilege requirements

AD FS Server Auditing level

For making changes to the AD FS auditing level, make sure to sign in with an account that has privileges to manage every individual AD FS Server in the AD FS Farm. The AD FS auditing level is a per-AD FS server setting and needs to be configured on each AD FS server. This also holds true for configuring the auditing policy.

AD FS Farm Logging Level

For making changes to the AD FS logging evens, make sure to sign in with an account that has privileges to manage the AD FS Farm. In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS Server.

Who to communicate to

When your organization utilizes a Security Incident and Event Monitoring (SIEM), Security Orchestration Automation and Response (SOAR) and/or a centralized log collection solution, talk to the people responsible for it. When AD FS is not yet onboarded, get it onboarded and perform the above risk analysis with them. When AD FS is already onboarded talk through the implications of switching between the auditing levels and enabling or disabling logging of events.

Enabling AD FS Auditing

How to check the AD FS auditing level

To check the current AD FS auditing level run the following line of Windows PowerShell:

Get-AdfsProperties | Select Auditlevel

How to enable the AD FS verbose auditing level

To enable AD FS verbose auditing, run the following lines of Windows PowerShell in an elevated Windows PowerShell window or PowerShell ISE:

Set-AdfsProperties -Auditlevel verbose

Restart-Service -Name adfssrv

Repeat the above line of Windows PowerShell on each AD FS server in the AD FS Farm.

How to enable the auditing policy

To enable the Auditing Policy, run the following command line in an elevated Command Prompt (cmd.exe) window:

auditpol.exe /set /subcategory:”Application Generated”
/failure:enable /success:enable

Repeat the above line of Windows PowerShell on each AD FS server in the AD FS Farm.

Enabling AD FS Logging

How to check the AD FS auditing level

To check the current AD FS auditing level run the following line of Windows PowerShell:

(Get-AdfsProperties).Loglevel

How to enable logging of successes and failures

To enable AD FS logging of Success and Failure events, run the following line of Windows PowerShell in an elevated Windows PowerShell window or PowerShell ISE on one of the AD FS Servers in the AD FS Farm:

Note:
In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, run these lines of Windows PowerShell on the primary AD FS Server.

Set-AdfsProperties -LogLevel `
((Get-AdfsProperties).LogLevel+’SuccessAudits‘,’FailureAudits‘)

Testing Auditing and Logging

After enabling the required levels of auditing and logging, it’s time to test them . Everyone should sign off (not literally, unless that’s procedure) on the correct working of the AD FS servers. Does authentication to cloud applications still work and does it result in the corresponding information? Does the SIEM, SOAR and/or centralized log collection solution handle the traffic?

Helpful tools

On its ADFSHelp site, Microsoft lists the events for AD FS Servers running Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019. For Windows Server 2016, there are currently 327 events listed.

Microsoft’s AD FS Events Module on GitHub can be useful to gather related AD FS events from the security, admin, and debug logs, across multiple servers. This tool allows the user to reconstruct the HTTP request/response headers from the AD FS logs when you don’t have a SIEM, SOAR and/or centralized log collection solution.

Rolling back hardening

To roll back hardening of the endpoints to Windows Server 2016’s default state, run the following two lines of Windows PowerShell in an elevated PowerShell or PowerShell ISE window:

Set-AdfsProperties -LogLevel ((Get-AdfsProperties).LogLevel | `
Where-Object {$_ -notmatch ‘Audits‘})

Set-AdfsProperties -Auditlevel basic

Additionally, run the following command line in an elevated Command Prompt (cmd.exe) window:

auditpol.exe /set /subcategory:”Application Generated” /failure:disable /success:disable

Concluding

Enable auditing on AD FS Servers and let these events flow into the same SIEM, SOAR and/or centralized log collection solution as your Domain Controller’s events to gain a monitoring solution for all authentication traffic both on-premises and in the cloud.

About Active Directory Virtualization Safeguards

Active Directory Domain Services in Windows Server 2012 is the first Windows Server Role to take advantage of the VM-GenerationID with the Active Directory Virtualization Safeguards feature.

About VM-GenerationID

The VM-GenerationID is a random 128bit identifier. Introduced as a new feature of Hyper-V in Windows Server 2012, it also found its way to the other main virtualization platforms, including VMware vSphere.

Note:
The VM-GenerationID functionality in ESXi 5.0 Update 2 was implemented (and released on December 20, 2012), based on a draft of the VM-GenerationID whitepaper. In the draft version of the VM-GenerationID whitepaper, the VM-GenerationID value was defined as a random 64bit value. In the final version of the VM-GenerationID whitepaper, the VM-GenerationID value was defined as a random 128bit value.

This VM-GenerationID is placed in the RAM of each virtual machine (VM) running on a VM-GenerationID-capable platform with VM-GenerationID-capable settings. Every VM gets its own VM-GenerationID from the virtualization platform. The virtualization platform keeps the VM-GenerationID the same for a VM, unless one of the below situations occur, as described in the VM-GenerationID whitepaper:

VM-GenerationID in VMware vSphere

The above table from the VM-GenerationID whitepaper was also documented on the VMware blogs with the appropriate vSphere terminology and answers to additional questions asked in the comments:

The VM-GenerationID is communicated through the VM GenerationID Counter Driver to virtual machines running on VMware vSphere 5.0 Update 2, and above. It is not governed through VMware Tools settings.

The value of the VM-GenerationID per VM is exposed in the VMX file as vm.genid or vm.genidx.

VM-GenerationID safeguarding Active Directory Virtualization

Starting with Windows Server 2012, a virtual Domain Controller reads the VM-GenerationID from RAM when it starts and before every write to the Active Directory database. It stores the value of VM-Generation ID in the msDS-GenerationID attribute of its object in the local Active Directory database. (this attribute is not replicated)

Before every write, the Active Directory service compares the VM-GenerationID in RAM with the msDS-GenerationId attribute in the Active Directory database. If they match, no problem. If they don’t match, magic happens: .

The invocationID is renewed, and;
The RID Pool block in use is discarded.

As you might have remembered from the previous blogpost in this series, this effectively designates the Domain Controller as a new replication partner for other Domain Controllers. It allows the Domain Controller to replicate in necessary changes to avoid USN Rollbacks and Lingering Objects.

Requirements

From the description above, you might have already figured out some situations that won’t trigger this behavior; Indeed, changes on the storage level won’t be observed and moving a virtual Domain Controller to or from a non-VM-GenerationID-capable hypervisor platform won’t trigger the safeguards either.

Even in straightforward vSphere deployments with straightforward management practices, though, you might not benefit from the Active Directory Virtualization Safeguards.

So, here is the complete list of requirements for Active Directory Virtualization Safeguards on VMware vSphere:

VMware vSphere needs to run version 5.0 update 2, or up.
VMware tools need to be installed and running on virtual Domain Controllers, ideally with a version that matches the VMware vSphere version.
The virtual Domain Controller needs to run Windows Server 2012, or up.
The Virtual Machine hardware version needs to be version 7, or up.

Just because you can…

… doesn’t mean you should snapshot virtual Domain Controllers. Winking smile

Some valid reasons for using virtual machine snapshots with Domain Controllers are to:

Backup software, that takes “image level” backups, typically rely on snapshots to ensure consistent backups
install software and/or updates on a virtual Domain Controller and want the ability to revert in case there are issues

The possible impact of Virtualization Safeguards on Disaster Recovery

Even with Active Directory Virtualization Safeguards, remember that snapshots are not backups. In fact, the Active Directory Best Practices Analyzer (BPA) will display a warning when Active Directory is only ‘backed up’ through snapshots and not following valid backup and restore procedures.

Forest-wide Disaster Recoveries

Special considerations are required for site-wide Disaster Recovery plans when talking to snapshots of virtual Domain Controllers. As a disaster typically refers to complete site (or Active Directory) outage, in a disaster you typically must recover multiple Domain Controllers or the entire Active Directory infrastructure. In most organizations, snapshots aren’t taken in a sufficiently orchestrated fashion of frequency to allow for the Disaster Recovery scenarios. Bare metal-like restore actions are also not possible with snapshots.

Forest-wide recovery could be from backup or orchestrated, for instance with VMware Site Recovery Manager (SRM).

Was it a Proper Restore or Virtualization Safeguard?

The Active Directory virtualization safeguards kick in during a Domain Controller recovery, as the hypervisor platform changes the VM-GenerationID of the recovered Domain Controller. When investigating Active Directory backup and restore solutions, don’t focus on Event ID 1109 in the Directory Services event log , solely, as this can be triggered by both. Instead:

Look for Event ID 1917 in the Directory Services event log when taking a backup to see if it uses the Active Directory writer, and;
Look in the registry for the DSA Previous Restore count.

There’s more information on analyzing Active Directory-aware Backup and Restore solutions, is available in my Whitepaper on Host-Based Backups and Restores of Domain Controllers.

Recovering the RID Master

One of the outcomes of the Active Directory Virtualization Safeguards is to invalidate the RID pool block that was assigned to the Domain Controller previously. So, what happens if virtualization safeguards kick in on the Domain Controller holding the RID Master Flexible Single Master Operations (FSMO) role?

The ‘new’ Domain Controller will not be able to obtain a RID Pool block, when the RID Master is down. The RID Master cannot issue RID pool blocks, until it has replicated with other Domain Controllers.

The solution here is to seize the RID Master FSMO Role on another Domain Controller.

Have Domain Controllers in multiple sites

You can only seize a FSMO role when you have Domain Controllers running and replicating. To overcome a site-wide Active Directory outage, always have Domain Controllers in multiple sites or use a Disaster Recovery site where you replicate to.

Recovering the RID Master

When the Domain Controller holding the RID Master Flexible Single Master Operations (FSMO) role is located in an Active Directory site, that experiences an outage, either:

Seize the RID Master role on a Domain Controller in an Active Directory site that is not experiencing an outage, as part of the Disaster Recovery plan.
Replicate the RID Master and PDC Emulator to a pre-assigned Disaster Recovery site as part of the Disaster Recovery plan.

After any of the above actions, restart the Directory Service on the new RID Master. Use the following PowerShell command:

Restart-service NTDS -force

Then force replication to another Domain Controller not impacted by the outage (if available). Reboot the Domain Controller holding the RID Master Flexible Single Master Operations (FSMO) role after all other Domain Controllers have started.

Recommendations

To take advantage of virtualization safeguards as an organization, please consider these recommendations:

Meet the requirements

Many procedures in organizations result in sub-optimal settings. A VM template with VM version 6 will ruin your dreams of Active Directory Virtualization Safeguards, especially when you’ve in-place upgraded the Operating System to Windows Server 2012. Out-of-date VMware tools will have the same effect on these dreams, so update them when you update the underlying hypervisor platform.

Use snapshots with moderation

Active Directory is not a drinking game (although there is a drink attribute in Active Directory’s schema). Use snapshots of virtual Domain Controllers with moderation. Installing software or patching a Domain Controller shouldn’t automatically mean you take a snapshot of it.

Plan for disaster recovery

Snapshots of virtual Domain Controller cannot, generally, be used to perform a complete Active Directory Forest restore. You’ll need proper Active Directory backups for this purpose. Also virtualization safeguards might interfere with the current Disaster Recovery plan for the RID Master, Plan accordingly.

Promotions vs. Restores

It is often easier to deploy a new Windows Server installation and promote it to a Domain Controller, than trying to restore a Domain Controller from a backup.

Of course, your mileage may vary, depending on the agents and additional software running on Domain Controllers.

Concluding

In general – it is unlikely you’ll frequently encounter the Active Directory virtualization safeguards, but it’s good to know it’s there if you need it to cover your behind.

Related blogposts

New features in AD DS in Windows Server 2012, Part 12: Virtualization-safe AD
List of Hypervisors supporting VM-GenerationID
Cases where VM-GenerationID doesn’t trigger AD virtualization safeguards, Part 1
Cases where VM-GenerationID doesn’t trigger AD virtualization safeguards, Part 2

About the Extensible Authentication Framework

Active Directory Federation Services (AD FS) offers the Extensible Authentication Framework (EAF). Leveraging this functionality, multi-factor authentication providers can hook their products into the authentication funnel.

Through an AD FS Agent, the authentication gets routed to the multi-factor authentication software, when an MFA claim is needed. Only when the multi-factor authentication software signals back that the multi-factor authentication was successful, will AD FS be able to successfully send a federation claim to the user.

About VASCO, OneSpan and DIGIPASS

OneSpan (formerly VASCO Data Security International) is a publicly traded cybersecurity technology company based in Chicago, Illinois with offices in Montreal, Brussels and Zurich. The company is historically known for its multi-factor authentication and electronic signature software.

VASCO started developing its DIGIPASS technology in the early 2000s. In 2009, VASCO made DIGIPASS two-factor authentication available in the App Store for iPhone and iPod Touch.

On May 30, 2018, VASCO changed its name to OneSpan.

Prerequisites

Before following the below steps, make sure you meet the following prerequisites:

Implement the OneSpan IDENTIKEY Authentication Server .
Copy the installation file for the AD FS component to a file location that is accessible to the AD FS Server(s). Make sure users accounts are configured with appropriate authentication information.
Log on to the AD FS Server(s) with an account that has privileges to manage Active Directory Federation Services. Make sure you run the last steps of this HowTo on the AD FS Server that is the primary server, when the AD FS Farm leverages the Windows Internal Database (WID) as the AD FS configuration database.
Make sure the AD FS Servers are able to communicate with the centralized CensorNet SMS PASSCODE server over TCP port 20003 and/or TCP port 20004. Web Application Proxies don’t need a connection to the server, though.

How to install DIGIPASS Authentication for Microsoft ADFS

Follow these steps to install DIGIPASS Authentication for Microsoft AD FS:

Log on to the AD FS server.
Locate the DIGIPASS Authentication for Microsoft AD FS installation file. Execute the following command line in an elevated Command Prompt (cmd.exe) window to start installing DIGIPASS Authentication for Microsoft AD FS:

msiexec /i dp-auth-for-adfs_<version>_x64.msi

The DIGIPASS Authentication for Microsoft AD FS <version> window appears.

On the Welcome to the DIGIPASS Authentication for Microsoft ADFS Setup screen, click Next >.

On the License Agreement screen, select the I accept the terms in the license agreement option and click Next >.

Click Next > on the Destination Folder screen to accept the default installation location. Alternatively, you can change the destination folder.

On the Ready to Install the Program screen, click Install.
After successful installation, click Finish to exit the setup program.

How to configure DIGIPASS Authentication for Microsoft ADFS

After the initial installation, follow these steps to configure DIGIPASS Authentication for Microsoft AD FS:

After clicking Finish in the DIGIPASS Authentication for Microsoft AD FS <version> window, it closes and the DIGIPASS Authentication for Microsoft ADFS Configuration Wizard is started:

On the Configure DIGIPASS Authentication for Microsoft ADFS screen, click
Next >.

On the Specify the connection details screen, provide the IP address or DNS name of the OneSpan IDENTIKEY Authentication Server. The default TCP port is 20003 for non-TLS and 20004 for TLS connections. Press Next > afterward.

On the Specify the IP address screen, select an IP address from the drop-down list of IP addresses assigned to the current machine. The DIGIPASS Authentication Module will use the selected IP address exclusively.

Note:
As VASCO component licensing operates on IP address, this ensures that the DIGIPASS Authentication Module will only use up one component license slot.

On the Specify whether to create an IDENTIKEY client record screen, select the Create client record automatically option. Specify the credentials for the administrator login at the IDENTIKEY Authentication Server to register the DIGIPASS Authentication Module in the authentication server database.
Click Next >.

On the Specify license key screen, select a license.dat file that contains a license key for DIGIPASS Authentication for Microsoft ADFS.

Note:
You can skip to activate later, but multi-factor authentication using DIGIPASS Authentication for Microsoft ADFS will only succeed after a valid license key is entered.

On the Ready to complete DIGIPASS Authentication Module configuration screen, review the data in the Detail column, and click Finish when done.

How to Update DIGIPASS Authentication for Microsoft ADFS

When you’ve installed DIGIPASS Authentication for ADFS with the installer for a previous version, you can update the installation with the accompanying Microsoft update package (*.msp), using the following command line on an elevated Command Prompt window (cmd.exe):

msiexec /update dp-auth-for-adfs_<version>_x64.msp

How to enable Multi-factor Authentication through DIGIPASS Authentication for Microsoft ADFS

Follow these steps to enable Multi-factor Authentication through DIGIPASS Authentication for Microsoft ADFS:

Log on to the (primary) AD FS server.
Open the AD FS Management tool.
In the left navigation pane, select Authentication Policies.
In the right task pane, click on Edit Global Multi-factor Authentication… link.
Select DP4AuthADFS as additional authentication method if it’s not selected already.
To enable authentication for all external authentication, also select Extranet. Alternatively, specify multi-factor authentication per Relying Party Trust (RPT).
Click OK.

Concluding

Using the the Extensible Authentication Framework (EAF) in Active Directory Federation Services (AD FS) makes enabling multi-factor authentication a breeze.

Azure AD Connect Release Management

As described in the blogpost Leveraging Azure AD Connect Staging Mode for Release Management, Staging Mode can be leveraged to control updates for Windows Servers running Azure AD Connect in the following areas:

Hardware, drivers, firmware and integration components
Operating System version and patch level
Azure AD Connect version
Azure AD Connect rules
Azure AD Connect configuration

The process includes making changes to a Staging Mode Azure AD Connect installation and switching the actively synchronizing Azure AD Connect installation with the Staging Mode.

The situation

You have an Active Directory Domain Services (AD DS) environment, and you synchronize objects to an Azure AD tenant, leveraging Azure AD Connect, 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.

You have deployed at least two Azure AD Connect installations. Both Azure AD Connect installations use a local SQL Server Express database. (You do not use a centralized SQL Server to store the databases for these Azure AD Connect installations).

You leverage Azure AD Connect Staging Mode for release management. You follow the process to upgrade the Staging Mode Azure AD Connect installation to Azure AD Connect version 1.3.20.0, or up.

The issue

The Staging Mode Azure AD Connect installation has the Automatic Upgrades feature enabled. This breaks the process for Azure AD Connect Release Management.

The cause

This behavior is expected.

In the release notes for Azure AD Connect version 1.3.20.0 , the following line of information provides more information:

Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.

Admins who upgrade Azure AD Connect manually to version 1.3.20.0 and up, are notified on the Ready to configure screen of the Microsoft Azure Active Directory Connect wizard:

The Automatic Upgrades feature has been expanded throughout versions of Azure AD Connect to include more deployment scenarios. Currently, the only deployment scenario that blocks automatic upgrades is the scenario where Azure AD Connect is deployed using a SQL Server as the database.

The solution

To continue to leverage Azure AD Connect Staging Mode for release management, you need to disable the Automatic Upgrades feature, when upgrading to Azure AD Connect version 1.3.20.0, and up.

Perform the following two lines of Windows PowerShell on the Windows Server running Azure AD Connect after the initial upgrade beyond version 1.2.70.0:

Import-Module ADSync

Set-ADSyncAutoUpgrade Disabled

Concluding

Changes in Azure AD Connect functionality to allow for increased security levels (in this case by offering automatic upgrades to older and perhaps vulnerable versions of Azure AD Connect) may have an impact on processes setup in the past to maintain control over its release management.

On the plus side, we no longer have to update the issuance transformation rules in Active Directory Federation Services (AD FS) for the Microsoft Office 365 Identity Platform RPT, manually. It’s something.

About Azure AD licensing

Today, Azure Active Directory offers three subscription licenses; free, premium and premium P2. The plain ‘Premium’ licenses are commonly referred to as P1 licenses to distinguish them from the more elaborate and costly P2 licenses.

The table on the Azure Active Directory pricing page details the differences between the free, premium P1 and premium P2 subscription licenses.

Azure AD Premium P2 subscription licenses include Azure AD Premium P1 subscription licenses. Therefore, for any organization using a mix of these two licenses in their Azure AD tenant(s), it’s important to make sure any account is not both assigned an Azure AD Premium P1 subscription license and an Azure AD Premium P2 subscription license. Dynamic groups are useful to make this distinction within an Azure AD tenant.

About Dynamic Memberships for Groups

The first Azure AD feature we use in this scenario is the Dynamic Groups feature.
In Azure Active Directory, admins can create complex attribute-based rules to enable dynamic memberships for groups. Dynamic group memberships reduce the burden of adding and removing users to groups manually. You can set up a rule for dynamic membership on security groups and Office 365 groups.

The dynamic nature is delivered through continuous re-evaluation; when any attribute of a user or device changes, Azure AD evaluates all dynamic group rules to see if the change would trigger any group membership changes. If a user or device satisfies a rule on a group, they are dynamically added as a member of that group. If they no longer satisfy the rule, they are removed.

You can’t manually add or remove a member of a dynamic group.

About Assigning Licenses to Groups

The second Azure AD feature we use is the ability assign licenses to groups. This feature makes it super-easy to not just assign licenses to groups, but also report on licenses, based on the number of members of a aptly-named group. When used with Access Reviews, the possibilities seem endless.

Getting ready

For this scenario, I’ll assume you have an Azure AD tenant with both a registered Azure AD Premium P1 subscription and a registered Azure AD Premium P2 subscription.

Privileges

To perform the steps where we create a group below, you will need to sign in with an account that has the Global administrator role assigned. To perform the steps where we assign the license to the newly created group, the Global administrator role suffices, but the License administrator role is also good enough.

Getting the required information

To create the dynamic membership rules, we first have to get some information out of the Azure AD tenant.

Use the following lines of PowerShell on a system with the Azure AD PowerShell Module installed to get the Stock Keeping Unit (SKU) information on the available subscription licenses in the Azure AD tenant:

Get-AzureADSubscribedSku | select SkuId,SkuPartNumber | Format-Table

We need the SKU for the Azure AD Premium P2 subscription license. Copy the GUID for the ServicePlanID for the AAD_PREMIUM_P2 subscription license SKU. The GUID might be different between Azure AD tenants, depending on the way Azure AD Premium P2 subscription licenses are acquired, but it should look something like this:

eec0eb4f-6444-4f95-aba0-50c24d67f998

How to create the group to assign P2 licenses

The need for Azure AD Premium P2 licenses is based on a couple of scenarios:

User accounts for people who create, perform and/or finish Azure AD Access Reviews
Privileged accounts for admins who need to perform Privileged Identity Management (PIM) to gain access to their administrator roles
Admins who want to use the expanded Risk events and Risky users reports as part of Azure AD Identity Protection, admins who want to set risk-based Conditional Access policies in Azure AD Identity Protection and admins who want to require multi-factor authentication registration as part of Azure AD Identity Protection
Admins who want to use the Entitlement Management Public Preview features and other future Azure AD Identity Governance features

Create the group

Follow these steps to create the group in the Azure AD portal:

Sign in to the Azure portal using an account that has the Global administrator role assigned.
In the left navigation pane, click on (the icon of) Azure Active Directory.
In Azure AD’s navigation menu, click on Groups.
Click + New Group.
In the New Group pane, specify the following information:
- For Group Type select Security from the drop-down list
- As the Group name specify a group name that fits the organization’s naming convention
- Use the Group description to denote that this group assigns Azure AD Premium P2 licenses to its members
- As the Membership type select Assigned.
Click Members, select the user accounts in the Azure AD tenant that you want to assign Azure AD Premium P2 licenses.
Click the Select button at the bottom of the pane to return to the New Group pane.
Click the Create button at the bottom of the New Group pane.

Assign the P2 license

Perform these steps toand to assign Azure AD Premium P2 subscription licenses to its members in the Azure Portal:

In the left navigation pane, click on (the icon of) Azure Active Directory again.
In Azure AD’s navigation menu, click on Licenses.
In the Licenses menu, click on All Products.
Select Azure AD Premium P2 or a subscription license that includes Azure AD Premium P2 from the list of All products by clicking on the selection square in front of it.
Click + Assign.
In the Assign license pane, select Users and Groups.
Select the previously created security group.
When you assign a subscription license that includes Azure AD Premium P2 make the appropriate choices by:
- Click Assignment options in the Assign license pane.
- On the License options blade, make the appropriate choices.
- Click OK at the bottom of the blade.
Click the Select button at the bottom of the pane to go back to the Assign license pane.
Click the Assign button at the bottom of the Assign license pane.

How to create the group that assigns P1 licenses to other users without overlap

Now, let’s create the second group. This will be a group with dynamic user memberships. Perform these steps:

Create the group

Follow these steps to create the group in the Azure AD portal:

In the left navigation pane, click on (the icon of) Azure Active Directory.
In Azure AD’s navigation menu, click on Groups.
Click + New Group.
In the Group pane, specify the following information:
- For Group Type select Security from the drop-down list
- As the Group name specify a group name that fits the organization’s naming convention
- Use the Group description to denote that this group assigns Azure AD Premium P2 licenses to its members
- As the Membership type select Dynamic User.
Click Add dynamic query.
In the Dynamic membership rules pane, build a rule, by clicking + Add expression.
- In the And/or column select And from the drop-down list.
- In the Property column typeassignedPlans
- In the Operator column select Any from the drop-down list.
- In the Value column type(assignedPlan.servicePlanId -neq ” <PasteP2SKUHere> “)
Create any additional membership rules that you would like to apply, if you don’t want to assign Azure AD Premium P1 licenses to all users, but a more select set of users.
Click the Save button at the top of the Dynamic membership rules pane.
Click the Create button at the bottom of the New Group pane.

Assign the P1 license

Follow these steps to assign Azure AD P1 subscription licenses for users that do not have Azure AD Premium P2 subscription licenses assigned:

In the left navigation pane, click on (the icon of) Azure Active Directory again.
In Azure AD’s navigation menu, click on Licenses.
In the Licenses menu, click on All Products.
Select Azure AD Premium P1 from the list of All products.
Click + Assign.
In the Assign license pane, select Users and Groups.
Select the previously created security group.
Click the Select button at the bottom of the pane to go back to the Assign license pane.
Click the Assign button at the bottom of the Assign license pane.

Concluding

Using two features for Azure AD groups, we can create a strong solution to tackle the scenario to mutually exclusively assign Azure AD Premium P1 subscription licenses and Azure AD Premium P2 subscription licenses.

Hat Tip

Thanks to Daniel Stefaniak for his help tackling this scenario.

What’s Planned

Deprecation of the Power BI content packs

Service category: Reporting
Product capability: Monitoring & Reporting

Starting on October 1st, 2019, Power BI will begin to deprecate all content packs, including the Azure AD Power BI content pack. As an alternative to this content pack, admins can use Azure AD Workbooks to gain insights into their Azure AD-related services. Additional workbooks are coming, including workbooks about Conditional Access policies in report-only mode, app consent-based insights, and more.

For more information about the workbooks, see How to use Azure Monitor workbooks for Azure Active Directory reports.

What’s New

New custom roles are available for app registration management Public Preview

Service category: Role-based Access Control
Product capability: Access Control

Custom roles (available with an Azure AD P1 and P2 subscriptions) can now help provide admins with fine-grained access, by letting them create role definitions with specific permissions and then assign those roles to specific resources. Currently, admins create custom roles by using permissions for managing app registrations and then assigning the role to a specific app. For more information about custom roles, see Custom administrator roles in Azure Active Directory (preview).

New provisioning logs can help admins monitor and troubleshoot app provisioning deployment Public Preview

Service category: App Provisioning
Product capability: Identity Lifecycle Management

New provisioning logs are available to help admins monitor and troubleshoot the user and group provisioning deployment. These new log files include information about:

What groups were successfully created in ServiceNow
What roles were imported from Amazon Web Services (AWS)
What employees weren’t imported from Workday

New security reports for all Azure AD administrators General Availability

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

By default, all Azure AD administrators will soon be able to access modern security reports within Azure AD. Until the end of September, they will be able to use the banner at the top of the modern security reports to return to the old reports.

The modern security reports will provide additional capabilities from the older versions, including:

Advanced filtering and sorting
Bulk actions, such as dismissing user risk
Confirmation of compromised or safe entities
Risk state, covering: At risk, Dismissed, Remediated, and Confirmed compromised
New risk-related detections (available to Azure AD Premium subscribers)

User-assigned managed identity is available for Virtual Machines and Virtual Machine Scale Sets General Availability

Service category: Managed identities for Azure resources
Product capability: Developer Experience

User-assigned managed identities are now generally available for Virtual Machines and Virtual Machine Scale Sets. As part of this, Azure can create an identity in the Azure AD tenant that’s trusted by the subscription in use, and can be assigned to one or more Azure service instances.

New Federated Apps available in Azure AD App gallery

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

In August 2019, Microsoft has added these 26 new apps with Federation support to the app gallery:

What’s Changed

Users can reset their passwords using a mobile app or hardware token General Availability

Service category: Self Service Password Reset
Product capability: User Authentication

Users who have registered a mobile app with an organization can now reset their own password by approving a notification from the Microsoft Authenticator app or by entering a code from their mobile app or hardware token.

New versions of the AzureAD PowerShell and AzureADPreview PowerShell modules are available

Service category: Other
Product capability: Directory

New updates to the AzureAD and AzureAD Preview PowerShell modules are available:

A new -Filter parameter was added to the Get-AzureADDirectoryRole parameter in the AzureAD module. This parameter helps you filter on the directory roles returned by the cmdlet.
New cmdlets were added to the AzureADPreview module, to help define and assign custom roles in Azure AD, including:
- Get-AzureADMSRoleAssignment
- Get-AzureADMSRoleDefinition
- New-AzureADMSRoleAssignment
- New-AzureADMSRoleDefinition
- Remove-AzureADMSRoleAssignment
- Remove-AzureADMSRoleDefinition
- Set-AzureADMSRoleDefinition

Improvements to the UI of the dynamic group rule builder in the Azure Portal

Service category: Group Management
Product capability: Collaboration

Microsoft has made some User Interface (UI) improvements to the dynamic group rule builder, available in the Azure portal, to help admins more easily set up a new rule, or change existing rules. This design improvement allows them to create rules with up to five expressions, instead of just one. Microsoft has also updated the device property list to remove deprecated device properties.

New Microsoft Graph app permission available for use with access reviews

Service category: Access Reviews
Product capability: Identity Governance

Microsoft has introduced a new Microsoft Graph app permission, AccessReview.ReadWrite.Membership, which allows apps to automatically create and retrieve access reviews for group memberships and app assignments. This permission can be used by scheduled jobs or as part of automation, without requiring a logged-in user context.

Azure AD activity logs are now available for government cloud instances in Azure Monitor

Service category: Reporting
Product capability: Monitoring & Reporting

Microsoft is excited to announce that Azure AD activity logs are now available for government cloud instances in Azure Monitor. Organizations can now send Azure AD logs to storage accounts or to an event hub to integrate with SIEM tools, like Sumologic, Splunk, and ArcSight.

Update users to the new, enhanced security info experience

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

On September 25, 2019, Microsoft will be turning off the old, non-enhanced security info experience for registering and managing user security info and only turning on the new, enhanced version. This means that users in your organization will no longer be able to use the old experience.

Authentication requests using POST logins will be more strictly validated

Service category: Authentications (Logins)
Product capability: Standards

Starting on September 2, 2019, authentication requests using the POST method will be more strictly validated against the HTTP standards. Specifically, spaces and double-quotes (“) will no longer be removed from request form values. These changes aren’t expected to break any existing clients, and will help to make sure that requests sent to Azure AD are reliably handled every time.

What’s Fixed

ADAL.NET ignores the MSAL.NET shared cache for on-behalf-of scenarios

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

Starting with Azure AD authentication library (ADAL.NET) version 5.0.0-preview, app developers must serialize one cache per account for web apps and web APIs. Otherwise, some scenarios using the on-behalf-of flow, along with some specific use cases of UserAssertion, may result in an elevation of privilege. To avoid this vulnerability, ADAL.NET now ignores the Microsoft authentication library for dotnet (MSAL.NET) shared cache for on-behalf-of scenarios.

The post What’s New in Azure Active Directory for August 2019 appeared first on The things that are better left unspoken.

Hybrid Identity

In this part of the series, we’ll look at best practices to handle time synchronization on non-domain-joined Web Application Proxy servers.

Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations.

If your Web Application Proxy servers are domain-joined, the default Windows Time hierarchy takes care of time synchronization. Reasons to domain-join Web Application Proxies are:

Centralized management policies dictating every Windows Server is domain-joined
You want to publish web applications using Windows Integrated Authentication, leveraging Kerberos Constrained Delegation (KCD). (Web Application Proxies need to be joined to the same Active Directory domain as the AD FS Servers)

Most Web Application Proxy server implementations result in non-domain-joined servers, that’s because:

Most implementations need to adhere to a rule in the standards framework that internet-facing servers are not domain-joined or may not have a direct connection to the Internet (read: they need to be proxied). With the Web Application Proxy role acting both as an AD FS Proxy and a fancy reverse proxy, this role is caught in the middle.
Most frameworks dictate that Internet-facing servers need to be placed on a perimeter network (also known as a DMZ) and organizations are not too fond of opening up the perimeter network to the internal network, or the Domain Controller (virtual) network for all the UDP and TCP network ports that are necessary to domain-join Windows Servers.

Why look at time synchronization for Web Application Proxies

Hybrid Identity deployments are often long and costly implementations. As they are built using on-premises systems, they are intended to provide the functionality for the full duration of the economic lifetime of these systems (4-5 years).

Having reliable time throughout the Hybrid Identity implementation is important.

Possible negative impact (What could go wrong?)

When time synchronization is overlooked for Web Application Proxies, their time may drift. Depending on the amount of time drift, functionality breaks:

People will no longer be able to log on, when outside the organization’s network, due to time mismatches with AD FS Servers (resulting in token time-outs) and/or intervening load balancers.
Logs from Web Application Proxies will no longer bear proper time stamps.
Certificate errors may occur when certificate validity can no longer be evaluated reliably.
Web Application Proxies will no longer be able to get Windows Updates.

Some of this behavior can be detected in an easy way, as people will complain when their functionality is negatively impacted. Other symptoms may be overlooked, until it’s too late.

Three solutions for time synchronization

There are three solutions to reliably implement time synchronization for non-domain-joined Web Application Proxies:

Synchronize time with a reliable time source off the network
Synchronize time with a reliable time source on the network
Synchronize time with a hypervisor host
(in the case of virtualized Web Application Proxies)

Synchronize time with a reliable time source off the network

This solution takes clues from the default method any non-domain-joined Windows installation synchronizes time with time.windows.com.

time.windows.com may not be the most reliable time source on the Internet, but may just work and offer sufficiently reliable time. Most organizations opt to synchronize systems with pool.ntp.org, but my recommendations for this solution are to:

Use a combination of DNS names and IP addresses, to avoid failures in time synchronization during DNS outages and reduce the risk of DNS poisoning.
For this practice, it’s important to periodically check the validity of the IP addresses entered.
Open any necessary firewall ports for NTP (UDP 123) from the Web Application Proxy Server(s) to the designated time sources on the Internet.

Synchronize time with a reliable time source on the network

Many large organizations already have a GPS-backed NTP appliance on their network. Some have even equipped each of their datacenters with one. These appliances are placed on the perimeter network or offer their services from a shared network segment to all other network segments, including the perimeter network (DMZ).

When configuring time synchronization with the appliance, make a risk assessment to connect to the IP address or the DNS host name; in large organizations you might not get notified of changes to this particular piece of infrastructure and you might end up with faulty time synchronization. Again, when using IP addresses, it’s important to periodically check the validity of the IP addresses entered.

While GPS-based attacks do exist, there are currently no examples known of successful GPS spoofing attacks. When choosing a GPS-based appliance, it might be wise to include the requirement that countermeasures have been taken to prevent GPS spoofing attacks as laid out in the US Department of Homeland Security’s whitepaper “Improving the Operation and Development of Global Positioning System (GPS) Equipment Used by Critical Infrastructure” dated November 12, 2017.

Synchronize time with a hypervisor host

As discussed previously for VMware-based scenarios, virtual machines running as Web Application Proxy servers may benefit from time synchronization with vSphere hosts.

Hyper-V-based en XenServer-based virtual machines running as Web Application Proxy servers may benefit from time synchronization with their respective hypervisor hosts.

On the above situations, no network ports need to be opened between networks or even to the Internet. The Integration Components (known in the VMware world as VMware Tools) take care of the communication between the hypervisor host and the virtual machine running as Web Application Proxy server. Of course, the hypervisor hosts themselves need to synchronize time with a reliable time source, which may require expanded network connectivity.

Getting Ready

To handle time synchronization on non-domain-joined Web Application Proxies, make sure to meet the following requirements:

System requirements

Make sure the Web Application Proxies are installed with the latest cumulative Windows Updates. This makes sure they have the latest information on time zone changes.

Privilege requirements

Make sure to sign in with an account that has local administrator privileges on each of the Web Application Proxies. Your Web Application Proxies all have different local administrator passwords, right?

Network requirements

When synchronizing time with a reliable time source on the Internet or on the network, make sure the Web Application Proxies can reach the time source using UDP port 123. Open up firewalls to allow this traffic.

When synchronizing time with the hypervisor platform, make sure the hypervisor hosts can either independently reach the time source using UDP port 123, or make sure the Domain Controller holding the PDCe FSMO role for the Active Directory domain the Hyper-V hosts are a member of can reach the time source using UDP port 123.

Who to communicate to

As the Web Application Proxies operate in a process, notify all stakeholders in the process. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery (as Web Application Proxy don’t store any dynamic data, in some organizations these hosts are not part of regular backup jobs but are backed up using an on-demand job after changes).

How to do it

To handle time synchronization on non-domain-joined Web Application Proxies, perform these actions:

Synchronize time with a reliable time source

To synchronize time with a reliable time source, be sure to check the connection to the time host on the Internet or the internal network, then set it.

Checking the connection to the time source

Run the following line on the Command Prompt (cmd.exe), when logged on to the Web Application Proxy to test the pool.ntp.org address as a reliable time source:

w32tm.exe /stripchart /computer:pool.ntp.org /dataonly /samples:5

Perform the above command line for all DNS names and IP addresses you want to test as a reliable time source. This command also comes in handy when you want to evaluate the IP addresses you may or may not enter as reliable time sources.

Configuring Time Sources

Run the following two lines on the Command Prompt (cmd.exe), when logged on with an account that has local administrative privileges on the Web Application Proxy to set time sources:

w32tm.exe /config /manualpeerlist: “europe.pool.ntp.org time.nist.gov 192.43.244.18 193.67.79.202” /syncfromflags:manual /reliable:yes /update

net stop w32time && net start w32time

Make sure to separate any DNS names and IP addresses for the /manualpeerlist switch with a space. This is the appropriate way to set multiple time sources.

Note:
The above DNS names and IP addresses are for illustration purposes. They may not operate any longer.

Synchronize time with a hypervisor host

To synchronize time with the hypervisor host, install the integration components for the hypervisor platform on the virtual machine that operates as Web Application Proxy. This should be sufficient as default settings on all hypervisor platforms is to have virtual machines synchronize time with the hypervisor.

Concluding

Synchronize time with a reliable time source on non-domain-joined Web Application Proxies to avoid issues.

Related blogposts

Active Directory Time Sync (broken by default)
Managing Active Directory Time Synchronization on VMware vSphere

About the webinars

I feel webinars are a great way to show people the potential of technology. While for some people the pages in a book are all they need to get going, for others it’s really inspiring to see someone perform the actions live in front of their face. That’s why, together with Netwrix, we’ll demo the most enticing recipes from my Active Directory Administration Cookbook live, during three webinars, each with their specific focus on separate Identity topics:

Webinar 1, Securing Active Directory

Tuesday September 24th 2PM BST

Active Directory has evolved over the years, but many admins still treat it like the platform that it was in the Windows Server 2003 era. It’s time to look at the new security features that were introduced in Active Directory over the years and how you can put them to good use!

This mostly-demos webinar will showcase a couple of the new security features, straight from Chapter 10 of the Active Directory Administration Cookbook that you can use to up your organization’s security game. See for yourself what they offer (and what they don’t) and how your organization may benefit from you applying them in the right way.

You’ll see such features as:

Fine-grained password and account lockout policies
The Local Administrator Password Solution (LAPS)
The Active Directory Recycle Bin
Group Managed Service Accounts (gMSAs)
The Protected Users group

Bonus:
Discover how to quickly detect, report, and respond on security AD changes.

Webinar 2, Connecting Active Directory to Azure AD

Wednesday September 25th 2PM BST

Chapters 11 and 12 of the Active Directory Administration Cookbook focus on how to use Azure AD Connect to implementing and manage an Active Directory Federation Services (AD FS) farm for single sign-on to Azure Active Directory and Office 365.

Azure AD Connect is a versatile yet free tool from Microsoft to build the bridge between Active Directory and Azure Active Directory. It takes care of synchronization of objects between the two identity platforms and can configure authentication, too. While not widely known, Azure AD Connect is the perfect tool to set up an AD FS Farm, consisting of an AD FS Server (also known as a Security Token Service) and a Web Application Proxy. It automatically sets up the Relying Party Trust to Azure AD. When done, Azure AD Connect has a couple of tricks up its sleeve that you might want to take advantage of.

Uncover how to:

Set up Azure AD Connect with the right choices
Configure AD FS through Azure AD Connect
Federate an Azure AD domain
Easily update the AD FS certificate on all WAPs and AD FS servers
Verify federated logins
Reset the Azure AD trust, when needed

Bonus:
Gain insights in sign-ins both in Active Directory on-premises and Azure AD in one dashboard.

Webinar 3, Hardening Azure AD

Thursday September 26th 2PM BST

Following the examples of 90% of Fortune 500 companies, organizations are dipping their toes in the water when it comes to Azure Active Directory. However, the platform has been around for quite a while already and has seen some major security improvements that were not implemented to older tenants. Because it might break things. As new organizations start using Azure AD tenants and older tenants might want to take advantage of the new security features, it’s about time to start looking at them.

This webinar, based on the tips from Chapter 14 of the Active Directory Administration Cookbook, focuses on security measures you can take today with your organization’s Azure AD Premium or Microsoft 365 E3 licenses. Join this session and you will not have to doubt if you’ve made the right decisions when it comes to cloud and hybrid identity!

Learn how to apply:

Conditional Access
Application registration policies
Guest invitation settings
Portal access restrictions

Bonus:
Learn how to easily tracks and reports on security and configuration changes.

Join me!

Get inspired and attend the live sessions, or get access by the recordings if you cannot join online.

Note:
These webinars are offered free of charge, thanks to the sponsoring by Netwrix. By signing up for these webinars you agree to their privacy policy.

About Netwrix

Netwrix logo Netwrix is a private IT security software company. They offer IT auditing solutions for systems and applications across your IT infrastructure. Netwrix specializes in change, configuration and access auditing software with its Netwrix Auditor solution. Netwrix is a partner of Microsoft, VMware, EMC, NetApp and HP ArcSight.

If you’ve worked in highly-secure highly-regulated IT environments, you’re probably familiar with the Netwrix brand, because their Active Directory auditing solution is one of the best out there.

The post I’m presenting three Webinars with Netwrix focusing on the best recipes from the AD Administration Cookbook appeared first on The things that are better left unspoken.

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 June 2019:

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4509475 June 27, 2019

The June 27, 2019 update for Windows Server 2016 (KB4509475) updating the OS Build number to 14393.3056 does not include Identity-related fixes.

KB4503294 June 18, 2019

The June 18, 2019 update for Windows Server 2016 (KB4503294) updating the OS Build number to 14393.3053 includes the following Identity-related fixes:

It addresses an issue that returns an error when using certutil.exe to verify a certificate. The error is “Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)”.
It addresses an issue with using Data Protection Application Programming Interface NG (DPAPI-NG) or a group-protected Personal Information Exchange Format (PFX) file. Data you protected using one of these mechanisms on Windows 10, version 1607 and Windows Server 2016 or earlier cannot be decrypted using Windows 10, version 1703 or later.
It reinforces the Certificate Revocation List (CRL) on Internet Key Exchange version 2 (IKEv2) machines for certificate-based virtual private network (VPN) connections, such as Device Tunnel, in an Always On VPN deployment.
It addresses high latency Active Directory Federation Services (AD FS) response times for globally distributed datacenters that may have SQL servers in remote datacenters. This improves the performance for all token requests coming to ADFS, which includes OAuth, Saml, Ws-Fed, and Ws-Trust.
It addresses an issue that may cause a Lightweight Directory Access Protocol (LDAP) paged search against a Windows 2016 Domain Controller to fail. The error message is “00000057: LdapErr: DSID-0C090AB0, comment: Error processing control, data 0, v3839.”

KB4503267 June 11, 2019

The June 11, 2019 update for Windows Server 2016 (KB4503267) updating the OS Build number to 14393.3025 includes mainly security fixes.

Aside from the four zero-days, Microsoft patched 11 remote code execution (RCE) bugs, three of which are rated critical. CVE-2019-0620 and CVE-2019-0722 are a Hyper-V bug that could let an attacker run arbitrary code on the host operating system by running specially designed code in a guest OS. CVE-2019-0888 is a vulnerability in the way ActiveX Data Objects (ADO) handle objects in memory and could allow an attacker to compromise a machine by convincing a user to visit a specially crafted website.

There are also 9 RCEs rated critical for Microsoft Edge and Chakra Core, all of which are either memory corruption bugs or problems with the way objects are handled in memory. Some of these vulnerabilities also affect Internet Explorer.

This update also includes one Identity-related fix:

It addresses an issue that may cause authentication to fail when using Windows Hello for Business on Windows Server 2016 with the Server Core option installed.

This updates also introduces an Identity-related known issue:

Some applications may fail to run as expected on clients of Active Directory Federation Services 2016 (AD FS 2016) after installation of this update on the server. Applications that may exhibit this behavior use an IFRAME during non-interactive authentication requests and receive X-Frame Options set to DENY.

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4509479 June 26, 2019

The June 26, 2019 quality update for Windows Server 2019 (KB4509479) updating the OS Build number to 17763.593 doesn’t include Identity-related fixes.

KB4501371 June 18, 2019

The June 18, 2019 quality update for Windows Server 2019 (KB4501371) updating the OS Build number to 17763.592 includes one Identity-related fix:

It addresses an issue that triggers a Group Policy update even when there are no policy changes. This issue occurs when using the client-side extension (CSE) for folder redirection.

KB4503327 June 11, 2019

The June 11, 2019 quality update for Windows Server 2019 (KB4503327)updating the OS Build number to 17763.557

includes mainly security fixes.

The post On-premises Microsoft Identity-related updates and fixes for June 2019 appeared first on The things that are better left unspoken.

Windows Server

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4507459 July 16, 2019

The July 16, 2019 update for Windows Server 2016 (KB4507459) updating the OS Build number to 14393.3115 includes the following Identity-related fixes:

It addresses an issue that may prevent the Netlogon service from establishing a secure channel and reports the error, “0xC000007A – ERROR_PROC_NOT_FOUND.”
It addresses an issue that may prevent some applications from running as expected on clients of Active Directory Federation Services 2016 (AD FS 2016) after installing KB4493473 on the server. Applications that may exhibit this behavior use an IFRAME during non-interactive authentication requests and receive X-Frame Options set to DENY.
It addresses an issue that prevents Microsoft Application Virtualization (App-V) scripting from working if you run it when you’re not connected to a domain controller (DC). App-V scripting also fails when you run it in an environment that only contains Microsoft Azure Active Directory.

Unfortunately, it also introduces a known issue:

Devices connected to a domain that is configured to use MIT Kerberos realms may not start up or may continue to restart after installation of this update. Devices that are domain controllers or domain members are both affected.

KB4507460 July 9, 2019

The July 9, 2019 update for Windows Server 2016 (KB4507460) updating the OS Build number to 14393.3085 provides protections against a variant (CVE-2019-1125) of the Spectre Variant 1 speculative execution side channel vulnerability, along with other security updates.

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4505658 July 22, 2019

The July 22, 2019 update for Windows Server 2019 (KB4505658) updating the OS Build number to 17763.652 includes the following Identity-related fixes:

It addresses an issue that prevents the Windows Event Log service from processing notifications that the log is full. This causes issues with some Event Log behaviors such as archiving the log when it reaches a maximum file size and you’ve configured the “Archive the log when full, do not overwrite events” setting. Additionally, the Local Security Authority (LSA) cannot handle CrashOnAuditFail scenarios when the Security Log is full, and events cannot be written.
It addresses an issue that prevents a system from recognizing a Microsoft account or Azure Active Directory account until the user signs out and signs in again.
It addresses an issue that may prevent the Netlogon service from establishing a secure channel and reports the error, “0xC000007A – ERROR_PROC_NOT_FOUND.”
It addresses an issue that may cause authentication to fail when using Windows Hello for Business on a server running Windows Server 2016 with the Server Core option installed.
It addresses an issue that doesn’t update the personal identification number (PIN) policy (minimum length, required digits, special characters, and so on) for Windows Hello for Business when a PIN already exists on the machine.
It reinforces the Certificate Revocation List (CRL) on Internet Key Exchange version 2 (IKEv2) machines for certificate-based virtual private network (VPN) connections, such as Device Tunnel, in an Always On VPN deployment.
It addresses an issue that prevents Microsoft Application Virtualization (App-V) scripting from working if you run it when you’re not connected to a domain controller (DC). App-V scripting also fails when you run it in an environment that only contains Microsoft Azure Active Directory.
It addresses an issue that exhausts User Datagram Protocol (UDP) ports on several hundred machines in a forest when there is very high Domain Controller Locator traffic. As a result, servers stop responding.

KB4507469 July 9, 2019

The July 9, 2019 update for Windows Server 2019 (KB4507469) updating the OS Build number to 17763.615 provides protections against a variant (CVE-2019-1125) of the Spectre Variant 1 speculative execution side channel vulnerability, along with other security updates.

The post On-premises Microsoft Identity-related updates and fixes for July 2019 appeared first on The things that are better left unspoken.

Speaking at User Groups (picture by Rick van den Bosch)

On Thursday evening October 3rd, 2019, I’ll deliver a 55-minute presentation together with Raymond Comvalius for the Dutch Windows Azure User Group (WAZUG) on Password-less authentication.

About WAZUG.nl

WAZUG logo (cloud only) The Dutch Windows Azure User Group (WAZUG) was founded in 2010 by a group of enthusiasts to inform and inspire developers, architects and consultants for Microsoft’s cloud application platform: Azure.

WAZUG organizes events roughly every month. They invite speakers to talk about technology, but also about reference cases. It’s also an ideal way to meet like-minded people and network. Meetings, food and drinks are always free to attendees.

WAZUG, these days, is run by Iwan Bel, Erwyn van der Meer, Edward Bakker and Steef-Jan Wiggers.

About WAZUG.nl 60

Meeting 60 is organized with the help of Ordina, a Dutch IT services provider in terms of managed ICT services, IT solutions and software engineering. They invited us over at their headquarters in Nieuwegein, the Netherlands.

In contrast to earlier WAZUG.nl meetings, WAZUG.nl 60 has an IT Pro focus.

The evening kicks off at 6PM with dinner. After a short welcoming ceremony, Raymond and I will present for 55 minutes. After a short break, a second session is presented. After the second session, there’s room and time for drinks up until 9:15PM.

About our presentation

Between 6:35PM and 7:30PM, we’ll deliver a 55-minute session on Password-less:

Password-less; day-to-day passwords be gone!

Microsoft’s marketing machine is abuzz to promote the latest and greatest for identity and access management: Password-less.

Raymond and I will show the ins and outs of Windows Hello for Business, Single Sign-on, Azure Active Directory and FIDO2. By leveraging these technologies, we can protect end-users from the troubles surrounding leaked, cracked, phished and eavesdropped credentials.

Looking under the hood, we make clear how password-less answers the question on how to deal with day-to-day passwords and finally brings light to the long dark tunnel we’ve stepped into when we embraced passwords in the mainframe-era.

Join us!

Join us for free.
If you haven’t yet, sign up to the Dutch Windows Azure User Group using a Microsoft account, and then register for this WAZUG event.

The post I’m co-presenting at WAZUG NL 60 appeared first on The things that are better left unspoken.

Hybrid Identity

In this part of the series, we’ll look at best practices to handle Windows activation on non-domain-joined Web Application Proxy servers.

Note:
This blogpost assumes you’re running Web Application Proxies as non-domain-joined Server Core Windows Server 2016 installations.

If your Web Application Proxy servers are domain-joined, you can use Active Directory-based activation to take care of Windows activation. However, this option can’t be used for Web Application Proxy servers that are non-domain-joined and/or placed on a perimeter network (also commonly referred to as a DMZ network).

Why look at Windows Activation for Web Application Proxies

Having activated Windows Server installations throughout the Hybrid Identity implementation is important.

Possible negative impact (What could go wrong?)

When Windows Server is not properly activated, recurring notifications will be shown.

Technically, functionality will not be reduced on non-activated Windows Servers, when installed with Volume License (VL) installation media. Windows Server 2016 will reboot every hour, disable certain services and show EventID 5074 on installations performed with Evaluation media.

More importantly, non-activated servers typically point to a rather casual attitude towards licensing. From a business continuity perspective it would make since to strictly adhere to the product use rights. Through audits, license incompliance might be discovered and measures may be taken, not just financially.

Four solutions for Windows Activation

There are four solutions to activate non-domain-joined Web Application Proxies:

Activate using KMS Hosts
Activate using Host-based Activation (for Hyper-V virtual machines only)
Activate using MAK and an Internet connection
Activate using MAK and the phone

How to do it

To activate non-domain-joined Web Application Proxy servers, perform these actions, per scenario:

Activate using KMS Hosts

Note:
This method will not work with Web Application Proxies that are installed using retail media.

Key Management Services (KMS) is a way to manage Windows Activation centrally for a networking infrastructure. Installations of Windows Server 2016 with Volume License (VL) media are the first installations of a released Microsoft Windows Server product that are not configured by default with a KMS client key since a long time (as opposed to Windows Server 2008, 2008 R2, 2012 and 2012 R2). Therefore, in the KMS scenario, the following requirements need to be met:

A working KMS host
Ideally: DNS-based name resolution for each of the Web Application Proxies to locate KMS.
Network connectivity from each of the Web Application Proxies to the KMS host
A KMS-based Volume License activation key (GVLK) entered as the product key in each Web Application Proxy, followed by the activation command.

If you haven’t already configured a KMS host, see the Microsoft documentation on Deploy KMS Activation for steps to set multiple of these servers up.

Note:
KMS Hosts running Windows Server 2008 R2, or earlier versions of Windows Server cannot be used as KMS hosts to activate Windows Server 2016 and beyond.

By default, KMS uses DNS SRV records to locate KMS hosts. Multiple SRV records allow for high-availability of the KMS functionality. However, one KMS can be assigned to a Web Application Proxy using the following command line:

slmgr.vbs /skms KMSHostOrIPAddress:1688

If using an IPv6 address to denote the KMS host, specify the address using square brackets. TCP 1688 is used by default for KMS hosts, but this port can be changed.

To test discovery of KMS hosts through DNS on Web Application Proxies, use the following line of Windows PowerShell on each of the Web Application Proxies:

Resolve-DnsName -Name _vlmcs._tcp -Type SRV -DNSonly

Note:
The Resolve-DnsName cmdlet will return a maximum of 25 records from DNS servers.

To test network connectivity between the Web Application Proxy and the KMS Host, perform the following line of Windows PowerShell on each of the Web Application Proxies:

Test-NetConnection -ComputerName KMSHostOrIPAddress -Port 1688

TCP 1688 is used by default for KMS hosts, but this port can be changed.

Activate each Web Application Proxy, by running the following two command lines on each server:

slmgr.vbs /ipk <PRODU-CTKEY-4WIND-NWSSE-RVERS>

slmgr.vbs /ato

Change the above product key for the specific product license key for the Operating System SKU that was used to install the Web Application Proxy servers. It differs between Standard Edition and Datacenter Edition. All GVLKs can be found in the Microsoft Documentation on KMS client setup keys.

Alternatively, KMS GVLKs can be configured centrally and Web Application Proxy servers can be activated centrally using the Volume Activation Management Tool (VAMT).

Activate using Host-based Activation (for Hyper-V virtual machines only)

Note:
This method will not work with Web Application Proxies that are installed using retail media.

When your Web Application Proxy hosts run as virtual machines on top of Hyper-V, you can take advantage of the Automatic Virtual Machine Activation (AVMA) feature.

To use this feature, the Hyper-V hosts that run the virtualized Web Application Proxies need to:

Run Windows Server 2012 R2, or up
Run the Datacenter Edition of Windows Server
Be properly activated themselves

When you meet these requirements, every virtual machine deployed to these Hyper-V hosts will be activated automatically, when they are configured with the Windows Server 2016 GVLK. When you use volume license media to install the Windows Server 2016-based Web Application Proxies, there is no additional required action.

Activate using MAK and an Internet connection

Another Volume License activation method for Windows Serer 2016 is to use Multiple Activation Keys (MAKs). The default activation method for MAKs is over the Internet to Microsoft’s datacenters.

This activation method requires access to the Internet addresses mentioned in Microsoft KnowledgeBase article 921471 to avoid error 0x8004FE33.

Activate each Web Application Proxy, by running the following two command lines on each server to enter the MAK:

slmgr.vbs /ipk <PRODU-CTKEY-4WIND-NWSSE-RVERS>

slmgr.vbs /ato

Alternatively, MAKs can be configured centrally and Web Application Proxy servers can be activated centrally using the Volume Activation Management Tool (VAMT). When VAMT is used for MAK Proxy Activation, only the device running VAMT needs an Internet connection.

Activate using MAK and the phone

When an Internet connection is out of the question on the perimeter network, phone activation is still available.

Obtain the Windows Server installation ID, using the following command line:

slmgr.vbs /dti

Write it down.

Run the following command line on the Web Application Proxy to show phone number information:

notepad.exe C:\Windows\system32\SPPUI\Phone.inf

Write down the nearest or most convenient number from the document.

Close the Notepad window.

Call the phone number and follow the prompts to obtain the confirmation ID.

Apply the confirmation ID (without the hyphens) using the following command line:

slmgr.vbs /atp VeryLongStringThatRepresentsTheConfirmationID

Testing proper activation

Check proper activation using the following command line:

slmgr.vbs /dlv

Concluding

Make sure Web Application Proxies remain functional beyond the default trial period, by activating their Windows Server installations.

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4512495 August 17, 2019

The August 17, 2019 update for Windows Server 2016 (KB4512495) updating the OS Build number to 14393.3181 includes the following Identity-related fixes:

It addresses an issue that prevents some users from receiving a TTL value when they are added as members of Shadow Principals. This occurs for users who have distinguished names (DN) that contain an escape character. The TTL value is now added as expected.
It addresses an issue that may break the domain trust when the Recycle Bin is configured on the domain that carries the trust.

KB4512517 August 13, 2019

The August 13, 2019 update for Windows Server 2016 (KB4512517) updating the OS Build number to 14393.3144 plugs RDP vulnerabilities that are rated ‘Critical’. It includes the following Identity-related fixes:

It addresses an issue that may prevent devices from starting up or cause them to continue restarting if they are connected to a domain that is configured to use MIT Kerberos realms. Domain controllers and domain members are both affected.

This is the issue that was introduced with KB4507459, dated July 16, 2019.

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4512534 August 17, 2019

The August 17, 2019 non-security update for Windows Server 2019 (KB4512534) updating the OS Build number to 17763.720 includes the following Identity-related fixes:

It addresses an issue that causes a workstation to stop working when you sign in using an updated user principal name (UPN) (for example, changing UserN@contoso.com to User.Name@contoso.com).
It addresses an issue that prevents some users from receiving a TTL value when they are added as members of Shadow Principals. This occurs for users who have distinguished names (DN) that contain an escape character. The TTL value is now added as expected.
It addresses an issue that may break the domain trust when the Recycle Bin is configured on the domain that carries the trust.

KB4511553 August 13, 2019

The August 13, 2019 update for Windows Server 2019 (KB4511553) updating the OS Build number to 17763.638

plugs RDP vulnerabilities that are rated ‘Critical’. It includes the following Identity-related fixes:

It addresses an issue that may prevent devices from starting up or cause them to continue restarting if they are connected to a domain that is configured to use MIT Kerberos realms. Domain controllers and domain members are both affected.

The post On-premises Microsoft Identity-related updates and fixes for August 2019 appeared first on The things that are better left unspoken.

Virtualizing Domain Controllers

After detailing Active Directory Virtualization Safeguards with VM-GenerationID in part 5 of this series on Virtualizing Domain Controllers on vSphere, it’s time to talk about the second Active Directory Domain Services feature that is enabled through the VM-GenerationID technology: Domain Controller cloning.

About Domain Controller cloning

Microsoft recommends not re-using Domain Controllers for other roles. When sticking with this recommended practice, Domain Controllers running the same Windows Server version in your environment are 99% identical.

In many large organizations, however, deploying an additional Domain Controller, even a virtual one, is a change that might span weeks. After the initial installation and promotion, multiple agents, additional software and tweaks need to be performed to make it a full family member of the Domain Controllers OU.

By leveraging the values for the VM-GenerationID in vRAM and in the Active Directory database (not replicated), a Domain Controller can see when its virtual hard disk is being re-used for another Domain Controller.

When properly prepared, the essential files for Domain Controller cloning, then, instruct the virtual Domain Controller to clone. Specifically, only the situation in which you want a Domain Controller to clone, will lead to cloning. All other situations will lead to booting into Directory Services Restore Mode (DSRM).

Domain Controller cloning enables fast, safer Domain Controller provisioning through clone operations. These operations include regular VM cloning and manual VMDK copy operations.

Note:
VMware Converter’s Hot cloning feature is not supported with Domain Controller cloning. The ‘cloning’ name overlay is purely coincidental.

Situations where Domain Controller cloning isn’t beneficial

There are a couple of situations where Domain Controller Cloning isn’t beneficial:

When you want to promote a Domain Controller in a remote location with limited bandwidth. When the remote location features a virtualization host and a VM template for the desired Windows Server version, it’s more beneficial to perform an Install from Media (IfM) installation. This is especially true when copying over the virtual hard disk of a cloneable Domain Controller might take longer to transfer than 60 days (the pre-Windows Server 2003 SP1 tombstone lifetime period).
When the agents and the software you install on Domain Controllers to make them fully functional isn’t cloneable and, thus, breaks Domain Controller cloning.

Requirements

The list of requirements to allow Domain Controller cloning starts with the requirements for VM-GenerationID, as shared earlier:

VMware vSphere needs to run version 5.0 update 2, or up.
VMware tools need to be installed and running on virtual Domain Controllers, ideally with a version that matches the VMware vSphere version.
The virtual Domain Controller needs to run Windows Server 2012, or up.
The Virtual Machine hardware version needs to be version 7, or up.

On top of these requirements, Domain Controller cloning adds additional requirements:

At least one Windows Server 2012-based Domain Controller (or a newer version of Windows Server) needs to be configured to host the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role. This change should be replicated to all Domain Controllers in affected Active Directory sites.
The Domain Controller holding the RID Master FMSO role needs to be available during the cloning process.
DNS needs to be available during the cloning process.
The reference Domain Controller cannot be a Read-only Domain Controller.
The reference Domain Controller needs to be a member of the Cloneable Domain Controllers security group in Active Directory or needs to be granted the DS-Clone-Domain-Controller extended right.
The reference Domain Controller cannot be assigned Managed Service Accounts (MSAs), unless these accounts are group Managed Service Accounts (gMSAs).
A CustomDCCloneAllowList.xml and DCCloneConfig.xml file needs to be available to the cloned Domain Controller in the root of a removable drive or in the folder of the Active Directory database (by default: C:\Windows\NTDS)
Applications that are incompatible with cloning should be uninstalled or added to CustomDCCloneAllowList.xml.

To be able to clone a Virtual Machine in vSphere, you must have the following privileges within the vSphere infrastructure:

Virtual machine .Provisioning.Clone virtual machine permissions on the virtual machine you are cloning.
Virtual machine .Inventory.Create from existing permissions on the datacenter or virtual machine folder.
Virtual machine.Configuration.Add new disk permissions on the datacenter or virtual machine folder.
Resource.Assign virtual machine to resource pool permissions on the destination host, cluster, or resource pool.
Datastore.Allocate space permissions on the destination datastore or datastore folder.
Network.Assign network permissions on the network to which the virtual machine will be assigned.
Virtual machine .Provisioning.Read customization specifications permissions on the root vCenter Server if you are customizing the guest operating system.

Recommended practices

Having performed Domain Controller cloning in large environment and in many demos, please adhere to these practices:

Leave the Cloneable Domain Controllers security group in Active Directory empty in-between clone operations.
Inventory and validate all software and agents, services and applications on the reference Domain Controller before cloning.

Note:
VMware Tools is validated and works with Domain Controller cloning.

Always shutdown the reference Domain Controller prior to cloning.
Ensure that the reference Domain Controller holds no Flexible Single Master Operations (FSMO) role.

When creating many clones from one reference Domain Controller, please:

Don’t use -CloneComputerName or -Static -IPv4Address in the dccloneconfig.xml file, as this results in clones with the same hostname and/or IPv4 address.
Ensure that the Dynamic Host Configuration Protocol (DHCP) service is functional in the infrastructure. The information specified in DcCloneConfig.xml should be unique. When a duplicate or invalid computer name is specified, when an IP address conflict is detected, when IP and DNS information is left out and there is no DHCP Server on the network, when only one WINS Server address is specified or when a typo is made in the Active Directory site name, Domain Controller Cloning will halt.
Don’t turn on the reference Domain Controller, until all mass cloning operations have finished. Alternatively, convert the first clone to a template and deploy new Domain Controllers from this template, but remember that this template is only re-useable for the duration of the Tombstone Lifetime.

How to clone a Domain Controller on vSphere

Perform these steps to clone a reference Domain Controller that is running as a virtual machine on VMware vSphere, resulting in a cloned Domain Controller, also running as a virtual machine on VMware vSphere:

1. Add the reference Domain Controller to the Cloneable Domain Controllers group

To add the reference Domain Controller to the Cloneable Domain Controllers security group, use the following PowerShell one-liner:

Add-ADGroupMember -Identity “Cloneable Domain Controllers” -Members “cn=dc01,ou=Domain Controllers,dc=domain,dc=tld”

Note:
You can run the above command on the reference Domain Controller when signed in, from another Domain Controller or any domain-joined device with the Active Directory Module for Windows PowerShell installed that you’re signed into with credentials that allow management of the security group. In the latter two cases, make sure the change is replicated throughout the Domain Controllers holding the PDCe FSMO role and the RID Master Role and the reference Domain Controller.

2. Resolve Service Principal Name (SPN) issues

run Get-ADServiceAccount on the reference Domain Controller, to get the list of Service Principal Names in use. To remove the Service accounts automatically, use the following PowerShell one-liner:

Get-ADServiceAccount –filter:“*” | Remove-ADServiceAccount

3. Resolve problems with non-cloneable applications, agents and services

You would typically run the Get-ADDCCloningExcludedApplicationList PowerShell Cmdlet to get a list of the programs and services blocking successful Domain Controller Cloning. The following PowerShell one-liner can be used to automatically create the CustomDCCloneAllowList.xml file in C:\Windows\NTDS:

Get-ADDCCloningExcludedApplicationList -GenerateXml -Path C:\Windows\NTDS -Force

4. Create the DCCloneConfig file

At this stage, run the New-ADDCCloningConfigFile PowerShell Cmdlet. You do not need to specify any parameters if you don’t want to.

When you don’t add any parameters, this Cmdlet will create the cleanest of DCCloneConfig.xml files in the Active Directory database path. This specific file will use the following Domain Controller Cloning configuration:

The target Domain Controller will be assigned IP-addresses through DHCP.
The target Domain Controller name will be automatically generated.
The target Domain Controller will be assigned the same Active Directory site as the reference Domain Controller.

If you want to specify a host name, Active Directory site or IP addressing information, a sample PowerShell one-liner would look like:

New-ADDCCloneConfigFile –CloneComputerName “DC02” –SiteName “ADSite01” -Static –IPv4Address “10.0.1.2” –IPv4SubnetMask “255.255.255.0” -IPv4DefaultGateway “10.0.1.1” -IPv4DNSResolver “10.0.0.2”

5. Shut down the reference Domain Controller

Now, shut down the Domain Controller, from within Windows Server. For instance, with the following PowerShell one-liner:

Stop-Computer

6. Clone the reference Domain Controller from vCenter

Perform these steps to clone the reference Domain Controller:

Open and log into the VMware vSphere or or vSphere Web Client.
Locate the virtual machine you wish to clone in the inventory.
Right-click the virtual machine and select Clone and then Clone to Virtual Machine from the context menu.
On the Select a name and folder page, enter a unique name for the clone Domain Controller and select a deployment location.
Click Next.
On the Select a compute resource page, select the host, cluster, resource pool, or vApp where the clone Domain Controller will run.
Click Next.
On the Select storage page, select the datastore or datastore cluster in which to store the template configuration files and all of the virtual disks.
Click Next.
On the Select deploy options page, do not select additional customization options for the clone Domain Controller.
On the Ready to complete page, review the virtual machine settings and click Finish.

After the clone operation succeeds, the clone Domain Controller appears in the inventory. Start it.

Start the reference Domain Controller when cloning completes, or use it as a template Domain Controller for the period that is maximized by the Active Directory Tombstone Lifetime.

Concluding

Domain Controller Cloning is useful when you want to create a replica Domain Controller fast.

Of course, you can use it to quickly create an extra Domain Controller when the current Domain Controllers are burdened, but you can also use it as a Disaster Recovery method. More on that in the next blogpost in this series.

Highlights

The headline for this release is the refinement of the AD FS management tasks:

Enabled six federation management tasks for all sign-in methods in Azure AD Connect. (Previously, only the “Update AD FS SSL certificate” task was available for all sign-ins.)
Removed token-signing certificates from the “Reset Azure AD and AD FS trust” task and added a separate sub-task to update these certificates.
Added a new federation management task called “Manage certificates” which has sub-tasks to update the SSL or token-signing certificates for the AD FS farm.
Added a new federation management sub-task called “Specify primary server” which allows administrators to specify a new primary server for the AD FS farm.
Added a new federation management task called “Manage servers” which has sub-tasks to deploy an AD FS server, deploy a Web Application Proxy server, and specify primary server.
Added a new federation management task called “View federation configuration” that displays the current AD FS settings. (Because of this addition, AD FS settings have been removed from the “Review your solution” page.)

What’s New

However, this release of Azure AD Connect contains many more new features and improvements:

New troubleshooting tooling helps troubleshoot the following scenarios:

“user not syncing”
“group not syncing”
“group member not syncing”

Support for national clouds in the Azure AD Connect troubleshooting script
The deprecated WMI endpoints for MIIS_Service have now been removed. Any WMI operations should now be done via the Windows PowerShell cmdlets.
Security improvement by resetting constrained delegation on AZUREADSSOACC object
When adding and/or editing a synchronization rule, if there are any attributes used in the rule that are in the connector schema but not added to the connector, the attributes are automatically added to the connector. The same is true for the object type the rule affects. If anything is added to the connector, the connector will be marked for full import on the next synchronization cycle.
Using an account that is a member of the Enterprise admins or Domain admins security group as the connector account is no longer supported.
In the Synchronization Manager, a full sync is run when a synchronization rule is created, edited and/or deleted. A popup appears on any rule change, notifying the admin if full import or full sync is going to be run.
New mitigation steps for password errors to the ‘connectors > properties > connectivity’ page
New deprecation warning for the sync service manager on the connector properties page. This warning notifies the admin that changes should be made through the Azure Active Directory Connect wizard.
New error definition for issues with a user’s password policy.
Prevent misconfiguration of group filtering by domain and OU filters. Group filtering will show an error when the domain and/or OU of the entered group is already filtered out and keep the admin from moving forward until the issue is resolved.
Admins can no longer create a connector for Active Directory Domain Services or Azure Active Directory in the old User Interface.
Fixed accessibility of custom UI controls in the Sync Service Manager
New warning when changing the sign-in method from federation to Password Hash Synchronization (PHS) or Pass-through Authentication (PTA), that all Azure AD domains and users will be converted to managed authentication.

What’s Fixed

The following issues in Azure AD Connect have been resolved:

Resolved a synchronization error issue for the scenario where a user object taking over its corresponding contact object has a self-reference (e.g. user is their own manager).
Help popups now show on keyboard focus.
For automatic upgrades, if any conflicting app is running from 6 hours, kill it and continue with upgrade.
Limit the number of attributes a customer can select to 100 per object when selecting directory extensions. This will prevent the error from occurring during export as Azure has a maximum of 100 extension attributes per object.
Fixed a bug to make the Active Directory Connectivity script more robust
Fixed a bug to make Azure AD Connect install on a machine using an existing Named Pipes WCF service more robust.
Improved diagnostics and troubleshooting around group policies that do not allow the ADSync service to start when initially installed.
Fixed a bug where the display name for a Windows computer was written incorrectly.
Fix a bug where the OS type for a Windows computer was written incorrectly.
Fixed a bug where non-Windows 10 computers were syncing unexpectedly. Note that the effect of this change is that non-Windows-10 computers that were previously synced will now be deleted. This does not affect any features as the sync of Windows computers is only used for Hybrid Azure AD domain join, which only works for Windows-10 devices.
Added several new (internal) cmdlets to the ADSync PowerShell module.

Version information

This is version 1.4.x.0 of Azure AD Connect.
The first release in the 1.4 branch for Azure AD Connect was made available for download on September 10, 2019.

The post Azure AD Connect version 1.4 introduces refined AD FS Management Capabilities appeared first on The things that are better left unspoken.

Why harden

Reasons why

Possible negative impact (What could go wrong?)

Getting Ready

System requirements

Privilege requirements

Who to communicate to

Determining weak protocols, cipher suites and hashing algorithms

Protocols

Cipher suites and hashing algorithms

Protocols, cipher suites and hashing algorithms and the negotiation order to use

How to disable weak protocols

Enable TLS 1.2

Disable TLS 1.0 and TLS 1.1

How to disable weak ciphers and algorithms

Testing proper hardening

Rolling Back Hardening

Concluding

Further reading

Why harden AD FS Servers

Reasons why

Possible negative impact (What could go wrong?)

Getting ready

System requirements

Privilege requirements

Who to communicate to

Unnecessary AD FS Endpoints

IdP-Initiated Sign-On endpoint

Windows Transport Endpoint

How to disable unnecessary AD FS endpoints

Testing proper hardening

Rolling back hardening

Concluding

What’s Planned

Application Proxy service update to support only TLS 1.2

Design updates are coming for the Application Gallery

Removal of the MFA server IP address from the Office 365 IP address

What’s New

New passwordless sign-in to Azure AD using FIDO2 security keys

New Federated Apps available in Azure AD App gallery

Automate user account provisioning for these newly supported SaaS apps

New Azure AD Domain Services service tag for Network Security Group

New Security Audits for Azure AD Domain Services Public Preview

New Authentication methods usage & insights Public Preview

New security reports are available for all Azure AD administrators Public Preview

New Security Audits for Azure AD Domain Services Public Preview

New B2B direct federation using SAML/WS-Fed Public Preview

New check for duplicate group names in the Azure AD portal

Azure AD now supports static query parameters in reply (redirect) URIs

Activity logs (MS Graph APIs) for Azure AD are now available through PowerShell Cmdlets

Updated filter controls for Audit and Sign-in logs in Azure AD

What’s Fixed

App-only tokens now require the resource application (Web API) to exist in the resource tenant

Active Directory replication

Components of Active Directory replication

The Directory Service Agent GUID

The InvocationID

Update Sequence Numbers

Timestamps

Replication types

Intra-site replication

Inter-site Replication

Challenges with Active Directory Replication

USN Rollbacks

Lingering Objects

Recommendations

Design for replication

Apply the defaults

Take advantage of new features

Monitor Active Directory replication

Don’t revert Domain Controllers to snapshots

Don’t restore Domain Controllers beyond the Tombstone Lifetime

Get rid of lingering objects

Concluding

Further reading

Why enable auditing on AD FS Servers

Reasons why

Possible negative impact (What could go wrong?)

Getting ready

Information requirements