Pages

Tuesday, June 19, 2018

Azure AD synchronization fails with: "user_realm_discovery_failed: User realm discovery failed" and "The remote server returned an error: (407) Proxy Authentication Required."

Problem

You’ve noticed that your Azure AD synchronization has stopped synchronizing for a period of time:

image

Launching the Synchronization Service Manager indicates the export job is failing with stopped-extension-dll-exception:


image

Reviewing the event logs show the following three events consistently logged:

  • Event ID: 6900
  • Event ID: 659
  • Event ID: 906

image

Log Name: Application
Source: ADSync

Event ID: 6900

Level: Error

The server encountered an unexpected error while processing a password change notification:

"user_realm_discovery_failed: User realm discovery failed

at InitializeAndGetTargetExtension(Object lockObject, TargetTaskScheduler taskScheduler, Dictionary`2 targetExtensions, ECMAInformation* ecmaInformation)

at TargetExtensionManager.ExportPasswords(TargetExtensionManager* , ECMAInformation* ecmaInformation, DynamicArray<ActiveDirectoryPasswordChange \*>* targetPasswordChanges, Char* forestInfo)

InnerException=>

The remote server returned an error: (407) Proxy Authentication Required.

at System.Net.HttpWebRequest.GetResponse()

at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

InnerException=>

none

"

image

Log Name: Application
Source: Directory Synchronization

Event ID: 659

Level: Error

Error while retrieving password policy sync configuration. Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed ---> System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required.

at System.Net.HttpWebRequest.GetResponse()

at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

--- End of inner exception stack trace ---

at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RunAsyncTask[T](Task`1 task)

at Microsoft.Online.Coexistence.ProvisionHelper.GetADALToken(String userName, String userPassword, MSOInstance adalServiceResource)

at Microsoft.Online.Coexistence.ProvisionHelper.GetSecurityToken(String userName, String userPassword, MSOInstance adalServiceResource)

at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.InitializeProvisionHelper()

at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.Initialize()

at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.GetCompanyConfiguration()

at Microsoft.Azure.ActiveDirectory.Connector.PasswordPolicy.RefreshPasswordPolicySyncSettings()

ErrorCode: user_realm_discovery_failed

StatusCode: 0

image

Log Name: Application
Source: Directory Synchronization

Event ID: 906

Level: Error

