SecureAuth FAQs

SecureAuth Idp Version affected: 7.5+

Description:

By default, the IdP does NOT validate the signature of the SSL cert from the SP in a SAML request.

Cause:

IdP version 9.1 and earlier will only validate if the realm is configured as anSP-Initiated by POST realm.

IdP version 9.2 and higher can validate signatures for SP-Initiated by POST or Redirect subject to minimum hotfix level (see below)

Resolution:

To enable signature validation for SP-Initiated configurations, copy/paste the public key of the certificate (whether publicly issued or self-signed) into the SAML Request text box under the SAML configuration.

If the certificate does not match then this error will be seen in the error log:

RequestID="a71312e9-b8eb-4656-8e15-72124861d45d" UserHostAddress="192.168.2.95" Message="SAML20SPInit exception error: Failed to receive authentication request by HTTP redirect, stack: at ComponentSpace.SAML2.Profiles.SSOBrowser.IdentityProvider.ReceiveAuthnRequestByHTTPRedirect(HttpRequest httpRequest, XmlElement& authnRequest, String& relayState, Boolean& signed, AsymmetricAlgorithm key)

at MFC.WebApp.SecureAuth.SAML20SPInit.ReceiveAuthnRequest(AuthnRequest& authnRequest, String& relayState)

Special Considerations:

The minimum required hotfix version required to support SP Init by Redirect:

IdP 9.2 TBC

IdP 9.3 9.3.0-16

IdP 19.07 TBC

IdP 19.07.01 TBC

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Overview

Google has been working with the Internet community to help strengthen the security of cookies. Draft RFC 6265bis-03 defines new settings for the SameSite cookie flag to allow for compatibility with several federated flows including SAML, WS-Fed and OAuth. Google is targeting the release of Chrome 80 on February 4, 2020 and will start enforcing the SameSite setting, even if not specified by the web server dropping the cookie, including the SP/RP or IdP.

Note: Google has delayed the rollout of the SameSite attribute enforcement in Chrome 80 until Feb. 17.

The changes Chrome is making are substantial and could impact your enterprise or customers. In order to accommodate this change, SecureAuth is providing a hotfix which set the SameSite flag to a value appropriate for federated workflows.

SecureAuth strongly recommends implementing this hotfix to avoid service interruption if you are using SAML, WS-Fed, OIDC/OAuth, or Forms Post.

What are SameSite cookies?

Here are a couple articles that do a great job of explaining the SameSite cookie change and how it works:

https://web.dev/samesite-cookies-explained/

https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html

Is the IdP the only side that needs to support SameSite?

Aside from SecureAuth having to update our software to ensure compatibility with this change, SAML/WS-Fed SP’s and OIDC/OAuth Clients (Relying Parties) may need to update their code to be compatible as well.

For example, in a SP-Initiated SAML workflow, if the SP does not set the SameSite flag to None,Secure, then this will break the SAML flow. The solution to this type of issue is to ensure the SP has updated their code to include the SameSite flag.

Note that SecureAuth cannot mitigate problems with Service Providers or OIDC/OAuth RPs that do not set “their” cookie SameSite flag to None,Secure, as the behavior is enforced by the Chrome 80 browser, not SecureAuth.

Microsoft patches

