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

What’s New

New riskDetections API for Microsoft Graph Public preview

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

Microsoft is pleased to announce the new riskDetections API for Microsoft Graph is now in public preview. Administrators can use this new API to view a list of their organization’s Identity Protection-related user and sign-in risk detections. Admins can also use this API to more efficiently query risk detections, including details about the detection type, status, level, and more.

New Federated Apps available in Azure AD app gallery

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

In June 2019, Microsoft has added these 22 new apps with Federation support to the Azure AD App Gallery:

Azure AD SAML Toolkit
Otsuka Shokai (大塚商会)
ANAQUA
Azure VPN Client
ExpenseIn
Helper Helper
Costpoint
GlobalOne
Mercedes-Benz In-Car Office
Skore
Oracle Cloud Infrastructure Console
CyberArk SAML Authentication
Scrible Edu
PandaDoc
Perceptyx
Proptimise OS
Vtiger CRM (SAML)
Oracle Access Manager for Oracle Retail Merchandising
Oracle Access Manager for Oracle E-Business Suite
Oracle IDCS for E-Business Suite
Oracle IDCS for PeopleSoft
Oracle IDCS for JD Edwards

Automate user account provisioning for these SaaS apps

Service category: Enterprise Apps
Product capability: Monitoring & Reporting

Azure AD admins can now automate creating, updating, and deleting user accounts for these newly-integrated apps:

What’s Changed

View the real-time progress of the Azure AD provisioning service

Service category: App Provisioning
Product capability: Identity Lifecycle Management

Microsoft has updated the Azure AD provisioning experience to include a new progress bar that shows admins how far they are in the user provisioning process. This updated experience also provides information about the number of users provisioned during the current cycle, as well as how many users have been provisioned to date.

Company branding now appears on sign out and error screens

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

Microsoft has updated Azure AD so that company branding now appears on the sign out and error screens, as well as the sign-in page. Administrators don’t have to do anything to turn this feature on; Azure AD simply uses the assets that have already been set up in the Company branding area of the Azure portal.

What’s Deprecated

Azure Multi-Factor Authentication (MFA) Server is no longer available for new deployments

Service category: MFA
Product capability: Identity Security & Protection

As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New organizations who want to require multi-factor authentication must now use cloud-based Azure Multi-Factor Authentication. Organizations who activated MFA Server prior to July 1 won’t see a change; Admins will still be able to download the latest version, get future updates, and generate activation credentials.

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

One of the questions I get asked a lot is:

Why virtualize Domain Controllers?

So, in this blogpost, I’m showing you reasons why virtualization for Domain Controllers and Active Directory is a good idea. I also know there are a lot of caveats when virtualization Domain Controllers, so this blogpost serves as a small part of a bigger series on how to do it right.

Reasons to virtualize Domain Controllers fall in three buckets:

Virtualization is mainstream
Active Directory is virtualization-friendly
Physical Domain Controllers waste compute resources

Let’s look at these three areas and provide some real-world examples.

Virtualization is mainstream

You’ve probably heard of ‘cloud’. Whether it’s Private Cloud (hosted in your own datacenters or the datacenters of an organization you’ve outsourced it to) or Public Cloud (like Microsoft’s Azure and Amazon’s AWS), virtualization, coupled with self-service, is the cornerstone to making it happen. “Virtualize First” is the new normal.

Also, virtualization is no longer black magic. Virtualization platforms like VMware’s Sphere and Microsoft’s Hyper-V platforms are well-documented. People who want to be proficient at managing virtualization have a wide range of training to follow and certificates to achieve. When you run into problems with any of the virtualization platforms, there’s free support options available, like Stack Overflow and the vendor’s support forums, next to paid support options.

Since Windows Server 2012, virtualization for Active Directory is fully supported by Microsoft. VMware fully supports virtualizing Domain Controller (as long as you follow their recommended practices).

