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.

In this part of the series, we’ll add an additional layer of information security to authentications that are routed through the Active Directory Federation Services (AD FS) implementation.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

Why look at Multi-Factor Authentication

Many organizations rely on usernames and corresponding passwords to verify the person authenticating. However, there are several reasons why this is not a sufficient method to securing authentication:

1. Web-based applications typically use the email address as the user name, because this is a globally unique identifier that people can get cheaply. Microsoft recommends keeping the userPrincipalName attribute equal to the mail attribute.
2. People reuse passwords between accounts.
3. Accounts are breached at a rate of 2 services per day.
4. People are bad at coming up with strong passwords.

A (temporary) solution is to add multi-factor authentication to the authentication flow. This way, after a person has correctly entered the username and password, a second verification is performed. This verification is based on information that was previously registered, and should leverage a different authentication factor:

• Something you can prove you know
  The password most organizations use
• Something you can prove you are
  Think of a fingerprint, face or iris scan, like Apple has with TouchID and FaceID, and Microsoft offers on its Surface devices.
• Something you can prove you have
  Think of a token device, a FIDO 2.0 key, certificate tied to a TPM chip or access to a phone or phone number in the form of returning a one-time password that you receive through a text message, a phone call or an authenticator app,

When you combine multiple authentication factors, multi-factor authentication (MFA) emerges, allowing for more secure authentication.

Reasons why

Usually, it only takes one leaked password to get to sensitive information an organization harbors. This could be privacy-related information related to employees and customers, but could also be information regarding products (source code), intellectual property and patents.

For systems, services and applications containing these types of information, multi-factor authentication should be used. For Azure AD-integrated applications, Conditional Access and Identity Protection offer multi-factor authentication, when needed. For AD FS-integrated applications, applying multi-factor authentication is more straightforward, unless you want to dig deep into REGEX…

Possible negative impact (What could go wrong?)

Multi-factor Authentication is a burden to end-users. Your colleagues and customers might not understand how to effectively perform multi-factor authentication, or move to a competitor that doesn’t require multi-factor authentication, or only when needed.

Choosing the right authentication method is important. Some multi-factor authentication methods are not as secure and user-friendly as others. For instance, because of recent SIM-swapping attacks, MFA through text messages is deemed too insecure to serve a purpose as multi-factor authentication method. Text messages are also inadequate for the situation where a person is on a plane, does have WiFi, but doesn’t have cellular reception.

About the Azure MFA Adapter

Microsoft introduced the Azure MFA Adapter in Windows Server 2016. When the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or up, this built-in adapter can be enabled and used.

When used, the Azure MFA Adapter communicates to Microsoft’s Azure MFA service to perform multi-factor authentication. People register only once for Self-service Password Reset, multi-factor authentication for Conditional Access, multi-factor authentication for Identity Protection and for multi-factor authentication for systems, services and applications through Active Directory Federation Services (AD FS).

Note:
Azure MFA Server also offers an AD FS MFA Adapter, but Microsoft recommends not performing new implementations of Azure MFA Server.

Getting ready

To implement the Azure MFA Adapter and secure AD FS-integrated systems, services and applications with multi-factor authentication, make sure to meet the following requirements:

Roll-out requirements

First off, everyone in scope for the AD FS-integrated systems, services and applications with multi-factor authentication needs to have performed their Azure MFA registration.

If a person doesn’t have an Azure MFA registration, access to the AD FS-integrated systems, services and applications for which multi-factor authentication is required, will be denied.

The scripts to get to know the colleagues using Azure Multi-Factor Authentication still offer sufficient functionality to discover who has an Azure MFA registration and which authentication method they use.

Information Requirements

To avoid multi-factor authentication prompt fatigue, multi-factor authentication should ideally only be required when strictly needed. It’s not the most brilliant of ideas to require multi-factor authentication for all AD FS-integrated systems, services and applications. Determine the systems, services and applications that truly need it, and require MFA in the situations where you need it. Application owners typically know best what their application does and needs.

System requirements

Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. Make sure the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or above.

As Azure Multi-factor Authentication information is stored in Azure AD only, and not written back to the on-premises Azure AD Connect or Active Directory environment, but is now used to integrate with on-premises systems, services and applications, now is a good time to look for a solution that creates backups of the Azure AD tenant.

Network requirements

The AD FS servers in the AD FS farm need to be able to communicate to the following urls over TCP port 443 (HTTPS):

• https://adnotifications.windowsazure.com
• https://login.microsoftonline.com

PRIVILEGE REQUIREMENTS

Make sure to sign in with an account that:

• Is a member of the Enterprise Admins group in Active Directory, and;
• Has privileges to manage the AD FS farm.

Note:
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.

Also, you’ll need the credentials of an account with the Global Administrator role in the Azure AD tenant in which you want to use Azure multi-factor authentication. If running these

WHO TO COMMUNICATE TO

If your users have not registered for Azure MFA yet, than this part of the implementation requires a communications plan.

How to enable Azure MFA on AD FS

Enabling Azure Multi-Factor Authentication on AD FS requires three steps:

1. Register Azure MFA in the tenant
2. Enable Azure MFA as AD FS Multi-factor Authentication method
3. Choose an appropriate Access Policy per AD FS Relying Party Trust (RPT)

Register Azure MFA in the tenant

First, run the following lines of Windows PowerShell in an elevated PowerShell window on each of the AD FS servers in the AD FS farm:

Install-Module MSOnline

Connect-MsolService

Log in.

$TenantID = (Get-MsolCompanyInformation).ObjectID$Certbase64 = New-AdfsAzureMfaTenantCertificate –TenantID $TenantID

New-MsolServicePrincipalCredential -AppPrincipalId
981f26a1-7f43-403b-a875-f8b09b8cd720 -Type Asymmetric –Usage Verify  -Value $CertBase64

Then, on the primary AD FS server in the AD FS farm, run the following lines of Windows PowerShell:

Set-AdfsAzureMfaTenant -TenantId $TenantID -ClientId
981f26a1-7f43-403b-a875-f8b09b8cd720

Enable Azure MFA as AD FS multi-factor authentication method

Now that the Azure MFA Adapter is available as a multi-factor authentication mechanism, we need to enable it for the AD FS farm, again on the primary AD FS server.

Run the following lines of Windows PowerShell:

$C = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

$C.Add(“AzureMfaAuthentication”)

Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $C

Choose an appropriate Access Policy per Relying Party Trust

Each AD FS-integrated system, service and application has its own relying party trust (RPT) relationship with AD FS. In AD FS on Windows Server 2016, and above, you can enable multi-factor authentication with built-in access policies.

These policies are aptly named:

• Permit everyone and require MFA for specific group
• Permit everyone
• Permit everyone for intranet access
• Permit everyone and require MFA from unauthenticated devices
• Permit everyone and require MFA from extranet access
• Permit specific group
• Permit everyone and require MFA, allow automatic device registration
• Permit everyone and require MFA

Note:
You can add access policies yourself if none of the built-in access policies fit your organization’s needs.

By default, every relying party trust is not configured with an access policy, which is the equivalent of the Permit Everyone access policy. You can change it to another policy using the following line of Windows PowerShell:

$RPT = Get-AdfsRelyingPartyTrust -Name “Microsoft Office 365 Identity Platform”

Set-AdfsRelyingPartyTrust -TargetRelyingParty $RPT -AccessControlPolicyName “Permit everyone and require MFA from extranet access”

Testing Azure MFA on AD FS

After enabling the Extended Protection for Authentication feature,  it’s time to test.

The Permit everyone and require MFA for specific group access policy is the ideal method to test the correct registration and working of Azure MFA. Simply create a group in Active Directory, configure the access policy for a relying party trust with the access policy and the group. Then, add a user account that had previously registered MFA to the group and use it to sign in to the system, services or application that is represented by the relying party trust.

Concluding

One Multi-factor Authentication method for all your organization’s Azure AD- and AD FS-integrated systems, services and applications?

Yes, it’s possible!

Further reading

Configure AD FS 2016 and Azure MFA
Getting started with Azure Multi-Factor Authentication and AD FS
Securing cloud resources with Azure Multi-Factor Authentication and AD FS
AD FS 2016 and Azure MFA – a few Nuances
Step-by-Step guide to configure Azure MFA with ADFS 2016

The post HOWTO: Enable Azure Multi-factor Authentication on AD FS appeared first on The things that are better left unspoken.

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.

In this part of the series, we’ll look at the security headers for AD FS implementations.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

Why look at Security Headers?

To prevent malicious attacks, many new protections for websites utilize security headers. Through security headers, you can prevent malicious scripts from running in browsers visiting your AD FS infrastructure, prevent the acceptance of forged TLS certificates and prevent clickjack attacks.

Reasons why

Through security response headers, the information security level of the AD FS infrastructure can be upgraded to a higher level.

Possible negative impact (What could go wrong?)

When the security response headers to tighten the security of the AD FS sign-in experience are configured wrongly, scripts can be blocked and the entire functionality of the AD FS implementation can be severely crippled.

When AD FS is used in default scenarios, the default settings for the AD FS security response headers can be safely used.

Getting ready

To change the security headers throughout the AD FS infrastructure, make sure to meet the following requirements:

SYSTEM REQUIREMENTS

Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. At a minimum, make sure AD FS Servers running Windows Server 2016 have the July 2019 Cumulative update (KB4507459) installed.

Note:
The ability to manage security headers is built into Active Directory Federation Services (AD FS) on Windows Server 2019.

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.

How to change the Security Response Headers

There are five security headers of interest:

1. HTTP Strict-Transport-Security (HSTS)
   The HSTS reponse header indicates to the browser that HTTPS is available and should always be used. This way, the connection cannot be downgraded to HTTP for the time period defined. The recommended value is 31536000 seconds (1 year)
2. X-Frame-Options
   The X-Frame-Options response header defines the ways the AD FS sign-in experience can be a part of an iFrame. To prevent attacks, it shouldn’t be, so deny is the best option for this header.
