KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:36:42 GMT

Current Revision posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:36:42 PM

Purpose

After enabling SAML authentication, it is possible that only a subset of users experience issues logging in, while others are able to log in without issues. The most common cause for SSO login issues experienced by only some users is the Identity Provider (IdP) sending an erroneous username to Appian. Appian usernames are always case sensitive, whereas some Identity Providers (IdPs) may be case agnostic in their treatment of usernames.

This article provides a framework for troubleshooting SSO issues impacting only a subset of users. If no users are able to log in, double check the SSO configurations and ensure that SSO is correctly configured by using the Administration Console to test prior to attempting to follow these steps.

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Before proceeding with further troubleshooting, make sure that the users for whom login attempts are failing, are using the correct username and password for the IdP. These credentials may be different from the username/password combinations used with native Appian authentication.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). Check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also ensure that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password, or otherwise prevented from successfully authenticating. The easiest way to check this is to see if the user is able to authenticate with the IdP itself. If the user is unable to authenticate with the IdP, the issue is most likely with the IdP rather than Appian.

Examine the login-audit.csv files

The login-audit.csv files located in the <APPIAN_HOME>/logs directory can provide additional information about the login attempts coming from the IdP. As login issues for some SSO users are typically caused by erroneous usernames, look for the following properties in login attempts with a Status of Failed and a Source of Portal:

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

To determine if this is the cause, you may compare these login attempts to the list of users found in the Administration Console to cross reference and determine if the username is correctly sent to Appian. The usernames can be corrected in two ways depending on the nature of the issue:

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers in appian_log4j.properties will record additional details about SAML logins in the app server log.

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

If the username appears correct but the user is still unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a support case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps lead to a expeditious resolution to the issue.

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:35:40 GMT

Revision 21 posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:35:40 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers in appian_log4j.properties will record additional details about SAML logins in the app server log.

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG log4j.logger.org.springframework.security=DEBUG log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:35:07 GMT

Revision 20 posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:35:07 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers in appian_log4j.properties will record additional details about SAML logins in the app server log.

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG

log4j.logger.org.springframework.security=DEBUG

log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:34:16 GMT

Revision 19 posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:34:16 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers in appian_log4j.properties will record additional details about SAML logins in the app server log.

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG log4j.logger.org.springframework.security=DEBUG log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:29:59 GMT

Revision 18 posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:29:59 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers will record additional details about SAML logins in the JBoss server log. Alter the following lines to DEBUG in <APPIAN_HOME>/ear/suite.ear/resources/appian_log4j.properties:

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG log4j.logger.org.springframework.security=DEBUG log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Elly Meng — Mon, 21 Aug 2023 17:28:13 GMT

Revision 17 posted to Appian Knowledge Base by Elly Meng on 8/21/2023 5:28:13 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

18.2 and earlier:

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

18.3 and later:

log4j.logger.org.opensaml.core.xml.util=TRACE

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

James Lee — Fri, 24 Jul 2020 12:48:11 GMT

Revision 16 posted to Appian Knowledge Base by James Lee on 7/24/2020 12:48:11 PM

Purpose

Table of Contents:

Ensure the user is using the correct username and password
Check user membership in SAML Users group and activation
Check IdP side settings for affected users
Examine the login-audit.csv files
Enable additional loggers
Gather a SAML trace

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: July 2020

Tags: SAML, admin console, how-to, authentication

KB-1450 How to troubleshoot SAML login issues impacting only some users

Parmida Borhani — Tue, 16 Jan 2018 21:55:03 GMT

Revision 15 posted to Appian Knowledge Base by Parmida Borhani on 1/16/2018 9:55:03 PM

Purpose

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, how-to, authentication

DRAFT KB-XXXX How to troubleshoot SAML login issues impacting only some users

Parmida Borhani — Mon, 15 Jan 2018 17:59:42 GMT

Revision 14 posted to Appian Knowledge Base by Parmida Borhani on 1/15/2018 5:59:42 PM

Purpose

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, how-to, authentication

DRAFT KB-XXXX How to troubleshoot SAML login issues impacting only some users

Parmida Borhani — Mon, 15 Jan 2018 17:58:37 GMT

Revision 13 posted to Appian Knowledge Base by Parmida Borhani on 1/15/2018 5:58:37 PM

Purpose

Instructions

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX How to troubleshoot SAML login issues impacting only some users

Parmida Borhani — Mon, 15 Jan 2018 17:54:26 GMT

Revision 12 posted to Appian Knowledge Base by Parmida Borhani on 1/15/2018 5:54:26 PM

Purpose

Instructions

Ensure the user is using the correct username and password

Before proceeding with further troubleshooting, make sure that the users for whom login attempts are failing are using the correct username and password for the IdP. These may be different from the username/password combinations used with native Appian authentication.

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is to see if the user is able to authenticate with the IdP itself. If the user is unable to authenticate with the IdP, the issue is most likely with the IdP rather than Appian.

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