Microsoft has released hotfixes for all the supported server operating systems ( https://docs.microsoft.com/en-us/aspnet/samesite/kbs-samesite ). This hotfix will set the SameSite value to “Lax” by default. For most use cases, SecureAuth will change the SameSite value to None,Secure to ensure compatibility with federated workflows. This hotfix is required for the SecureAuth SameSite hotfix. Note that in some iFrame use cases, applying the Microsoft hotfixes before the SecureAuth hotfix may result in failed SSO.

From time to time Microsoft may replace existing hotfixes with newer versions.The SecureAuth hotfix checks for the Microsoft December 2019 and January 2020 hotfixes before installation.

To check which version of .NET is currently installed see this article:

https://support.secureauth.com/hc/en-us/articles/360039397031-How-to-show-which-NET-version-is-installed

Are you impacted?

Most SAML, WS-Fed and some OIDC/OAuth workflows are impacted, as well as IdP consuming SAML and Forms Auth post-auth use cases in cross site POST requests. Because of the variety of ways in which applications can be integrated, and some may or may not be on the same root domain, it is not possible to provide a definitive set of use cases that will be impacted. SecureAuth strongly recommends implementing this hotfix to avoid service interruption if you are using SAML, WS-Fed, OIDC/OAuth, or Forms Post. If not applied, for example, federated login request may fail, loop or just prompt the user for credentials. In addition, logout functions may not work properly.

The SecureAuth Identity Platform/IdP hotfix was designed to ensure the least amount of disruption for our customers. The hotfix can be installed by your IT staff, and specifically designed to avoid conflicts or incompatibilities with customizations. In the rare event a customization may be impacted, the hotfix installer will detect this condition and abort the installation warning of a possible conflict. If this is encountered, please contact SecureAuth support.

No SecureAuth Endpoint products (Passcode, Authenticate, Login for Windows/Mac, RADIUS server) are impacted at this time.

What does the hotfix do?

This hotfix adds the SameSite flag to most cookies dropped by IdP or Identity Platform products:

Appends all cookies with the SameSite=None,Secure flags except for those browsers that do not supported as noted below

What do you need to do?

Detailed instructions and a link to download the hotfix and can be found here: https://docs.secureauth.com/x/HwKcAw

Apply the hotfix to your dev/UAT environments for testing

Apply the hotfix to your prod environments

Ensure your partners (Service Providers or other federated integration partners) support the SameSite flag

Note that a system reboot is not required. The patch takes effect immediately upon being implemented.

Known Issues with hotifx:

If the UserAgent=NULL, the login will fail if the initial hotfix release (HF200106_004) is used.

This issue is addressed in the updated version of the hotfix, versionHF200106_004_8.

How do I test:

Verify the workflow functions as expected (benchmark testing):

The target IdP is unpatched

Using an unaltered browser such as Microsoft Edge or Chrome79, logon to IdP and obtain a SSO token that you would expect to work with the SP you will be testing

Perform a SP-Initiated flow on the application

Expected result: SSO should succeed

Verify workflow fails as expected (benchmark testing):

The target IdP is unpatched

Use Firefox 72. Testing this behavior in Firefox is easier than Chrome because Chrome can provide false positives due to a 2 minute grace period provided by Chrome.

In Firefox, in theabout:configpage change "network.cookie.sameSite.laxByDefault" and "network.cookie.sameSite.noneRequiresSecure" flags totrue by double-clicking those values.

Logon to an unpatched SecureAuth IdP an obtain a SSO token that you would expect to work with the SP you will be testing

Perform a SP-Initiated flow on the application

Expected result: SSO failure

Verify SecureAuth IdP is setting the SameSite cookie attribute correctly:

Ensure the SecureAuth IdP you are testing against has the required Microsoft and SecureAuth SameSite hotfixes applied

Open an Incognito Browser window in Chrome

Press F12 to open developer tools

Select the “Network” menu item on the top navigation bar

Check the “Preserve log” option on the row below the top navigation bar

Login to your IdP realm, such as a portal realm where you would expect to get a SSO cookie (any interactive login realm will work)

Click on the “Cookies” tab in the main body of the window

In the “Name” column, scroll through the list of elements and look for “Response Cookies” as shown in the example below. This can typically be found on the SecureAuth.aspx page.

All “Response Cookies” should have the Secure flag checked and the SameSite flag set to “None”, as shown in the example below

https://cloud.google.com/docs/chrome-enterprise/policies/?policy=LegacySameSiteCookieBehaviorEnabled

Verify IdP and SP SameSite cookies are setting the proper values (Chrome 80 compatible):

Ensure the SecureAuth IdP you are testing against has the required Microsoft and SecureAuth SameSite hotfixes applied

Use Firefox 72. Testing this behavior in Firefox is easier than Chrome because Chrome can provide false positives due to a 2 minute grace period provided by Chrome.

In Firefox, in theabout:configpage change "network.cookie.sameSite.laxByDefault" and "network.cookie.sameSite.noneRequiresSecure" flags totrue by double-clicking those values

Logon to a patched SecureAuth IdP and obtain a SSO token that you would expect to work with the SP you will be testing

Perform a SP-Initiated flow on the application

If it fails, then either the IdP or the SP is not setting the SameSite cookie flag as required

Impacted flows:

Most commonly it is a IdP-side issue for:

SP-initiated requests while using SecurePortal

SP-initiated requests while using Transparent SSO

Most commonly it is a SP/RP-side issue for:

SP-initiated requests

Authorization Code, Implicit, and Hybrid flows using response_mode=form_post

POST to the authorization_endpoint

POST to the end_session_endpoint

IdP initiated request to SecureAuth SAML consumer

Notes:

iFrame use cases may be impacted if the domains are different between the site hosting the iFrame and the IdP

Other flows may be impacted as well. The above list is a sample of commonly impacted flows, not a comprehensive list.

SecureAuth suggests testing all your applications with all browsers your enterprise supports, as well as testing with the Chrome 80 beta

If you have failures when testing against Chrome 80 or FireFox when configured to enforce SameSite but not other browsers, you need to ensure the SP/RP servers are setting their cookie’s SameSite flag to None,Secure. SecureAuth cannot mitigate problems with Service Providers or OIDC/OAuth RPs that do not set “their” cookie SameSite flag to None,Secure, as the behavior is enforced by the Chrome 80 browser, not SecureAuth.

What about incompatible SPs/RPs?

As noted above, it is inevitable that some SPs/RPs will not properly set their cookie SameSite flag. SecureAuth will be tracking reported SPs/RPs that are not properly supporting the SameSite flag and will update this post to a link to that document when available.

Other Browsers

In time, Microsoft Edge and FireFox will start enforcing defaults for SameSite, but as of this writing, Firefox has not released a target release and Microsoft is targeting Edge 80 (both can be manually enabled on current releases). IE does support the previous draft of RFC respecting Lax and Strict, but “by default” supports None by ignoring the flag.

Safari, iOS, MacOS and some older Chrome versions have a bit more of a complicated story. Safari and embedded browsers on MacOS 10.14 and all browsers on iOS 12, and Chrome 51-66 have defects where they do not handle SameSite=None properly. Apple has chosen to only fix this defect on their most current OS versions. The SecureAuth SameSite hotfix handles these well documented exceptions for MacOS, iOS and specific Chrome versions by not sending the SameSite attribute to those browsers.

What if I’m unable to install the SecureAuth hotfix, or am on an unsupported IdP version?

If you are unable to install the SecureAuth SameSite hotfix, or on an unsupported version of SecureAuth IdP, the SameSite enforcement by Chrome80 can be disabled manually on the user’s browser.

Browse to:

Change the “SameSite by default cookies” = Disabled

Restart the browser

If the computers running the Chrome browser are managed, the setting can be changed via a policy change. This article provides instructions on how to change this behavior via policy change.

What happened?:

Google has delayed the rollout of the SameSite attribute enforcement in Chrome 80 until Feb. 17. With that change new security settings are enforced that require a hotfix to be applied to the SecureAuth appliance to work properly with some federated workflows

Why didn’t you notify our organization?:

SecureAuth did a comprehensive customer communication program starting in early January, with three notifications to customers over the past four weeks

My organization is impacted now, what do I do?:

Have your users use an alternate browser (FireFox, Edge, Safari, IE)

Disable Chrome SameSite enforcement as explained here

Update your SecureAuth appliances with the required Microsoft and SecureAuth hotfixes

How do I update my appliances?

Hotfix instructions can be found here

I want more, information detailed information about this SameSite change:

Please read this document

I’m on an unsupported version, what do I do?:

Submit a SecureAuth support ticket requesting the SameSite patch, including your version number

Follow these instructions to install

Note: Google has delayed the rollout of the SameSite attribute enforcement in Chrome 80 until Feb. 17.

This notice applies to SecureAuth IdP versions:

7.4.3

8.0.1

8.0.2

8.0.3

8.1

8.2

9.0

9.01

9.02

Disclaimer:

The patchto address the SameSite issue is available for customers whose current version is no longer covered under the standard SecureAuth Support agreement. Fixes addressing unsupported versions of SecureAuth IdP are being made available as best effort fixes, and have not been subjected to the normal quality assurance processes, and as such are not supported or guaranteed. Testing and applying the patch is the sole responsibility of the customer, and no warranty is implied or inferred by receiving this patch from SecureAuth.

Recommendations:

The enforcement of the samesite cookie impacts a small segment of workflows used by most IdP customers. Cross site posts are primarily impacted. An example of an impacted workflow is:

User logs onto a portal and gets SSO cookie

User browses directly to the SP and tries to logon

The SP does an SP-initiated logon flow back to the IdP

The browser does not present the SSO cookie because of samesite enforcement

Logon action fails or user is prompted to logon

Note that other workflows, or iFrame use cases may also be impacted.

SecureAuth recommends you test your applications using Chrome 80 (or Chrome 80 beta if prior to Feb. 4, 2020) and Firefox with SameSite enforcement enabled.After testing, you may find that no applications or use cases are impacted and applying the patch is unnecessary.You also may find that one or two applications are impacted, and you may choose to apply this patch to the impacted realms, rather than globally.

Getting the patch:

Contact SecureAuth support to obtain the Samesite patch for your IdP version.

Installation:

Take the normal precautionary measures you typically perform before updating any enterprise system, such as taking a snapshot of the VM prior to making any changes

Take the server out of production

Review the following article to ensure that the prerequisite Microsoft .Net update and Microsoft patches have been installed: https://support.secureauth.com/hc/en-us/articles/360038330652-SameSite-cookie-support-and-Chrome-80

Back up global.asax and global.asax.vb from the root of all impacted realms. For example, d:\secureauth\secureauth1

Copy the patched global.asax and global.asax.vb to the root of all impacted realms. For example, d:\secureauth\secureauth1, replacing the existing files

No reboot or IIS reset is needed

Test the impacted realms

Return the server to production

Issues:

Contact SecureAuth support if you identify any issues with this patch. The product management team will determine if the issues will be addressed on a case by case basis.

Google updated the chrome browser starting on Feb. 17, 2020 requiring a hotfix to be applied to the SecureAuth appliance to work properly with some federated workflows. Click here to find out more.

We are excited to share that the SecureAuth Identity Platform (formerly SecureAuth IdP) and multiple enhanced endpoints products are now generally available! Click here to learn more!

Version Affected: All

Description:

How to show which versions of the .NET Framework are installed.

Cause:

Some articles require specific versions or a minimum version of .NET to be installed on the IdP.

Resolution:

Open a Powershell window and run this command:

gci 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse | gp -name Version,Release -EA 0 | where { $_.PSChildName -match '^(?!S)\p{L}'} | select PSChildName, Version, Release | Sort-Object version

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version affected: All

Description:

When using the Helpdesk realm, it fails to save changes stating "Sorry, the highlighted fields below could not be saved due to a misconfiguration" even though the highlighted fields are those set to Show Disabled and you had no desire to update them.

Cause:

Group Restrictions to the helpdesk realm cause this problem.

Resolution:

1.Open the Admin Console and navigate to the Data tab for the Helpdesk Realm

2. In the Profile Provider settings, change "Same as above" to False

3. Set Default Profile Provider to "Directory Server"

4. In the Profile Connection Settings, set the AD connection as before but remove the group restriction.

Note: The Group Restriction must remain in the Membership connection section to prevent unauthorized users from connecting.

5. Click Save

Special Considerations:

This is fixed in 19.07.01

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version - All

Description:

When a SecureAuth Realm is created, it is given the name SecureAuth plus a sequential number (e.g. SecureAuth3). Some customers prefer to use their own naming scheme to make it easier for users to locate resources. The instructions below discuss how to change the name of a SecureAuth IdP realm.

Resolution:

1. Open a command prompt with elevated user rights (Run as administrator)

2. Backup the IIS configuration by entering the following command into the command prompt:

\%windir\%\system32\inetsrv\appcmd.exe add backup "PreRenameBackup"

press Enter

3.Change a realm's name by entering the following command into the command prompt:

\%windir\%\system32\inetsrv\appcmd.exe set app "Default Web Site/OriginalAppName" -path:/NewAppName

press Enter

information:

Change OriginalAppName to the SecureAuth Realm name to change (e.g. SecureAuth3)

Change NewAppName to the preferred name for the realm

4. Repeat step 3 for each realm that requires a name change

5. Restart the World Wide Web publishing service by entering the following command into the command prompt; iisrest and press Enter

Note:

Should an error occur during the rename process, the configuration can be reverted to the previous settings by restoring the backup made at the beginning of the process. Follow the instructions below to recover from the backup.

1. Open a command prompt with elevated user rights (Run as administrator)

2. Restore the IIS configuration by entering the following command into the command prompt,

\%windir\%\system32\inetsrv\appcmd.exe restore backup "PreRenameBackup"

3. Restart the World Wide Web publishing service by entering the following command into the command prompt, iisresetand press Enter

Warning - Once a realm name is changed, the previous realm name (e.g. SecureAuth3) becomes unavailable to access, please ensure that a proper migration plan is in place before making the change

SecureAuth Idp Version affected: All

Description:

When using SQL to store some of the Profile entries for a user, the following error occurs

SqlProfileProvider.SetPropertyValues: Error received when saving data to user storage, exception: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Table-valued parameter 37 ("@DigitalFP"), row 0, column 0: Data type 0xF3 (user-defined table type) has a non-zero length database name specified. Database name is not allowed with a table-valued parameter, only schema name and type name are valid.

Cause: The Standard SQL Stored Procedures expects a value for certain attributes. This isn't a problem when using SQL as the complete profile store but when only using it for a few attributes, if these values are missing, it throws an error.

Resolution:

Open the Admin Console

On the Realm in question, click on the Data tab

Set the follow 4 Attributes to be stored in SQL

Fingerprints

Push Notification Tokens

Oath Tokens

Access Histories.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Description

Upon attempting to login to a website like WebEx while using SP initiated SAML request, you get this error:

Error: at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer) at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle) at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair() at System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey() at MFC.WebApp.SecureAuth.SAML20SPInit.CreateSAMLResponse(AuthnRequest authnRequest, String sUser) at MFC.WebApp.SecureAuth.SAML20SPInit.Page_Load(Object sender, EventArgs e)