3. X-XSS-Protection
   The X-XSS-Protection response header used to stop web pages from loading when cross-site scripting (XSS) attacks are detected by browsers. This is referred as XSS filtering. The value 1; block is the most effective, as the browser will not render the AD FS sign-in experience when an XSS attack is detected.
4. Cross-origin Resource Sharing (CORS)
   Web browsers prevent web pages from making cross-origin requests initiated from within scripts. This can be enabled to allow accessing resources in other origins (domains). CORS is disabled by default and should remain disabled.
5. Content-Security-Policy (CSP)
   The CSP response header is used to prevent cross-site scripting, clickjacking and other data injection attacks by preventing browsers from inadvertently executing malicious content.

The step to enabling the above security response headers is to run the following line of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -EnableResponseHeaders $true

It should be enabled by default, but if not, running the above line of Windows PowerShell sets the X-Frame-Options security response header to deny on Windows Server 2016.

Note:
On Windows Server 2019, it enables the other four security response headers, too.

Then, run the following four lines of Windows PowerShell in an elevated PowerShell window:

Set-AdfsResponseHeaders -SetHeaderName “Strict-Transport-Security” -SetHeaderValue “max-age31536000; includeSubDomains”

Set-AdfsResponseHeaders -SetHeaderName “X-Frame-Options” -SetHeaderValue “deny”

Set-AdfsResponseHeaders -SetHeaderName “X-XSS-Protection” -SetHeaderValue “1; mode=block”

Set-AdfsResponseHeaders -SetHeaderName “Content-Security-Policy” -SetHeaderValue “default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:”

This will enable the above security response headers with the following settings:

AD FS uses JavaScript in the authentication process and therefore enables JavaScript by including ‘unsafe-inline’ and ‘unsafe-eval’ sources in default policy. While this is not the safest value for the Content Security Policy header, it’s needed to allow the onload.js script to run, to enable customizations of this Javascript and/or to replace the built-in Javascript to switch to the Paginated User Experience for AD FS.

Testing Security Response Headers

SecurityHeaders.com offers a great web interface to query the security response headers of your AD FS infrastructure.

Concluding

Deep in the basement of AD FS, a couple of values live, that true security admins will try to tame: security response headers. Use the information in this blogpost to tame these response headers and prevent common attacks against AD FS.

Further reading

Customize HTTP security response headers with AD FS 2019
An Introduction to HTTP Response Headers for Security
The 8 HTTP Security Headers Best Practices
HTTP Security Headers: 5 Headers You Must Implement on Your Site
Hardening your HTTP response headers

The post HOWTO: Change the Security Response Headers on AD FS appeared first on The things that are better left unspoken.

Recent versions of Azure AD Connect deploy a Service Connection Point (SCP) into your Active Directory Domain Services (AD DS) environment(s). Let's look a bit closer to what this SCP looks like, what it does by default and how you can use and tweak it to your advantage.

About Service Connection Points

Active Directory allows for a specific object that points to specific services. This way, an application, system and/or service administrator can provide guidance on where to find the (nearest) instance of his/her application, system and/or service to domain-joined devices and LDAP-enabled devices.

Many Microsoft and 3rd party applications and services have embraced the concept of service connection points in Active Directory in the past. Microsoft Exchange, Microsoft System Center Configuration Manager (SCCM) and Active Directory Rights Management Services are the ones that come to mind.

About Azure AD Connect's SCPs

Azure AD Connect's Service Connection Point includes information on the following items in its Keywords attribute:

1. azureADId; The Azure Active Directory tenant ID
2. azureADName; The Azure Active Directory tenant's verified custom DNS domain name, or the *.onmicrosoft.com DNS domain name if no verified custom DNS domain name exists for the Azure AD tenant

Azure AD Connect's Service Connection Point exists as:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=domain,DC=tld

The Service Connection Point needs to be available to all domains in the Active Directory forest that contains computer objects.

When is the Service Connection Point created?

Azure AD Connect creates the Service Connection Point in Active Directory, when:

1. You install and configure Azure AD Connect with Express Settings, or;
2. You install and configure Azure AD Connect. Then, you enable Hybrid Azure AD Join while supplying Enterprise Admin credentials, or
3. You install and configure Azure AD Connect. Then, you enable Hybrid Azure AD Join, and use the ConfigureSCP.ps1 script to create the Service Connection Point manually.

Inspecting the keywords

You can easily get the information in the Keywords attribute using the following lines of Windows PowerShell:

$scp = New-Object System.DirectoryServices.DirectoryEntry

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,`
CN=Device Registration Configuration,CN=Services,CN=Configuration,`
DC=domain,DC=tld"

$scp.Keywords

When is the information used?

The information in the Service Connection Point is used by domain-joined devices during their Hybrid Azure AD Join to discover Azure AD tenant information through an LDAP query. The device performs Home Realm Discovery (HRD) based on the azureADName keyword.

Situations with multiple Azure AD tenants

Microsoft's vision scope for Hybrid Azure AD Join and Device WriteBack is one Active Directory forest connected to one Azure AD tenant. However, for complex organizations, this is not feasible. For these organizations, an alternative to the Service Connection Point point to one Azure AD tenant is available as client-side registry settings.

Clear the Service Connection Point

To use this method, clear Azure AD Connect's Service Connection Point object first:

1. Launch ADSI Edit (adsiedit.msc) with an account that is a member of the Enterprise Admins group in Active Directory.
2. Connect to the Configuration Naming Context of your domain.
3. Browse to CN=Configuration,DC=domain,DC=tld, then CN=Services and finally CN=Device Registration Configuration.
4. Right click CN=62a0ff2e-97b9-4513-943f-0d221bd30080 and select Properties from the context menu.
   1. Select Keywords from the Attribute Editor window and click Edit.
   2. Select the values of azureADId and azureADName (one at a time) and click Remove.
5. Repeat steps 2-4 for each domain in the Active Directory forest.
6. Close ADSI Edit.

Create client-side registry settings

Use the following example to create a Group Policy Object (GPO) to deploy a registry setting configuring a Service Connection Point entry in the registry of devices in scope:

1. Open the Group Policy Management console (gpmc.msc)
2. Create a new Group Policy Object where you want to Service Connection Point information to propagate to.
3. Edit the Group Policy Object.
4. Navigate to  Computer Configuration > Preferences > Windows Settings > Registry.
5. Right-click on the Registry node and select New > Registry Item.
6. On the General tab, configure the following:
   1. Action: Update
   2. Hive: HKEY_LOCAL_MACHINE
   3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
   4. Value name: TenantId
   5. Value type: REG_SZ
   6. Value data: The GUID or Directory ID of your Azure AD instance (This value can be found in the Azure portal > Azure Active Directory > Properties > Directory ID)
7. Click OK to save the Registry item.
8. Right-click on the Registry and select New > Registry Item again.
9. On the General tab, configure the following
10. 1. Action: Update
    2. Hive: HKEY_LOCAL_MACHINE
    3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
    4. Value name: TenantName
    5. Value type: REG_SZ
    6. Value data: Your verified domain name if you are using federated environment such as AD FS. Your verified domain name or your onmicrosoft.com domain name for example, contoso.onmicrosoft.com if you are using managed environment
11. Click OK to save the Registry item.
12. Close the Group Policy editor window.
13. Link the newly created group policy object to the desired Organizational Unit (OU) containing domain-joined computers.
14. Close the Group Policy Management console.

How the information can be abused

The information in the Service Connection Point can be abused. The Network Service Scanning technique in the MITRE ATT&CK framework (T1046) specifically hints at the way the information can be abused:

With cloud environment, adversaries may attempt to discover services running on other cloud hosts or cloud services enabled within the environment. Additionally, if the cloud environment is connection to an on-premises environment, adversaries may be able to identity services running on non-cloud systems.

Concluding

Azure AD Connect's Service Connection Point allows for domain-joined devices to perform Home Realm Discovery (HRD). In complex environments and for staged rollouts, client-side registry settings can be used to achieve the same goal.

Further reading

Tutorial: Configure hybrid Azure Active Directory join for managed domains
Tutorial: Configure hybrid Azure Active Directory joined devices manually
Post configuration tasks for Hybrid Azure AD join
Step-by-Step guide to connect down-level devices to Azure AD (in hybrid environment)
How can I locate Service Connection Point for Azure AD connect?
Azure AD Connect: Enabling device writeback

The post A closer look at Azure AD Connect’s Service Connection Point appeared first on The things that are better left unspoken.

In recent days, a new strain of ransomware was detected. It encrypts files and appends their file names with the extension, ".SaveTheQueen". The most interesting part of this malware is it propagates using the SYSVOL share on Active Directory Domain Controllers.

About the Active Directory System Volume

The Active Directory System Volume (SYSVOL) is a shared folder that stores Group Policy information along with optional logon logoff startup and shutdown scripts and their supporting files.

The contents of SYSVOL are public. This means that files stored here can be read by every user and every device, by default. Only members of the Domain Admins and/or Enterprise Admins group have permissions to modify and take ownership, unless permissions have been delegated further.

The System Volume is shared by all Domain Controllers and is replicated between Domain Controllers using Distributed File System Replication (DFSR). In older Active Directory environments NT File Replication Service (NTFRS) may still be used, although it has been deprecated in Windows Server 2019.

SaveTheQueen and the System Volume

Varonis performed an audit trail for this malware and it reveals that:

1. The infected user created a file named "hourly" on the SYSVOL share
2. Many log files were created on the SYSVOL share, each with the name of a device in the domain
3. Many different IP addresses accessed the "hourly" file

They concluded that the log files were used to monitor the infection process on new devices, and that the "hourly" file was a scheduled task that ran malware on new domain-joined devices using a Windows PowerShell script.

The attacker had likely obtained and used domain admin privileges to write files to SYSVOL. The attacker ran PowerShell code on the infected hosts that created a scheduled task to open, decode and run the malware.

