I feel that every organization has at some point received phishing emails where the attacker impersonates a high level executive such as a CEO to email a CFO or someone in finance in the organization to try and have funds urgently transferred to an account. These phishing attempts can be very difficult to adequately protect because the attacker can easily create an email account from a legitimate service such as Gmail with the CEO’s name concatenated with perhaps a number at the end. The display name will only show the first and last name of the CEO and some users could potentially miss that the email address is not from within their organization. There are many products available that addresses this and one that I am familiar with is Office 365 Advanced Threat Protection which provides a feature named mailbox intelligence which has the following configurable actions:

Being able to purchase ATP would be dependent on the size of the organization and whether they’re able to afford the additional licenses but in the event that they are not able to, I would like to demonstrate a possible Exchange Online transport rule solution that can prepend a disclaimer for the incoming email. Note that this wouldn’t be very scalable as you would have to either configure separate rules for each user with a disclaimer identifying the user or have one rule configured for specific users but use a generic disclaimer.

Begin by navigating to mail flow> rules:

Create a new rule:

Provide a name for the rule and configure a condition specifying that The sender is located… with the setting Outside the organization:

Add another condition specifying A message header… with the setting matches these text patterns:

Add the full name of the user into the specify words or phrases window:

In the Do the following… field, you can select any of the actions you would like to execute when such a message with the matching display name but for this example we will use prepend a disclaimer:

You are free to use HTML to format the disclaimer and the following one I included is a yellow text box with the warning Caution: This is an external email from John Smith:

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0

style='border-collapse:collapse;mso-yfti-tbllook:1184;mso-padding-alt:0in 0in 0in 0in'>

<tr style='mso-yfti-irow:0;mso-yfti-firstrow:yes;mso-yfti-lastrow:yes;

height:11.9pt'>

<td width=323 valign=top style='width:242.35pt;border:solid #2A3B48 1.0pt;

background:#F4DF11;padding:0in 5.4pt 0in 5.4pt;height:11.9pt'>

<p class=MsoNormal><b><span style='font-size:9.0pt;color:#993922'>CAUTION: </span></b><span

style='font-size:9.0pt'>This is an external email from John Smith <o:p></o:p></span></p>

</td>

</tr>

</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

Review and add any additional conditions such as The recipient is… with your own email to test the rule before adding it globally:

Proceed to test by sending an email from an external domain with the specified display name you created in the rule to verify that the emails are prepended with a disclaimer.

----------------------------------------------------------------------------------------------------------------------------

Other layers of protection you can add in addition to this are as follows:

Enabling Mail Tips for that warn users when they send an email with external recipients

This needs to be enabled at a global level so either everyone gets the mail tip or no one does so proper communication needs to be made to the organization.

Execute the following cmdlet to determine review the setting:

Get-OrganizationConfig | FL *mailtips*

Note that the screenshot below indicates it is currently set to False. To enable it, execute the cmdlet:

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true

Users will notice the following when they have an email with external recipients in the To field:

Prepending a disclaimer for all external emails

You can create a transport rule similar to the one described in this post but omit the condition for the header and tag all external emails entering the organization. If you choose to implement this then I would suggest changing the action for the rule that matches a display name so you don’t end up inserting two disclaimers.

Problem

You’ve deployed a new Active Directory Federation Services (ADFS) farm on Windows Server 2019 and integrated DUO MFA with the portal so users logging onto Office 365 would be redirected to the ADFS portal protected by DUO 2FA but notice that using a Chrome or Edge browser fails to display the DUO authentication prompt and presents the following error:

Request to the server has been blocked by an extension.

Internet Explorer 11 does not exhibit this issue.

Performing a Google search for the error reveals that this is a known issue as described in the following DUO KB:

How do I resolve the error "Request to server has been blocked by extension" when logging in to Duo-protected AD FS on Server 2019?
https://help.duo.com/s/article/4832?language=en_US

In Windows Server 2019, Microsoft introduced a new security feature to allow for custom HTTP headers to be sent by AD FS. As a result there are more restrictive policies around displaying the Duo Prompt.

You proceed to implement the suggested additional configuration frame-src api-xxxxxx.duosecurity.com to the Content Security Policy (CSP) to the ADFS response headers as suggested but continue to receive the error.

Solution

I’m not completely sure what date the article was written as I could not find any reference but I’ve come across a similar issue a while ago as outlined in the following post:

Configuring Content-Security-Policy HTTP Response Header on Citrix ADC for Citrix Apps and Desktops with DUO integration
http://terenceluk.blogspot.com/2020/02/configuring-content-security-policy.html

I had not seen the DUO knowledge base article during the troubleshooting in my blog post but the extra frame-src api-xxxxxx.duosecurity.com made sense as it explicitly specifies the URL to begin with api- followed by 5 characters and finally .duosecurity.com. However, as implementing the following cmdlet didn’t work:

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self''unsafe-inline''unsafe-eval'; img-src 'self'; frame-src api-xxxxxx.duosecurity.com "

I took another look at the second cmdlet that is suggested if the CSP has already been configured and noticed that the API hostname string had only 5 X, rather than 6 in the cmdlet above:

$apihostname = "api-XXXXX.duosecurity.com"

$CSP = ((Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders).'Content-Security-Policy')

$CSP = $CSP + "; frame-src " + $apihostname

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue $CSP

I tried modifying the CSP to include only 5 X but that did not correct the issue.

Troubleshooting at a deeper level with the developer tools revealed that frame was trying to load the following URL: https://api-8fe1dff4.duosecurity.com/

Refused to frame 'https://api-8fe1dff4.duosecurity.com/' because it violates the following Content Security Policy directive: "frame-src api-xxxxxx.duosecurity.com".

This did not match the allowed string so I followed the same configuration I used in my previous blog post and simply allowed all subdomains for duosecurity.com as such:

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self''unsafe-inline''unsafe-eval'; img-src 'self'; frame-src *.duosecurity.com"

**Note that the ResponseHeaders value gets truncated and will not display the full configuration unless you change the $FormatEnumerationLimit value to -1 by executing: $FormatEnumerationLimit=-1

The page began to load properly on Edge and Chrome once the above configuration was made.

I’m always open to corrections to my posts so please feel free to leave a comment if there is a better way of handling this.

Improving the security of user authentication has always been a top priority for many organizations and one of the products I’ve been working with which has become very popular is Microsoft’s Azure AD Password Protection. For those who are not familiar with this Microsoft offering, this product essentially allows you to leverage the password protection Azure provides to cloud accounts to be extended to your on-premise Active Directory. The following are some highlights of the product:

• Global banned passwords list> Microsoft has compiled and continue to maintain a list of passwords that their security team has deemed to be a security risk rom real-world security telemetry on actual password spray attacks. This list is not disclosed to the public because it would render it ineffective.
• Custom banned password list > Organizations can use this feature to ban passwords they deem to be a security risk. These passwords are generally company and product names, location, and other words that can be easily guessed because it relates to the company in some way or another. Note that there is a 16 character limit.
• Advanced password evaluation> Microsoft outlines the method they use to evaluate the strength of a password (https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad) that includes normalization and banned lists. A score is calculated based on the formula outlined in the document I provided and I would say that it is a great method.
• Augments on-premise Active Directory password policy > Azure AD Password Protection (and its 8 character limit) does not replace the on-premise password policy but rather extends it. The on-premise password policy configuration will be enforced for users.
• Reduced dependency on Azure > Azure AD password hash sync is not a requirement and the on-premise domain controllers do not need to constantly connect to Azure through the proxy service for password checks as the policy is downloaded locally every hour. In the event that registered proxy servers are not available, the Azure AD Password Protection DC agents continue to enforce their cached password policy.
• Domain controllers does not need to maintain a persistent connection to Azure > The domain controllers rely on the Azure AD Password Protection Proxy Service to retrieve the password policy so there is no requirement to open additional outbound access.
• Audit mode> You can’t actually turn Azure AD Password Protection for a subset of your on-premise Active Directory but you are provided with an audit mode that logs whether a password would have been accepted or rejected. I typically use this with a group of pilot users during the test phase.

There are an abundance of documentation provided from Microsoft that I found useful when I need refresh my memory so I will list them here:

Enforce Azure AD password protection for Windows Server Active Directory– How Azure AD Password Protection works
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/concept-password-ban-bad-on-premises

Plan and deploy on-premises Azure Active Directory Password Protection– Deployment guide
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy

Eliminate bad passwords in your organization– How passwords are evaluated and how global and custom banned password lists work
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

Enable on-premises Azure Active Directory Password Protection– Enabling and disabling the password policy for testing and production
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-operations

Password Guidance – Some of the information is a bit dated as the publication was written in May 2016 but the concepts are still useful
https://www.microsoft.com/en-us/research/publication/password-guidance/

With all the information provided above, let’s proceed with the deployment.

Environment Prerequisites

• The installers for the proxy and DC agent are available to be downloaded without a login and can be retrieved at the following URL: https://www.microsoft.com/en-us/download/details.aspx?id=57071
• Azure AD Premium P1 license licenses are required for the organization
• You can deploy both the Azure AD Password Protection Proxy Server and DC Agent directly on a domain controller for testing but this is not recommended, instead, have at least 1 x Azure AD Password Protection Proxy Server residing on a member server in the domain and the DC Agent installed on all the domain controllers
• Multiple forests are supported but if each Azure AD Password Protection Proxy Server can only support one forest and its domain controller
• Do not install the Azure AD Password Protection Proxy Server on a RODC as it is not supported
• Load balancers are not necessary as the Azure AD Password Protection DC agent uses a simple round-robin-style algorithm when deciding which proxy server to call
• All of the servers, including the domain controllers, need to have the Universal C Runtime installed
• The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows Server 2012. By default, this service is enabled via manual trigger start
• Network connectivity over RPC endpoint mapper port 135 and the RPC server port must exist between at least one domain controller in each domain and at least one server that hosts the proxy service
• All servers that have the Azure AD Password Protection Proxy service installed must have network access to the following endpoints:
  • https://login.microsoftonline.com– Authentication requests
  • https://enterpriseregistration.windows.net– Azure AD Password Protection functionality

Azure AD Password Protection DC agent Requirements

• The install requires a server reboot
• Operating system must be Windows Server 2012 or later
• Domain and forest functional does not need to be Windows Server 2012
• .NET 4.5 must be installed
• The domain controllers should be using Distributed File System Replication (DFSR) for sysvol replication