Resolution

The certificate is mismatched between the Service Provider and the SecureAuth realm

The security in this certificate does not allow the group “Network Service” to read the certificate.

When there is an environment with 2 or more SecureAuth appliances:

The Load Balancer is not set to “persistent” load balancing, so the traffic is flip flopping between server 1 and 2 and getting confused

The Forms Auth/SSO Token is not set up properly on the SecureAuth realm level

One of the servers does not have the correct certificate selected for that realm

SecureAuth version affected: All

Description: Textlog files, for each SecureAuth realm, operate on toggle switch. By default, Error logging is always enabled, but Audit and Debug logging can be enabled or disabled. This is determined by the Text checkbox found under the realm's Logs tab, through the Admin Console.

If Text logging is enabled, SecureAuth will document login data of every login attemptin the form of text files found within the realm's file directory--with the exception of the Error log which only writes log datawhen a realm encounters an error:

D:\Secureauth\SecureAuth#\AuditLogs

D:\Secureauth\SecureAuth#\debuglogs

D:\Secureauth\SecureAuth#\ErrorLog

Once enabled, logging will remain enabled until disabled. Because of this, log files can pile up quick and take up a lot of hard drive space. These files can be selected and cleared in bulk by doing the following.

- On the SecureAuth IdP server, open File Explorer and direct to the following directory:D:\Secureauth

- In the search bar, in the top left corner of the window, search for one of the following wild card strings:

Audit.20*.log: searches the current file directory for all Audit log files dated to a 20XX year.

Debug.20*.log:searches the current file directory for all Debug log files dated to a 20XX year.

Warning.20*.log:searches the current file directory for all Error log files dated to a 20XX year.

*20*.log:searches the current file directory for all log files--Audit, Debug, and Error--dated to a 20XX year.

Thesewild card search strings will exclude the most current Audit, Debug, and Error log files on the server. To remove these files as well, remove the *20* prefix to any search string. Back logged files are savedwith the following naming format Type.YYYY-MM-DD.Log.

- Once the search completes, Ctrl+A can be used to select all files.

- Press the Delete keyboard key, or right-click and select Delete, to remove all found log files from the IdP server.

Version Affected: 19.07.01 and lower

Description:

Are AuthNRequests using AssertionConsumerServiceIndex instead of AssertionConsumerServiceURL supported by IdP, e.g.:

SAML Request from ServiceProvider:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

ID="s28cb348252f8d30dd32ae2fda8cf1eb25411bb861"

Version="2.0"

IssueInstant="2018-09-30T11:55:01Z"

Destination=" https://idp.domain.com/SecureAuth123/ "

ForceAuthn="false"

IsPassive="false"

AssertionConsumerServiceIndex="0"

>

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ServiceProvider.domain.com</saml:Issuer>

<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"

SPNameQualifier="ServiceProvider.domain.com"

AllowCreate="true"

/>

</samlp:AuthnRequest>

Cause:

AssertionConsumerServiceIndex is used when multiple Service Providers send AuthNRequests to the same IdP endpoint (realm), i.e. many SPs to a single realm. The IdP should then use the SPs metadata together with theAssertionConsumerServiceIndex to map to the correct AssertionConsumerServiceURL which to send the SAML response back to.

Resolution:

AssertionConsumerServiceIndex is supported in SecureAuth IdP from the following hotfix versions:

9.1.0-53

9.2.0-30

9.3.0-13

19.07-2

19.07.01-1

For further information please see this document:

https://docs.secureauth.com/display/KBA/SAML+integrations+using+AssertionConsumerServiceIndex+hotfix

Workaround:

For earlier versions configure a separate realm per Service Provider instead of pointing all Service Providers at a single realm.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products

SecureAuth IdP Version Affected: All

Description/Cause:

If a user connects using port 80 (http) to a realm that it secured with SSL, it will throw a 403.4 Forbidden error. This guide will help you create a rule within URL Rewrite that automatically redirects all http requests to https.

download it right here.

Resolution:

Create a rule with URL Rewrite within IIS that redirects all http requests to https for allrealms.

If you don't have the URL Rewrite extension, you can The first thing we need to do is open IIS Manager. Expand "Sites," then select"Default Web Site." Double click the URL Rewrite module to open it. Follow the steps below to configure the rule.

1. Click "Add Rule(s)"

2. Select "Blank Rule" under Inbound Rules.

3. Set the name of the rule (1), Set the Match URL to use Wildcards (2), Set the Pattern to * (3), Set the Logical Grouping to "Match Any" (4), Add the condition that is highlighted (5).

4. On the rule, set the action type to "Redirect", and fill out the rest of the settings exactly like the picture below. Click apply afterwards.

5. Lastly, any realm that you want to utilize this rulemust have "Require SSL" turned off.You can do this by going to any realm, clicking on SSL Settings, and removing the check mark from the "Require SSL" box.

SecureAuth IdP Version Affected: 9.2 and below

Description:When trying to login via UPN, TOTP is not showing up as a MFA option

Cause:Most of the time, users enroll their Authenticate app using SamAccountName rather than UPN. Because of this, the searchable attribute stated in the Data tab is used as a salt to encrypt the seed value.

