Troubleshoot SNA Manager SSO Authentication Failure with Azure Entra ID

Available Languages

Download Options

  • PDF     (20.5 KB)
    View with Adobe Reader on a variety of devices
  • ePub     (83.5 KB)
    View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle)     (68.5 KB)
    View on Kindle device or Kindle app on multiple devices
Updated:August 6, 2026
Document ID:226234

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Issue

Users experienced SSO authentication failures when attempting to log into SNA Manager after integrating with Azure Entra ID as the Identity Provider (IdP) for SAML authentication. The specific error message displayed was:

"The authentication service was unable to fulfill your request. If this problem persists, contact your administrator."

During the setup process, after importing the SP (Service Provider) metadata file, the SNA Manager FQDN automatically changed from the original SNA Manager URL to include "/fedlet", which contributed to the authentication setup failure. The system audit logs confirmed authentication failures with "Unknown User" errors, indicating that the SNA Manager was not recognizing the usernames being transmitted in the SAML response from Azure.

Environment

  • Cisco Secure Network Analytics (SNA) Manager version 7.6.0

  • Microsoft Azure Entra ID configured as SAML Identity Provider

Resolution

The resolution involved correcting the SAML NameID attribute configuration in both Azure Entra ID and the SNA Manager to ensure proper username format matching.

Step 1: Perform SAML Trace Analysis

Use browser developer tools to perform a SAML trace and inspect the IdP response from Azure to identify the NameID format being transmitted. The trace revealed that Azure was sending the full User Principal Name (UPN) in the NameID attribute:

<Subject><NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="https://device.corp.example.com/fedlet">username@example.com</NameID>

Step 2: Review SNA Manager Audit Logs

Check the SNA Manager audit logs to confirm authentication failures correlating with the malformed NameID:

Aug 3 06:53:36 device AuditLogger[1480861]: AuditLogger: osaxsd/1480861,4003,2026-08-03T06:53:36TZD+0000,Bad User,x.x.x.x,Login on ssh failed: Unknown User

Step 3: Modify Azure SAML NameID Configuration

In the Azure Entra ID SAML configuration, change the NameID attribute from the default User Principal Name to use the "On-premises SAM account name". This ensures that the NameID contains only the username without the domain suffix (username@example.com becomes username).

Step 4: Update SNA Manager SAML ID Configuration

Navigate to the SNA Manager user management page and update the SAML ID value to match the corrected NameID format that is transmitted by Azure after the configuration change.

Step 5: Verify SSO Authentication

Test the SSO authentication by attempting to log in through the SAML workflow. The user now successfully authenticates without receiving the previous error message.

Cause

The authentication failure was caused by a mismatch between the NameID format sent by Azure Entra ID and the username format expected by the SNA Manager. Azure was configured to send the User Principal Name (UPN) in the format "username@example.com" in the SAML NameID attribute, while the SNA Manager expected only the username portion without the domain suffix. This format discrepancy resulted in the SNA Manager treating the incoming authentication requests as coming from unrecognized users, leading to "Unknown User" authentication failures.

Related Content

Revision History

Revision Publish Date Comments
1.0
06-Aug-2026
Initial Release
TAC Authored

Contributed by Cisco Engineers

  • Security TAC Engineers

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products