Enabling the following loggers will record additional details about SAML logins in the JBoss log files. Alter the following lines to DEBUG in <APPIAN_HOME>/ear/suite.ear/resources/appian_log4j.properties:

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Jussi Lundstedt — Mon, 15 Jan 2018 11:08:58 GMT

Revision 11 posted to Appian Knowledge Base by Jussi Lundstedt on 1/15/2018 11:08:58 AM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

The most common cause for SSO login issues experienced by only some users is the Identity Provider (IdP) sending an erroneous username to Appian. Appian usernames are always case sensitive, whereas some Identity Providers (IdPs) may be case agnostic in their treatment of usernames.

Action

The below steps provide a framework for troubleshooting SSO issues impacting only a subset of users. If no users are able to log in, double check the SSO configurations and ensure that SSO is correctly configured by using the Administration Console to test prior to attempting to follow these steps.

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Jussi Lundstedt — Mon, 15 Jan 2018 11:05:59 GMT

Revision 10 posted to Appian Knowledge Base by Jussi Lundstedt on 1/15/2018 11:05:59 AM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

The login-audit.csv files located in the <APPIAN_HOME>/logs/audit directory can provide additional information about the login attempts coming from the IdP. As login issues for some SSO users are typically caused by erroneous usernames, look for the following properties in login attempts with a Status of Failed and a Source of Portal:

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Jussi Lundstedt — Mon, 15 Jan 2018 11:03:24 GMT

Revision 9 posted to Appian Knowledge Base by Jussi Lundstedt on 1/15/2018 11:03:24 AM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Ensure the user is using the correct username and password

Check user membership in SAML Users group and activation

Check IdP side settings for affected users

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

For example, a failed login attempt might look like this:

2017-08-29 15:51:22,usr.name,Failed,192.168.14.15,Portal,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36"

Adjust IdP settings to send usernames in the form expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Enable additional loggers

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.saml2=DEBUG

Gather a SAML trace

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">john.smith</saml2:NameID>

<saml2:Attribute Name="usernameAttribute" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">john.smith</saml2:AttributeValue>
</saml2:Attribute>

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Parmida Borhani — Tue, 09 Jan 2018 21:54:47 GMT

Revision 8 posted to Appian Knowledge Base by Parmida Borhani on 1/9/2018 9:54:47 PM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

The most common cause for SSO login issues experienced by only some users is a mis-broadcasting of the username from the Identity Provider. Appian usernames are always case sensitive, whereas some Identity Providers (IdPs) may be case agnostic in their treatment of usernames.

Action

Examine the login-audit.csv files

In order to determine which users are impacted, check the login-audit.csv files located in the <APPIAN_HOME>/logs/audit directory. As login issues for some SSO users are typically caused by mistakenly broadcast usernames, look for the following properties in login attempts with a Status of Failed and a Source of Portal:

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

To determine if this is the cause, you may compare these login attempts to the list of users found in the Administration Console to cross reference and determine if the username is correctly sent to Appian. Mis-broadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also ensure that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome to gather the SAML request and response. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a support case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Parmida Borhani — Tue, 09 Jan 2018 21:45:52 GMT

Revision 7 posted to Appian Knowledge Base by Parmida Borhani on 1/9/2018 9:45:52 PM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being sent, such as john.doe instead of u12345

To determine if this is the cause, you may compare these login attempts to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast to Appian. Mis-broadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also ensure that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Gather a SAML trace

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

KB-XXXX Troubleshooting SSO Login Issues Impacting Some Users

Jussi Lundstedt — Tue, 09 Jan 2018 18:10:50 GMT

Revision 1 posted to Appian Knowledge Base by Jussi Lundstedt on 1/9/2018 6:10:50 PM

Symptom

After enabling SSO based authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

The most common cause for SSO login issues experienced by only some users is a mis-broadcasting of the username. Appian usernames are always case sensitive, whereas some Identity Providers (IdPs) may be case agnostic in their treatment of usernames.

Action

The below steps provide a framework for troubleshooting SSO issues impacting only some users. If no users are able to log in, please double check the SSO configurations and ensure that SSO is correctly configured by using the Administration Console to test prior to attempting to follow these steps.

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being broadcast, such as john.doe instead of u12345

To determine if this is the cause, you may compare these to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast. Misbroadcast usernames can be corrected in four ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider can fix this.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication with the exception of allowing multiple SAML IdPs per user in Appian 17.4 and later. If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also check that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is if the user is able to authenticate with the IdP itself. If this does not work, the issue is most likely with the IdP rather than Appian

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the user in Appian but not the IdP, submit a new case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

This article applies to all Appian versions that support configuring SAML authentication via the Admin Console. Some of the troubleshooting tips above may also apply to earlier Appian versions with SSO configured via custom Spring Security files.

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Parmida Borhani — Tue, 09 Jan 2018 18:10:11 GMT