Resolution:If your enrollment realm is set to use samAccountName, and you want to login to another realm using UPN, the search attribute in the Data tab will need to be samAccountName. The searchFilter will need to be "(&(objectClass=user)(|(sAMAccountName=\%v)(userPrincipalName=\%v))) ". Then delete the domain in the datastore connection and you are set. If using L4E, the search filter has to match what L4E is sending, which is samAccountName, but the searchable attribute has to match what was set in the enrollment realm.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

When end users are receiving OTPs via SMS the sender number is not consistent and appears to be coming from different phone numbers rather than a fixed SMS shortcode or an alphanumeric SMS sender label.

Cause:

Normally we appear to send SMS from an alphanumeric label "SecureAuth" but that is blocked in the US. Additionally SMS short codes are heavily blocked on Sprint and T-Mobile.

Resolution:

To circumvent SMS blocking in such circumstances, our SMS providerdelivers such messages via a pool of "long number" senders to ensure the SMS isn't blocked.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

Which versions of SecureAuth IdP support mS-DS-ConsistencyGuid.

Cause:

A migration to Office365 or merge into an existing Org may require that mS-DS-ConsistencyGuid is used instead of objectGUIDfor the sourceAnchor.

Both objectGUID and mS-DS-ConsistencyGuid are stored in Active Directory as an array of 16 bytes. When objectGUID is returned via LDAP it is automatically translated into a String value containing the GUID as text by Active Directory, however this does not happen formS-DS-ConsistencyGuid so the raw byte array is returned instead.

In older versions of IdP the raw byte array cannot be read by SecureAuth IdP correctly and if attempts are made to add it to a SAML assertion the result looks garbled and may contain unprintable characters.

Resolution:

The below versions of IdP can correctly read and translate themS-DS-ConsistencyGuid attribute into a string value.

Version 19.07 and higher of SecureAuth IdP already have support formS-DS-ConsistencyGuid included from initial release.

IdP versions 9.1 to 9.3 also have support formS-DS-ConsistencyGuid from the following hotfix versions:

9.1.0-54

9.2.0-30

9.3.0-11

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

After applying new windows updates, that includes the KB4530702 (Monthly Rollup) update released by Microsoft on December 10, 2019, SecureAuth realms and the SecureAuth admin site are no longer accessible.

Cause:

KB4530702 can remove the IP and certificate bindings to the Default Web Site in IIS.

Resolution:

Restore the correct bindings settings in IIS for the Default Web Site.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 9.2 and higher

Description:

When SAML metadata has been shared by a realm with a Service Provider, some Service Providers can attempt SAML Artifact Binding instead of HTTP Post Binding or HTTP Redirect Binding. This typically causes a delay while the Service Provider times out.

Cause:

The metadata shared by a realm includes an AttributeAuthorityDescriptor with a SOAP binding.

SecureAuth IdP does not currently have SAML SOAP support.

Resolution:

Edit the metadata XML before sharing with the Service Provider.

Remove the entireAttributeAuthorityDescriptor section including everything within e.g.:

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: All

Windows Version Affected: Server 2012 or 2012 R2, Server 2016

IIS Version Affected: 8.x onwards

Description: Depending on the complexity of the page, hardware load, resource limits, and network latency, when trying to load a realm a user could receive in a timeout error, even though the page is still being loaded within IIS.

Cause: When a IIS application pool restarts or recycles, it typically takes a long time for the first request to execute before a user will be displayed a page from the IdP, whether the access is for a realm or the admin console.

Resolution:

You will need to enable the Application Initialization module for IIS first in order to enable the pre-load features for the application pool and the IdP sites:

Open Server Manager.

In Server Manager, click the Manage menu, and then click Add Roles and Features.

In the Add Roles and Features wizard, click Next. Select the installation type and click Next. Select the destination server and click Next.

On the Server Roles page, expand Web Server (IIS), expand Web Server, expand Application Development, and then select Application Initialization. Click Next.

https://support.secureauth.com/hc/en-us/articles/360025609171-Preventing-slow-realm-response-times-during-periods-of-inactivity

On the Select Features page, click Next.

On the Confirm installation selections page, click Install.

On the Results page, click Close.

Once Application Initialization has been installed, you need to configure IIS the have the application pools always running, and the virtual directories to pre-load on start:

Open Internet Information Services (IIS) Manager:

Click on the Server name (under “Start Page”)

Open Configuration Editor, change the drop down tosystem.webServer/applicationInitialization

Configure “doAppInitAfterRestart”=True

Click Apply (under Actions in the top right)

Click on Application Pools

Right click on the Application Pool that your apps are in (by default “.Net v4.5”) and select Advanced Settings

Configure “Start Mode”= AlwaysRunning

Configure "Idle time-out action" = Suspend

Repeat for all Application Pools that have applications you want this feature enabled for

Under Sites, right click on a realm (such as SecureAuth1) and select Manage Application/Advanced Settings

Configure “Preload Enabled”=True

Repeat steps 10-11 for all realms you want pre-loaded

Perform iisreset

A powershell script has also been added for your convenience in case this is a more plausible option to run. Please utilize the ShareFile link below to obtain the script. Please download and extract and then give it an administrative Powershell run.

https://secureauth.sharefile.com/d-s0c5c9b158c049ca8

Special Considerations (optional as needed): Once IIS restarts, or when the application pool recycles, there is still a lead time needed for IIS to pre-load each page, and this can take up to a couple of minutes depending on the number of realms needing to be loaded. During this time access will still seem slow, so it may be a good idea to schedule application pool recycles to occur outside of normal usage hours.

The above prevents delays when the application pool is initially started or restarted. In addition it may be desirable to prevent IIS from shutting down inactive workers or change the default idle timeout using this article:

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Description:

When opening a SharePoint folder from Internet Explorer, is gives an Access Denied message

Cause:

This problem occurs when the SharePoint site is first opened in 32bit version of IE

Resolution:

Open the 64bit version of IE fromC:\Program Files\Internet Explorer\iexplore.exe

SecureAuth IdP Version Affected: 9.3,19.07

Description:

The New Experience console only opens a white blank page, nothing else is rendered. Opening the browser's Developer Tools Network tab shows a 502 Bad Gateway error:

https://localhost/httpproxy/tatooine/assets/sa-components.min.css

