Active Directory Virtualization Safeguards with VM-GenerationID on VMware vSphere

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

Virtualizing Domain Controllers

Arriving at the fifth part of this series on Virtualizing Domain Controllers on vSphere, I managed to gather some feedback on these blogposts. One question that emerged after writing the last blogpost on Replication considerations for Domain Controllers running on VMware vSphere was:

Isn’t Windows Server 2012 supposed to solve all these challenges with virtualizing Domain Controllers?

That’s an interesting question. Some Active Directory admins might respond with their knee-jerk “It depends.” response. There are a couple of other variables out there that have impact on the integrity of the Active Directory database: We’ve discussed time differences in Part 2, and the default replication settings, the tombstone lifetime, DFSR and the Active Directory Recycle Bin in Part 3. Now, let’s look at the Active Directory Virtualization Safeguards and the underlying VM-GenerationID and when they help, and the situation in which they don’t. As usual, you’ll find a list of recommendations at the end of this blogpost.

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

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

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 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

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.

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.

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.

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.

Posted on August 9, 2019 by Sander Berkouwer in Azure Active Directory, What's New

HOWTO: Disable unnecessary AD FS endpoints

This entry is part 6 of 7 in the series Hardening Hybrid Identity

Hybrid Identity

In this part of the series, we’ll harden the AD FS Server installations, by disabling unnecessary endpoints they offer.

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

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

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.

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.

Posted on August 6, 2019 by Sander Berkouwer in Active Directory, Active Directory Federation Services, Azure Active Directory, Security

HOWTO: Disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect

This entry is part 5 of 7 in the series Hardening Hybrid Identity

Hybrid Identity

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

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

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

Secure connections over the Internet are commonly encrypted. The protocol, cipher suite and hashing algorithm are negotiated to make sure both ends of the communications channel can understand what’s being interchanged encrypted. In most cases, this would result in the strongest protocol, cipher suite and hashing algorithm being used.

However, for communications containing personally identifiable information (PII data) or information on data subjects, more guarantees are needed. A common mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA), would be to force the component responsible for interchanging this data to use the strongest protocol, cipher suite and hashing algorithm.

This is exactly what the topic is for today: Making sure Azure AD Connect interchanges information on the TLS 1.2 protocol only.

Possible negative impact (What could go wrong?)

When an Azure AD Connect installation is hardened improperly, it may stop synchronizing objects from Active Directory to Azure Active Directory. Synchronization cycle occur every 30 minutes, by default. So you may not get events indicating something is wrong in Event Viewer right away.

When synchronization stops or is partial, the most apparent problem is that colleagues will start experiencing lack of functionality; When they get married, their name change is not reflected everywhere. When they get added to a group, they don’t gain access to cloud applications. When they change or reset their password, it’s not reflected, or they receive a “Something went wrong” error, etc.

However, things get tricky when people are laid off on the spot. In these situations, it’s important that the user account is disabled, stripped from permissions and/or removed throughout all systems as soon as possible.

Getting Ready

To enforce Azure AD Connect to use TLS 1.2 only, make sure to meet the following requirements:

System requirements

Make sure the Windows Server installations 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 you are signed in with an account that has local administrative privileges on the Windows Server(s) running Azure AD Connect.

Who to communicate to

When intending to make changes to Azure AD Connect installations, 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

How to enforce Azure AD Connect to use TLS 1.2 only

To enforce Azure AD Connect to use TLS 1.2 only, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations running Azure AD Connect:

Note:
RFC 8446 defines the Transport Layer Security (TLS) Protocol Version 1.3. However, TLS 1.3 has not found its way to Windows Server, yet. It is unavailable at the time of writing.

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

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.

Note:
The registry changes are step 1 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to disable weak protocols, cipher suites and hashing algorithms on the Windows Servers running Azure AD Connect, before testing these systems.

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 running Azure AD Connect. 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.

Rolling back hardening

To roll back the settings that enforce Azure AD Connect to use TLS 1.2 only, use the following lines of Windows PowerShell:

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 0 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 0 -PropertyType DWORD