You could ask yourself if Microsoft still tests Domain Controller functionality and updates on physical hardware. If this is the case and you’re running Domain Controllers on physical hardware, aren’t you putting your organization at risk?

Active Directory is virtualization-friendly

From its inception back in 1997, Active Directory has been virtualization-friendly.

It has never had high memory or I/O requirements. You can run Domain Controllers on machines with loathsome specifications. A single CPU, just a few GBs of RAM and some GBs of disk storage is all you need to even run a Windows Server 2019-based Domain Controller. When running Domain Controllers as Server Core installations, the requirements drop even further. This makes them ideal candidates to virtualize.

The distributed nature of the Active Directory database also adds to the virtualization-friendliness of Active Directory. Scale-out is the preferred method to increase Active Directory performance, not scale-up (except perhaps for the Domain Controller holding the PDC emulator FSMO role…). Just add small-sized VMs to the virtualization platform and Active Directory is again ready to go.

All Domain Controllers are created equal (but some Domain Controllers, like the aforementioned PDC emulator) and replication offers a multi-master model. This makes Active Directory resilient; with the majority of Domain Controllers decimated during a disaster, it can still function. Also, purely based on the virtual disk of a Domain Controller, it can be restored on a compatible virtualization platform.

These system specs, its distributed nature and its sustainable level of degradation are all specifics for virtual machines that virtualization admins love to host for you.

Physical Domain Controllers waste compute
resources

When looking for the cheapest rack server on Dell.com today, I stumbled upon the PowerEdge R240. It has a Celeron G4900 3,1GHz processor, 8GB RAM and a 1TB HDD for a mere $589. For $926 there is an Intel Xeon E2124-based, 16GB model available from HP Enterprise. These systems have one thing in common: The smallest sized disk you can buy in them measures 1TB. This disk size is overkill in any networking environment, except for Fortune 500 companies as the Active Directory files don’t take up that much space. (unless you’re storing user profile pictures in them, but even then it’s not a huge problem). Even the 8GB RAM of the cheapest Dell rack server you can get allows you to cache the Active Directory database for an organization with over 100,000 users.

Active Directory simply isn’t able to utilize the compute resources available on modern hardware. Running Domain Controllers on physical hardware equals wasting computer resources. Wasting compute resources means wasting money.

Concluding

Virtualize Domain Controllers.

Does that mean you can virtualize all your Domain Controllers? Does that mean you can be as coarse with virtual Domain Controllers as you can be with physical Domain Controllers? Does that mean virtual Domain Controllers are as secure as physical Domain Controllers? Join me for the answers on these questions in the next parts of this series.

The post Why virtualize Domain Controllers? appeared first on The things that are better left unspoken.

Virtualizing Domain Controllers

In the first part of this series, we discussed why we want to virtualize Domain Controllers. The first question people ask is:

How do I properly size Domain Controllers on my virtualization platform?

Specifically, for VMware vSphere, this is a good question, because there are a couple of areas of attention, beyond the recommended practices from Microsoft:

Microsoft recommended practices

For sizing Domain Controllers, Microsoft recommends to:

Deploy at least two Domain Controllers per Active Directory domain.
Create exceptions for antimalware solutions for the folders containing Active Directory files.
Deploy the Local Administrator Password Solution (LAPS).
Do not install additional software or Server Roles on Domain Controllers.
Install Windows updates on Domain Controllers.
Keep information security measures on Domain Controllers, like antimalware, backup, restore, monitoring, auditing, bad password blocking and SIEM solutions, up to date.
Have a recovery plan available for Active Directory.

Areas of Attention

CPU

A good rule of thumb for the number of virtual Central Processing Units (vCPUs) for is to size virtual Domain Controllers with 1 vCPU, when the environment has 10,000 users, or less. When the environment has more than 10,000 users, add another vCPU to the Domain Controllers.

