SSO with ADFS 2 and Cisco WebEx

By wfcastle33 on November 28, 2017 • ( 0 )

Specific SSO errors and fixes covered: Invalid SAML Assertion (13), Untrusted Issuer (24)

Single-Sign On allows users to access web based applications with their domain credentials, thus eschewing the need for unique user names and passwords. WebEx does have a separate SAM (Security Accounts Management) interface, but as long as the domain names and WebEx user names match, SSO can be accomplished.

Cisco Webex allows for a Single Sign-On (SSO) design leveraging several technologies. In this case, I used Microsoft’s ADFS 2.0 because it was already in place and providing SSO for internal services. WebEx is an external cloud service, so things were about to get more complicated. There is no external LDAP connection, nor does Cisco provide one, so there will be no automatic updates of domain account status.

This article covers some specifics in the WebEx SSO setup only, not ADFS 2. However, when you engage Cisco about SSO configuration they’ll provide the following documentation: SSO Options, ADFS 2 Setup and SSO Configuration. Note that SSO isn’t available in the WebEx Administration web interface until they enable it. If they haven’t enabled SSO Configuration it will be missing from the Configuration–>Common Site Settings list.

The documentation provided by Cisco is pretty good although not complete. This post should fill in the blanks.

There are two assumptions made as to the basis of the SSO errors: The Relying Party Trusts and Claims Rules in ADFS are configured properly in accordance with Cisco’s instructions.

The first thing you’ll need is an export of the Token-Signing certificate used by ADFS. Export it in DER X509 format from the ADFS Server. The certificate can be found in the Certificates sub-folder in the Service parent folder. Import the X509 certificate into WebEx with the Site Certificate Manager link.

*** If you haven’t changed the lifetime of the ADFS default certificates (encryption and token signing), now is a good time. There are powershell scripts around the web to do this. By default they are set to expire annually and although there is an auto renew feature, it did disrupt internal services like Microsoft Dynamics (CRM). In response, I set them to expire after ten years. These are internal communication certificates with no internet exposure by design.***

To avoid the Untrusted Issuer (24) and most of the IdP (Identity Provider) errors, import the SAML metadata from the default internal ADFS link:

https://host.domain.com/FederationMetadata/2007-06/FederationMetadata.xml

Where “host” is the internal DNS entry for the federation services (by default, Microsoft suggests “sts1”) and “domain.com” is the internal domain. Accessing this link downloads the XML file with complete SAML metadata.

The last hurdle in the WebEx SSO configuration is the entry for the “AuthnContextClassRef” field. The documentation will recommend a simple “urn:federation:authentication:windows” option. If this doesn’t work, users will receive an “Invalid SAML Assertion (13)” error on the subsequent web page after login. Depending upon how ADFS is configured and if it’s installed as a proxy, this SAML authentication class may not work.

Adding the following classes should help ADFS successfully authenticate the user back to WebEx:

urn:oasis:names:tc:SAML:2.0:ac:classes:Password

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

When adding these classes into the AuthnContextClassRef field they need to be separated by semi-colon with no spaces.

If domain users are not added to WebEx they will receive an “Untrusted User” error after login. Meaning, the credentials are correct according to ADFS, but they have no account in WebEx to get privileges assigned.