Concluding

Enforcing Azure AD Connect to use TLS v1.2 is a perfect mitigating measure in terms of a GDPR-enforced data privacy impact analysis (DPIA). Be sure to implement it, and enable TLS 1.2 on the Windows Server installations running Azure AD Connect, too.

Active Directory and time

Why the correct time is important to Domain Controllers

You might not think accurate time is important in Active Directory, and you would be right in most cases. However, there are a couple of cases where accurate time is important:

Kerberos authentication, as heavily used in Active Directory, allows for five minutes time difference between an authenticating client (that could also be a domain-joined server) and the authenticating server (that is always a Domain Controller). Beyond the five minute time frame, authentication fails.
Domain Controllers replicate the contents of the Active Directory database based on InvocationIDs, indicating replication partners, unique serial numbers per object (USNs) and the originating DN (Domain Controller) for writes to objects.
Only when two writes in Active Directory cross replication, the time stamp is used to make the last write win.

That’s why Active Directory offers a time hierarchy.

About the Active Directory Time Hierarchy

In every Active Directory environment, time is synchronized in a hierarchy. This hierarchy is depicted in the below image, courtesy of the Time Synchronization in Active Directory Forests page in the Microsoft TechNet Wiki:

The Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain represents the top of the hierarchy and is considered the authoritative time source. That’s why the Active Directory Best Practices Analyzer (BPA) reports an action when this Domain Controller does not synchronize its time with an external source, like a pool of NTP servers on the Internet or a couple of GPS-equipped internal appliances, or a combination of both.

The Domain Controller holding the PDCe FSMO role represents the top. This Domain Controller is contacted by the w32time service running on:

Domain Controllers holding the PDCe FSMO role for the other domains in the Active Directory forest (although these Domain Controllers can synchronize with any Domain Controller from the root domain)
The other Domain Controllers in the root domain

Domain-joined devices and member servers in the root domain, then, contact these other Domain Controllers to synchronize time with. (This reduces the load on the Domain Controller with the PDCe FSMO role.)

In the other domains in the Active Directory forest, other Domain Controllers in these domains synchronize their time with the Domain Controller holding the PDCe FSMO role in their domain. Domain-joined devices and member servers in the non-root domain can synchronize with any Domain Controller in their respective domain.

Challenges with time drift

The above hierarchy works almost flawless in environments with physical Domain Controllers, but represents a couple of challenges when working with virtualized Domain Controllers:

When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. Domain Controllers synchronizes time with the tier above them only every 3600 seconds, so in extremis Domain Controllers may provide member servers and domain-joined devices wrong time for an hour, resulting in possible authentication failures.
When the hypervisor host is not synchronizing time with a reliable time source, it may provide the wrong time to a virtual Domain Controller. In environments with high volumes of changes to objects in Active Directory, this might result in replicating changes from the Domain Controller as they are indicated as winning last writes, due to incorrect time stamps.
When the time difference is greater than 48 hours, the w32time service on Windows Server 2008, and up, will not correct the time, because of the phase correction limits. Microsoft KnowledgeBase article 884776 explains how to change these limits through the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. (However, with incorrect time, there is no Kerberos, and thus no Group Policy…)

Microsoft recommended practices

Microsoft recommends to:

Synchronize the time of the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain with a reliable time source.
Use the default time synchronization hierarchy throughout Active Directory.

Specific to virtual Domain Controllers, Microsoft has held different points of view on time synchronization.

accurate time for Windows Server 2016

Microsoft introduced increased polling and clock update frequency in Windows Server 2016 Active Directory, when compared to Windows Server 2008/2012. While this introduces a small additional CPU load on Domain Controllers, it does provide for more Accurate Time for Windows Server 2016 because of more frequent polling, updating and through an algorithm that calculates time difference trends.

Time Synchronization on VMware vSphere

There are two models for time synchronization between virtual Domain Controllers and VMware vSphere hosts:

Disable time synchronization between virtual machines and the hypervisor to avoid a virtual Domain Controller to pick up bad time settings when the hypervisor is not synchronizing time properly.
Synchronize the time on hypervisor hosts to the same external time source as the Domain Controller with the PDCe FSMO role in the forest root domain.