When in doubt, start with 2 vCPUs in virtual Domain Controllers and add vCPUs as needed. The Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role will be the most burdened Domain Controller of all. It performs these additional tasks, when compared to all the other Domain Controllers in the Active Directory domain:

Password changes performed by other Domain Controllers in the Active Directory domain are replicated preferentially to the PDC emulator.
If a logon authentication fails at a given Domain Controller in an Active Directory domain due to a bad password, the Domain Controller will forward the authentication request to the PDC emulator to validate the request against the most current password. If the PDC reports an invalid password to the Domain Controller, the Domain Controller will send back a bad password failure message to the user.
Account lockout is processed on the PDC emulator.
The Domain Controller with the PDC emulator FSMO role, by default, functions as the authoritative source of time in the Active Directory domain.
The Domain Controller with the PDC emulator FSMO role fulfills the role of the PDC in the NetLogon Remote Protocol methods. Therefore, the Domain Controller with the PDC emulator FSMO role must support and perform all PDC specific functionality specified in that section. Every other Domain Controller must not perform this functionality.

Tip!
In VMware vSphere-based VMs with more than one vCPU, make sure to look at the Networking section below to avoid the unavailability of receive-side scaling.

RAM

If you want highly-performing Domain Controllers, provide them with a sufficient amount of Random Access Memory (RAM) to be able to cache the Active Directory database (ntds.dit).

A good metric to monitor is the Database/Database Cache %Hit counter for the LSASS process on Domain Controllers. A low hit rate indicates that the Domain Controller would benefit from more RAM.

Storage

Microsoft recommends to use a 40GB system volume (C:\) to store the Windows Operating System. However, Active Directory requires additional storage. You may or may not place these files on the system volume, depending on your view on dynamic files. Independent of this choice, you need to take into account the following storage needs for a Domain Controller:

Active Directory role	250 MB
Active Directory database	4 KB per object (excluding photos)
Active Directory logs	22MB
Active Directory System Volume	Any files you store in the SYSVOL share
Active Directory System Volume	2MB per Group Policy object
Active Directory System Volume	20MB for the Central Policy Store
Active Directory System Volume	1GB for the SYSVOL replication staging area

For a typical organization of 100,000 persons, this would lead to 5GB of additional storage requirements. Of course, when such an organization would decide to store user photos in Active Directory, storage requirements could potentially triple.

Networking

Ideally, configure virtual Domain Controllers with one virtual Network Interface Card (vNIC). Use VMXNET3 for best performance.

Additionally, upgrade the VMware Tools of existing virtual machines to version 10.2.5. The Windows Receive Side Scaling (RSS) feature is not functional on virtual machines running VMware Tools versions 9.10.0 up to 10.1.5. On virtual Domain Controllers with multiple vNICs, under heavy network load, this may cause a situation where CPU0 is overloaded, as depicted in the below screenshot:

Since VMXNET3 driver version 1.7.3.8 (as part of VMware Tools 10.2.5), this driver version enables Receive-side Scaling (RSS) and Receive Throttle settings, by default – but only for new VMware Tools installations on new virtual machines. If you upgrade an existing VMware Tools install, these settings will remain as is.

On existing virtual Domain Controllers, make sure to enable Receive Side Scaling (RSS) and set the Receive Throttle to 30, using the following line of Windows PowerShell on virtual Domain Controllers running VMware Tools 10.2.5, or up:

Enable-NetAdapterrss –Name “*”

Agents and add-ons

On top of the above requirements for the Active Directory role, make sure you provide sufficient resources for the typical agents and add-ons your organization would typically install on Domain Controllers, like antimalware, backup, restore, monitoring, auditing, bad password blocking and SIEM solutions.

In practice

Because of this last area of attention, we see organizations typically deploy virtual Domain Controllers with 1 vCPU, 4GB RAM, a 60GB system volume and 1 vNIC.