Revision 6 posted to Appian Knowledge Base by Parmida Borhani on 1/9/2018 6:10:11 PM

Symptoms

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being broadcast, such as john.doe instead of u12345

To determine if this is the cause, you may compare these to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast to Appian. Misbroadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also check that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is if the user is able to authenticate with the IdP itself. If the user is unable to authenticate with the IdP, the issue is most likely with the IdP rather than Appian.

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome to gather the SAML request and response. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a new case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

DRAFT KB-XXXX Troubleshooting SAML login issues impacting only some users

Parmida Borhani — Tue, 09 Jan 2018 18:10:00 GMT

Revision 5 posted to Appian Knowledge Base by Parmida Borhani on 1/9/2018 6:10:00 PM

Symptom

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being broadcast, such as john.doe instead of u12345

To determine if this is the cause, you may compare these to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast to Appian. Misbroadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also check that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is if the user is able to authenticate with the IdP itself. If the user is unable to authenticate with the IdP, the issue is most likely with the IdP rather than Appian.

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome to gather the SAML request and response. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a new case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

This article applies to Appian versions 7.11 and later.

Last Reviewed: January 2018

Tags: SAML, admin console, authentication

KB-XXXX Troubleshooting SAML Login Issues Impacting Only Some Users

Jussi Lundstedt — Tue, 09 Jan 2018 13:40:08 GMT

Revision 4 posted to Appian Knowledge Base by Jussi Lundstedt on 1/9/2018 1:40:08 PM

Symptom

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being broadcast, such as john.doe instead of u12345

To determine if this is the cause, you may compare these to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast to Appian. Misbroadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider will enable Appian to treat all usernames as lowercase regardless of IdP casing.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also check that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is if the user is able to authenticate with the IdP itself. If the user is unable to authenticate with the IdP, the issue is most likely with the IdP rather than Appian.

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome to gather the SAML request and response. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a new case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

This article applies to all Appian versions that support configuring SAML authentication via the Admin Console. Some of the diagnosis tips above may also apply to earlier Appian versions with SSO configured via custom Spring Security files. Please note that configuring SSO via custom Spring Security override files is deprecated as of Appian 7.11 and Appian Technical Support is unable to assist in resolving issues arising with custom override files.

Tags: SAML, admin console, authentication

KB-XXXX Troubleshooting SAML Login Issues Impacting Only Some Users

Jussi Lundstedt — Tue, 09 Jan 2018 13:21:46 GMT

Revision 3 posted to Appian Knowledge Base by Jussi Lundstedt on 1/9/2018 1:21:46 PM

Symptom

After enabling SAML authentication, a subset of users experiences issues logging in, while others are able to log in without issues.

Cause

Action

Examine the login-audit.csv files

Casing errors, such as John.Doe@Acme.com instead of john.doe@acme.com
Mistakenly included or omitted parts of username conventions such as john.doe@acme.com instead of john.doe
Alternative user identifiers being broadcast, such as john.doe instead of u12345

To determine if this is the cause, you may compare these to the list of users found in the Administration Console to cross reference and determine if the username is correctly broadcast to Appian. Misbroadcast usernames can be corrected in three ways depending on the nature of the issue:

Adjust IdP settings to broadcast usernames as expected by Appian. This is particularly useful if there is a consistent error such as omitting or including the domain part of an e-mail address or sending the wrong type of user identifier.
Request help from Appian Technical Support in renaming users impacted by the issue.
If the issue is caused by Appian expecting lowercase usernames and the IdP sending mixed-case usernames, unchecking "Retain Casing" in the Administration Console SAML settings for this identity provider can fix this.

Check user membership in SAML Users group and activation

It is a best practice to restrict SAML authentication to a particular group of users to prevent total lockout in the case of an IdP-originated issue or an erroneous configuration change. Appian does not allow the same user multiple methods of authentication (native, LDAP and SAML). If the login-audit.csv files do not indicate any of the errors above, check that the users impacted by the issue are members of the SAML Users group configured in the Admin Console. While checking this, also check that the users experiencing the issue haven't been deactivated on the Users tab of the Admin Console.

Check IdP side settings for affected users

Ensure that the users affected have not been deactivated on the IdP side, locked out due to an expired password or otherwise prevented from successfully authenticating. The easiest way to check this is if the user is able to authenticate with the IdP itself. If this does not work, the issue is most likely with the IdP rather than Appian

Gather a SAML trace

If none of the steps above lead to a solution, you may use a third-party tool such as SAML Tracer for Firefox or SAML Message Decoder for Chrome. If the user is unable to authenticate with the IdP, contact your IdP's technical support staff. If the issue only impacts the users in Appian but not the IdP, submit a new case to Appian Technical Support and include SAML Traces (request and response) for a user that is able to authenticate and one that is experiencing issues for further analysis. Submitting both allows Appian Technical Support staff to cross-check for differences between successful and failed logins, and helps find an expedient resolution to the issue.

Affected Versions

Tags: SAML, admin console, authentication