There are some things you need to know:

Disable time synchronization with the hypervisor host

Many websites on the internet will instruct you to disable the Synchronize guest time with host option in the virtual machine’s properties to disable time synchronization with the hypervisor host, like in the below screenshot:

Virtual Machine Properties

As VMware KnowledgeBase article 1189 points out, this does not completely disable time synchronization, because virtual Domain Controllers will synchronize their time when you,

Suspend it, the next time you resume it
Migrate the virtual Domain Controller using vMotion
Take a snapshot
Restore to a snapshot
Shrink the virtual disk
Restart the VMware Tools service
Reboot the virtual Domain Controller

To effectively disable time synchronization, add the following lines to your virtual machine’s advanced configuration options:

tools.syncTime = “0”
time.synchronize.continue = “0”
time.synchronize.restore = “0”
time.synchronize.resume.disk = “0”
time.synchronize.shrink = “0”
time.synchronize.tools.startup = “0”
time.synchronize.tools.enable = “0”
time.synchronize.resume.host = “0”

To disable time synchronization across multiple VMs at once, use VMware vRealize Orchestrator.

Synchronize hypervisor time with a reliable source

Synchronizing the time on the hypervisor with a reliable source sounds like a piece of cake, but gets tedious to manage at large scale. When you’ve found your way to manage the configuration of all hypervisor hosts, it’s also noteworthy to:

Disable VMware Distributed Resource Scheduler (DRS) for Domain Controllers holding the PDCe FSMO role
Use Host-Guest Affinity Rule for Domain Controllers holding the PDCe FSMO role

Recommendations

Disable time synchronization with the hypervisor host on the virtual Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain and synchronize its time with a combination of:

DNS names of a reliable time source on the internet, like pool.ntp.org.
IP addresses of a reliable time source on the internet, like 131.211.8.244 and 5.79.108.34. (This make sure time synchronization occurs even when DNS is unavailable and minimizes the effect of DNS poisoning attacks.)
IP addresses of reliable time sources on the internal network, like GPS-based NTP appliances on the internal network. (This makes sure time synchronization occurs even when internet connectivity is unavailable).

For all other virtual Domain Controllers, virtual member servers and virtual domain-joined devices, make sure the hypervisor hosts they run on have accurate time. Then, the virtual machines will make the most of time synchronization from both the hypervisor and Active Directory. Especially when they run Windows Server 2016, or up.

Why harden Azure AD Connect

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

Azure AD Connect installations are typically placed on the internal network, close to Active Directory Domain Controllers. In fact, many security experts advice to treat Azure AD Connect installations as Domain Controllers. When an Azure AD Connect installation is compromised, the information on the Windows Server and in the Azure AD Connect database can be used to:

Make changes to the entire Azure AD Connect tenant, for instance by changing the password of an account with the Global Administrator role or adding an account to a group to provide access to resources.
Make changes to the Organizational Units (OUs) in Active Directory in scope for Azure AD Connect (in the case of hardened service accounts with privileges limited to the OUs in scope, for instance change passwords for administrators, add accounts to groups and attach new on-premises accounts to existing Azure AD accounts through the objectGUID or mS-DS-ConsistencyGUID attribute, used as source anchor.
Implement additional Domain Controllers and/or perform a DCSync attack, based on the Replicate Changes and Replicate Changes All permissions assigned in Active Directory to the Azure AD Connect service account.

Also remember that Azure AD Connect cannot be implemented on Server Core installations of Windows Server or Windows containers: Azure AD Connect requires a Windows Server installation with Desktop Experience (or what most people call a ‘Full Server’)

Possible negative impact (What could go wrong?)

Getting Ready

To disable unnecessary services on Windows Servers running Azure AD Connect, make sure to meet the following requirements:

System requirements

Make sure the Windows Server installations 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 Windows Server running Azure AD Connect reside.

Who to communicate to

When intending to make changes to Azure AD Connect installations, 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

Unnecessary services

By default

The following Windows services are disabled, by default, on Windows Server with Desktop Experience installations of Windows Server 2016:

Auto Time Zone Update (tzautoupdate)
Computer Browser (browser)
Microsoft App-V Client (AppVClient)
Net.Tcp Port Sharing Service (NetTcpPortSharing)
Offline files (cscService)
Routing and Remote Access (RemoteAccess)
Smart Card (SCardSvr)
User Experience Virtualization Service (UevAgentService)
Windows Search (WSearch)

These services do not require any further attention.

Additional services

The following Windows services are enabled and have Manual or Automatic startup types on installations of Windows Server 2016 with the Desktop Experience (Full Installations). These can be disabled:

ActiveX Installer (AxInstSV) (AxInstSV)
Bluetooth Support Service (bthserv)
CDPUserSvc (CDPUserSvc)
Contact Data (PimIndexMaintenancesvc)
dmwappushsvc (dmwappushsvc)
Downloaded Maps Manager (MapsBroker)
Geolocation Service (lfsvc)
Internet Connection Sharing (ICS) (SharedAccess)
Link-Layer Topology Discovery Mapper (lltdsvc)
Microsoft Account Sign-in Assistant (wlidsvc)
Microsoft Passport (NgcSvc)
Microsoft Passport Container (NgcCtnrSvc)
Network Connection Broker (NcbService)
Phone Service (PhoneSvc)
Print Spooler (Spooler)
Printer Extensions and Notifications (PrintNotify)
Program Compatibility Assistant Service (PcaSvc)
Quality Windows Audio Video Experience (QWAVE)
Radio Management Service (RmSvc)
Sensor Data Service (SensorDataService)
Sensor Monitoring Service (SensrSvc)
Sensor Service (SensorService)
Shell Hardware Detection (ShellHWDetection)
Smart Card Device Enumeration Service (ScDeviceEnum)
SSDP Discovery (SSDPSRV)
Still Image Acquisition Events (WiaRpc)
Sync Host (OneSyncSvc)
Touch Keyboard and Handwriting Panel (TabletInputService)
UPnP Device Host (upnphost)
User Data Access (UserDataSvc)
User Data Storage (UnistoreSvc)
WalletService (WalletService)
Windows Audio (Audiosrv)
Windows Audio Endpoint Builder (AudioEndpointBuilder)
Windows Camera Frame Server (FrameServer)
Windows Image Acquisition (WIA) (stisvc)
Windows Insider Service (wisvc)
Windows Mobile Hotspot Service (icssvc)
Windows Push Notifications System Service (WpnService)
Windows Push Notifications User Service (WpnUserService)
Xbox Live Auth Manager (XblAuthManager)
Xbox Live Game Save (XblGameSave)

Unnecessary tasks

On Windows Server installations with Desktop Experience, two scheduled tasks exist that can be removed without consequences on Windows Servers running Azure AD Connect:

\Microsoft\XblGameSave\XblGameSaveTask
\Microsoft\XblGameSave\XblGameSaveTaskLogon

How to disable unnecessary services

As the Windows Servers running Azure AD Connect are part of Active Directory Domain Services, the best way to disable the unnecessary Windows Services is through Group Policy.

Follow these steps:

Sign in with an account that is a member of the Domain Admins group, or with an account that is delegated to create and link Group Policy objects (GPOs) to Organizational Units (OUs).
Open the Group Policy Management console (gpmc.msc).
In the left navigation pane, navigate to the Organizational Unit (OU) where the AD Windows Servers running Azure AD Connect reside.
Right-click the OU and select Create a GPO in this domain, and Link it here….
In the New GPO pop-up, provide a name for the Group Policy Object, corresponding to the naming convention for Group Policy objects in the environment.
Click OK
Back in navigation pane of the Group Policy Management console, expand the OU and click on the Group Policy object link.
Click OK in the Group Policy Management Console pop-up, explaining You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other location where this GPO is linked.
Right-click the Group Policy object and select Edit… from the context menu.
The Group Policy Management Editor window appears.
In the left navigation pane, under Computer Configuration, expand the Policies node.
Expand the Windows Settings node.
Expand the Security Settings node.
Select System Services.
In the main pane, for each service in the above list, double-click the service, and then select the Define this policy setting option and select the Disabled service startup mode.
When done, close the Group Policy Management Editor window.
Close the Group Policy Management Console window.
Sign out.

How to remove scheduled tasks

As the Windows Servers running Azure AD Connect are part of Active Directory Domain Services, the best way to remove the unnecessary scheduled tasks is through Group Policy Preferences.

Note:
Do not place Group Policy settings and Group Policy preferences in the same Group Policy object, as this will result in synchronous processing behavior and slowness during startups of the Windows Servers running Azure AD Connect.

Follow these steps:

Sign in with an account that is a member of the Domain Admins group, or with
an account that is delegated to create and link Group Policy objects (GPOs) to
Organizational Units (OUs).
Open the Group Policy Management console (gpmc.msc).
In the left navigation pane, navigate to the Organizational Unit (OU) where
the Windows Servers running Azure AD Connect reside.
Right-click the OU and select Create a GPO in this domain, and Link
it here….
In the New GPO pop-up, provide a name for the Group Policy
Object, corresponding to the naming convention for Group Policy objects in the
environment.
Click OK
Back in navigation pane of the Group Policy Management console,
expand the OU and click on the Group Policy object link.
Click OK in the Group Policy Management
Console pop-up, explaining You have selected a link to a Group
Policy Object (GPO). Except for changes to link properties, changes you make
here are global to the GPO, and will impact all other location where this GPO is
linked.
Right-click the Group Policy object and select Edit… from
the context menu.
The Group Policy Management Editor window
appears.
In the left navigation pane, under Computer Configuration,
expand the Preferences node.
Expand the Control Panel Settings node.
Expand the Scheduled Tasks node.
In the main pane, right-click on Scheduled Tasks and select New and then Scheduled Task from the context menu.
In the New Task Properties window,select Delete as the action and provide the name of the scheduled task, exactly as provided above.
Click OK.
Repeat steps 13-15 for the second task.
When done, close the Group Policy Management Editor
window.
Close the Group Policy Management Console window.
Sign out.

Testing proper hardening

Rolling back hardening

To roll back hardening of the services and removal of the scheduled tasks, disable the Group Policy object(s) or remove the link between the Group Policy object(s) and the Organizational Unit (OU) where the Windows Servers running Azure AD Connect reside.

Concluding

Disable unnecessary services on all Windows Servers running Azure AD Connect throughout the Hybrid Identity implementation using Group Policy.

Thank you!

Thank you KNVI for organizing this meetup.

Posted on July 15, 2019 by Sander Berkouwer in Active Directory, Being Published, Community, Microsoft MVP, Personal

a blog by Sander Berkouwer

About Active Directory Virtualization Safeguards

About VM-GenerationID

VM-GenerationID in VMware vSphere

VM-GenerationID safeguarding Active Directory Virtualization

Requirements

Just because you can…

The possible impact of Virtualization Safeguards on Disaster Recovery

Forest-wide Disaster Recoveries

Was it a Proper Restore or Virtualization Safeguard?

Recovering the RID Master

Have Domain Controllers in multiple sites

Recovering the RID Master

Recommendations

Meet the requirements

Use snapshots with moderation

Plan for disaster recovery

Promotions vs. Restores

Concluding

Related blogposts

Further reading

Why enable auditing on AD FS Servers

Reasons why

Possible negative impact (What could go wrong?)

Getting ready

Information requirements

AD FS Server Auditing level

AD FS Farm Logging Level

System requirements

Privilege requirements

AD FS Server Auditing level

AD FS Farm Logging Level

Who to communicate to

Enabling AD FS Auditing

How to check the AD FS auditing level

How to enable the AD FS verbose auditing level

How to enable the auditing policy

Enabling AD FS Logging

How to check the AD FS auditing level

How to enable logging of successes and failures

Testing Auditing and Logging

Helpful tools

Rolling back hardening

Concluding

Further reading

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

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