This looks like a combination of Mitre ATT@CK Framework steps

Concluding

This strongly reminds me of the way admins in the past would keep tabs on who singed into domain-joined devices or what software is installed on domain-joined devices in the past by having usernames or the output of wmic product written into device-specific files in SYSVOL.

To me, it is the latest sign of malware leveraging the infrastructure that admins rely upon to do their jobs, not for good but for evil.

Further reading

A Queen's Ransom: Varonis Uncovers Fast-Spreading "SaveTheQueen" Ransomware 
God save the Queen […] 'cause Ransom is money – SaveTheQueen Encryptor

The post SaveTheQueen Ransomware leverages Active Directory’s SYSVOL to propagate appeared first on The things that are better left unspoken.

Azure Active Directory is Microsoft's Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft announced a plan for change regarding Azure MFA.

What's announced

Microsoft is planning to replace the current Custom controls (preview) in Conditional Access with an approach that allows partner-provided authentication capabilities to work seamlessly with the Azure Active Directory administrator and end user experiences.

What's the experience today

Custom controls in Conditional Access are in Public Preview since December 17, 2018. This functionality gives organizations the ability to integrate 3rd-party services as controls in Conditional Access, including MFA services from RSA, Duo Security, Trusona and SecureAuth:

Today, 3rd-party MFA solutions face the following limitations:

• They work only after a password has been entered
• They don't serve as MFA for step-up authentication in other key scenarios
• They don't integrate with end user or administrative credential management functions

Today, 3rd-party MFA partner integration is a feature that requires Azure AD Premium P1 subscription licenses.

What's New

The new implementation will allow partner-provided authentication factors to work alongside built-in factors for key scenarios, including:

• Registration
• Usage
• MFA claims
• Step-up authentication
• Reporting
• Logging

Custom controls will continue to be supported in Public Preview alongside the new design until the new design reaches General Availability. At that point, Microsoft will give organizations time to migrate to the new design.

What this means

Starting with this announced preview, organizations can use their existing 3rd-party MFA investments with Azure Active Directory. When the functionality reaches General Availability, they can use 3rd-party MFA in production for far more scenario's than they can currently.

There is currently no information on changes in licensing for the functionality. During the preview phase, it is safe to assume the license requirements remain the same.

Further reading

Custom controls (preview)
Azure AD conditional access custom controls are in public preview
Azure AD + 3rd party MFA = Azure AD Custom Controls

The post Announced: Azure AD to offer more 3rd Party MFA features appeared first on The things that are better left unspoken.

In Hybrid Identity implementations, where objects and their attributes are synchronized between on-premises Active Directory environments and Azure AD tenants, integrity is key; When user objects on both sides have different attributes, or exist multiple times at one side, information security drops to critical levels fast.

To avoid this situation, Azure AD Connect matches user objects from the on-premises Active Directory to Azure AD.

Upon provisioning an object from on-premises Active Directory to Azure AD, Azure AD performs additional actions one time, when compared to updating a user object. These two action are named:

1. Hard Matching
2. Soft Matching

The actions are performed in the above sequence; Hard matching is attempted, before soft matching is attempted. If there's no match, a new user object is created in Azure AD to correspond to the user object in the on-premises Active Directory environment.

Hard Matching

To definitively match an on-premises Active Directory user object to an Azure AD user object, Azure AD Connect looks at the sourceanchor attribute.

During normal synchronization cycles, this attribute is already used to provide the end-to-end connection between the on-premises Active Directory user object and the Azure AD user object through Azure AD Connect's connector spaces and metaverse, so it's an ideal way to match.

The Azure Active Directory Connect wizard, used to configure Azure AD Connect installations provides options to choose the sourceanchor attribute:

The above screenshot is a screenshot of a recent versions of Azure AD Connect. It provides the default option to Let Azure AD manage the source anchor and a list of available attributes to use as an alternative through the Choose a specific attribute option.

Let Azure AD manage the source anchor

When the Let Azure AD manage the source anchor option is selected, Azure AD Connect checks if there is a previous (older) Azure AD Connect installation connected to the Azure AD tenant. If there is, it will default to the objectGUID attribute . If this is the first Azure AD Connect installations, or all other Azure AD Connect installations have already been migrated to use mS-DS-ConsistencyGUID as the sourceanchor attribute for user objects, the mS-DS-ConsistencyGUID attribute is automatically selected as the sourceanchor attribute.

Choose a specific attribute

When you Choose a specific attribute it is important to choose an attribute that:

1. Does not exceed 60 characters in length
2. Does not contain special characters like \ ! # $ % & * + / = ?  and ^
3. Is globally unique throughout your organization
4. Is either a string, integer or binary

A good sourceanchor attribute is not based on a person's name, because this may change, however some organizations still choose to do so, based on the mail attribute…

Note:
The sourceanchor attribute chosen is stored in the configuration of the Azure AD tenant.

Note:
When upgrading or changing settings, Azure AD Connect reports that the Azure AD Connect installation for this tenant still uses objectGUID to synchronize user objects.

Hard matching occurs, based on the following data:

An example for writing the immutableID attribute to an Azure AD object, based on an Active Directory user's objectGUID attribute using Windows PowerShell is:

$user = jos.haarbos@domain.tld

$guid = [guid]((Get-ADUser -Identity $user)").objectGuid)

$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())

Connect-AzureAD

Set-AzureADUser -UserPrincipalName $user -ImmutableId $immutableID

When hard matching provides a match, soft matching is not attempted. However, the non-matching rules still apply.

Soft Matching

When hard matching doesn't provide a match, soft matching is attempted. Soft matching is little more straight-forward than hard matching as it's based on the following data:

Through soft matching, anon-premises Active Directory user object is matched to an Azure AD user object, when:

1. The userPrincipalName attributes match
2. The userPrincipalName attribute for the on-premises user object matches with any of the e-mail addresses in the Azure AD user object's proxyAddresses attribute
3. The primary SMTP address (denoted with SMTP: in the proxyAddresses attribute matches the userPrincipalName or any of the e-mail addresses in the Azure AD user object's proxyAddresses attribute

When soft matching provides a match, hard matching is established at the first synchronization cycle by setting the immutableID attribute for the Azure AD user object, based on the sourceanchor configuration. This is done for disaster recovery purposes: When the (only) Azure AD Connect installation fails, a replacement Azure AD Connect installation can pick up synchronization for end users by accurate hard matching.

Non-matching

To avoid information security-related incidents, like the one pointed out by Dirk-Jan Mollema at Troopers 19, Azure AD Connect no longer attempts to hard match or soft match Active Directory user accounts to Azure AD-based user objects with privileged roles, like the Global Administrator role.

Caveats

Now, the above explanation is straight-forward. There are a couple of caveats, though, that you should take into account:

1. When you delete an object in Azure AD and then synchronize an object from on-premises to Azure AD within 30 days, hard matching and soft matching may not be triggered. Instead the previously deleted object is matched and reanimated. This is because the object was deleted, but not purged from the Azure AD Recycle Bin. Perform the following steps to get the result you want: Delete the object, purge the object, perform a sync cycle.
2. In environments without existing Exchange Online-deployments, when you really don't want an object in Azure AD to be matched with an on-premises AD object, assign the Azure AD object the tenant-specific userPrincipalName suffix (@*.onmicrosoft.com) and clear the immutableID attribute.
3. When the Azure AD Connect installation fails and a replacement Azure AD Connect installation takes over, synchronized user objects in Active Directory matched to Azure AD privileged roles will not be matched. For this scenario:
   1. Make sure at least one non-synchronized Global Admin account exists with the @*.onmicrosoft.com userPrincipalName suffix
   2. Make sure you have Password Hash Synchronization (PHS) deployed

Concluding

Hard matching is useful in both on-premises and cloud migration scenarios and to pinpoint a specific on-premises user object to an Azure AD object.

When things are slightly less difficult, soft matching provides the right amount of flexibility and speed to finish an Azure AD Connect implementation as part of a Hybrid Identity project within the allotted time.

Just remember you can't synchronize admins anymore…

Further reading

Azure AD Connect: When you have an existent tenant
Soft (SMTP) vs. Hard (immutableID) matching with Azure AD Connect
How to use SMTP matching to match on-premises accounts to Office 365 accounts
Azure AD Connect soft- vs. hard matching explained

The post Explained: User Hard Matching and Soft Matching in Azure AD Connect appeared first on The things that are better left unspoken.

Today, I received an e-mail from Nikola Pejková from Veeam congratulating me with being selected for the 2020 Veeam Vanguard Program by the Veeam Vanguard team.

For me, it means I successfully renewed my previous four Veeam Vanguard Awards, dating back to 2016 and can celebrate my first lustrum as a Veeam Vanguard.

I feel honored.

Thank you!

About Veeam Vanguards

The Vanguard program is led by the Veeam Technical Product Marketing & Evangelism team and supported by the entire company. It's a program around the community of Veeam experts that truly get Veeam's message, understand Veeam's products and are Veeam's closest peers in IT.

Veeam Vanguard represent Veeam's brand to the highest level in many of the different technology communities. These individuals are chosen for their acumen, engagement and style in their activities on and offline.

The full list of Veeam Vanguards will be available shortly here.

Further Reading

I am a 2019 Veeam Vanguard
I am a 2018 Veeam Vanguard
I am a 2017 Veeam Vanguard
I am a 2016 Veeam Vanguard

The post I’m a 2020 Veeam Vanguard appeared first on The things that are better left unspoken.

This morning, I received an e-mail message from Maryam Scoble:

VMworld 2019 Distinguished Speaker

Dear Sander,

 

Congratulations on being named a VMworld 2019 Distinguished Speaker. This new program recognizes the hard work of VMworld speakers who maintain a survey score of 4.2 or higher, speaking at sessions with 150 attendees or more over the span of two VMworld conferences, starting with VMworld 2018.

 

We realize lots of hard work, practice and dedication goes into acquiring the knowledge and expertise to skillfully present content to our attendees and they show their appreciation by their survey ratings. You have certainly made your mark! Your Distinguished Speaker designation speaks highly of how well you and your work are perceived by our customers, partners and VMware employees. It is a valuable contribution that deserves our recognition.

Attached was this beautiful award signed by Allison Crooker:

Thank you

As the VMworld Distinguished Speaker award is an award based on the satisfaction scores of VMworld attendees, I'd like to once again thank the people in these sessions for expressing their opinions on the way Deji, Matt and I present on Active Directory during these events.

The post I’m awarded VMworld 2019 Distinguished Speaker appeared first on The things that are better left unspoken.

Azure Active Directory is the identity platform to many of today's organizational applications and services. When you can't sign in, then this poses a big challenge to achieve productivity, either as an administrator or an end-user.

This blogpost provides the instructions to solve the situation, when you receive error AADSTS50052, when signing into Azure AD and Azure AD-integrated applications and services.

The situation

You are a security-focused professional, working for/with an organization that requires strong passwords.

Your organization allows you to sign into Azure AD and/or Azure AD-integrated applications and services using either a cloud-only account or an account that has its password synchronized from an on-premises environment.

The issue

When you sign in to Azure Active Directory and/or an Azure AD-integrated application and/or service, you can't sign in.

Instead, login.microsoft.com provides an error message:

AADSTS50052 InvalidPasswordExceedsMaxLength

You can't sign in.

The cause

The error occurs, because you are trying to sign in with an account that has a password of over 256 characters.

This limit on passwords is in effect in Azure AD since March 13th, 2020, at 10AM PST (18:00 UTC).

The solution

To successfully sign-in, the password needs to be changed.

Cloud-only account

For a cloud-only Azure account, you can reset the password for the account using the Azure AD self-service password reset (SSPR) functionality. Visit https://aka.ms/sspr to do so.

When the Azure AD self-service password reset (SSPR) functionality is not offered by the organization, an administrator needs to reset the password. If all accounts within the Azure AD tenant are configured with passwords over 256 characters, either:

1. Sign in with the initial Azure AD administrator account, as this account is configured with the Azure AD self-service password reset (SSPR) functionality, by default.
2. Sign in with an Azure AD administrator account that is equipped with a FIDO 2 security key.

Synchronized account

For a synchronized account, sign into the on-premises identity platform and reset the password or have the password reset in the on-premises identity platform to a password that is configured with 256 characters or less.

The post KnowledgeBase: You receive error AADSTS50052 when you sign into Azure AD and Azure AD-integrated applications and services appeared first on The things that are better left unspoken.

Yesterday, a new version of Azure AD Connect was released: version 1.5.18.0. This is the first release in the 1.5.x branch of Azure AD Connect.

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

What's New

Azure AD Connect v1.5.18.0 offers the following new features:

Support for the mS-DS-ConsistencyGUID feature for groups

Since Azure AD Connect v1.1.553.0, the mS-DS-ConsistencyGUID attribute can be used as the source anchor for user objects. The benefit of using the mS-DS-ConsistencyGUID attribute instead of the objectGUID attribute is that admins can migrate user objects from one Active Directory forest in scope of Azure AD Connect to another Active Directory forest in scope of Azure AD Connect. Azure AD Connect would automatically reconnect the Azure AD object and Azure AD-integrated applications and services to the new object without having to rely on soft matching.

Now, this feature is also available for group objects. This feature allows admins to move groups between forests or reconnect groups in AD to Azure AD where the AD group objectID has changed, e.g. when an AD server is rebuilt after a calamity. For more information see Moving groups between forests.

Note:
The mS-DS-ConsistencyGUID attribute is automatically set on all groups in scope of Azure AD Connect. There is no required actions to enable this feature.

What's Changed

Azure AD Connect v1.5.18.0 offers the following changes:

Removed the Get-ADSyncRunProfile PowerShell cmdlet

The Get-ADSyncRunProfile PowerShell cmdlet is removed because it is no longer in use.

More information when using an admin account as Connector account

Since Azure AD Connect version 1.4.18.0, using an account with memberships to the Enterprise admins group or the Domain admins group as the AD DS connector account is no longer supported in new Azure AD Connect Deployments.

In version 1.5.18.0, the warning admins see when attempting to use an account with memberships to the Enterprise admins group or the Domain admins group for the AD DS connector account is changed to provide more context.

Introduction of Remove-ADSyncCSObject

Microsoft added a new PowerShell cmdlet to remove objects from the connector space.

The old
CSDelete.exe tool is removed, and it is replaced with the new
Remove-ADSyncCSObject PowerShell cmdlet.

The Remove-ADSyncCSObject PowerShell cmdlet takes a CsObject
as input. This object can be retrieved by using the Get-ADSyncCSObject PowerShell
cmdlet.

What's Fixed

Azure AD Connect v1.5.18.0 offers the following fixes:

• Microsoft a bug in the group writeback forest/OU selector on rerunning the Azure AD Connect wizard after disabling the feature.
• Microsoft introduced a new error page that will be displayed if the required DCOM registry values are missing with a new help link. Information is also written to log files.
• Microsoft fixed an issue with the creation of the Azure Active Directory synchronization account where enabling Directory Extensions or Password Hash Synchronization (PHS) may fail because the account has not propagated across all Azure AD service replicas before attempted use.
• Microsoft fixed a bug in the sync errors compression utility that was not handling surrogate characters correctly.
• Microsoft fixed a bug in the Automatic Upgrades functionality, which left Azure AD Connect in the scheduler suspended state.

Version information

This is version 1.5.18.0 of Azure AD Connect.
This release is the first release in the 1.5 branch for Azure AD Connect. It was made available for download on April 2, 2020.

Download information

You can download Azure AD Connect here.
The download weighs 96.5 MB.

The post Azure AD Connect v1.5.18.0 brings mS-DS-ConsistencyGUID as source anchor for Groups appeared first on The things that are better left unspoken.

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

What's New

Disaster recovery: Download and store provisioning configuration

Service category: App provisioning
Product capability: Identity lifecycle management

The Azure AD provisioning service provides a rich set of configuration capabilities. Organizations need to be able to save their configuration so that they can refer to it later or roll back to a known good version. Microsoft has added the ability for Azure AD administrators to download their provisioning configuration as a JSON file and upload it when they need it.

Azure AD B2B Collaboration available in Azure Government

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

The Azure AD Business to Business (B2B) collaboration features are now available between some Azure Government tenants. To find out if your tenant is able to use these capabilities, follow the instructions at How can I tell if B2B collaboration is available in my Azure US Government tenant?.

Azure AD B2B is planned for Microsoft Azure operated by 21Vianet (Azure China 21Vianet) tenants.

Azure Monitor integration for Azure Logs available in Azure Government

Service category: Reporting
Product capability: Monitoring and reporting

Azure Monitor integration with Azure AD logs is now available in Azure Government. You can route Azure AD Logs (Audit and Sign-in Logs) to a storage account, Event Hub and Log Analytics.

Identity Protection Refresh in Azure Government

Service category: Identity protection
Product capability: Identity security and protection

Microsoft is excited to share that they have now rolled out the refreshed Azure AD Identity Protection experience in the Microsoft Azure Government portal.

What's Changed

Azure AD sign-in logs are now available for all free tenants through the Azure portal

Service category: Reporting
Product capability: Monitoring and reporting

Starting now, organizations who have free tenants can access the Azure AD sign-in logs from the Azure portal for up to 7 days. Previously, sign-in logs were available only for customers with Azure Active Directory Premium licenses. With this change, all tenants can access these logs through the portal.

Note:
Organizations still need a premium license (Azure Active Directory Premium P1 or P2) to access the sign-in logs through Microsoft Graph API and Azure Monitor.

Password length is limited to 256 characters

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

To ensure the reliability of the Azure AD service, user passwords are now limited in length to 256 characters. Users with passwords longer than this will be asked to change their password on subsequent sign in, either by contacting their admin or by using the self-service password reset feature.

This change was enabled on March 13th, 2020, at 10AM PST (18:00 UTC), and the error is AADSTS 50052, InvalidPasswordExceedsMaxLength.

HomeRealmDiscovery policy changes appear in the audit logs

Service category: Audit
Product capability: Monitoring and reporting

Microsoft fixed a bug where changes to the HomeRealmDiscovery policy were not included in the audit logs. Admins can now see when and how the policy was changed, and by whom.

SSPR now requires two gates for admins in Azure China 21Vianet

Service category: Self-Service Password Reset
Product capability: Identity security and protection

Previously in Microsoft Azure operated by 21Vianet (Azure China 21Vianet), admins using self-service password reset (SSPR) to reset their own passwords needed only one "gate" (challenge) to prove their identity. In public and other national clouds, admins generally must use two gates to prove their identity when using SSPR. But because Microsoft didn't support SMS or phone calls in Azure China 21Vianet, Microsoft allowed one-gate password reset by admins.

Microsoft has created SSPR feature parity between Azure China 21Vianet and the public cloud. Going forward, admins must use two gates when using SSPR. SMS, phone calls, and Authenticator app notifications and codes are supported.

What's deprecated

Deprecation of Directory-wide groups option from Groups General Settings on Azure portal

Service category: Group management
Product capability: Collaboration

To provide a more flexible way for organizations to create directory-wide groups that best meet their needs, Microsoft has replaced the Directory-wide Groups option from the Groups > General settings in the Azure portal with a link to dynamic group documentation. Microsoft has improved its documentation to include more instructions so administrators can create all-user groups that include or exclude guest users.

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

When working with Veeam products, you'll be familiar with the *.vbk extension. Veeam uses this file extension to store back-ups, made with Veeam Backup & Replication (VBR).

Based on the popular demand from my fellow Dutch Veeam Vanguard Maurice Kevenaar, Veeam now has published the Extract utility as a separate download on their web-site. This can be found under the Additional Downloads to Veeam's Software for Enterprise section on the main download page.

About the Extract utility

Previously, the Extract utility was only part of Veeam Backup & Replication (VBR) installations. With a file size of roughly 5 GB for its installation ISO file, it might prove to be a hurdle in an environment with nothing left and you need to download it using 4G… or you need to get things up and running fast, but now you need to first install VBR before getting to the utility…

This is why the Extract utility is now available as a separate download.
The Extract utility is provided in three flavors and available for both Windows and Linux:

1. Windows command line tool, usable without pre-requisites
2. Windows command-line tool with an optional user interface, that requires .NET Framework 4.7.2
3. Linux console utility

At a mere 5MB, the Extract utility ZIP file saves a lot of time downloading and installing version 10.0.0.4461 of the Extract utility.

When to use the Extract utility

The Extract utility can be useful in disaster recovery situations, where there is nothing left and, for instance, you need to recover that first Domain Controller that allows you to deploy Veeam Backup and Replication again and restore everything else, due to permissions throughout the environment. In this case it may be a faster option to extract data from local backup files.

However, if you do need a temporary Veeam Backup & Replication (VBR) installations, Veeam recommends downloading and installing VBR Community Edition, just due to the sheer amount of restore options it provides.

The post Veeam now provides a stand-alone VBK Extract Utility appeared first on The things that are better left unspoken.

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 March 2020:

Windows Server 2016

We observed the following updates for Windows Server 2016:

KB4540670 March 10, 2020

The March 10, 2020 update for Windows Server 2016 (KB4540670) updating the OS build number to 14393.3564 includes both security and quality improvements.

None of these improvements are Identity-related.

KB4541329 March 17, 2020

The March 10, 2020 update for Windows Server 2016 (KB4541329) updating the OS build number to 14393.3595 includes Active Directory Domain Services and Active Directory Federation Services fixes:

Active Directory Domain Services

The following Active Directory Domain Services fixes are included in KB4541329:

1. It addresses an issue that might cause Domain Controllers to register a lowercase and a mixed or all uppercase Domain Name System (DNS) service (SRV) record in the _MSDCS.<forest root domain> DNS zone. This occurs when Domain Controller computer names contain one or more uppercase characters.
2. It addresses an issue that prevents machines that have enabled Credential Guard from joining a domain. The error message is "The server's clock is not synchronized with the primary domain controller's clock."

Active Directory Federation Services

This update addresses an issue with high CPU usage on Active Directory Federation Services (AD FS) servers that occurs when the backgroundCacheRefreshEnabled feature is enabled.

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB4538461 March 10, 2020

The March 10, 2020 update for Windows Server 2019 (KB4538461) updating the OS build number to 17763.1098 includes both security and quality improvements.

None of these improvements are Identity-related.

KB4541331 March 17, 2020

The March 17, 2020 update for Windows Server 2019 (KB4541331) updating the OS build number to 17763.1131 includes Active Directory Domain Services and Active Directory Federation Services fixes:

Active Directory Domain Services

The following Active Directory Domain Services fixes are included in KB4541331:

1. It addresses an issue that might cause Domain Controllers to register a lowercase and a mixed or all uppercase Domain Name System (DNS) service (SRV) record in the _MSDCS.<forest root domain> DNS zone. This occurs when Domain Controller computer names contain one or more uppercase characters.
2. It addresses an issue that prevents machines that have enabled Credential Guard from joining a domain. The error message is "The server's clock is not synchronized with the primary domain controller's clock."
3. It restores the constructed attribute in Active Directory and Active
   Directory Lightweight Directory Services (AD LDS) for msDS-parentdistname. 
4. It addresses an issue that creates the Storage Replica administrator group
   with the incorrect SAM-Account-Type and Group-Type.
   This makes the Storage Replica administrator group unusable when moving the
   Primary Domain Controller emulator (PDCe) Flexible Single Master Operations
   (FSMO) role.

Active Directory Federation Services

The following Active Directory Federation Services fixes are included in KB4541331:

1. It addresses high latency in Active Directory Federation Services (AD FS) response times for globally distributed datacenters in which SQL might be on a remote datacenter.
2. It improves the performance for all token requests coming to AD FS, including OAuth, Security Assertion Markup Language (SAML), WS-Federation, and WS-Trust.
3. It addresses a high latency issue in acquiring OAuth tokens when AD FS front-end servers and back-end SQL servers are in different datacenters.
4. It addresses an issue to prevent SAML errors and the loss of access to third-party apps for users who do not have multi-factor authentication (MFA) enabled.
5. It addresses an issue with high CPU usage on Active Directory Federation Services (AD FS) servers that occurs when the backgroundCacheRefreshEnabled feature is enabled.

KB4554354 March 30, 2020

The March 30, 2020 update for Windows Server 2019 (KB4554354) updating the OS build number to 17763.1132 addresses an issue that was introduced with KB4527818 on February 25, 2020. It is not an Identity-related update.

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

Just like every month, Microsoft released cumulative quality updates to its supported Operating Systems in March 2020. This month's updates, however, show a particular focus on several fixes for Azure AD-joined and Hybrid Azure AD-joined Windows 10 devices.

Let's take a look:

What's fixed

The respective updates for Windows 10 address these three issues:

1. It addresses an issue that might cause a delay of up to two minutes when signing in or unlocking a session on Hybrid Azure Active Directory-joined machines.
2. It addresses an issue that causes authentication in an Azure Active Directory environment to fail and no error appears.
3. It addresses an issue that causes authentication to fail when using Azure Active Directory and the user's security identifier (SID) has changed.

Updates

The issues are fixed in these respective updates:

Guidance

When you are experiencing issues with Azure AD-joined and Hybrid Azure AD-joined Windows 10 devices, then give priority to the March 2020 cumulative quality update for the respective Windows 10 version(s) in your organization(s) over older updates.

The post Improvements for (Hybrid) Azure AD-joined Windows 10 devices in the March 2020 Cumulative Updates appeared first on The things that are better left unspoken.

For many organizations, the reality is that their on-premises systems need to communicate to Microsoft cloud services. Whether it is for Azure AD Connect, Azure AD Connect Health, Azure AD Password Protection, or the Azure MFA NPS extension, you'll need to install either or both the MSOnline or AzureAD PowerShell modules.

On Windows Server 2016-based installations, however, you may run into a problem quickly, when you just want to download and install the module.

The situation

You run a Windows Server 2016-based installation.

You want use the installation to communicate with Azure Active Directory programmatically. You want to:

• Install the the MSOnline or AzureAD PowerShell module,
• Run the configuration script for Azure AD Connect Health for AD FS
• Run the configuration script for Azure AD Connect Health for AD DS,
• Run the configuration script for Azure AD Password Protection, or
• Run the configuration script for the Azure Multi-factor Authentication extension to Microsoft Network Policy Server (NPS).

Note:
All the above situations result in installing and registering the NuGet provider and installing either the MSOnline or AzureAD PowerShell module

You are prompted that PowerShell requires the NuGet provider version 2.8.5.201 or newer to interact with NuGet-based repositories. It asks you want PowerShellGet to install and import the NuGet provider.

You click 'Yes' or type Y.

The issue

You receive the below Windows PowerShell error:

WARNING: MSG:UnableToDownload «https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409» «»

WARNING: Unable to download the list of available providers. Check your internet connection.

WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ".

Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.

The cause

The error is caused by the way Windows PowerShell interacts with the NuGet infrastructure delivering both the NuGet Package Provider and the Windows PowerShell Module.

The entire infrastructure is secured with SSL/TLS. This prevents eavesdropping and meddle in the middle-type attacks, where a malicious person with inject rogue code into a plain-text communication stream.

Windows PowerShell does not communicate with the infrastructure using TLS 1.2, but with a less secure encryption protocol. As with many other infrastructure, the NuGet infrastructure has switched off less secure encryption protocols. The best current way on Windows Server 2016 to interact with the infrastructure is using TLS 1.2.

The solution

To download the NuGet Package Provider and the MSOnline or AzureAD PowerShell module, issue the following line of Windows PowerShell first:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Then, repeat the line of Windows PowerShell to install the PowerShell module.

The post Knowledgebase: You receive error ‘Unable to download’ when you try to install the AzureAD or MSOnline PowerShell Module appeared first on The things that are better left unspoken.

Hot on the heels of Azure AD Connect version 1.5.18.0, Microsoft is releasing a new version of Azure AD Connect to fix an issue introduced in that first version of this 1.5.x.x branch of Azure AD Connect versions.

This is an important version if your organization has deployed Group Filtering.

About Azure AD Connect Group Filtering

As stated in the Microsoft Documentation, you can configure Azure AD Connect to filter users and devices based on a group membership. The Group Filtering feature is available on the Filter users and devices page, when you initially configure Azure AD Connect when using the custom installation path:

There a couple of things you should know:

• When you disable group-based filtering, it can't be enabled again.
• It's not supported to use group-based filtering in a custom configuration. It's only supported to configure this feature by using the installation wizard.
• When using OU-based filtering in conjunction with group-based filtering, the OU where the group and its members are located must be included (selected for synchronization).
• Nested group membership is not resolved – objects to synchronize must be direct members of the group used for filtering.
• When synchronizing multiple Active Directory forests, you can configure group-based filtering by specifying a different group for each AD connector.

What's fixed

This hotfix build fixes an issue with Azure AD Connect version 1.5.18.0 if your organization has the Group Filtering feature enabled and use mS-DS-ConsistencyGUID as the source anchor.

As the Group Filtering feature is intended for pilot deployments only, and when used Azure AD Connect only synchronizes a small set of objects, the impact of the issue is not a complete fallout. Instead, it is worth noting that you want to use version 1.5.20.0 for your pilot deployments, instead of a previous download of version 1.5.18.0. A lot can happen in one week.

Version information

This is version 1.5.20.0 of Azure AD Connect.
This release is the first release in the 1.5 branch for Azure AD Connect. It was made available for download on April 9, 2020.

Download information

You can download Azure AD Connect here.
The download weighs 96.6 MB.

The post Azure AD Connect version 1.5.20.0 fixes an issue with Group Filtering appeared first on The things that are better left unspoken.

On April 22nd, 28th and 30th, 2020, I'll present three 1-hour webinars with Netwrix. Tune in to get the best in Active Directory security, Hybrid Identity and Azure AD Hardening demonstrated from me and Netwrix' Jeff Melnick!

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

Wednesday April 22nd, 10 AM Pacific Time / 1PM Eastern Time

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 to security AD changes.

WEBINAR 2, CONNECTING ACTIVE DIRECTORY TO AZURE AD

Wednesday April 28th, 10 AM Pacific Time / 1PM Eastern Time

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

Wednesday April 30th, 10 AM Pacific Time / 1PM Eastern Time

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.

Register here.

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 empowers information security and governance professionals to reclaim control over sensitive, regulated and business-critical data, regardless of where it resides.

Over 10,000 organizations worldwide rely on Netwrix solutions to secure sensitive data, realize the full business value of enterprise content, pass compliance audits with less effort and expense, and increase the productivity of IT teams and knowledge workers. Founded in 2006, Netwrix has earned more than 150 industry awards and been named to both the Inc. 5000 and Deloitte Technology Fast 500 lists of the fastest growing companies in the U.S.

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

With Security Defaults being the norm in newly created Azure AD tenants and their respective Office 365 tenants, it's a good time to look at how Veeam Backup for Office 365 offers modern authentication since version 3.

Setting up modern authentication requires these five steps after you've downloaded and installed Veeam Backup for Office 365:

1. Creating an app registration in Azure AD
2. Delegate the right permissions to the custom application
3. Create a service account in Azure AD
4. Create an app password for the service account
5. Create a new organization in Veeam Backup for Office 365

Note:
For the purposes of this blogpost, I'm configuring Veeam Backup for Office 365 4b (version 4.0.0.2516).

Step 1: Creating an app registration in Azure AD

Now it's time to create a Veeam Backup for Office 365-specific app registration. Follow these steps to do so:

• Open a web browser and navigate to https://portal.azure.com.
• Sign in with an account that has the Global administrator role assigned, or the combination of the Cloud application administrator, Privileged Role administrator and Application administrator roles.
• Perform multi-factor authentication when prompted.
• In the left navigation pane for the Azure Portal, click on Azure Active Directory.
• In the Azure AD-specific navigation menu, click on App registrations.
• In the main App registration pane, click the + New registration link in the taskbar.
  The Register an application pane appears.

• For the Name field, enter a meaningful name for the app registration that follows your organization's naming convention for app registrations.
• Click the Register button at the bottom of the pane.

You have now created an application registration with default permissions and are taken directly to its Overview pane.

Step 2: Delegate the right permissions to the custom application

The default permissions are a bit excessive on one side, but also lacking on the other side. It's time to set the right permissions. Follow these steps to do so:

• On the App registration's Overview pane, note the value for Application (Client) ID. Copy it into a Notepad window, for instance, as it's a GUID and you don't want to enter it incorrectly. We need to enter this value into Veeam Backup for Office 365 when configuring the organization.
• Click on the View API permissions button.
  The VBO-AppRegistrationName | API Permissions page appears.
• On the line that lists the User.Read permissions, click on the three dots at the end of the line and click Remove Permission to remove this default permission. Veeam Backup for Microsoft Office 365 does not need this particular permission.

• Click Yes, remove to do so.
• Click the + Add a permission button.
  The Request API permissions page appears.
  • Click the Microsoft Graph tile.
  • Click the Application permissions tile.
  • In the list of permissions, select Directory.Read.All under Directory.
  • In the list of permissions, select Group.Read.All under Groups.
  • Click the Add permissions button at the bottom of the pane.
• You are taken back to the VBO-AppRegistrationName | API Permissions page.
• Click the + Add a permission button again.
  The Request API permissions page appears.
  • Click the Exchange API tile.
  • Click the Application permissions tile.
  • Select the full_access_as_app permission.

• Click the Add permissions button at the bottom of the pane.
  You are taken back to the VBO-AppRegistrationName | API Permissions page.
• Click the + Add a permission button again.
  The Request API permissions page appears.

• • Click the SharePoint API tile.
  • Click the Application permissions tile.
  • Select the Sites.FullControl.All permission under Sites.
  • Click the Add permissions button at the bottom of the pane.
• Back on the VBO-AppRegistrationName | API Permissions page, click the Grant admin consent for TenantName button.
• Answer Yes to the question 'Do you want to grant consent for the requested permissions for all account in TenantName? This will update any existing admin consent records this application already has to match what is listed below.'

The app registration in Azure AD now has the required API permissions to interact with Office 365's Exchange Online, SharePoint Online and OneDrive for Business. Let's specify the certificate we've created earlier:

• In the VBO-AppRegistrationName navigation pane, on the left side, click on Certificates & secrets.
• In the VBO-AppRegistrationName | Certificates & secrets pane, click the + New client secret button.
• In the Add a client secret modal, type a description for the shared secret in the Description field if you think this helps identify your actions.
• Select an expiration time that is appropriate for your organization, or except the default of 1 year.
• Click the Add button.
• Copy the value of the client secret and note it down.

You are now done with specifying the app registration for Veeam Backup for Office 365.

Note:
As you might have noticed, the default lifetime of a client secret for an app registration is valid for 1 year. After this period, you'll have to perform the steps again, then update the information in Veeam Backup for Office 365.

Step 3: Create a service account in Azure AD

The next item on our list is to create the service account Veeam Backup for Office 365 in Azure Active Directory. Follow these steps to do so:

• In the Azure Portal, click on Azure Active Directory in the left most navigation menu. This leads back to the Overview page of the Azure AD tenant.
• In Azure AD's navigation menu, click on Users.
• click the + New user link in the taskbar.
  The New User pane appears.
• Provide a User name.
• Scroll down a bit to the Password area. Underneath the greyed-out field for password, select the Show Password option. Copy the password.
• Scroll down a bit further to the Groups and Roles are.
• Click the User link, next to Roles to change the roles for the service account.
  The Directory roles pane appears.
• Select the following two roles from the list of Directory roles:
  • Exchange administrator
  • SharePoint administrator
• Click the Select button at the bottom of the pane.
  You are lead back to the New User pane.
• Click the Create button at the bottom of the pane.
• Close the Azure Portal by closing your browser.

Memberships to the Exchange administrator or SharePoint administrator role automatically requires multi-factor authentication when signing in when Security Defaults are enabled.

Step 4: Create an app password for the service account

Let's sign in one time with the Veeam Backup for Office 365 service account to configure a strong password and configure multi-factor authentication:

• Open an incognito window of your web browser.
• Navigate to https://myprofile.microsoft.com.
• At the sign-in page enter the userPrincipalName for the Veeam Backup for Office 365 service account. Click the Next button afterward.
• Enter the password.
• Now, update the password by typing in or pasting the current password and then typing in or pasting the new strong password twice. Click Sign in when done.
• You'll be required to setup multi-factor authentication as your organization needs more information to keep the account secure. Click Next.

• Register the Microsoft Authenticator app first:
  • Download the Microsoft Authenticator App on a mobile device.
  • On the Start by getting the app screen, click Next.
  • On the Set up your account screen, click Next.
  • Open the Microsoft Authenticator App on the mobile device. In the right top corner of the app tap the + sign, select Work or school account and scan the QR code.
  • In the web browser click Next.
    Microsoft performs the multi-factor authentication method a first time. Approve the sign-in on the mobile device.
  • In the web browser click Next.
• Now, register the phone method:
  • On the Phone screen, select your country and enter the phone number.
  • Click Next.
    Microsoft sends you a one-time passcode in a text message.
  • Type the passcode on the Phone screen in the browser.
  • Click Next.
  • In the web browser click Next.
• Click the Done button.
• Sign in again.
  You will be taken to the My account experience.

• Click the UPDATE INFO > link on the Security info tile to add sign-in methods.
• Click the + Add method link at the top of the list of currently configured sign-in methods.
  The Add a method pop-up appears.
• In the Add a method pop-up, select App password from the drop-down list of methods.
• Enter a meaningful name for the app password. Include the service and server name as a bare minimum.
• Click Next.
• Copy the app password.
• Click Done.
• Close the browser window.

Step 5: Create a new organization in Veeam Backup for Office 365

Perform the following actions to Create a new organization in Veeam Backup for Office 365:

• Open Veeam Backup for Office 365 on the Windows Server installation where you've installed Veeam Backup for Microsoft Office 365.
• In the top-left corner of the application, click Add Org from the taskbar.
  The ADD ORGANIZATION pop-up window appears.
• On the Organization deployment type screen, click Next to select the default settings.
• On the Office 365 connection settings screen, select your specific sovereign Office 365 region, or choose Default to choose the default Office 365 regions.

• Make sure Modern authentication is selected and click Next.

• On the Exchange Online Credentials screen;
  • Supply the Application (Client) ID for the app registration in Azure AD in the field for Application ID:.
  • Enter the application secret in the Application secret: field.
  • Browse the certificate from the local computer's certificate store and select it. Click Finish when done.
  • Supply the username and the app password for the Veeam Backup for Office 365 service account.
• Click Next.

Now follow the rest of the steps to configure or reconfigure your Veeam Backup for Office 365 installation to your organization's needs.

The post Configuring Veeam Backup for Microsoft Office 365 with Modern Authentication appeared first on The things that are better left unspoken.

Multi-factor authentication is the current solution to the problem of inadequate information security in today's world of user names and passwords. When you have enabled multi-factor authentication in Microsoft Azure and Office 365, you might need app passwords to allow for certain access to not disrupt the business.

The situation

As an organization, you use Microsoft Azure Active Directory (Azure AD). Your colleagues access data and functionality through Azure AD-integrated applications, services and systems. Your organization uses the default settings in Azure AD.

You have enabled multi-factor authentication through either:

1. Security Defaults
2. Conditional Access

A colleague needs to access functionality and/or data through an outdated application or needs a service to communicate with your data using a privileged account in a situation that requires multi-factor authentication by your information security policies.
(in the latter case, as an Azure AD admin you create and optionally synchronize an account with least privileges as the service account)

The colleague cannot log in using modern authentication, is not prompted for multi-factor authentication, and as a result, is unable to gain access to the functionality or data.

You do not want to make an exception to the policies, so you allow the colleague to use one or more app passwords.

You instruct the user to create an app password. He or she performs the following steps:

• He or she opens a web browser on her system and navigates to https://myaccount.microsoft.com/security-info.
• He or she signs in using the credentials for the account.
• He or she performs multi-factor authentication to gain access to multi-factor authentication management mode as part of the MyProfile / MyAccount experience.
• He or she clicks on the UPDATE INFO > link on the Security info tile.
  The link leads to the Security info page.
• He or she presses the + Add method button.
  The Add a method modal screen appears.
• He or she opens the drop-down list of available methods.

The issue

The drop-down list for Add a method doesn't offer to create an App password.

The cause

The colleague cannot create an App password, because multi-factor authentication is required through Conditional Access or Security Defaults

The solution

To be able to create an App password, the account needs to be configured with the per-account multi-factor authentication requirement.

Note:
For accounts that are used as daily accounts for colleagues, configuring per-account multi-factor authentication results in a painful experience, as these settings override Conditional Access policies and Security Defaults and require multi-factor authentication for every sign-in with the account, unless remember multi-factor authentication is enabled. For these purposes, another solution is recommended; either create a separate service account or migrate to an app(lication) that the user can use with modern authentication.

Follow the below steps to enable per-user multi-factor authentication for an account:

• Open a browser and navigate to the Azure AD Portal.
• Sign in with an account that has the Global administrator or Privileged Authentication administrator role assigned.
• In the left navigation pane, click Azure Active Directory.
• In Azure Active Directory's navigation pane, click on Security.
• In the Security navigation pane, click on MFA.
• In the Multi-Factor Authentication | Getting started main pane click the Additional cloud-based MFA settings link.
  A new browser tab or window opens with the multi-factor authentication page.
  On the Service settings tab you should see that the option to Allow users to create app passwords to sign in to non-browser apps is enabled by default.
• Click the Users tab.
  On the Users tab, you should see a list of user objects within the Azure AD tenant.
• Search the user object, or select it from the list of users.
• In the area to the right of the users list, you should see the following links for the user object:
  1. Enable
  2. Manage user settings
• Click the Enable link.
• In the About enabling multi-factor auth modal window, click the enable multi-factor auth button.
• In the Updates successful modal screen, click the close button.
• The value in the MULTI_FACTOR AUTH STATUS column for the user object should now show Enabled.
• In the area to the right of the users list, a new link appears: Enforce.
• Click Enforce.
• In the About non-browser applications modal, click the enforce multi-factor auth button.
• In the Updates successful modal screen, click the close button.
  The value in the MULTI_FACTOR AUTH STATUS column for the
  user object should now show Enforced.
• Sign out and ask the colleague to try and create an App password again.

After a few minutes, the colleague should be able to create an App password in multi-factor authentication management mode as part of the MyProfile / MyAccount experience.

Note:
After the app password is set, the per-account multi-factor authentication requirement can be removed by clicking the Disable link in the are to the right of the users list in the multi-factor authentication portal.

Concluding

Fumbling around in legacy portals to change legacy settings for legacy applications is quite the experience. I hope the whole ordeal left you with the bittersweet aftertaste of 'Let's not do this again'.

The post KnowledgeBase: App Passwords are only available to users with a non-Conditional Access MFA requirement appeared first on The things that are better left unspoken.

We've migrated many Active Directory Federation Services (AD FS) implementations from Windows Server 2012 R2 to Windows Server 2016 and beyond. This blogpost intends to share our experiences during these migrations, so you can take advantage of them during your migrations.

How we migrate

In general, we migrate AD FS servers by adding additional AD FS servers to the AD FS Farm. From there, we take one of three routes:

1. We cut over the external IP address of the AD FS Farm in the internal DNS zone to the new AD FS server. If applicable, we also change the IP address of the AD FS Farm in the perimeter DNS zone or in the HOSTS file of Web Application Proxy server(s). This is our usual path when an organization wants to migrate one single AD FS server to a new one.
2. We add the additional AD FS server(s) to the load-balancer that spreads the authentication requests to a pool of AD FS servers. After a short period of coexistence to check if everything works, we remove the AD FS server(s) the organization no longer wants to use. This is our usual path when an organization has a load-balancer in place; a typical situation when an organization has deployed multiple AD FS servers.

What is migrated

Some settings are configured, by default, when you add an AD FS server to an existing AD FS Farm, while others require manual migration:

Created, by default

By default, the following settings and configuration items are automatically provisioned on additional AD FS servers to the same AD FS farm:

• The certificate-based trust to the Active Directory Federation Services (AD FS) farm for the Web Application Proxy server(s)
• Membership to the AD FS Farm's FarmNodes configuration for the AD FS farm
• User rights assigments and delegations for the AD FS (managed) service account
• Windows Firewall exceptions to allow inbound communications

Migrated, by default

By default, the following settings and configuration items are automatically provisioned on additional AD FS servers to the same AD FS farm:

• Configuration of all Relying Party Trust (RPT) and AD FS endpoints
• Device Registration settings
• Token-signing and Token-decrypting certificates
• The AD FS certificate, but only when the additional AD FS server is created through the Azure AD Connect wizard

Needs to manually be set or migrated

However, important parts need to be migrated or configured manually:

• The AD FS certificate, unless the additional AD FS Server is created through the Azure AD Connect wizard
• Name resolution to relying parties, when it is not dependent on a DNS infrastructure
• Any firewall rules between the AD FS server and the (load balancer for the) Web Application Proxy Server(s)
• Any firewall rules
  • between the AD FS server and the (virtual IP address and the individual nodes of the) SQL Server (cluster or Always-on Availability Group), if SQL Server is used to host the AD FS Configuration Database (by default: TCP1433), or
  • between the AD FS server and the other AD FS servers, if Windows Internal Database (WID) is used to host and synchronize changes to the AD FS Configuration Database (by default: TCP80)
• Any network firewall rules and/or network proxy exceptions between the AD FS server and the relying parties
• When the last AD FS server for a down-level version of Windows Server is decommissioned, the AD FS Farm Behavioral Level (FBL) needs to be upgraded. This is a manual action.

Creating an inventory

To transition AD FS servers, it's a good idea to create an inventory beforehand. Answer these questions:

Q1 What does the AD FS farm look like?

Determine the amount of AD FS servers that are part of the AD FS farm and their hostnames, so you can check the routes and firewall rules from any (new) AD FS server. Run the following line of Windows PowerShell from the AD FS server that is the primary server in case of WID, or any AD FS server when Microsoft SQL Server is used to host the AD FS configuration database:

(Get-AdfsProperties).Hostname

(Get-AdfsProperties).ArtifactDbConnection

(Get-AdfsFarmInformation).FarmNodes | Format-Table

The above three cmdlets return the URL of the AD FS Farm, whether its using Windows Internal Database (WID) or a Microsoft SQL Server as the AD FS configuration database and a table with all the AD FS servers, including their roles in the AD FS farm.

Q2 What domain are the AD FS servers joined to?

As all AD FS servers in an AD FS farm need to be joined to the same Active Directory domain, we'll look up the DNS domain name using any one of the AD FS servers with the following line of Windows PowerShell:

(Get-WmiObject Win32_ComputerSystem).Domain

Q3 What are the current Relying Party Trusts?

To gather this information, you need to run the following lines on the AD FS server that is the primary server in case of WID, or any AD FS server when Microsoft SQL Server is used to host the AD FS configuration database::

(Get-ADFSRelyingPartyTrust).Name | Format-Table

(Get-ADFSRelyingPartyTrust).MetadataUrl | Format-Table AbsoluteUri

The above two cmdlets return the names of the Relying Party Trusts (RPTs) configured on the AD FS farm, and their federation metadata URLs.

Q4 What do the AD FS servers use for name resolution?

Now that we know the URLs for the AD FS Farm, and federation metadata URLs for relying parties, we can determine the name resolution method used by the AD FS servers. They're either using a DNS server or using the HOSTS file. The above URLs are mostly covered by DNS, but a safe check is to check the HOSTS file for uncommented entries on the current AD FS server(s) with the following line of PowerShell:

Get-Content C:\Windows\System32\drivers\etc\hosts | Select-String -NotMatch "^#"

Entries in the HOSTS file indicate IP addresses used by AD FS servers to locate services and hosts.

Q5 What additional routes do the AD FS servers use?

Use the following line of Windows PowerShell to find any additional routes that the current AD FS server(s) use:

Get-NetRoute

Q6 What are the AD FS Certificates in use?

An AD FS Farm uses three certificates:

1. The Service Communications certificate
2. The Token-signing certificate
3. The Token-decrypting certificate

To get a handle on all three, use the following Windows PowerShell scripts:

$ADFSCerts = Get-AdfsCertificate

$CertArray = @()
ForEach ($Cert in $ADFSCerts) {
$CertObject = [PSCustomObject]@{
CertificateType = $Cert.CertificateType
Subject = $Cert.Certificate.Subject
NotAfter = $Cert.Certificate.NotAfter
}
$CertArray += $CertObject
}

$CertArray

This outputs a table with the three AD FS-specific TLS certificates, together with their subjects and their expiry dates.

Q7 What are the current certificates in use?

We also need to know which other TLS certificates are available on the current AD FS servers. As we're only interested in TLS certificates for the local machine, we can use the following lines of PowerShell:

Set-Location Cert:\LocalMachine\My

Get-ChildItem | Format-Table FriendlyName, Subject, NotAfter

This outputs a table with TLS certificates, together with their subjects and their expiry dates.

Implement the new AD FS server

Implementing the new AD FS server is easy. Simply create a new (virtual) machine with your favorite supported Windows Server version on it.

A1 Domain-join the AD FS server

As stated for Q2, all AD FS servers in the same AD FS farm need to be joined to the same Active Directory domain. With the answer of Q2, join the AD FS server to the domain using the following two lines of Windows PowerShell:

Add-Computer -DomainName "domain.tld"

Restart-Computer

Note:
You may have to configure a fixed IP address and/or DNS server address on the Windows Server installation before you're able to join the Active Directory domain.

A2 Take care of the basics

Although domain-joining a Windows Server installation to Active Directory takes care of most things, double check that the Windows Server installation is activated, up to date with Windows Updates, protected with an anti-malware solution and configured with the right time and time zone before you continue with the next steps.

A3 Implement the required name resolution method

The new AD FS server needs to be able to resolve the hostname for AD FS server(s) and the federation metadata URLs. When the answer to Q4 pops up with HOSTS file entries, then recreate these on the new AD FS server as well.

A4 Configure the right networking settings

As the new AD FS server needs to be able to communicate to the other AD FS server(s) or the SQL Server (cluster), the Web Application Proxy servers, the federation metadata URLs for its relying parties and any other services, systems and/or applications on your network, Take care of:

• The necessary routes,
• Firewall rules and
• Proxy exceptions.

The required information is in the answers to questions Q3 and Q5.

A5 Install the certificate(s)

Install the same TLS certificate(s) that is/are used by the current AD FS server(s) on the new AD FS server, too. Export these certificates from the current Web Application Proxy server(s) and/or AD FS server(s) with their private keys, or download the certificate(s) again from your certification authority.  The required information is in the answers to questions Q6 and Q7.

A6 Install the AD FS Server feature

Run the following lines of Windows PowerShell to install the AD FS Server feature:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

A7 Configure the AD FS Server

Run the following lines of Windows PowerShell to configure the AD FS server:

Note:
This example uses a user account as AD FS service account and adds the server to the AD FS farm, based on the Primary Server in a WID setup. Here is an example that uses SQL Server and a group Managed Service Account.

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject –match "sts.domain.tld"}).Thumbprint