Azure AD Password Protection proxy service Requirements

• The install does not require a server reboot
• Operating system must be Windows Server 2012 or later
• .NET 4.5 must be installed
• Must be configured to grant domain controllers the ability to log on to the proxy service (this ability is controlled via the "Access this computer from the network" privilege assignment)
• Outbound TLS 1.2 HTTP traffic allowed
• A Global Administrator account will be used to register the proxy service and forest with Azure AD
• Network access must be enabled for the set of ports and URLs specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application#prepare-your-on-premises-environment
• HTTP proxy is supported but additional configuration must be performed (this post will not demonstrate the configuration)

Microsoft Azure AD Connect Agent Updater prerequisites Requirements

The Microsoft Azure AD Connect Agent Updater service is installed along with the Azure AD Password Protection Proxy service. In the event where any of the following applies, further configuration would be required:

• If your environment uses an HTTP proxy server, follow the guidelines specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-connectors-with-proxy-servers
• The Microsoft Azure AD Connect Agent Updater service also requires the TLS 1.2 steps specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application#tls-requirements

Configure Azure AD Password Protection

Enable the Azure AD Password Protection service by logging into https://portal.azure.com and navigating to Azure Active Directory > Security > Authentication Methods > Password Protection and configure the following:

Enable password protection on Windows Server Active Directory: Yes
Mode: Audit

Deploying the Azure AD Password Protection Proxy service

Begin by verifying that .NET 4.5 or later is installed by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" | Format-List

Compare the version number with the following table to verify that a supported version is installed:

Verify that the Windows Firewall service is running:

Proceed to install the Azure AD Password Protection Proxy service onto the proxy server:

Launch PowerShell and execute the following cmdlet to verify that the proxy service has been installed:

Import-Module AzureADPasswordProtection

Get-Service AzureADPasswordProtectionProxy | FL

Proceed to register the proxy service with the following cmdlet:

Register-AzureADPasswordProtectionProxy -AccountUPN '<yourGlobalAdministrator@onmicrosoft.com>'

**Note that I’ve had two deployments where an error thrown but the second try completes:

Proceed to register the on-premises Active Directory forest with the following cmdlet:

Register-AzureADPasswordProtectionForest -AccountUpn '<yourGlobalAdministrator@onmicrosoft.com>'

You can verify the registration by reviewing the Audit Logs entriesin the Azure portal:

Target: AADPasswordProtectionProxy

**Note that if there is an HTTP proxy in the environment for machines to reach the internet then there are extra steps required to be performed. The environment in this example does not have a HTTP proxy so I will not be demonstrating the process.

Deploying the Azure AD Password Protection DC Agent

Begin by verifying that DFSR is used to replicate the sysvol folder by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols" | Format-List

The Local State value should be 3. The following is where the parameter and value is stored in the registry:

Verify that .NET 4.5 or later is installed by executing the following cmdlet:

Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" | Format-List

Compare the version number with the following table to verify that a supported version is installed:

Ensure that the Kerberos Key Distribution Center service is started:

Verify that the Windows Firewall service is running:

Proceed to install the Azure AD Password Protection DC Agent onto the Domain Controller server:

Proceed to restart the domain controller:

Once the domain controller has been successfully restarted, verify that the Azure AD Password Protection DC Agent service has started:

Proceed by launching the Event Viewer then navigate to Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin and verify that the following event ID is logged indicating that the agent is successfully enforcing the Azure password policy:

Source: DCAgent
Event ID: 30006
Level: Information
User: System

The service is now enforcing the following Azure password policy.

Enabled: 1
AuditOnly: 1
Global policy date: ‎2019‎-‎11‎-‎03T00:00:00.000000000Z
Tenant policy date: ‎2020‎-‎02‎-‎20T22:35:50.188026500Z
Enforce tenant policy: 1

Review the Operational log and verify that the following event is logged:

Source: DCAgent
Event ID: 10000
Level: Information
User: System

The password filter dll has successfully loaded and initialized.

You should also see the following event logged indicating the agent has starting:

Source: DCAgent
Event ID: 20000
Level: Information
User: System

The Azure AD Password Protection DC Agent service is starting.

The following event will verify that the agent has started:

The Azure AD Password Protection DC Agent service has successfully started.

The following event will also be logged indicating that the specified certificate is used to authenticate with Azure:

The following forest certificate credential is being used for authentication to Azure.

Forest certificate thumbprint: FC5E044348BB950D3B3B515F5B39830B532E1C1D
Forest certificate NotBefore: ‎2020‎-‎02‎-‎20T21:30:21.000000000Z
Forest certificate NotAfter: ‎2021‎-‎02‎-‎20T09:25:17.000000000Z
Forest certificate object DN: CN=1192827B-F3E2-4B12-95A7-2070859A5C23,CN=Forest Certs,CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=corp,DC=domain,DC=com

Test Azure AD Password Protection

Prepare a test plan with multiple passwords to test and verify that the expected outcome is achieved. The following is an event that would be logged if the password is not expected to be accepted but is allowed because audit mode is configured:

Source: DCAgent
Event ID: 30029
Level: Information
User: System

The reset password for the specified user would normally have been rejected because it matched multiple tokens in the combined Microsoft global and per-tenant banned password list of the current Azure password policy.

The current Azure password policy is configured for audit-only mode so the password was accepted.

UserName: testuser
FullName: Test User

The following is an event that would be logged if the password is accepted because it is compliant with the Azure password policy:

Source: DCAgent
Event ID: 10015
Level: Information
User: System

The reset password for the specified user was validated as compliant with the current Azure password policy.

UserName: testuser
FullName: Test User

The following is an event that would be logged if the user of a custom banned password is detected:

Source: DCAgent

Event ID: 30003

Level: Information
User: System

The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy.

UserName: username
FullName: username

Enforcing Azure AD Password Protection

When testing of the password policy with pilot users is complete, proceed and switch the Mode from Audit to Enforced:

----------------------------------------------------------------------------------------------------------------------------

Other notable items

It is important to note that you should leverage your on-premise password policies to enforce a minimum password length as Azure defaults to 8 characters. I always suggest to use the Password Settings Object (PSO) instead of the Default Domain Policy GPO because of the added flexibility and there have been environments where modifying the Default Domain Policy GPO did not enforce the configured minimum password length I wanted.

As mentioned earlier, there is a 16 character limit for banned passwords:

The following Azure AD Password Protection object will be created in the Configuration container after a successful deployment of Azure AD Password Protection:

I’ve found that maintaining storage usage on a Remote Desktop Session Host (RDSH) has always been a challenge as there can be so many ways a user would inadvertently fill up the storage if items such as profile management and folder redirection is not configured to safely manage disk space usage. One of the clients I’ve been working with saw an increase in storage consumption on their Citrix shared desktop servers after moving the entire organization to work from home. This did not come to a surprise but the original design was not meant to accommodate the change so we began reviewing the additional policies we could apply to these Windows Server 2019 shared desktops published through Citrix.

One of the components we noticed that had increased growth was the recycling bin. Many of the users did not have the habit of purging the items so we had to determine a way of cleaning out the items. The immediate ideas were:

1. Disable the recycle bin as the previous Citrix XenDesktop and VMware Horizon View optimization scripts did
2. Configure a logoff script that emptied the recycle bin upon logging off for the user
3. Educate the users to manually purge them

None of the above ideas were ones we wanted to adopt so we looked into whether there was a way to delete the files in the recycle bin after a specified amount of time. What we found to be available is a feature in Windows 10 named Storage Sense as shown in the following screenshots:

Reviewing the shared desktop servers with the Windows Server 2019 operating system showed that this feature was also available without the need to install any additional features. However, the native group policy templates on the domain controllers did not provide the settings found on the Windows 10 operating system:

Computer Configuration > Administrative Templates > System > Storage Sense:

We had restrictions on installing additional policy templates for the Active Directory domain controllers so I decided to use Process Monitor to determine where the configuration registry keys reside and use them to configure the servers. The following is where these registry keys reside:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy

The following is a table for the configuration mappings:

The settings we decided on are as follows:

Storage Sense: Enabled

Run Storage Sense: Every month

Delete temporary files that my apps aren’t using: Enabled

Delete files in my recycle bin if they have been there for over: 60 days

Delete files in my Downloads folder if they have not be used for: Never

To apply these registry settings via group policy on the servers, the following GPO with User Configuration were configured:

Here is an example of one of the registry changes:

Key Path: Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy

Value name: 01

Value type: REG_DWORD

Value data: 1

Note that as this GPO will be applied to computer objects, namely the Citrix shared desktops, we will need to enable loopback settings as such:

Computer Configuration > Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode

Enabled / Merge

Link the GPO to the OU that contains the shared desktop computer object, run gpupdate /force and you verify that the settings are applied.

Problem

You attempt to use PowerShell to connect to MSOnline via the cmdlet Connect-MsolService but it fails and displays the following message:

PS C:\> Connect-MsolService Connect-MsolService : This account is blocked. Contact your Tenant administrator.

At line:1 char:1

+ Connect-MsolService

+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], MicrosoftOnlineException

+ FullyQualifiedErrorId : 0x80048823,Microsoft.Online.Administration.Automation.ConnectMsolService

PS C:\>

Your environment has MFA enabled and you notice that the authentication prompt you receive when you execute Connect-MsolService displays the legacy login and not the modern authentication prompt:

… which leads to the MFA prompt to not be displayed.

You review the installed Windows Azure Active Directory Module for Windows PowerShell and determine that it is at the older 1.0.0 version:

You proceed to use the Install-Module -Name MSOnline cmdlet to upgrade the module but receive the following error indicating version 1.0 is already installed and to use the force switch for a side-by-side install:

PS C:\> Install-Module -Name MSOnline

Untrusted repository

You are installing the modules from an untrusted repository. If you trust this repository, change its

InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from

'PSGallery'?

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y

WARNING: Version '1.0' of module 'MSOnline' is already installed at

'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\MSOnline'. To install version '1.1.183.57', run Install-Module and

add the -Force parameter, this command will install version '1.1.183.57' in side-by-side with version '1.0'.

PS C:\>

Attempting to use the force switch will continue to fail:

PS C:\> Install-Module -Name MSOnline -force PackageManagement\Install-Package : The following commands are already available on this system:'Add-MsolAdministrative

UnitMember,Add-MsolForeignGroupToRole,Add-MsolGroupMember,Add-MsolRoleMember,Add-MsolScopedRoleMember,Confirm-MsolDomai

n,Confirm-MsolEmailVerifiedDomain,Connect-MsolService,Convert-MsolFederatedUser,Get-MsolAccountSku,Get-MsolAdministrati

veUnit,Get-MsolAdministrativeUnitMember,Get-MsolCompanyInformation,Get-MsolContact,Get-MsolDirSyncConfiguration,Get-Mso

lDirSyncFeatures,Get-MsolDirSyncProvisioningError,Get-MsolDomain,Get-MsolDomainFederationSettings,Get-MsolDomainVerific

ationDns,Get-MsolGroup,Get-MsolGroupMember,Get-MsolHasObjectsWithDirSyncProvisioningErrors,Get-MsolPartnerContract,Get-

MsolPartnerInformation,Get-MsolPasswordPolicy,Get-MsolRole,Get-MsolRoleMember,Get-MsolScopedRoleMember,Get-MsolServiceP

rincipal,Get-MsolServicePrincipalCredential,Get-MsolSubscription,Get-MsolUser,Get-MsolUserByStrongAuthentication,Get-Ms

olUserRole,New-MsolAdministrativeUnit,New-MsolDomain,New-MsolGroup,New-MsolLicenseOptions,New-MsolServicePrincipal,New-

MsolServicePrincipalAddresses,New-MsolServicePrincipalCredential,New-MsolUser,New-MsolWellKnownGroup,Redo-MsolProvision

Contact,Redo-MsolProvisionGroup,Redo-MsolProvisionUser,Remove-MsolAdministrativeUnit,Remove-MsolAdministrativeUnitMembe

r,Remove-MsolApplicationPassword,Remove-MsolContact,Remove-MsolDomain,Remove-MsolForeignGroupFromRole,Remove-MsolGroup,

Remove-MsolGroupMember,Remove-MsolRoleMember,Remove-MsolScopedRoleMember,Remove-MsolServicePrincipal,Remove-MsolService

PrincipalCredential,Remove-MsolUser,Reset-MsolStrongAuthenticationMethodByUpn,Restore-MsolUser,Set-MsolAdministrativeUn

it,Set-MsolCompanyContactInformation,Set-MsolCompanySecurityComplianceContactInformation,Set-MsolCompanySettings,Set-Ms

olDirSyncConfiguration,Set-MsolDirSyncEnabled,Set-MsolDirSyncFeature,Set-MsolDomain,Set-MsolDomainAuthentication,Set-Ms

olDomainFederationSettings,Set-MsolGroup,Set-MsolPartnerInformation,Set-MsolPasswordPolicy,Set-MsolServicePrincipal,Set

-MsolUser,Set-MsolUserLicense,Set-MsolUserPassword,Set-MsolUserPrincipalName'. This module 'MSOnline' may override the

existing commands. If you still want to install this module 'MSOnline', use -AllowClobber parameter.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21

+ ... $null = PackageManagement\Install-Package @PSBoundParameters

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],

Exception

+ FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.PowerShell.Pack

ageManagement.Cmdlets.InstallPackagePS C:\>

Solution

The scenario outlined above contains two issues that are dependent of each other:

1. The MSOnline version 1.0 does not prompt us with MFA and as this is required, the login process fails and we are given the This account is blocked. Contact your Tenant administrator. message.
2. Attempting to update MSOnline from 1.0 to the latest 1.1.183.57 with the force switch fails

Issue #1, where the legacy MSOnline module is unable to prompt for MFA, will be resolved once we are able to update it to the latest version. To correct the issue, proceed by first uninstalling MSOnline version 1.0 from Programs and Features:

Then install the latest MSOnline with the Install-Module -Name MSOnline cmdlet:

PS C:\> Install-Module -Name MSOnline

Untrusted repository You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y PS C:\>

Use the Get-Module cmdlet to verify that the latest version has been installed:

Proceeding to execute the Connect-MsolService will now bring up the modern authentication prompt allowing you to complete the MFA authentication:

One of the common questions I’ve had from clients who have recently transitioned to Office 365 is how they can disable the option for users to stay signed into Office 365 after authenticating.

Stay signed in? Do this to reduce the number of times you are asked to sign in.

Don't show this again

The problem organizations have this with option is that regardless of whether 2FA is required for logging in, they are no longer prompted to log in even after they’ve closed the browser (without logging off). The only way to force the user to log in again is if they proactively signed out and this poses as a security risk if they were on a public computer. Removing this prompt is quite simple and the following are steps for how to achieve this.

Begin by logging into https://portal.azure.com and navigating to Azure Active Directory:

Select Company Branding on the left blade:

If you already have a configuration for Company Branding configured, click into it, otherwise, click on the Configure button to create a new one:

You are free to configure the additional company branding options but if you only want to turn the option to stay signed in then scroll to the bottom and look for the setting named:

Show option to remain signed in

… and select No:

A new company branding configuration will now appear:

Users will no longer get the option to remain signed in but if they have selected to remain signed in then before this setting has been configured then they will continue to be automatically logged in.

For reference, this is the official documentation from Microsoft outlining the steps above: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding

I’ve recently taken on a project to review a client’s Azure environment and address all the risks associated with the lack of redundancy in its current design and the first task was to inventory their virtual machines so we can map them accordingly to the function it provides. One of my colleagues who have been working with this client forewarned me that there would be few name mismatches between the name given to the virtual machine in Azure and the name of the computer in the operating system. What may be named as SQL potentially could have been repurposed to a completely different function.

To clarify, the name I’m referring to is the configuration on the top left corner of the Azure virtual machine as compared to the value under the Computer name field, which is what, say, a computer is named within the Windows operating system:

There isn’t an easy way to retrieve this information so I did a quick search on the internet to see if there was a script available and was not able to find one so I wrote one using the Get-AzVM cmdlet to quickly retrieve, compare and output in the PowerShell console. More refinement can be made to the script but this quick and dirty job provided me with what I need so please feel to expand it as necessary.

Begin by copying the following and saving it as a .ps1 file:

foreach ( $azVM in Get-AzVM ) {

$networkProfile = $azVm.NetworkProfile.NetworkInterfaces.id.Split("/")|Select -Last 1

$vmName = $azVm.OsProfile.ComputerName

$rgName = $azVm.ResourceGroupName

#$tags = $azVM.Tags

$hostname = (Get-AzVM -ResourceGroupName $rgName -Name $azVm.OsProfile.ComputerName -status).computername

$IPConfig = (Get-AzNetworkInterface -Name $networkProfile).IpConfigurations.PrivateIpAddress

[pscustomobject]@{

Name = $azVm.OsProfile.ComputerName

ComputerName = $hostname

"IP Addresses" = $IPConfig

#Tags = $tags

"Az Name Match Host Name" = $azVm.OsProfile.ComputerName.equals($hostname)

}

}

Here is a screenshot of what it looks like in the Windows PowerShell ISE editor:

With the script saved in a directory, proceed to connect to Azure:

Connect-AzAccount

The environment in this example redirects the login to a Citrix ADC that performs AAA authentication with DUO MFA:

Your subscription name, tenant ID will be displayed upon successful authentication:

Navigate to the directory with the script and execute it with .\<scriptname>.ps1:

As mentioned previously, more refinement such as handling blank Computer Names differently or exporting it to a CSV instead. Also note that I originally included outputting the Tags but have commented it out in the script.

With the COVID-19 pandemic ravaging business globally over the past two months, many organizations have been rushing to deploy or scale up their previously piloted collaboration products to full production. One of the clients I worked with had an immediate need to leverage the free trial Microsoft Teams licenses Microsoft was providing to organizations and as this organization did not have an Office 365 tenant setup, the first step was to set one up and decide how they want users to authenticate. The decision was made to use Active Directory Federation Services as they wanted to keep the authentication traffic directed to their on-premise infrastructure, which leverages DUO multi-factor authentication. I’ll be writing a series of blog posts as I deploy an ADFS farm, Citrix ADC for load balancing, DUO integration, and AD Connect with ADFS for authentication. This post will outline the process of deploying a redundant ADFS infrastructure. The operating system I’ll be using for this deployment is Windows Server 2019, which is ADFS version 4.0.

Prerequisites

Servers:

1. Prepare 4 x Windows Server 2019 servers
2. 2 of the servers will be your ADFS servers hosted on your internal server subnet
3. The other 2 servers will be your ADFS Web Application Proxy servers that should be placed in your DMZ (these servers does not have to be joined to the domain and I typically suggest they reside in a workgroup unless there is a compelling reason to join them to the domain)

Service Account:

You will need to decide the type of service account to use for the ADFS farm. The options are to use a Group Managed Service Account (recommended) or an existing user domain account (the traditional method). Review the following documentation for more information:

Manually Configure a Service Account for a Federation Server Farm
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/manually-configure-a-service-account-for-a-federation-server-farm

Database:

You will need to decide whether to use WIN (Windows Internal Database) or SQL Server database for the farm. There are advantages and disadvantages for each option so please review the following documentation for more information:

The Role of the AD FS Configuration Database
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-ad-fs-configuration-database

Certificate:

You will need a certificate with the FQDN for your ADFS deployment and optionally a subject alternative name for the subdomain certauth.<yourFQDN>. Using a certificate with the SAN name would allow device authentication and user certificate authentication to connect to the ADFS server via port 443 at different FQDNs (e.g. fs.contoso.com and certauth.fs.contoso.com). Not using a certificate with the certauth.<yourFQDN> SAN entry will create an additional binding on port 49443 on the same FQDN for user certificate authentication.

More detail can be found at the following Microsoft documentation:

AD FS support for alternate hostname binding for certificate authentication
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-support-for-alternate-hostname-binding-for-certificate-authentication

DNS:

1. An internal DNS entry for the FQDN of your ADFS farm (e.g. fs.contoso.com) that points to your load balancer to load balance the ADFS authentication traffic between the internal ADFS server farm
2. An external DNS entry for the FQDN of your ADFS Web Application Proxy (e.g. fs.contoso.com) that points to your internet facing firewall, which will then NAT the IP into a load balancer to load balance the ADFS Web Application Proxy servers