Or if the HttpProxy rewrite rules have been changed to "Redirect" as per this article ( https://support.secureauth.com/hc/en-us/articles/360029283112-New-Experience-Console-Blank-White-Page-Bad-Gateway ) then an error 500 Internal Server error will be shown:

Cause:

Browsing directly togives a more detailed error:

This is caused by non-standard authentication settings for the "Default Web Site" in IIS or the HttpProxy application in IIS, e.g. ASP.NET Impersonation is enabled.

Resolution:

1. Open IIS Manager, click on "Default Web Site" in the left hand pane then "Authentication" in the middle pane:

2. Ensure the authentication settings are set to the defaults as per the below:

3. Repeat for the HttpProxy application:

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version affected: All

Description: By default, when you click 'Forgot Password', the link is opened in the same browser tab. This article describes how to change that behavior.

Resolution:Edit the theme for the realm to force a new tab to be opened after clicking the 'Forgot Password' link.

1. Go to D:\SecureAuth\SecureAuthXX\Themes (Where SecureAuthXX is the portal realm)

2. Copy and paste the "2016 Light" folder and give the copy a sensible name, such as "2016 Custom"

3. Drill down into the new "2016 Custom" folder to

D:\Secureauth\SecureAuthXX\Themes\2016 Custom\directives\Common\forgotPasswordLink\

4. Edit forgotPasswordLink.html

5. Add the following text:

target="_blank"

6. Save the changes.

7. Open the Admin Console and select the Overview tab

8. Change the theme from 2016 Light to the new theme you created (Eg. 2016 Custom)

9. Save

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: All SecureAuth Versions (Backup ToolVersion 2.4.1)

Description:When trying to run the backup tool, it does not pass the .Net Framework version check.

Cause: The backup tool is unable to check for .NetFramework versions above 4.6.1.

Resolution:Open up the backup tool on a administrator level notepad. Ctrl+F 394271 to locate the part of the script that checks the .NetFramework version. As you can see, it only checks up to .Net Framework 4.6.1. We will need to add the proper .Net Framework version in order to pass the check.

There are three areas in this script that checks for the .Net Framework version. Once for a minimum backup, second for a full backup, and a third time for the restore. Make the change on one and copy and paste it over to the other sections so all three have updated .Net Framework version checks.

IF [\%_DotNetReleaseDec\%] EQU [394802] (

SET _DotNetReleaseVer=4.6.2

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [394806] (

SET _DotNetReleaseVer=4.6.2

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [460798] (

SET _DotNetReleaseVer=4.7

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [460805] (

SET _DotNetReleaseVer=4.7

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [461308] (

SET _DotNetReleaseVer=4.7.1

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [461310] (

SET _DotNetReleaseVer=4.7.1

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [461808] (

SET _DotNetReleaseVer=4.7.2

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [461814] (

SET _DotNetReleaseVer=4.7.2

SET _DotNetSupportedVer=TRUE

)

IF [\%_DotNetReleaseDec\%] EQU [528049] (

SET _DotNetReleaseVer=4.8

SET _DotNetSupportedVer=TRUE

)

The values that are next to the .NetRelease are values that can be viewed here. https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

These values must match along with the .NetFramework version on your Registry Editor. Now after saving these changes, you will be able to properly run the backup tool.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

SAML Consumer is looping back to the IdP and then back to the SAML consumer instead of logging in to the App.

SAML tracer does show a cookie being created but it disappears straight away.

Cause: SAML consumer creates the cookie based on what is in the Assertion.

Most browsers can only handle a cookie size of up to 4096 bytes so although we consume the assertion and create the cookie, the browser dumps it.

Resolution:

The SAML Consumer VAM will consumer the entire assertion.

Liaise with the IdP team so that they send fewer attributes in their SAML assertion. This will reduce the size of the cookie and solve the issue.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

The .Net Saml Consumer VAM can work with any SAML IdP. Some IdPs, such as the one used with Azure AD require an AuthN request to work. Eg, they need the SP initiated workflow.

The .Net Saml Consumer VAM can support this.

Cause: 3rd Party IdP limitations

Resolution:

1. Create the Identity Provider settings within the VAM SamlAdmin console as normal

https://yourvam.example.com/samlconsumer/sp.aspx?IDProviderName=Bob

2. Edit the Forms Authentication settings to go to the following URL

Where yourvam.example.com is the address of the server running the VAM and the IDProviderName is the Name you set in the Saml Consumer Admin console.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

How to disable Debug text logging on all realms

Cause:

The debug text logs can consume a lot of disk space over time. It is common to forget to disable debug logging after troubleshooting which can eventually lead to multiple realms having debug logging enabled. The Admin console does not offer an easy way to disable debug logging in bulk.

Resolution:

TheDisable-SATextDebugLogging tool can be used to disable debug logging on all realms.

1. Important, althoughDisable-SATextDebugLogging has been thoroughly tested it is very important to take a snapshot or backup of IdP prior to running the tool.

2. DownloadDisable-SATextDebugLogging to the IdP:

https://secureauth.sharefile.com/d-s3056eca8e3a4f4ea

3. Run the tool on the IdP from any folder where you have write permissions

4. To begin with the tool will back up all the web.config files in D:\SecureAuth\* and write a rollback batch file to a subfolder called Rollback within the same folder containing the executable.

5. The tool will then decrypt all the web.config files, disable debug text logging in all realms and then encrypt them again. It will also write a log file to the same folder as the executable. When complete the log file will be automatically opened.

6. If desired, the entire operation can be rolled back by running the batch file in the Rollback folder. Run this as Administrator.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: IdP - All versions

Description:

The Hybrid flow allows an application to request an Authorization Code, Access Token and/or ID Token directly from the Authorization endpoint so can be fully handled via the Users Browser for the initial login or can use the code with the token endpoint.

Cause: This KB outlines how to use the Hybrid flow

Resolution:

This is an example of the query string used for the Hybrid flow

https://youridp.secureauth.com/secureauth8/?response_type=code+id_token&client_id=YourClientID

&redirect_uri=https://app.getpostman.com/oauth2/callback&scope=openid+profile&state=State&nonce=n-0S6_WzA2Mj

(line breaks added for easier viewing)

1.Replace youridp.secureauth.com with the FQDN of your SecureAuth server

2. Replace secureauth8 with your Oauth realm

3. Replace the YourClientID with your Client ID

4. Replace the redirect_uri with your redirect uri

5. OpenID is required as a scope, you can have more

6. Nonce is required.

The valid response_types for this are

response_type= code+id_token

response_type= code+id_token+token

response_type= code+token

Writing the response type in a different order will cause an error.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: All

Description: When launching an IdP initiated SAML app via a SecurePortal realm, the attempt fails with the following error

System Error: We are unable to continue at this time. Please close your browser and try again. Error: at System.Threading.Thread.AbortInternal() at System.Threading.Thread(Object stateInfo) at System.Web.HttpResponse.AbortCurrentThread() at MFC.WebApp.SecureAuth.SAML20IdpInit.Page_Load(Object sender, EventArgs e)

However, logging into the realm itself, the SAML application works fine.

Cause: Mismatch of "Get Shared Secret" and "Set Shared Secret" values between the Portal realm and the SAML realm.

Resolution:

1. Open the Admin Console

2. Navigate to the Workflow tab of the Portal Realm

3. Scroll down to the Custom Identity Consumer section and make a note of the Get Shared Secret and Set Shared Secret Values

4. Swap to the workflow section of the SAML realm

5. Match the values of Get Shared Secret and Set Shared Secret to the corresponding values of the SecurePortal realm.

6. Click Save.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version affected: All

Description:

When attempting to use an OpenID realm, it fails withserver_error: An unexpected error occurred.

redirect_uri=https\%3a\%2f\%2fexample.oidc.com&state=A2SAAEAEMFNg7l

Cause:

This can happen when the scope is missing from the request. Follow the steps below to resolve.

If the below does not fix the issue, check the Audit log for the cause.

Resolution:

1. Grab the full address from the address bar, including the query string. It will look something like:

" https://Secureauth.example.com/SecureAuth123/Authorized/OidcAuthorize.aspx?

response_type=code&client_id=123f65a1232212389c952123b56cea16

& "

(Line breaks added for ease of reading)

2. Check that Scope is in the query string (it's missing in the above example)

3. Edit your OIDC server so it requests the scope.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: All

Description: Admin console does not work. Sometimes this is a white screen.

Cause: Compatibility Mode has been enabled in IE causing IE to act like an unsupported version

Resolution:

1. Open Internet Explorer

2. Click on Tools | Compatibility View

3. Remove the your IdP website from the compatibility view list.

4. If you're going to an FQDN eg idp.mydomain.com it might also count as an "Intranet Site" so if it is still broken after performing step 3, go ahead an untick "Display Intranet Sites in Compatibility View"

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 9.x

Description:

Trying to use SP Initiated SAML with BrainSpace and it is not working.

The User is redirected to the IdP but the IdP errors after the User logs in.

Cause:

Also BrainSpace acts like it is SP initiated - Eg, It redirects you from the SP to the IdP. It does not send an AuthN request.

Resolution: As BrainSpace does not send an AuthN request, you need to set the PostAuth tab to IdP Initiated rather than SP initiated.

1. Open the Web Admin Console

2. Navigate to the Post Auth page of the realm in question

3. Change to SAML 2.0 (IdP Initiated) Assertion

4. Hit Save

Special Considerations:

Ensue the Issuer and audience match the identifier on the Brainspace side of things

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth Idp Version affected: 9.3, 19.07

Description:

In environments where internet access is only available via a proxy server, the IdP admin console will not open and gets stuck on a blank white screen.

Cause:

IdP version 9.3 uses a feature in IIS called ARR (Application Request Routing). This works in a similar fashion to a proxy so when behind another proxy server it needs to be configured to chain the proxy requests.

Resolution:

1. Take a snapshot of the IdP.

2. Open IIS Manager, click on the server name and then Application Request Routing Cache.

https://support.secureauth.com/hc/en-us/articles/360027641592-Data-stores-cannot-be-saved-in-the-new-experience-when-IdP-is-behind-a-proxy

3. In the right-hand pane click "Server Proxy Settings".

4. Scroll down until you see Proxy Chain and enter the proxy details here, then click Apply.

5. Ensure that all IPs documented here are allowed through the proxy: https://docs.secureauth.com/display/KBA/SecureAuth+Cloud+Services

6. Try the admin console once more.

Notes:

Also see this article:

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: 9.2

Description:

After using Content and Localization | Verbiage editor to make changes to the DFP Label (accountupdate_labeldfp) these changes are not reflected in the Self Service page.

Cause: Web Config setting is overriding the text that was set in the verbiage editor

Resolution:

1. Open the Admin Console

2. Navigate to the System Info tab for the Self Service Realm

3. Click "Click here to edit the Web Config File"

4. Search for UUpdateDFPLabel

5. Remove the value from this field to force the self service page to use the DFP label that you've set in the verbiage editor (See screenshot for the correct edit)

6. Click save.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version affected: All

Description: Users cannot login - after MFA, they are returned to the login screen and the process starts again. Sometimes Users can login, especially if they move through the login process very quickly.

Cause: Filesync 4.x needs the Service running on the Primary and Secondary servers. If not, the Manifest file gets out of date and this causes the web.config to appear to be newer on the secondary servers. This causes filesync to keep copying the web.config from the primary to secondary every minute.

The end result is anyone who is attempting to login when the web.config is copied again, will have their session terminated and the login process will start again.

Resolution:

1. Login to the Primary Server.

2. Open Services.msc

3. Set the SecureAuth Filesync Service to Automatic start type

4. Start the SecureAuth Filesync Service.

5. Make sure the Manifest file now updates

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description: When attempting to reset a password, the attempt fails with "Password was not changed Exception: Exception has been thrown by the target of an invocation. - The server is unwilling to process the request. (Exception from HRESULT: 0x80072035)

Cause:

The AD server refuses to accept plain text password reset requests and the connection mode on the Data Tab is set to Standard instead of Secure or SSL

Resolution: Switch to a more secure method of connecting to Active Directory.

1. Open the Web Admin Console and Navigate to the realm in questions

2. Click on the Data Tab for the realm

3. Change the Connection Mode from Standard to Secure or SSL

4. Save the changes

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

How to write a Regex (Regular Expression) that matches the ITU E.123 and E.164 formats.

Cause:

The SecureAuth Best Practices guide mentions that phone numbers should be formatted as per ITU E.123 and/or E.164:

https://docs.secureauth.com/display/KBA/Phone+Number+and+Email+Formatting+Best+Practices

Resolution:

Use the following regex:

^\+\d{1,3}\s\d{2,3}\s\d{2,3}\s\d{4}|^\+\d{1,3}\s\d{1,14}(\s\d{1,13})?|^\(\d{3}\)\s\d{3}\s\d{4}?

This is comprised of 3 regular expressions combined:

1. E.123

^\+\d{1,3}\s\d{2,3}\s\d{2,3}\s\d{4}

matches a 1 to 3 digit country code followed by a space, then 2 to 3 digits, another space, another 2 to 3 digits a final space then 4 digits, e.g.:

+1 123 456 7890

+31 42 123 4567

2. E.123

^\(\d{3}\)\s\d{3}\s\d{4}?

matches the standard national US 3-3-4 number format. A 3 digit area code in brackets, followed by a space, then 3 more digits, followed by another space then 4 digits e.g.:

(112) 123 4567

Note the area code must be in brackets.

3. E.164

^\+\d{1,3}\s\d{1,14}(\s\d{1,13})?

matchesa 1 to 3 digit country code followed by a space then between 1 and 14 digits, optionally followed by another space and up to 13 further digits, e.g.:

+44 1234 567890

+44 1234567890

Note: E.164 allows for a maximum of 15 digits, up to 3 of which are the country code, therefor the second grouping of 14 digits can complete the number. The optional 13 characters are to allow for countries that traditionally have a space between their area code and the local number.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 9.x

Description:

URL Rewrite is being used to detect a Users location and redirect them to a different realm.

For example, one use case for this is to move Internal Users to a Windows SSO enabled realm to save them from typing their credentials when on premise.

The problem this KBA address is that this redirect continues to happen even after they've changed location.

Cause:

Incorrect redirect type used on the URL Rewrite Rule.

Resolution:

When doing a redirect, URL Rewrite defaults to a 301 (Permanent) redirect. This causes the Users browser to cache the redirect and not check in with IIS every time.

A better option is to use a 307 (Temporary) redirect.

1. Open IIS on the SecureAuth IdP

2. Navigate to the URL Rewrite rule in question

3. Edit the redirect type from a 301 to a 307 and Apply the changes

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth IdP Version Affected: 9.2+

Description:When configuring a SAML integration, the service provider throws a signature error.

Cause:There are various reasons to why a signature error could be invoked. One of the more common ways is if it is expecting a SHA1 or SHA2 signing algorithm and there is a mismatch.

Resolution:Check if the certificate being used is SHA1 or SHA2

If a SHA1 certificate is being used, but the drop down is selected for SHA2, there will be a error.

SHA1 Certificate:

If a SHA2 certificate is being used, either dropdown can be used.

SHA2 Certificate:

Further Troubleshooting: Open up command prompt with elevated privileges and run this command "certutil -store my > c:\temp\certinfo.txt". This will write a text file to the C:\Temp directory with information regarding the certificate on the appliance personal cert store. In order for your SHA2 certificate to be enabled for SHA2 signing, the Cryptographic Service Provider needs to be "Microsoft Enhanced RSA and AES Cryptographic Provider"

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

The following error is received when trying to sign the SAML assertion or message. If signing is disabled then the error does not occur:

Error: at ComponentSpace.SAML2.Utility.XmlSignature.Generate(XmlElement xmlElement, String elementId, AsymmetricAlgorithm signingKey, KeyInfo keyInfo, SignedXml signedXml, String inclusiveNamespacesPrefixList, String digestMethod, String signatureMethod) at ComponentSpace.SAML2.Assertions.SAMLAssertionSignature.Generate(XmlElement xmlElement, AsymmetricAlgorithm signingKey, X509Certificate2 x509Certificate, String inclusiveNamespacesPrefixList, String digestMethod, String signatureMethod) at MFC.WebApp.SecureAuth.SAML20SPInit.CreateSAMLResponse(AuthnRequest authnRequest, String sUser) at MFC.WebApp.SecureAuth.SAML20SPInit.Page_Load(Object sender, EventArgs e)

Cause:

If the certificate being used to sign the SAML is a SHA2 certificate then the CSP (Cryptographic Service Provider) may be incorrect and/or the SAML Signing algorithm may be incorrectly set.

SHA2 signing requires the"Microsoft Enhanced RSA and AES Cryptographic Provider" CSP.

Resolution:

To check the SHA version of the certificate and verify the CSP see this article:

https://support.secureauth.com/hc/en-us/articles/360026511172-Getting-Signature-Errors-During-SAML-Integration

As per the above article you also need to select the correct SHA version for signing from the drop down list.

Additionally if the cert is SHA2 and has the wrong CSP for SHA2 signing then use this article:

https://support.secureauth.com/hc/en-us/articles/360021301651-How-to-support-signing-with-a-SHA256-certificate

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: All

Description:

How to find out the MFA method used during logon

Cause:

When auditing or troubleshooting a realm that requires a second factor it may be necessary to determine which MFA method is being used for each logon attempt.

Resolution:

For normal workflows interacting with the realm via a browser:

1. Ensure Audit logging is enabled on the realm in question (Text or Syslog).

2. Filter the log for EventID24010, this will show up in the text log as:

<EventID>24010</EventID>

and Syslog like:

EventID="24010"

3. The MFA method will show up in between the<Message></Message> tags like the following 5 Text log examples:

<Root><EventID>24010</EventID><Timestamp>10/23/2019 7:49:11 AM</Timestamp><SeverityLevel>Information</SeverityLevel><Priority>3</Priority><UserAgent>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; wbx 1.0.0)</UserAgent><UserHostAddress>172.16.20.228</UserHostAddress><BrowserSession>2a0c0ec0-d18f-4b6f-9e73-170bcf15e1d1</BrowserSession><RequestID>34fc7e84-e3a9-465e-8dad-4ef79ad1201b</RequestID><Realm>SecureAuth68</Realm><Appliance>WIN-122436</Appliance><Company>SecureAuth Support</Company><Version>9.0.1.74</Version><UserID>user1</UserID><Message>PIN Method Selected RegistrationPIN</Message></Root>

<Root><EventID>24010</EventID><Timestamp>10/23/2019 8:20:57 AM</Timestamp><SeverityLevel>Information</SeverityLevel><Priority>3</Priority><UserAgent>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; wbx 1.0.0)</UserAgent><UserHostAddress>172.16.20.228</UserHostAddress><BrowserSession>8d2ba3a9-3d69-490f-a3f4-4ac68dfe1f56</BrowserSession><RequestID>0c6a4c38-318d-4f9d-9a6d-62806da33a3f</RequestID><Realm>SecureAuth68</Realm><Appliance>WIN-122436</Appliance><Company>SecureAuth Support</Company><Version>9.0.1.74</Version><UserID>user1</UserID><Message>Push Notification Method Selected</Message></Root>

<Root><EventID>24010</EventID><Timestamp>10/23/2019 8:22:05 AM</Timestamp><SeverityLevel>Information</SeverityLevel><Priority>3</Priority><UserAgent>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; wbx 1.0.0)</UserAgent><UserHostAddress>172.16.20.228</UserHostAddress><BrowserSession>1dee8e97-bf76-4c81-b0a2-bcfe1a651bd7</BrowserSession><RequestID>f57c9ff6-7d74-4a03-8547-021aa15c8d4a</RequestID><Realm>SecureAuth68</Realm><Appliance>WIN-122436</Appliance><Company>SecureAuth Support</Company><Version>9.0.1.74</Version><UserID>user1</UserID><Message>Push Notification Method Selected</Message></Root>

<Root><EventID>24010</EventID><Timestamp>10/23/2019 8:22:36 AM</Timestamp><SeverityLevel>Information</SeverityLevel><Priority>3</Priority><UserAgent>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; wbx 1.0.0)</UserAgent><UserHostAddress>172.16.20.228</UserHostAddress><BrowserSession>4e875e1d-fed7-4bb8-991d-647091df4d59</BrowserSession><RequestID>18d8be39-70b6-43b5-b573-d50a432cf3a7</RequestID><Realm>SecureAuth68</Realm><Appliance>WIN-122436</Appliance><Company>SecureAuth Support</Company><Version>9.0.1.74</Version><UserID>swatts</UserID><Message>SMS SMethod elected</Message></Root>

<Root><EventID>24010</EventID><Timestamp>10/23/2019 8:23:06 AM</Timestamp><SeverityLevel>Information</SeverityLevel><Priority>3</Priority><UserAgent>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; wbx 1.0.0)</UserAgent><UserHostAddress>172.16.20.228</UserHostAddress><BrowserSession>9119ebd2-18f4-4d59-9102-43d495ec304e</BrowserSession><RequestID>91352c36-606d-4574-ac98-79427733ae9e</RequestID><Realm>SecureAuth68</Realm><Appliance>WIN-122436</Appliance><Company>SecureAuth Support</Company><Version>9.0.1.74</Version><UserID>swatts</UserID><Message>OATH Registration Method Selected</Message></Root>

and here's some Syslog examples:

Message="Push Notification Method Selected"

Message="OATH Registration Method Selected"

For API workflows:

1. Ensure Audit logging is enabled on the realm in question (Text or Syslog).

2. Filter the log for EventID 60201, this will show up in the text log as:

<EventID>60201</EventID>

and Syslog like:

EventID="60201"

3. The MFA method will show up in between the<Message></Message> tags and appear similarly in Syslog. The MFA method can be found immediately following AuthRequestType:

[AuthController].[PostAuthRequestAsync] Auth controller invoked with: '{"UserId":"USERNAME","Domain":null,"Token":"","AuthRequestType":"sms"

Special Considerations:

For a full list of Audit EventIDs and what they mean see this document here:

https://docs.secureauth.com/pages/viewpage.action?pageId=6226565

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 19.07+

Description:

When attempting to log into the Admin console, only a white screen loads.

Dev Tools (F12) shows 502 error when attempting to open

https://localhost/httpproxy/api/v3/sysinfo/ping

Attempting to navigate there manually, you see a 502.3 error

Cause:

Netmon can be used to check the actual cause but typically it is that the binding cert has a problem.

Resolution:

Acquire a new certificate.

1. Open IIS

2. Click Default Web Site

3. Click Bindings

4. Select https and Click Edit

5. Click Select

6. Choose the new Cert

7. Click OK

Special Considerations:

If the above doesn't fix it, please perform the following steps in order to get a log that shows the root cause

1. Open an Admin Command prompt

2. runnetsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl3. Reproduce the issue4. Runnetsh trace stopto stop tracing5. Grab C:\Temp\net.etl and send it through to support.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth version affected: 9.1+

Description:

Some tools such as SSL Labs utility may report that an IdP is not offering this header. Does IdPoffer this header by default or is any additional configuration required?

Cause:

In this instance SSL labs https://www.ssllabs.com/ssltest/ was used to scan the IdP.

This tooldoes comprehensive free SSL testing but scans the root level, e.g. /Default Web Site, rather then the individual realms themselves. Because HSTS is built into IdP code at the realm level, HSTS scans on the root level may not show as enabled.

Resolution:

In Idp versions 9.1+ HSTS is enabled by default and it is built into IdP code so there are no extra steps needed.

Security Headers tool https://securityheaders.io/ analyzes HTTP headers. With this tool you can navigate to https://IdP_fqdn /realm# and if HSTS is enabled this tool will show it as enabled.

In the case of tools, such as SSL labs, that scanning at default web site level it is possible to add an Outbound Rule to IIS URL Rewrite configuration which injects the security header and does not interfere with the code in IdP.

iPadOS Version Affected: 13.x and Newer

Description:

When trying to download a mobile profile on the new versions of iPadOS, the SecureAuth page will give one of the following errors:

"Unable to download the profile - 4-Please contact admin - Unable to contact the Certificate Authority (WSE 3.0 configuration is incorrect)"

or

“Safari could not install a profile due to an unknown error”

Even if something appears on the mobile device, it will not include the necessary certificates to be used properly for applications such as a VPN.

Cause:

Apple has changed the User Agent with the newer versions of iPadOS. The previous User Agent displayed as a MobileOS / iPad, but the newer versions now display as a MacOS User Agent as default.

Resolution:

To workaround this, we need to change the iPadOS User Agent back to an MobileOS / iPad User Agent.

1. On your iPad, Go to Settings > Safari > Request Desktop Website

2. Turn off the All Websites setting

3. Retry to download the mobile profile

You should be able to successfully download the mobile profile now similar to earlier versions.

SecureAuth will be addressing the iPadOS User Agent change in a hotfix or new release. As of now, there is no release date of this fix.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

MacOS Version Affected: 10.14.6 (Mojave) and 10.15.x (Catalina)

Safari Version Affected: 13.0.x and newer

Description:

Client-side certificates used for validating users through IIS may not work with the latest versions of MacOS and Safari. This means that any web browser login requiring the user to present a certificate as part of their authentication may potentially have issues.

Error message may include "the server unexpectedly dropped the connection" or "the operation couldn't be completed" or "Error 9816" when choosing a valid certificate.

Some examples of workflows that may be affected by this issue would be Citrix Receiver-AGEE Client Certificate Authentication and SecureAuth's Certificate Authentication via SSL (C-SSL). Cisco Anyconnect VPN Clients may be affected, but it does look like the newer versions of MacOS v10.15 and Cisco Anyconnect VPN Client v4.8 work.

Cause:

Apple support has responded by saying that it is perhaps likely a bug and is continuing to investigate. There is little transparency on what the investigation is like and information regarding whether it will likely be fixed has not been released.

Resolution:

We have been told to use third-party web browsers for the meantime as they seem to be working with the Client Certificate Authentication according to our tests. The following have been tested and seem to work on MacOS for the meantime.

Chrome

Firefox

Apple support has mentioned that this could perhaps be fixed in later versions. With each update, there is a possibility that client certificate authentication could start working again on a specific MacOS or Safari version.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

SecureAuth Version Affected: 19.07.01

Description:

Threat Services under the Adaptive Authentication tab appears disabled even though the box is properly licensed for this feature. This KBA only applies to new v19.07.01 SecureAuth SISU (SecureAuth Installation Setup Utility) deployments.

Cause:

SISU SecureAuth package for v19.07.01 contains a MFC.SecureAuth.License.dll in the API folder's bin that should not be included by default. Therefore, when SISU tries to install the valid MFC.SecureAuth.License.dll in that location, it doesn't because there is already one there.

Resolution:

There is a fix currently for already deployed v19.07.01 appliances.

1. Copy the file from:

D:\Secureauth\SecureAuth1\bin\MFC.SecureAuth.License.dll

2. Paste the file into:

D:\Secureauth\Api\bin

You want to overwrite the file in the MFC.SecureAuth.License.dll in the D:\Secureauth\Api\bin location.

The actual fix for new SISU deployments will be coming very soon, and this KBA will be updated when it has been tested and completed.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: IdP 8.2 and higher

Description:

When sending the fingerprint_id to the DFP confirmation endpoint API (POST to /api/v1/dfp/confirm) the following response is received:

ApiResponseHTTPStatusCode="OK" ApiResponseStatus="not_found" ApiResponseMessage="Could not resolve fingerprint with ID XXXXXXXXXXXXXXXXXXXXX"

Cause:

If the fingerprint is not found in the datastore during the preceding DFP validation (POST to /api/v1/dfp/validate), or is "found_for_update", then the API returns afingerprint_idand caches that fingerprint_id for a short while in memory.

The cache duration is set by the web.config app setting keyApi.HttpRequestValidityPeriodInMinutes,which is 2 minutes by default.

If the fingerprint_id is then sent to the DFP confirmation endpoint (POST to /api/v1/dfp/confirm) the API carries out the following pseudo-code steps:

if fingerprint_id is found in the cache AND the datastore then it updates the existing fingerprint in the datastore and sends:

"verified", "Fingerprint has been confirmed."

else if fingerprint_id is found ONLY in the cache then it adds a new fingerprint to the datastore and sends:

"verified", "Fingerprint has been confirmed."

else if fingerprint_id is found ONLY in the datastore then it does nothing and sends back:

"found", "Fingerprint exists."

finally ifnoneof the conditions above match then it does nothing and sends back:

"not_found", "Could not resolve fingerprint with ID XXXXXXXXXXXXXXXXXXXXX"

So the error message means the fingerprint does not exist in the datastore AND additionally the cache does not contain the fingerprint, which can happen if the cache has expired, or in a load balanced scenario, a different IdP is being contacted than the node that cached the fingerprint.

Resolution:

Review logs to ensure that the time difference between fingerprint validation and confirmation is no greater than the web.config app setting keyApi.HttpRequestValidityPeriodInMinutes. Adjust API client code accordingly or increaseApi.HttpRequestValidityPeriodInMinutes.

If the IdP is in a load balanced pool, ensure that session affinity/persistence is maintained so the API requests are not bouncing around individual nodes.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 9.1 9.2 9.3 19.07

Description: When attempting to enroll a Yubikey device, the enrollment fails with the error verification failed.

Error Logs show

LogChannel="SA_ERROR" FormatVersion="0.0.1" EventID="-1" Timestamp="2019-10-17T17:32:52.140Z" CompanyID="" ApplianceID="" Realm="SecureAuth10" UserID="" BrowserSession="3552d30a-0b29-424d-82a0-278dd058cc1b" RequestID="573ecb61-a10b-4680-9569-388e43d97bec" UserHostAddress="10.10.12.79" Message="SecureAuth.Integration.YubiKey.YubiKeyHelper.GetResponse exception: Unable to connect to the remote server"

This problem can also stop previously enrolled devices from successfully working as a MFA method.

Cause:

IdP cannot access the Yubico endpoints which are currently

" https://api.yubico.com/wsapi/verify?id= "" https://api2.yubico.com/wsapi/verify?id= "" https://api3.yubico.com/wsapi/verify?id= "" https://api4.yubico.com/wsapi/verify?id= "" https://api5.yubico.com/wsapi/verify?id= "

Make sure your IdP can reach these endpoints. If it needs to reach them via a Proxy, follow the steps below.

Resolution:

The Yubikey enrollment and Yubikey MFA validation ignores the realm proxy settings and try to go directly to the Yubico endpoints. In order to force Yubikey to use your proxy settings, please complete the following steps

1. Take a backup of your web.config

2. Open the WebAdmin console in Classic View and navigate to the System Info tab of the realm in question.

3. Click the Decrypt button

4. Edit your Web.config in your favourite text editor

5. Search for

6. Directly below <System.Net> add the following (I don't recommend copy + paste from here as you might get illegal characters)

<defaultProxy> <proxy proxyaddress="http://12.34.56.78:8080" bypassonlocal="true" />

</defaultProxy>

7. Perform the same on any realm that uses Yubikey for MFA.

Special Considerations: It is not possible to directly add credentials to this section. If your Proxy requires authentication, as long as this is set correctly on the System Info tab, you should be fine as you'll already be authenticated to the proxy when the Yubikey uses it.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: 9.x

Description:

When click on the Tools | Decrypt Web Config option in the Web Admin Console, it errors with the standard Custom Error page.

If Custom Errors are turned off, you see the real error

Cause:

One of the SecureAuthXYZ realm folders in D:\SecureAuth\ is missing a Web.Config file.

Resolution:

The Web.config only goes missing when the SecureAuth administrator themselves has accidentally moved it so they will typically know which realm they've just been working on and should check there.

However, the following steps can be performed to get a list of folders where the web.config is missing

1. RDP into the IdP2. Open an Admin Powershell3. RunGCI "D:\SecureAuth" -Directory | ?{(gci $_.FullName -Filter "web.config").count -eq 0}4. This will return a list of Folders where the web.config is missing.

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Version Affected: IdP9.1+

Description:

When trying to extend the timeout on a Link to Accept via E-mail, it does not honor the session timeout on the workflow tab.

Cause:

There is a different timeout setting for Link to Accept specifically.

Resolution:

Decrypt the webconfig for the realm in question and add this appsetting, where "x" is the minutes desired.

<add key="L2AValidityThreshold" value="X" />

SecureAuth Knowledge BaseArticles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.