$ServiceCred = Get-Credential

Add-AdfsFarmNode -CertificateThumbprint $thumb -ServiceAccountCredential $ServiceCred –PrimaryComputerName PrimaryServerDNSName

Restart-Computer

Alternatively:
As an alternative to actions A5 through A7, you can also use the Azure Active Directory Connect Configuration wizard to install the certificate, install the AD FS Server feature and add the AD FS server to the AD FS Farm. This method requires traffic over TCP port 5985 from the Azure AD Connect server(s) to the AD FS server(s).

A8 (Optionally) Configure Azure AD Connect Health

To monitor the health of the new AD FS server, install the Azure AD Connect Health agent for AD FS onto it and configure it. Through the Azure AD Connect Health dashboard that is part of the Azure Portal, you can then see the activity and health for the AD FS server when you put it in use.

A9 Harden the AD FS server

Of course, you want to apply hardening before you put the AD FS server in use. Refer to these earlier blogposts for my hardening recommended practices:

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

Put the AD FS server in use

The AD FS server is now ready for use.

A10 Testing the Functionality of the new AD FS server

However, before you put a new AD FS server in use, check that you can sign in to the applications, services and/or systems that are represented by the relying party trusts, like you would normally. Check this by pointing an internal device through its HOSTS file to IP address of the new AD FS server for the DNS name of the AD FS Farm