Deploying the first ADFS server

Begin by launching server manager and clicking on Add roles and features:

Click Next:

Select Role-based or feature-based installation and click Next:

Leave the Select a server from the pool radio button selected and click Next:

Select Active Directory Federation Services and click Next:

Leave the Features as default and click Next:

The Active Directory Federation Services window will be displayed providing a description and links for documentation. Proceed and click Next:

A restart isn’t usually necessary so you can leave the radio button for that option unchecked and then click on Install:

The feature will proceed to install:

You will be presented with the link Configure the federation service on this server. once the installation completes. Proceed by clicking on the link to launch the configuration:

This is the first ADFS server in the farm so leave the radio button Create the first federation server in a federation server farm selected and click Next:

Ensure that you are logged in as a domain administrator for the install and if not, change the account to one that has permissions then click Next:

Proceed to select the certificate if you have already imported one onto the server’s Local Computer store or use the Import button to import a certificate from the wizard, enter the FQDN you’ll be publishing ADFS service and finally a logical name for the organization that would be displayed on the ADFS portal login page:

As shown in the warning banner presented, the KDS Root Key has not been configured for the use of a Group Managed Service Accounts but for the purpose of this deployment, we’ll be using a traditional service account:

We’ll be using a WIN database for this deployment:

A summary of the deployment will be displayed, proceed by clicking Next:

A prerequisites check will be made and if all are met then proceed by clicking on Configure:

Note that the certificate I used did not have the SAN entry certauth.<FQDN> so the warning message about configuring an additional binding pn port 49443 is created:

The SSL certificate subject alternative names do not support host name ‘certauth.domain.com’. Configuring certificate authentication binding on port ‘49443’ and hostname ‘fs.domain.com’.

Once the server has been successfully configured, you may receive the additional warning message depending on what your internal domain is:

The SSL certificate does not contain all UPN suffix values that exist in the enterprise. Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices. For more information, see http://go.microsoft.com/fwlink/?LinkID=311954

The reason why this message will be displayed is because the organization in this example uses a domain with the suffix .local, which is a non-internet routable TLD (top level domain) and therefore the certificate does and cannot have this FQDN as a name. This can be safely ignored as you would be using a routable domain such as the one for your email address.

Click on the Close button to complete the configuration.

Before proceeding to deploy the second ADFS server for the farm, I usually proceed to test the functionality of the newly deployed ADFS server to verify it is in good health. Aside from reviewing the event logs, one of the ways to validate the functionality is to turn on the sign on page, which used to be enabled in previous ADFS versions but is now disabled by default.

Begin by confirming that the sign on page is disabled, enable it, then configure that it is enabled.

Use the following cmdlet to determine whether the sign on page is enabled:

Get-AdfsProperties |Select-Object *EnableIdp*

Use the following cmdlet to enable the sign on page:

Set-AdfsProperties -EnableIdpInitiatedSignonPage $True

Use the following cmdlet to confirm that the sign on page is enabled:

Get-AdfsProperties |Select-Object *EnableIdp*

**If you do not have the load balancer set up yet then you will either need to modify the internal DNS entry for fs.contoso.com to point directly to the first ADFS server or use a host record on the computer you intend to test the sign on page.

Launch a browser and navigate to the following URL to verify that a sign on page is presented, then click on Sign in:

https://fs.contoso.com/adfs/ls/idpinitiatedsignon.htm

Proceed to sign in with domain credentials and verify you are able to successfully sign in successfully:

Deploy the second redundant ADFS Server

With the health of the first ADFS server verified, repeat the same deployment procedure on the second ADFS server but select Add a federation server to a federation server farm during the install as shown in the screenshot below:

Ensure that you are using an account with domain administrator permissions:

If you deployed the first ADFS server with a WIN database then proceed by filling in the Primary Federation Server name with the FQDN of the server (e.g. svr-adfs-01.internaldomain.com). If the deployment uses a SQL server then select Specify the database location for an existing farm using SQL Server and enter the SQL database information:

Select an imported SSL certificate (same one you used for the first server) or import it if it hasn’t already been placed into the Local Computer certificate store:

As mentioned during the deployment of the first server, we will be using a traditional service account for the deployment:

A summary of the deployment will be displayed:

The deployment will commence:

Proceed with the configuration once the prerequisites check has completed successfully:

You’ll see similar warning messages as the first deployment:

Click on the Close button when the installation has completed:

This concludes the deployment of the internal ADFS servers farm. The next post will outline the deployment of the Web Application Proxy servers.

As a follow up to my previous post demonstrating the deployment of a redundant Active Directory Federation Services (ADFS) Farm on Windows Server 2019:

Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html

This post services to demonstrate the deployment of the internet facing ADFS Web Application Proxy servers.

Prerequisites

Servers:

Prepare 2 x Windows Server 2019 servers that will serve as the ADFS Web Application Proxy servers located in a DMZ network (these servers does not have to be joined to the domain and I typically suggest they reside in a workgroup unless there is a compelling reason to join them to the domain)

Certificate:

You can use the same certificate that you used for your internal ADFS servers that contain the FQDN for your ADFS deployment (e.g. fs.contoso.com)

DNS:

During the deployment:

I’ve had inconsistent results during the deployment if the WAP server connects to a internal ADFS server in the farm that hosts a secondary read only copy of the WID so begin by configuring the WAP server to connect directly to the internal ADFS server that host the primary writable WID database.

After the deployment:

Determine how you will be configuring the ADFS Web Application Proxy servers’ DNS settings.

Scenario #1 – Using your internal Active Directory DNS servers

If you are using your internal Active Directory DNS servers, which will serve the IP address of either your load balancer that load balances the internal ADFS server farm, then no action is required as the Web Application Proxy servers will properly resolve the IP required to get to the internal farm.

Scenario #2 – Using your external DNS servers

If these DMZ servers are not going to use your internal Active Directory DNS servers to perform lookups and/or using a DNS service that is unaware of the internal IP address for the fs.contoso.com address then you would either create a record on these DNS servers (if you manage them) or use host records on the Web Application Proxy servers to force traffic to fs.contoso.com to the load balancer so communication can be established between them and the internal ADFS server farm.

In addition to the above scenarios, you will need to create an external DNS entry for the FQDN of your ADFS Web Application Proxy (e.g. fs.contoso.com) that points to your internet facing firewall, which will then NAT the IP into a load balancer to load balance the ADFS Web Application Proxy servers.

Deploying the first ADFS Web Application Proxy server

Begin by launching server manager and clicking on Add roles and features:

Click Next:

Select Role-based or feature-based installation and click Next:

Leave the Select a server from the pool radio button selected and click Next:

Select Remote Access and click Next:

Leave the Features as default and click Next:

The Remote Access window will be displayed providing a description of the service. Proceed and click Next:

The following Add Roles and Features Wizard window will be displayed to display the tools that will be installed onto the server:

Select the Web Application Proxy role and click Next:

A restart isn’t usually necessary so you can leave the radio button for that option unchecked and then click on Install:

The Web Application Proxy and dependent components will proceed to install:

You will be presented with a Welcome wizardonce the installation completes. Proceed by clicking on the link to launch the configuration:

Fill out the following fields:

Federation service name - Enter the fully qualified domain name (FQDN) of the AD FS server (e.g. fs.contoso.com)

User name and Password - An account with location administrator permissions on the internal ADFS server

Select the SSL certificate that has been installed onto the Local Computer certificate store:

Proceed with the configuration by clicking on the Configure button:

The configuration will begin:

Once the configuration completes, click on the Close button:

The Remote Access Management Console should automatically launch listing the server name on the left window:

Click on the Publish button on the right window:

Click Next to proceed:

I feel that most material available on the internet demonstrating the deployment of a WAP server are never very clear on this step so I’d like to try providing a bit more information for the differences between the following preauthenticationmethods.

Active Directory Federation Services (AD FS)

This preauthentication method will always direct the traffic for the published application to the AD FS server so the user requesting the traffic will be authenticated by your internal ADFS server farm. There are also 3 different types of preauthentication when you select this option and they are:

• Web and MSOFBA
• HTTP Basic
• OAuth2

Which option you should select depends on the requirements of the application you’re publishing so review the following article and determine the correct method:

Publishing Applications using AD FS Preauthentication

https://docs.microsoft.com/en-us/windows-server/remote/remote-access/web-application-proxy/publishing-applications-using-ad-fs-preauthentication

In the document from the link above, scroll down to the following headings:

• Publish an Application that uses MS-OFBA
• Publish an Application that uses HTTP Basic
• Publish an Application that uses OAuth2 such as a Microsoft Store App

An example of when you would need to select this option is if you are configuring AD FS claims-based authentication with Outlook on the web. If you select Pass-through preauthentication then you would have effectively bypassed ADFS sending the authentication back to the Exchange server.

Pass-through

This preauthentication method will directly send the traffic for the published application to the backend server and bypasses the internal AD FS server farm. What this means is that if you are publishing a web application that leverages AD FS for authentication then you have effectively bypassed it and sent the user or application to authenticate to the application server.

One of the common questions I’ve been asked in the past is which of the above should you be selecting if you are publishing ADFS so you can have users accessing Office 365 to authenticate against it and the short answer is both would work because the target server for the traffic redirected from Office 365 to your WAP server is destined for the ADFS server. Selecting Active Directory Federation Services (AD FS) or Pass-through would send the traffic essentially to the same place.

Please refer to the following documentation for more information on the differences as this setting cannot be changed afterwards but you can always remove and recreate the published application:

Publish Applications using AD FS Preauthentication

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383640(v=ws.11)

Publish Applications using Pass-through Preauthentication

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383639(v=ws.11)

I’ll include the screenshots for using both options to demonstrate what the configuration looks like.

Option #1: Active Directory Federation Services (AD FS)

Note that the Microsoft Office 365 Identity Platform Worldwide option would only be displayed if you have already confirmed this in the ADFS farm. If you are publishing other applications then you will need to make sure configure them in the ADFS farm before you attempt to publish them.

Enter a logical name for the web application, the FQDN for the external URL, select the SSL certificate that has been imported into the LocalComputer certificate store, determine whether you want to enable HTTP to HTTPS redirection, and finally enter the backend internal ADFS farm’s URL (this will be same as the external URL for this design):

Option #2: Pass-through