These dimension are a far cry from the other sizing we often encounter in organization where, according to the design all hardware factors are blades and a physical Domain Controller was deemed necessary. The typical dimension of these Domain Controller blades depend on the phase in the project where its importance was understood. The largest Domain Controller we’ve come across was a blade with 2 CPUs, 24 cores, 512GB RAM and 2 300GB hard disks in RAID1.

Concluding

Sizing is often the first hurdle to cross when virtualizing Domain Controllers. Join me for the next parts were we drill deeper into the integrity, confidentiality and availability of Domain Controllers.

Just out of curiosity, what was the largest physical Domain Controller you’ve ever come across in production? Winking smile

The post Sizing Domain Controllers correctly on VMware vSphere appeared first on The things that are better left unspoken.

Last week, on Tuesday June 20 2019, the Royal Dutch Association of Information and IT Professionals (KNVI) organized the “Active Directory, What’s Cooking?” Event at Hit Eten en Drinken in Cappele aan den Ijssel in the Netherlands.

As we were to gather at 18:30, I worked for a customer in Utrecht that Tuesday. I can start and leave early, there, so this left me with ample room in my schedule to fiddle around.

I anticipated traffic on my way over, but didn’t meet any. I arrived at 16:45. I took a seat inside and prepared some slides, while I waited for the other speakers and the organization to arrive. At 18:30, the food on the BBQ was ready, and we could all enjoy food before getting to the presentation part of the evening.

At 20:00, Erwin Derksen and I kicked off with some light entertainment. We discussed Multi-Factor Authentication and Azure Active Directory Domain Services. 45 minutes in, I talked a bit about the book, its timelines and struggles. Concluding, my colleague Barbara Forbes talked about how she helped me with her Azure DevOps magic, to create pre-canned Active Directory environments with one click in under 35 minutes.

I signed a couple of books and then we had some drinks. I came home at 22:45 with a huge smile on my face.

Thank you!

Thank you KNVI for organizing this meetup.

The post Pictures of the KNVI "Active Directory, What’s Cooking?" Event appeared first on The things that are better left unspoken.

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.

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

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 disable unnecessary services on Windows Servers running Azure AD Connect, make sure to meet the following requirements:

System requirements

Make sure the Web Application Proxies 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 AD FS servers 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

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

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

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.

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

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

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.

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

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.

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.

What’s New

New riskDetections API for Microsoft Graph Public preview

New Federated Apps available in Azure AD app gallery

Automate user account provisioning for these SaaS apps

What’s Changed

View the real-time progress of the Azure AD provisioning service

Company branding now appears on sign out and error screens

What’s Deprecated

Azure Multi-Factor Authentication (MFA) Server is no longer available for new deployments

Virtualization is mainstream

Active Directory is virtualization-friendly

Physical Domain Controllers waste compute resources

Concluding

Microsoft recommended practices

Areas of Attention

CPU

RAM

Storage

Networking

Agents and add-ons

In practice

Concluding

Thank you!

Why harden Azure AD Connect

Reasons why

Possible negative impact (What could go wrong?)

Getting Ready

System requirements

Privilege requirements

Who to communicate to

Unnecessary services

By default

Additional services

Unnecessary tasks

How to disable unnecessary services

How to remove scheduled tasks

Testing proper hardening

Rolling back hardening

Concluding

Further reading

Active Directory and time

Why the correct time is important to Domain Controllers

About the Active Directory Time Hierarchy

Challenges with time drift

Microsoft recommended practices

accurate time for Windows Server 2016

Time Synchronization on VMware vSphere

Disable time synchronization with the hypervisor host

Synchronize hypervisor time with a reliable source

Recommendations

Further reading

Why harden

Reasons why

Possible negative impact (What could go wrong?)

Getting Ready

System requirements

Privilege requirements

Who to communicate to

How to enforce Azure AD Connect to use TLS 1.2 only

Testing proper hardening

Rolling back hardening

Concluding

Further reading

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

Physical Domain Controllers waste compute
resources