This technical and functional test verifies that the AD FS Server is functioning properly to meet your organization's needs.

A11 Add the AD FS Server to the pool, or switch it

Now you can add the AD FS server to the back-end pool of the load balancer, if you want to add it to an already existing load-balanced of AD FS servers.

If you want to switch around an old AD FS server with a new AD FS server, instead, switch the DNS record from the old AD FS server to the new AD FS server.

If there are Web Application Proxies connected to the AD FS farm, switch these around too, be either switching the entry for the AD FS farm in the Web Application Proxy's HOSTS file or changing the IP address for the AD FS farm in the DNS zone for the perimeter network.

A12 Monitor the new AD FS Server's traffic and load

As you put the AD FS server in use, monitor its traffic using Azure AD Connect Health to see if your load balancer is indeed flowing authentication requests to it. Monitor the CPU and memory on the new AD FS server to assure the load is as expected.

Decommissioning the old AD FS Server(s)

Now that the new AD FS server is running as it should, we can decommission any AD Fs server that is faulty, redundant, running a previous version of Windows Server or you want to get rid of for some other reason.

Perform these actions to decommission an AD FS Server:

A13 Remove the AD FS Server from the pool

Remove the AD FS server as an endpoint from the back-end pool of the load balancer. Monitor traffic to the AD FS server to make sure no more authentication requests are sent to the host.