Enter a logical name for the web application, the FQDN for the external URL, select the SSL certificate that has been imported into the LocalComputer certificate store, determine whether you want to enable HTTP to HTTPS redirection, and finally enter the backend internal ADFS farm’s URL (this will be same as the external URL for this design):

Proceed with publishing the application by clicking on the Publish button:

Close the wizard when completed:

You should now see the newly published ADFS web application in the Published Web Applications window:

Repeat the previous steps for the second ADFS Web Application Proxy server and you should see the additional server listed in the Remote Access Management Console:

There is no need to publish the application twice if you have multiple Web Application Proxies as the publication of the application will automatically be configured on the other servers.

Event Logs

The following are event log entries that will be logged on the internal ADFS server when the Web Application Proxy Server successfully connects to the internal ADFS farm:

Log Name: AD/FS Admin

Source: AD FS

Event ID: 395

Level: Information

The trust between the federation server proxy and the Federation Service was established successfully using the account 'contoso\tluk'.

Proxy trust certificate subject: CN=ADFS ProxyTrust - ADFSWAP1.

Proxy trust certificate thumbprint: 1A2A8768073DB880E2ED086E8226848F129E4DB

Log Name: AD/FS Admin

Source: AD FS

Event ID: 396

Level: Information

The trust between the federation server proxy and the Federation Service was renewed successfully.

Proxy trust certificate subject: CN=ADFS ProxyTrust - ADFSWAP1.

Proxy trust certificate old thumbprint: 1A2A8768073DB880E2ED086E8226848F129E4DBE.

Proxy trust certificate new thumbprint: 18F8E09B827F49D23073BE398E8D9BF643D8AF75.

Problem

You’ve completed deploying the configuration required that allow clients to use AD FS (on Windows Server 2019) claims-based authentication to connect to Exchange Server 2019 Outlook on the web (formerly known as Outlook Web App) and the Exchange admin center (EAC) as outlined in the following documentation:

Use AD FS claims-based authentication with Outlook on the web
https://docs.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019

… but notice that attempting to navigate to /owa throws two different errors depending on the browser you use:

Google Chrome:

The page isn’t working

mail.contoso.com redirected you too many times.

ERR_TOO_MANY_REDIRECTS

Internet Explorer:

Server Error in '/owa' Application.

Encryption certificate is absent

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Microsoft.Exchange.Security.Authentication.AdfsConfigurationException: Encryption certificate is absent
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[AdfsConfigurationException: Encryption certificate is absent]
   Microsoft.Exchange.Security.Authentication.Utility.GetCertificates() +130
   Microsoft.Exchange.Security.Authentication.AdfsSessionSecurityTokenHandler.CreateTransforms() +12
   Microsoft.Exchange.Security.Authentication.AdfsFederationAuthModule.FederatedAuthentication_ServiceConfigurationCreated(Object sender, ServiceConfigurationCreatedEventArgs e) +143
   Microsoft.IdentityModel.Web.FederatedAuthentication.get_ServiceConfiguration() +177
   Microsoft.IdentityModel.Web.HttpModuleBase.Init(HttpApplication context) +17
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +580
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +165
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +267
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +341

[HttpException (0x80004005): Encryption certificate is absent]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +523
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +107
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +688

Attempting to navigate to /ecp throws the following error:

Server Error in '/ecp' Application.

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

Reviewing the event logs shows the following error consistently logged on the Exchange server:

Log Name: Application

Source: ASP.NET 4.0.30319.0

Event ID: 1309

Level: Warning

Event code: 3005

Event message: An unhandled exception has occurred.

Event time: 4/23/2020 2:41:17 PM

Event time (UTC): 4/23/2020 5:41:17 PM

Event ID: 034a726997a145338d6d7f878e25b637

Event sequence: 2

Event occurrence: 1

Event detail code: 0

Application information:

Application domain: /LM/W3SVC/1/ROOT/owa-20-132321372689777583

Trust level: Full

Application Virtual Path: /owa

Application Path: E:\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\

Machine name: OSMIUM

Process information:

Process ID: 14576

Process name: w3wp.exe

Account name: NT AUTHORITY\SYSTEM

Exception information:

Exception type: AdfsConfigurationException

Exception message: Encryption certificate is absent

at Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()

at Microsoft.Exchange.Security.Authentication.AdfsSessionSecurityTokenHandler.CreateTransforms()

at Microsoft.Exchange.Security.Authentication.AdfsFederationAuthModule.FederatedAuthentication_ServiceConfigurationCreated(Object sender, ServiceConfigurationCreatedEventArgs e)

at Microsoft.IdentityModel.Web.FederatedAuthentication.get_ServiceConfiguration()

at Microsoft.IdentityModel.Web.HttpModuleBase.Init(HttpApplication context)

at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)

at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)

at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)

at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Request information:

Request URL: https://mail.contoso.bm:443/owa/

Request path: /owa/

User host address: 172.16.10.105

User:

Is authenticated: False

Authentication Type:

Thread account name: NT AUTHORITY\SYSTEM

Thread information:

Thread ID: 18

Thread account name: NT AUTHORITY\SYSTEM

Is impersonating: False

Stack trace: at Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()

at Microsoft.Exchange.Security.Authentication.AdfsSessionSecurityTokenHandler.CreateTransforms()

at Microsoft.Exchange.Security.Authentication.AdfsFederationAuthModule.FederatedAuthentication_ServiceConfigurationCreated(Object sender, ServiceConfigurationCreatedEventArgs e)

at Microsoft.IdentityModel.Web.FederatedAuthentication.get_ServiceConfiguration()

at Microsoft.IdentityModel.Web.HttpModuleBase.Init(HttpApplication context)

at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)

at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)

at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(sIntPtr appContext, HttpContext context)

at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Custom event details:

Solution

This issue took quite a bit of my time to troubleshoot as I thought I had made a mistake for the configuration outlined in the document. What I later determined from the event constantly logged shown above was that the self-signed Microsoft Exchange Server Auth Certificate on the Exchange 2019 servers have expired and it was causing the authentication redirect to the AD FS server to fail. To quickly determine whether this is the case for an environment, simply launch the event viewer on one of the Exchange servers, navigate to the Application logs and filter based on Event ID 24:

You should see an event similar to the following:

Log Name: Application

Source: MSExchange Web Services

Event ID: 24

Level: Error

The Exchange certificate [Subject]

CN=Microsoft Exchange Server Auth Certificate

[Issuer]

CN=Microsoft Exchange Server Auth Certificate

[Serial Number]

2BF79A269A16ACB047DE62C555EAF2B7

[Not Before]

3/18/2015 2:36:19 PM

[Not After]

2/20/2020 1:36:19 PM

[Thumbprint]

E60327C0FFB444247A6CD5E2BAD6AD58083BD6F1

expired on 2/20/2020 1:36:19 PM.

The certificate in this environment expired on February 20, 2020 and while this Exchange Server 2019 wasn’t installed 5 years ago (this is the default lifetime of the self-signed certificate), the first Exchange Server 2013 or 2016 was probably installed sometime in 2015. This certificate is installed on every Exchange server in the organization and shared as it is not unique to the identity of any of the servers.

To renew this certificate, begin by executing the following cmdlet to display the certificates on the Exchange server and confirm that the Microsoft Exchange Server Auth Certificate listed has indeed expired:

Get-ChildItem cert:\localmachine\my | ft Thumbprint,Notafter,Subject

Use the Get-AuthConfig cmdlet to confirm that the expired certificate is being used:

Note the matching thumbprint.

Use the following cmdlet to retrieve the thumbprint of the expired certificate:

Get-AuthConfig | fl Currentcer*

Copy the Thumbprint down as you will need this later.

Note that if the certificate has expired then you can simply renew it directly from the EAC console but I had issues accessing the EAC so I decided to use PowerShell to perform the renewal as outlined in the documentation here:

Renew an Exchange Server certificate
https://docs.microsoft.com/en-us/exchange/architecture/client-access/renew-certificates?view=exchserver-2019

Execute the following cmdlet to list all of the certificates the Exchange server is using and confirm that the previously copied thumbprint matches the one listed as Subject: CN=Microsoft Exchange Server Auth Certificate :

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $true} | Format-List FriendlyName,Subject,CertificateDomains,Thumbprint,NotBefore,NotAfter

Execute the following cmdlet to retrieve the expired certificate as an object then renew it with the New-ExchangeCertificate cmdlet:

Get-ExchangeCertificate -Thumbprint <paste the thumbprint previous copied> | New-ExchangeCertificate -Force -PrivateKeyExportable $true

Here is an example of the cmdlet ran with the thumbprint copied previously:

Get-ExchangeCertificate -Thumbprint E60327C0FFB444247A6CD5E2BAD6AD58083BD6F1 | New-ExchangeCertificate -Force -PrivateKeyExportable $true

Copy the thumbprint to notepad and clearly label this is the renewed certificate.

Executing the previous cmdlet:

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $true} | Format-List FriendlyName,Subject,CertificateDomains,Thumbprint,NotBefore,NotAfter

… will now show the expired and renewed certificate:

If you’re like me where you’re unable to access EAC, you can view the new certificate in the IIS console as well:

Execute the Get-AuthConfig cmdlet and make a note of the that the CurrentCertificateThumbprint is populated while the PreviousCertificateThumbprint and NextCertificateThumbprint are empty:

Proceed to replace the expired certificate by executing the following cmdlets:

$thumb = "< The New Certificate Thumbprint>"

$date = get-date

Set-AuthConfig -NewCertificateThumbprint $thumb -NewCertificateEffectiveDate $date

Here is an example of the cmdlet to execute with the information above:

$thumb = “BDE4266ED877E95F38D303878A048C0EA0183C7B”

$date = get-date

Set-AuthConfig -NewCertificateThumbprint $thumb -NewCertificateEffectiveDate $date

Execute the Get-AuthConfig cmdlet and notice how that the CurrentCertificateThumbprint hasn’t changed but the NextCertificateThumbprint field is now populated with the new certificate’s thumbprint:

Proceed to publish the new certificate and clearing the old expired certificate from the configuration by executing the following cmdlets:

Set-AuthConfig -PublishCertificate

Set-AuthConfig -ClearPreviousCertificate

Execute the Get-AuthConfig cmdlet and notice how that the CurrentCertificateThumbprint has been updated with the new certificate’s thumbprint and the NextCertificateThumbprint field is cleared:

Proceed and confirm that these events are no longer logged:

… then test to confirm that the /owa and /ecp are now being redirected to AD FS.

As a continuation of the AD FS deployment from two of my previous posts:

Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory_21.html

Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html

This post serves to demonstrate the deployment of Duo to provide two-factor authentication for ADFS services using browser-based federated logins.

Deployment instructions as demonstrated in this post can be found directly from Duo here: https://duo.com/docs/adfs

Prerequisites

Download the DUO AD FS installer package for Windows 2012 R2 and later here: https://dl.duosecurity.com/duo-adfs3-latest.msi

Copy the file to your internal ADFS in your farm.

View the checksums for the Duo downloads here: https://duo.com/docs/checksums#duo-ad-fs

Retrieve Duo Configuration Parameters

Begin by logging onto the Duo Admin Panel (https://admin.duosecurity.com/) with an administrator account:

Navigate to Applications and click on Protect an Application

Type ADFS into the search field to locate Microsoft ADFS in the applications list then click on the Protect button to the right:

The following details will be displayed:

• Integration key
• Secret key
• API hostname

Copy the 3 text strings down into notepad as you will need them for the deployment later:

Install DUO MFA Adapter onto ADFS Servers

Log onto your internal ADFS server hosting the primary WIN database and run the duo-adfs3-1.2.0.17.msi MSI installer:

Enter the previously documented strings for:

• Integration key
• Secret key
• API hostname

Then decide whether you want to enable or disable the following 2 configuration parameters:

• Bypass Duo authentication when offline
• Use UPN username format

If you only have one ADFS server in your farm then select either of the option would not matter. However, if you have more than one ADFS server or plan to deploy an additional one in the near future then select Enter shared session key option and generate a unique key with the following PowerShell cmdlets:

$bytes = new-object "System.Byte[]" 30

(new-object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($bytes)

[Convert]::ToBase64String($bytes)

Place the unique key into notepad so you can use it for the deployment of the next ADFS server and then paste it into the Enter shared session key field:

Proceed with the install:

The following prompt will be displayed upon completing the install:

Repeat the steps above for the additional ADFS servers in the farm.

Configuring AD FS to use DUO for MFA

Launch the AD FS Management console:

Navigate to AD FS > Service > Authentication Methods and click on the Edit link for Additional Authentication Methods:

In the Edit Authentication Methods window, select Duo Authentication for AD FS 1.2.0.17 and click OK:

The ADFS farm is now ready to leverage the Duo Authentication for two-factor authentication.

Depending on the requirements in your environment, the default Access Control Policies may be sufficient but if it isn’t, you can configure additional ones by navigating to ADFS > Access Control Policies:

Note how the default Permit everyone and require MFA policy is not currently in use by any applications in this environment.

This environment also does not have any Relying Party Trusts (applications using AD FS for claims based authentication) configured:

Configuring Content Security Policy (CSP) on AD FS 2019

As of Windows Server 2019, the Content Security Policy security feature was introduced to secure ADFS and therefore the inline DUO prompt will not load properly without adding the Duo API hostname with the format api-xxxxxxxx.duosecurity.com into the Content Security Policy security configuration:

Option #1 – If Content Security Policy (CSP) has not yet been set on AD FS 2019, run the following command to set CSP allowing the Duo Prompt:

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self''unsafe-inline''unsafe-eval'; img-src 'self'; frame-src api-xxxxxx.duosecurity.com "

Option #2 – If you have set existing CSP in AD FS 2019, run this PowerShell script to append the necessary changes:

$apihostname = "api-XXXXX.duosecurity.com"

$CSP = ((Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders).'Content-Security-Policy')

$CSP = $CSP + "; frame-src " + $apihostname

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue $CSP

Please remember to replace api-xxxxxx.duosecurity.com in both of the options above with the Duo hostname you copied from the Duo administration portal earlier.

Testing Duo two-factor authentication on the idpinitiatedsignon.htm page

If you do not have any Relaying Party Trusts configured but want to test the newly deployed Duo, you can use the idpinitiatedsignon.htm page to test.

Begin by enabling the page by executing the following cmdlet as ADFS 2016 and newer disables the page by default:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Verify that the sign on page is displayed when browsing to the URL: https://<ADFSServer>/adfs/ls/idpinitiatedsignon.htm

Navigate to AD FS >Relying Party Trusts and click on Add Relying Party Trust… under the Actions pane on the right:

Select Claims Aware and click Start:

Select Import data about the relying party published online or on a local network and paste the following under the Federation metadata address (host name or URL): text field:

https://<ADFSServerFQDN>/federationmetadata/2007-06/federationmetadata.xml

Specify a Display name and an optional description in the Notes field:

Select Permit everyone and require MFA under the Choose an access control policy options:

Verify the configuration and click Next:

Clear the Configure claims issuance policy for this application and click Close:

Navigate to the URL: https://<ADFSServer>/adfs/ls/idpinitiatedsignon.htm and you should see an additional Sign in to one of the following sites: option. Ignore that option and proceed to sign with the Sign in to this site option:

Enter your Active Directory credentials:

You should now see the Duo 2-factor authentication prompt:

The following page will be displayed upon successfully signed in:

As a continuation of the AD FS deployment from two of my previous posts:

Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory_21.html

Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html

This post serves to demonstrate the configuration of Citrix ADC (formerly known as Citrix NetScalers) to load balance the ADFS farm as well as the ADFS Web Application Proxy (WAP) servers.

Design Considerations

As outlined in the Load Balancer requirements section in the following Microsoft documentation:

AD FS Requirements
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements

• The load balancer MUST NOT terminate SSL. AD FS supports multiple use cases with certificate authentication which will break when terminating SSL. Terminating SSL at the load balancer is not supported for any use case, which means the Protocol you will use for your Load Balancing Service Group and Virtual Server will be SSL_BRIDGE and not SSL as the latter terminates the SSL connection and re-establishes the connection.
• SNI support is recommended and any Citrix ADC / NetScaler above version 11.1 supports it (https://www.citrix.com/content/dam/citrix/en_us/citrix-developer/documents/Netscaler/how-to-connect-to-adfs-3-0-from-netscaler-adc-load-balancer.pdf)
• The health probe that the Citrix ADC should use to monitor the health of the ADFS servers should be HTTP and not HTTPS.
• ADFS also does not support HEAD requests (https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq#does-ad-fs-support-head-requests) so the Citrix ADC should use a GET request to probe the health of the server.
• DNS round robin is not recommended but this won’t be an issue as we’ll be using a Citrix ADC to provide load balancing.
• It is NOT recommended to use IP based session affinity or sticky sessions for authentication traffic to AD FS within the load balancer. This can cause an overload of certain nodes when using legacy authentication protocol for mail clients to connect to Office 365 mail services (Exchange Online).

IP Requirements

• 1 x IP address will be required for the VIP of the load balancing virtual server on the Citrix ADC that represents the internal ADFS farm
• 1 x IP address will be required for the VIP of the load balancing virtual server on the Citrix ADC that represents the internal ADFS WAP servers
• 1 x public IP address will be required to NAT traffic from the internet to the WAP VIP

We’ll be using a Citrix ADC VPX 200 Standard license with the build NS13.0 52.24.nc for this demonstration.

Firewall Rules

• Other than port 443 traffic between the Citrix ADC / NetScaler, you will also need to allow port 80 in order to monitor the health of the ADFS server (both internal farm and Web Access Proxy)
• ICMP is optional and is convenient for troubleshooting at times but it is not necessary

Internal ADFS farm and WAP Servers

• The Load Balancing virtual server for the internal ADFS farm servers and the WAP servers will have the same configuration all of the components:
  • Monitor
  • Service Group
  • Virtual Server

This essentially means that you can confirm the load balancing virtual server for the internal ADFS farm servers then repeat the same for the WAP servers.

Creating a Service Monitor

One of the most common question I am asked the most is how to properly create a service monitor for the ADFS servers as Microsoft recommends against monitoring the service via HTTPS and to use HTTP as described in the following documentation under the Load Balancer requirements:

AD FS Requirements

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements#BKMK_7

• It is recommended to use the HTTP (not HTTPS) health probe endpoints to perform load balancer health checks for routing traffic. This avoids any issues relating to SNI. The response to these probe endpoints is an HTTP 200 OK and is served locally with no dependence on back-end services. The HTTP probe can be accessed over HTTP using the path ‘/adfs/probe'

• http://<Web Application Proxy name>/adfs/probe
• http://<ADFS server name>/adfs/probe
• http://<Web Application Proxy IP address>/adfs/probe
• http://<ADFS IP address>/adfs/probe

Another common blog post I am sent for review is the following:

Load balancing ADFS and ADFS Proxy using Citrix ADC

https://www.vcloudnine.de/load-balancing-adfs-and-adfs-proxy-using-citrix-adc/

While the write up is excellent with describing the behavior and monitoring process of the service, the following use of the HEAD request for the monitor would not work:

add lb monitor mon_adfs_http HTTP -respCode 200 -httpRequest "HEAD /adfs/probe" -LRTM ENABLED -destPort 80

Attempting to configure such a monitor with the HTTP Request configured as HEAD /adfs/probe as shown in the following screenshot will cause the probe to fail.

It does not come to a surprise that this is a common mistake as the HEAD request is the default when a HTTP monitor is created and the Microsoft documentation explicitly states ADFS also does not support HEAD requests (https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq#does-ad-fs-support-head-requests) so the monitor would display the following probe error:

Failure - HTTP response code 405 received.

This can also be tested directly from the Citrix ADC / NetScaler by getting into the Linux shell and executing:

HEAD <IP Address>/adfs/probe

The correct method of retrieving the health of the ADFS server is through the GET method, which would return a 200 OK response:

GET -s <IP Address>/adfs/probe

***Note that you need to include the -s as that switch displays the status code but it is not needed when configuring the monitor.

If you omit the -s then no output would be displayed:

----------------------------------------------------------------------------------------------------------------------------

Extra Commands to Test

Another command that can be executed within the Linux shell of the Citrix ADC / NetScaler to test the health of the ADFS is:

curl -i http://<IP Address>/adfs/probe

You can also use the same curl command within a PowerShell console to probe the health ADFS server:

curl http://<IP Address>/adfs/probe

----------------------------------------------------------------------------------------------------------------------------

With the above outlined, create a HTTP type monitor as shown in the following screenshots:

Name: A preferred monitor name (e.g. mon_adfs_http)

Type: HTTP

Interval: 5 seconds

Response Time-out: 2 seconds

Response Codes: 200

Custom Header: <leave blank>

HTTP Request: GET /adfs/probe

Secure: <unchecked>

Advanced Parameters

Leave all settings as default and enable LRTM (Lease Response Time using Monitoring):

Create Server Objects

Create the server objects on the Citrix ADC that represents ADFS servers. This demonstration will use the internal server farm servers as an example but the steps are the same for the Web Application Proxy (WAP) servers that provide external ADFS connectivity.

Repeat the same procedure for all of the servers in the farm.

Create Service Group

It is possible to use either Services of ServiceGroups to represented the ADFS service that will be offered but ServiceGroups provide an simpler method of adding more than one server for the service so this example will employ this approach.

Provide a name for the Load Balancing Service Group, configure the protocol as SSL_BRIDGE and leave the rest of the parameters as the default.

***Note that as mentioned above (and repasted below), we cannot terminate the SSL connection on the load balancer as this is not supported.

The load balancer MUST NOT terminate SSL. AD FS supports multiple use cases with certificate authentication which will break when terminating SSL. Terminating SSL at the load balancer is not supported for any use case.

With the empty service group will be created, click on No Service Group Member to add the previously created server objects that were created:

Proceed to select the servers for the ADFS farm:

Configure the Port for the two servers to be 443 and leave the rest as defaults:

The selected servers will now be in the service group:

Proceed to click on the Monitors option on the right side of the load balancing service group:

Click on the No Service Group to Monitor Binding to add the previously created monitor for the ADFS servers:

Click on the Add button to display the available monitors:

Select the previously created monitor from the bottom of the list (new monitors are placed at the bottom):

Click on the Bind button to bind the monitor to the service group:

The Monitors section should now display 1 Service Group to Monitor Binding:

Click Done to complete the configuration for the service group:

Create Virtual Server

Proceed to create a new virtual server:

Provide a name for the Virtual Server, configure the protocol as SSL_BRIDGE, enter the pre-allocated VIP as the IP Address, specify the port as 443, and leave the rest of the parameters as the default.

With the newly created Load Balancing Virtual Server created, click on No Load Balancing Virtual Server ServiceGroup Binding to add the previously created Service Group:

Click on the Add button:

Select the Service Group created earlier:

Click on the Bind button to complete the configuration:

Complete the creation of the virtual server by clicking on Done:

Confirm that the virtual server’s State and Effective State is in an UP state, then repeat the same procedure for the Web Application Proxy (WAP) servers.

One of the common questions I’ve been asked by my colleagues who are a part of an on-premise migration to Azure project is how to reset an Azure Migrate Appliance, which has already been configured and registered with an existing Azure Migrate Project. A typical scenario where this may be necessary can be for organizations that did not have any Azure tenant setup and in order to generate an assessment report for the client, the consultant uses their own organization’s tenant. From there, an assessment can be created for the client, obtain approval and proceed with the migration. The challenge that comes when it is time to migrate is that the assessment and evidently the associated tenant is incorrect. Navigating to the Azure Migrate Appliance’s configuration webpage does not provide a way to change the configuration as shown in the screenshot below:

https://localhost:44368

To reset an Azure Migrate OVA virtual appliance configured for VMware vSphere is actually quite simple. Begin by navigating to the following path on the deployed Azure Migrate Windows OVA appliance:

C:\ProgramData\Microsoft Azure\Config\

Then proceed to open the following file in the directory:

appliance.json

Search for the following line:

“IsApplianceRegistered”: “True”,

Change the value of True to False and save the file:

“IsApplianceRegistered”: “False”,

While I’ve found that the majority of the times I’ve done this does not require a restart, I would advise to restart the virtual machine anyways.

The Azure Migrate Appliance will now be reset to the unconfigured state:

You’ll be able to log into a different tenant after setting up the prerequisites:

One of the most common questions I tend to be asked by colleagues is how would they be able to connect multiple Azure virtual networks together and allow them to utilize a single VPN gateway to connect back to an on-premise network so that traffic can flow in between the virtual networks and across the site-to-site VPN. As most Azure administrators will already know, a virtual network is the traffic isolation boundary on the Azure platform. Virtual networks in Azure does not allow any ingress traffic by default (https://docs.microsoft.com/en-us/azure/security/fundamentals/isolation-choices#networking-isolation). There are two choices available to connect virtual networks together and they are:

1. Site-to-site VPN
2. VNet Peering

I won’t go into too much detail as there are many articles and documentation outlining the advantages and disadvantages between the two. In addition to this article that outline the differences: https://azure.microsoft.com/en-us/blog/vnet-peering-and-vpn-gateways/ also be aware of the bandwidth limitations, traffic traversing through the internet and overhead when using a VPN. VNet Peering uses the Azure backbone and therefore provides more bandwidth and less latency. So assuming if features such as encryption isn’t necessary, using VNet Peering is typically a much better option.

This blog post will serve to demonstrate the configuration of a hub and spoke topology where virtual networks are connected with VNet Peering and the spoke connecting to an on-premise network via VPN Gateway.

Environment

The following is the topology we will begin with:

The virtual networks are configured with the following parameters:

Name: vnet-prod-eastus
Address Space: 10.248.0.0/16
Subnet Name: 10.248.1.0-24
Subnet: 10.248.1.0/24
Gateway Subnet: 10.248.255.0/27
Virtual Machine Name: btadc03
Virtual Machine IP: 10.248.1.250

Name: vnet-dev-eastus
Address Space: 10.249.0.0/16
Subnet Name: 10.249.1.0-24
Subnet: 10.249.1.0/24
Virtual Machine Name: vm-dev-linux
Virtual Machine IP: 10.249.1.4

Name: vnet-uat-eastus
Address Space: 10.250.0.0/16
Subnet Name: 10.250.1.0-24
Subnet: 10.250.1.0/24
Virtual Machine Name: vm-uat-linux
Virtual Machine IP: 10.250.1.4

Objective

The goal of the configuration is to establish a bidirectional connection between:

• vnet-dev-eastus and vnet-prod-eastus
• vnet-uat-eastus and vnet-prod-eastus
• vnet-dev-eastus and on-premise datacentre
• vnet-uat-eastus and on-premise datacentre

Note that there will be now bidirectional communication between:

• vnet-dev-eastus and vnet-uat-eastus

Being able to achieve this will require an NVA appliance deployed in vnet-prod-easus, which I will cover in a different post or you can refer to the following article: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

VNet Peering Topology

The bidirectional VNet Peering we will be configuring will between:

• vnet-dev-eastus and vnet-prod-eastus
• vnet-uat-eastus and vnet-prod-eastus

Topology with Configuration

The topology with VNet Peering configuration will look as such:

VNet Configuration

The three virtual networks are configured as shown in the following screenshots:

vnet-prod-eastus

vnet-dev-eastus

vnet-uat-eastus

Configuring VNet Peering between vnet-dev-eastus (spoke) and vnet-prod-eastus (hub)

Configure the VNet Peering between vnet-dev-eastus peer to vnet-prod-eastus by navigating into the spoke virtual network, click on Peerings under Settings and then the Add button:

Provide a meaningful name for the peering between the two VNets and for this example, I will use the following:

vnet-dev-eastus-to-vnet-prod-eastus

vnet-prod-eastus-to-vnet-dev-eastus

Allow virtual network access from vnet-dev-eastus to vnet-prod-eastus: Enabled
Allow virtual network access from vnet-prod-eastus to vnet-dev-eastus: Enabled
Allow forwarded traffic from vnet-prod-eastus to vnet-dev-eastus: Disabled
Allow forwarded traffic from vnet-dev-eastus to vnet-prod-eastus: Disabled
Allow gateway transit: Enabled

Note that hoovering over the Allow gateway transit checkbox will add a checkmark into it but clicking into it would grey out the option as such:

It appears a bit odd but this is normal.

A bidirectional VNet Peering between the two VNets will now be created. Note that the peering from the spoke to hub will have Gateway transit disabled:

Clicking into the hub’s VNet Peering will show that Use remote gateways is checked:

Configuring VNet Peering between vnet-uat-eastus (spoke) and vnet-prod-eastus (hub)

The procedure for the other spoke will be the same as above.

Configure the VNet Peering between vnet-uat-eastus peer to vnet-prod-eastus by navigating into the spoke virtual network, click on Peerings under Settings and then the Add button:

Provide a meaningful name for the peering between the two VNets and for this example, I will use the following:

vnet-uat-eastus-to-vnet-prod-eastus

vnet-prod-eastus-to-vnet-uat-eastus

Allow virtual network access from vnet-uat-eastus to vnet-prod-eastus: Enabled
Allow virtual network access from vnet-prod-eastus to vnet-uat-eastus: Enabled
Allow forwarded traffic from vnet-prod-eastus to vnet-uat-eastus: Disabled
Allow forwarded traffic from vnet-uat-eastus to vnet-prod-eastus: Disabled
Allow gateway transit: Enabled

As with the previous spoke virtual network configuration, the Allow gateway transit will be greyed out when you enable it.

A bidirectional VNet Peering between the two VNets will now be created. Note that the peering from the spoke to hub will have Gateway transit disabled:

Clicking into the hub’s VNet Peering will show that Use remote gateways is checked:

vnet-prod-eastus (hub) VNet Peering configuration

The VNet Peering for the hub network to the other two spokes would have already been created and configured and look similar to the following:

Clicking into the properties of the peering will show that Allow gateway transit is enabled and Use remote gateways greyed out:

Virtual Machines for Testing

As show in the diagrams earlier this post, there are VMs in each network that will be used for testing.

The virtual machine vm-dev-linux resides in the vnet-dev-eastus virtual network:

The virtual machine vm-uat-linux resides in the vnet-uat-eastus virtual network:

The virtual machine vm-btadc03 resides in the vnet-prod-eastus virtual network:

The IP addresses for these virtual machines are as follows:

vm-btadc03
Private IP: 10.248.1.250

vm-dev-linux
Public IP: 13.72.106.103
Private IP: 10.249.1.4

vm-uat-linux
Public IP: 13.72.109.104
Private IP: 10.250.1.4

A SSH connection will be established with the two Linux VMs:

A ping test confirms that connectivity between vnet-dev-eastus (spoke to hub) is functional:

A ping test confirms that connectivity between vnet-uat-eastus (spoke to hub) is functional:

If your on-premise VPN gateway appliance is configured with the routes to send traffic from the on-premise network to the spoke networks then you should also be able to ping from the spoke networks through the hub network, over the site-to-site VPN and to the on-premise VM. In the even that you are not able to, verify that you have the routes on the on-premise VPN gateway. The following is a screenshot of a WatchGuard firewall providing VPN gateway services for the on-premise network:

Note that the 10.249.0.0/16 and 10.250.0.0/16 routes for the two hub networks are configured.

------------------------------------------------------------------------------------------------------------------------

Extra - VNet Peering configuration

For reference, the following are information notes available for each configuration parameter during the VNet Peering configuration.

One of the most common engagements I am engaged with for post Citrix or VMware virtual desktop deployments is to troubleshoot slow Windows VDI login performance and I’ve found that if profile management solutions such as Citrix UPM was deployed correctly, the root cause would typically be the Active Directory Group Policy Objects that are either intentionally or unintentionally applied to the user accounts or desktops. Having gone through an exercise I’ve done numerous in the past today and realizing I never wrote a blog post about it, this post will serve to demonstrate how I typically approach the troubleshooting process in a Citrix XenDesktop VDI environment.

Step #1 – Replicate the issue

The first step is to replicate the issue so use an account that is experiencing the slow logon times and log onto a virtual desktop while making a note of when you logged on and when it completed as you will need these later.

Step #2 – Review the duration for each component during the logon process

Leave the session to the desktop connected once the login process has completed and then proceed to launch the CitrixDirector or the Monitor console in Citrix Cloud’s Virtual Apps and Desktops Service and then click on the Trends option:

With the Trends console displayed, click on the Logon Performance tab and scroll down to the Logon Duration by User Session section:

In the Search associated users field, search for the login name of the user account that was used to test:

As shown in the screenshot above, a breakdown of the duration for the logon is displayed in multiple columns. The headings that typically consumes the most amount of time are:

1. GPOs
2. Profile Load

GPOs are the Active Directory Group Policy objects that are applied to the account during logon and the Profile Load is, in this case, Citrix UPM that is configured.

From the metrics provided above, we can see that the Profile Load takes approximately 10.966 seconds while the GPOs take 35.99 seconds.

Step #3 – Review Citrix UPM logs

To gain a better understanding of the processes contributing to the Profile Load process, navigate back to the virtual desktop that was used for testing and navigate to the following directory:

C:\Windows\System32\LogFiles\UserProfileManager

**Note that this directory is configurable but this environment uses the default.

The log we are interested in ends with the desktop name_pm.log as shown in the screenshot below:

Open the log and navigate to the line with Starting logon processing to review how long each process has taken:

Step #4 – Review Event Logs for GPOs

If the GPOs being applied to the user and virtual desktop is causing an extended amount of time during the logon process then the next step is to launch the event logs of the virtual desktop and navigate to the following event log:

Microsoft/Windows/GroupPolicy/Operational

Scroll and locate the event ID 5324 that has a time stamp close to the time you initiated the login:

Scroll upwards to later events and you should see an event ID 4001 that states the following details: Starting user logon Policy processing for <your username>:

Continue to scroll up and you’ll see another event 4017 entry that specifies which domain controller was used for the LDAP bind:

Continuing to the next event ID 5017 will show how long the LDAP bind took:

The next event ID 5326 will indicate how long the domain controller discovery took:

An event ID 5327 will be written to provide an estimated bandwidth:

From here on the following event entries will allow you to determine how long each component is consuming during the login process for the user.

Registry Extension Processing duration:

Citrix Group Policy ExtensionProcessing duration:

Folder Redirection Extension Processing duration:

Group Policy Drive Maps Extension Processing duration:

Group Policy Printers Extension Processing duration:

This post serves to quickly demonstrate how to install and import the ExchangeOnlineManagement (Exchange Online PowerShell V2) module to connect to Exchange Online in Microsoft 365 to retrieve data, create new objects, update existing objects, remove objects and configure other Exchange Online features.

Begin by executing the following cmdlet to install the ExchangeOnlineManagement module:

Install-Module -Name ExchangeOnlineManagement

Then use the following cmdlet to import and list the version of the module:

Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement

If the displayed version is out of date, the following cmdlet can be executed to update the module:

Update-Module -Name ExchangeOnlineManagement

With the ExchangeOnlineManagement module installed proceed to connect to Exchange online with:

Connect-ExchangeOnline

The following modern authentication prompt supporting MFA will be displayed:

Entering valid administrative credentials will successfully connect you to the tenant:

Below is example of modifying an account’s default calendar permissions upon successfully connecting:

You’re attempting to install a PowerShell module such as SharePointPnPPowerShellOnline to use Connect-PNPONline (https://docs.microsoft.com/en-us/powershell/module/sharepoint-pnp/connect-pnponline?view=sharepoint-ps) to establish a connection to SharePoint online, which prompts you to install the NuGet provider. Proceeding to answer yes to the prerequisite install quickly fails with the following message:

PS C:\> Install-Module SharePointPnPPowerShellOnline

NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet

provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or

'C:\Users\tluk\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by running

'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install and import

the NuGet provider now?

[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

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

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

PackageManagement\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.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7405 char:21

+ ... $null = PackageManagement\Install-PackageProvider -Name $script:N ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac

kageProvider], Exception

+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro

vider

PackageManagement\Import-PackageProvider : No match was found for the specified search criteria and provider name

'NuGet'. Try 'Get-PackageProvider -ListAvailable' to see if the provider exists on the system.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7411 char:21

+ ... $null = PackageManagement\Import-PackageProvider -Name $script:Nu ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidData: (NuGet:String) [Import-PackageProvider], Exception

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProv

ider

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

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

PackageManagement\Get-PackageProvider : Unable to find package provider 'NuGet'. It may not be imported yet. Try

'Get-PackageProvider -ListAvailable'.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7415 char:30

+ ... tProvider = PackageManagement\Get-PackageProvider -Name $script:NuGet ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (Microsoft.Power...PackageProvider:GetPackageProvider) [Get-PackageProvi

der], Exception

+ FullyQualifiedErrorId : UnknownProviderFromActivatedList,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPacka

geProvider

Install-Module : NuGet provider is required to interact with NuGet-based repositories. Please ensure that '2.8.5.201'

or newer version of NuGet provider is installed.

At line:1 char:1

+ Install-Module SharePointPnPPowerShellOnline

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (:) [Install-Module], InvalidOperationException

+ FullyQualifiedErrorId : CouldNotInstallNuGetProvider,Install-Module

PS C:\>

Solution

A quick workaround for this error is configure TLS 1.2 for the PowerShell session with the following command:

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

NuGet provider will install once the above is executed:

PS C:\> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

PS C:\> Install-Module SharePointPnPPowerShellOnline

NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet

provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or

'C:\Users\tluk\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by running

'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install and import

the NuGet provider now?

[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

Untrusted repository

You are installing the modules from an untrusted repository. If you trust this repository, change its

InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from

'PSGallery'?

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y

PS C:\>

To permanently correct the issue, open the registry and navigate to the following path for the 64 bit .Net Framework:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319

Add the chUseStrongCrypto key with the following PowerShell cmdlet:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Repeat the same for the 32 bit .Net Framework:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Problem

You’ve noticed that access the ADFS authentication portal from the internal network with Internet Explorer via the internal farm (not WAP) displays the Windows Security login prompt instead of the form webpage authentication:

Navigating to the same sign on page through the ADFS Web Application Proxy from the internet displays the expected webpage form authentication:

Solution

In order for allow clients on the internal network to authenticate via the webpage form based authentication, the ADFS URL needs to be added to the Local Intranet zone for Internet Explorer:

**Note that the environment used in this example has a GPO configured that locks out the user from adding sites to the Local intranet.

To correct this issue with a GPO that you can apply globally in the organization, you will need to decide whether the Group Policy should:

1. Add the site *and* prevent users from adding sites
2. Add the site *and* allow users to add additional sites

If #1 is the desired affect then create or append to a GPO that is applied to the user accounts with the settings:

User Configuration/Policies/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/Site to Zone Assignment List

Then add the ADFS URL into the Value Name and 1 as the Value.

The GPO will add the site into the Intranet Site and disallow the user from adding more sites:

Using the Computer policy because the latter gray’s out the zones and prevents the users from knowing or adding sites to the zones.

If #2 is desired then create a Group Policy Preferences Registry Extension then configure the following:

Hive: HKEY_CURRENT_USERS

Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\domain.com\fs

Value name:http

Valuetype: REG_DWORD

Valuedata: 00000001

For reference, the following are the Value data for the other zones:

**Note that native group policy settings will take precedence over Group Policy Preferences so if the Site to Zone Assignment List is configured then it will override (not merge) the registry settings.

I recently received a question from someone who had issues setting up a monitor on his Citrix ADC / Netscaler appliance and who had come across my previous blog post:

Configure Citrix ADC to load balance Microsoft Active Directory Federation Services (AD FS) on Windows Server 2019

http://terenceluk.blogspot.com/2020/05/configure-citrix-adc-to-load-balance.html

The issue he had was that the HTTP monitor he had set up would fail with the LAST RESPONSE from the AD FS server as: Failure - TCP connection successful, but application timed out

I haven’t come across this issue before but after going through the settings with him, we determined that he had forgotten to specify the destination port in the monitor as shown in the screenshot:

I hope this helps anyone who may encounter this issue during their configuration.

Problem

You attempt to upgrade Citrix Licensing from 11.14.0.1 build 23101 to 11.16.3.0 build 30000 but the process fails with:

Failed to configure Citrix Licensing.

Upgrade failed. The server.xml and other configuration files were not found. Contact Citrix.

Fiddling around with the executable and MSI to ensure that it is not blocked does not correct the issue:

Solution

I’m not sure about what causes this issue but it has happened to me several times during my upgrades of the Licensing server role. To complete the upgrade, simply uninstall the Citrix Licensing application in Programs and Features:

Then install the licensing server role again:

The license files aren’t removed during an uninstall but ensure that you have access to the Citrix portal to redownload the license if it is not present.