GetADALToken [user_realm_discovery_failed]: unexpected authentication failure. STS endpoint (https://login.windows.net), userName (Sync_DIRSYNC01_d5b89680b957@contoso.onmicrosoft.com), tenantName (contoso.onmicrosoft.com), adalAuthority(https://login.windows.net/contoso.onmicrosoft.com) user_realm_discovery_failed: User realm discovery failed | The remote server returned an error: (407) Proxy Authentication Required..

image

Solution

One of the possible causes to this error is if the DirSync service is attempting reach Azure via a proxy server and is unable to authenticate. In the case of this example, the DirSync server was able to synchronize directly via the internet but had inadvertently inherited proxy settings due to a network misconfiguration. Changing the proxy settings did not correct the problem as DirSync continued to connect to the proxy. To correct this problem, you’ll need to edit a configuration file for the synchronization service manager to stop it from using a proxy.  Navigate to the following directly:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config

.. and locate the machine.config file:

image

Duplicate the file to create a backup:

image

Open the file and navigate to the end of the configuration:

image

Add the following under the </system.web> tag:

<system.net>

<defaultProxy enabled="false"></defaultProxy>

</system.net>

image

Save the file, restart the Azure synchronization services and rerun the synchronization.

Friday, June 15, 2018

Update June 2018: Securing Citrix NetScaler VPX to score A+ rating on SSL Labs

This post serves as an update to my previous blog post:

Update: Securing Citrix NetScaler VPX to score A+ rating on SSL Labs

http://terenceluk.blogspot.com/2017/09/update-securing-citrix-netscaler-vpx-to.html

… which will no longer score an A+ rating because the ciphers are now out of date.

In order to score an A+ rating:

image

… we’ll need to update the ciphers to the following:

TLS1-ECDHE-RSA-AES256-SHA

TLS1-ECDHE-RSA-AES128-SHA

TLS1-DHE-RSA-AES-256-CBC-SHA

TLS1-DHE-RSA-AES-128-CBC-SHA

TLS1-AES-256-CBC-SHA

TLS1-AES-128-CBC-SHA

TLS1.2-ECDHE-RSA-AES-256-SHA384

TLS1.2-ECDHE-RSA-AES-128-SHA256

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

TLS1.2-DHE-RSA-AES256-GCM-SHA384

TLS1.2-DHE-RSA-AES128-GCM-SHA256

TLS1-ECDHE-ECDSA-AES256-SHA

TLS1-ECDHE-ECDSA-AES128-SHA

image

The command to execute on the NetScaler are as follows:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-ECDSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-ECDSA-AES128-SHA

The ciphers above were tested on a NetScaler NS12.1 48.13.nc and verified to score an A+.

image

Wednesday, June 13, 2018

Signing into Dell Wyse thin client creates a Windows temporary profile

Problem

You’ve noticed that users logging into Dell Wyse Z90QQ10 and Z90QQ7P thin clients are receiving temporary profiles regardless of whether the write filter on the thin client is turned on or off:

You've been signed in with a temporary profile.

You can’t access your files, and files created in this profile will be deleted when you sign out. To fix this, sign out and try signing in later. Please see the event log for details or contact your system administrator.

clip_image002

Solution

While I have yet find a permanent solution for this problem, what appears to be a workaround is to:

  1. Stop and disable the Client Cleanup (also known as NetXClean) service
  2. Clean up the orphaned registry key representing the user’s profile
  3. Leave the write filter off

clip_image002[4]

clip_image002[6]

Instructions for cleaning up the temporary profile can be found here in one of my previous blog posts:

Logging into Windows displays the system tray message: “You’ve been signed in with a temporary profile.”
http://terenceluk.blogspot.com/2018/03/logging-into-windows-displays-system.html

I’ll update this post when I am able to find a solution that allows the write filter to be left on.

Tuesday, June 12, 2018

Executing Test-CsFederatedPartner throws the error: “No matching cluster found in topology.”

Problem

You attempt to use the Test-CsFederatedPartner cmdlet (https://docs.microsoft.com/en-us/powershell/module/skype/test-csfederatedpartner?view=skype-ps) to test a configured partner federation but receive the following error:

PS C:\> Test-CsFederatedPartner -TargetFqdn sip.contoso.com -Domain contoso.com

Test-CsFederatedPartner : No matching cluster found in topology.

At line:1 char:1

+ Test-CsFederatedPartner -TargetFqdn sip.contoso.com -Domain

tokiomillenn ...

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

~~~

+ CategoryInfo : ResourceUnavailable: (:) [Test-CsFederatedPartne

r], InvalidOperationException

+ FullyQualifiedErrorId : NoMatchingClusterFound,Microsoft.Rtc.Management.

SyntheticTransactions.TestFederatedPartnerCmdlet

PS C:\> Test-CsFederatedPartner -TargetFqdn lyncedge01.sourceDomain.com -Domain contoso.com

image

Solution

I’ve been asked about this error quite frequently every so often so I hope this blog post will help anyone who may be searching for this error when using the cmdlet. The most frequent cause of this issue is if you did not specify the correct value for the TargetFqdn switch as most administrators tend to misinterpret that as being the external partner’s Edge server SIP address and having this incorrect value would throw the error. The correct value for this switch is actually the internal FQDN name of the local Edge server. Using the correct value for this switch with the domain switch will allow the test to execute and return the result similar to the following output:

Target Fqdn : lyncedge01.sourceDomain.com

Result : Success

Latency : 00:00:00

Error Message :

Diagnosis :

image

Monday, June 4, 2018

VMware Horizon View 7.4.0 reports the following error for connection and security servers: "Server's certificate is not trusted." and "Server's certificate cannot be checked."

Update: June 7, 2019

I’ve noticed that the following two patches also causes the issues and uninstalling them corrects the issue:

Windows Server 2012 R2: KB4103725

Windows Server 2008 R2: KB4103718

clip_image002clip_image002[4]

Problem

You’ve noticed that a previously error free VMware Horizon View 7 administrator console display all Connection Servers and Security Servers in an error state and clicking into the properties of the servers display the following message:

Version: 7.4.0

Status:

Server's certificate is not trusted.

Server's certificate cannot be checked.

SSL Certificate: Invalid

image

Using the following KB to disable Certificate Revocation List (CRL) check via the registry key corrects the issue:

Administration dashboard in VMware Horizon View reports the error: Server's certificate cannot be checked (2000063)
https://kb.vmware.com/s/article/2000063

However, this error was not present and not intentional changes have been made to the environment.

Solution

I wasn’t comfortable or satisfied with implementing the registry to disable Certificate Revocation List (CRL) check because this wasn’t required before so after reviewing what was changed on the server over the last few days, I noticed that the following patch was installed on the servers:

KB4103724 for the Windows Server 2012 R2 connection servers:

image

KB4103713 for the Windows Server 2008 R2 connection servers:

image

To correct the problem, locate the patch in the Installed Updates console and remove it:

image

An alternative way to remove the patch via command is as follows:

wusa.exe /uninstall /kb:4103724 < for Windows 2012 R2 servers

wusa.exe /uninstall /kb:4103713 < for Windows 2008 R2 servers

The status of all the servers should change back to green after the removal and restart of the servers:

image

Friday, June 1, 2018

Deploying SecurEnvoy 2FA with Exchange Server 2016 OWA

I recently had to deploy SecurEnvoy 2FA with Exchange Server 2016’s OWA and noticed that there wasn’t official documentation for the configuration so I thought I’d write this blog post to outline the steps I used.  Note that the steps outlined in the Exchange 2013 documentation is accurate and the steps below are the same but I’ve added additional post deployment tasks for customizing the login page.

Environment Information

SecurEnvoy: Version 9.1.501 (https://www.securenvoy.com/support/downloads.shtm)
Microsoft Exchange: Exchange 2016 CU8
Server Operating System: Windows Server 2016

Deployment Steps

Begin by downloading the SecurEnvoy package from the portal:

image

Extract the securenvoy.zip package and navigate into the Release9.1.501 folder::

imageimage

Proceed into the Agents folder and navigate into the Microsoft Server Agent folder:

imageimage

Run the setup.exe executable:

image

Install the agent:

imageimage

Configure the SecurEnvoy server or servers in the SecurEnvoy Servers tab:

image

Note that you’ll need to add the Exchange server to the SecurEnvoy server as a Radius client via the administration console:

image

Once configured, ensure that the Test Server option returns a Server OK status:

image

Click on the IIS Authentication tab and enable the Include SecurEnvoy Plugin in IIS option then click Update:

image

Answer OK to the prompt asking to install the CGI module:

imageimage

Restart IIS when asked:

imageimage

Launch IIS (Internet Information Services Manager), select the Default Web Site node and then double click the SecurEnvoy Two Factor Authentication node:

image

Enable the Enable Authentication On Site option and click Apply:

image

You will get an OK displayed to confirm the change:

image

Navigate the owa node and double click the SecurEnvoy Two Factor Authentication node:

image

Enable the Enable Authentication On /owa option, click Apply and restart IIS:

image

Hit the refresh button and SecurEnvoyAuth node should appear:

image

Right click on the SecurEnvoyAuth node, Manage Application then Advanced Settings…:

image

Verify that the Application Pool is configured as MSExchangeOWAAppPool:

image

Select the top node under Start Page and double click the SecurEnvoy Two Factor Authentication node:

image

Uncheck Allow non secure connections (http) option:

image

Add the following to the Logoff URL’s:

/owa/auth/logon.aspx
/owa/auth/logoff.aspx

image

Restart IIS when asked:

image

The portal should now display the SecurEnvoy login screen:

image

Assuming you would like users to use their username to login, ensure that you have configured a default domain for the portal with either of the following options:

Option #1 – Configure a default domain within the SecurEnvoy configuration

image

Option #2 – Configure a default domain within Exchange admin center

Navigate to the Exchange server’s C:\windows directory and open the file seiis.ini, locate the DefaultDomain= line and add the domain name:

image

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

If the above is not configured and you use only the user name to log in then you would get the following loop:

imageimage

Message: Passcode OK

Redirecting to secured resource, please wait

If you don't redirect after a short time Click here

imageimage

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

With the above configured, proceed to by backing up:

passcodeok.htm
auth.htm
accessdenied.htm

… located in \Program Files(x86)\SecurEnvoy\Microsoft IIS Agent\WEBAUTHTEMPLATE then copying the SecurEnvoy supplied OWA login page by navigating to

C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\SAMPLES\OWA2016

… and copying the 3 htm files into:

C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEBAUTHTEMPLATE

image

The login page should look as such:

image

I’m not completely sure why but the 4 deployments I’ve been in did not include the images so the following are the for the broken / missing images:

…/securenvoyauth/images/top.gif

…/securenvoyauth/images/heading_logo.gif

…/securenvoyauth/images/buttons/oneswipe.gif

…/securenvoyauth/images/buttons/send.gif

…/securenvoyauth/images/blackbottom.gif

image

I choose to remove the following images because:

…/securenvoyauth/images/heading_logo.gif – this icon did not seem necessary

…/securenvoyauth/images/buttons/oneswipe.gif – this button never worked for my deployments

The heading logo doesn’t look good and one Swipe doesn’t seem to work

The customizations I made to the page to look as such are as follows:

image

The pages to edit are:

Auth.htm
Accessdenied.htm
Realtime.htm

Initial Logon Page – auth.htm

  1. Copy blackbottom.gif into the directory C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEB\images (this is to fix the broken banner at the bottom)
  2. Copy <yourLogo>.png into the directory: C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEB\images
  3. Open auth.htm in the directory: C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEBAUTHTEMPLATE
  4. Change the title between the <title> tags to <YourCompany> Webmail
  5. Search for the line referencing the image heading_log.gif and remove it

<IMG height="23" alt="" src="/securenvoyauth/images/heading_logo.gif" width="27" align="middle" border="0">

  1. Search for the line referencing the image oneswipe.gif and remove the following:

onload="se_oneswipe_init('placeFocus()', '/securenvoyauth/images/buttons/oneswipe.gif', 'USERID', 'PIN', '', 'send');"

  1. Search for the line referencing top.gif and replace it with <yourLogo>.png
  2. Search for the line setting the background colour #edf2f8 and change it to #ffffff (white)
  3. Add font-family: Arial; for style2, style4, style5 and style6
  4. Change all styles with x-small as the font size to small

**Note that I did a Google search of SecurEnvoy OWA pages and downloaded the missing blackbottom.gif and send.gif images.

Access Denied Page – accessdenied.htm - displayed if incorrect credentials are entered

Repeat a subset of the steps required for initial logon page.

  1. Open accessdenied.htm in the directory: C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEBAUTHTEMPLATE
  2. Change the title between the <title> tags to <YourCompany> Webmail
  3. Search for the line referencing the image heading_log.gif and remove it

<IMG height="23" alt="" src="/securenvoyauth/images/heading_logo.gif" width="27" align="middle" border="0">

  1. Search for the line referencing top.gif and replace it with <YourLogo>.png
  2. Search for the line setting the background colour #edf2f8 and change it to #ffffff (white)
  3. Add font-family: Arial; for style2, style4, style5 and style6
  4. Change all styles with x-small as the font size to small

2FA Page - realtime.htm – displayed for SecurEnvoy code

  1. Open realtime.htm in the directory: C:\Program Files (x86)\SecurEnvoy\Microsoft Server Agent\WEBAUTHTEMPLATE
  2. Search for the line referencing top.gif and replace it with <YourLogo>.png
  3. Search for the line setting the background colour #edf2f8 and change it to #ffffff (white)
  4. Add font-family: Arial; for style1, auto-style1, auto-style2, auto-style3

I’ve tried logging out of the webmail portal and was sent back to the login screen so I don’t think modifications are required for the logout.htm file.

Hope this helps!