A14 Change the AD FS Primary server

Chances are, the AD FS server that you want to remove is the primary AD FS server for an AD FS farm running the Windows Internal Database (WID) as the method to host the AD FS configuration database. This is part of the answer to Q1.

Note:
You don't have to perform this action for an AD FS Farm that uses SQL Server as the method to host the AD FS configuration database.

On the new AD FS server or one of the other remaining AD FS servers, you'll need to run the following line of Windows PowerShell to make the AD FS server the primary server:

Set-AdfsSyncProperties -Role PrimaryComputer

Then, on the other AD FS servers, make sure they all point to the new primary AD FS server  with the following line of Windows PowerShell:

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName NewADFSPrimaryServer.domain.tld

You can check the role for an AD FS server in a WID-based AD FS Farm using the following line of Windows PowerShell:

Get-AdfsSyncProperties

A15 Remove the AD FS server role

Uninstalling the AD FS Server role from an AD FS server, removes it from the AD FS farm. Perform the following line of Windows PowerShell to do so:

Uninstall-WindowsFeature ADFS-Federation

A16 Check proper removal of the decommissioned AD FS Server(s)

It is important to check that the decommissioned AD FS server are properly removed from the AD FS Farm. To gather this information, you need to run the following line of Windows PowerShell from the AD FS server that is the primary server in case of WID, or any AD FS server when Microsoft SQL Server is used to host the AD FS configuration database:

(Get-AdfsFarmInformation).FarmNodes | Format-Table

If the AD FS server you decommissioned is still there, you'll have to remove it using Remove-AdfsFarmNode. The way you use this Windows PowerShell cmdlet is subject to the AD FS service account used.

A17 Remove infrastructure services

As you now have decommissioned the AD FS server, make sure to also remove it from monitoring, logging, backup, anti-malware and other infrastructure management services your organization leverages.

A18 Remove the server from the domain

After you have decoupled the AD FS server from the infrastructure services supporting it, remove it from the Active Directory domain using the following line of Windows PowerShell and specifying an Active Directory account that has sufficient (delegated)permissions to remove a computer from Active Directory:

$Cred = Get-Credential

Remove-Computer –UnjoinDomaincredential $cred -PassThru -Verbose -Restart

Afterward, remove the computer account for the server from Active Directory and DNS.

After you have decommissioned an AD FS server

After you have decommissioned an AD FS server, answer this question:

Q8 Is this the last AD FS Server running this version?

An AD FS farm operates using a specific Farm Behavioral Level (FBL), depending on the oldest Windows Server version used by AD FS servers in the AD FS farm. When the last AD FS server running a previous version of Windows Server is removed from the AD FS farm, the FBL can be upgraded with action A19.

After you decommission an AD FS server, answer these questions:

A19 Upgrade the AD FS Farm Behavioral Level (FBL)

When all AD FS servers running a previous version of Windows Server have been decommissioned, you can opt to upgrade the AD FS Farm Behavioral Level (FBL). There are some good reasons to upgrade the FBL if you're coming from Windows Server 2012 R2 to Windows Server 2016:

• Built-in Azure Multi-Factor Authentication AD FS Adapter and Azure MFA as primary authentication method
• Device compliance status for AD FS claims issuance rules and Azure AD Connect device write-back for Azure AD-joined devices
• Sign-in with Windows Hello for Business
• Oauth 2, Open ID Connect and SCIM support
• SAML 2.0 inCommon and eGov support
• Access Control Policies manageability
• Sign-in with accounts from non-Active Directory LDAPv3 directories
• Sign-in with accounts from Active Directory forests to which an Active Directory two-way trust is not configured
• Sign-in with accounts from Active Directory Lightweight Directory Services (AD LDS)
• Per-Relying Party Trust branding
• Improved auditing (more streamlined, less verbose)
• Send password expiry claims to RPTs to notify users when using Office 365

Use the following line of Windows PowerShell to do so:

Invoke-ADFSFarmBehavioralLevelRaise

A20 Convert claims rules to Authentication Policies

A common way to define multi-factor authentication for extranet access on an AD FS Farm running Windows Server 2012 R2 is to define it using claims issuing rules and/or through Custom settings per Relying Party Trust. In AD FS on Windows Server 2016, and up, these settings are managed through Authentication Policies. This is a good time to convert to Authentication Policies. If need be, you can create your own additional Authentication Policies to provide custom authentication settings. By applying an Authentication Policy to a Relying Party Trust, you apply the authentication settings.

A21 Testing the Functionality of the AD FS Farm

The FBL upgrade is an important upgrade to get these new features, but there is also a risk: As many relying parties query your AD FS Farm's federation metadata and endpoints, their infrastructure might decide that your infrastructure is now capable of OpenID Connect, for instance, and try to communicate using it, while your Relying Party Trusts (RPTs) might not support it in their settings yet.

Check that you can sign in to the applications, services and/or systems that are represented by the relying party trusts, like you would normally.

Concluding

The above approach is our real-world tested approach to transitioning AD FS Servers, based on projects with our customers.

Enjoy!

The post A Real-world tested Approach for Transitioning AD FS Servers appeared first on The things that are better left unspoken.