WebEx SSO with Microsoft AD FS 2.0

[Christopher Stock]

WebEx SSO with Microsoft AD FS 2.0

Hello All,

We are  looking forsome guidance to setup AD FS 2.0 with WebEx Online meetings and WebEx Connect,We have our AD FS 2.0 Server setup but seem to be having issues getting the SAMLAssertion to work correctly. I am hoping that someone has run across thisbefore or someone from Cisco can help as tech support doesn’t support SSO.

So far we have installed AD FS 2.0, ran the setup wizard,exported the cert, up loaded it to WebEx, edited the federation Serviceproperties name and identifier. Added that info to WebEx. Once that was done wedownloaded the xml file from WebEx and imported that info AD FS 2.0. Once therewe added the Claim rules.

Now are suck, WebEx rejects the login with the error Reason: InvalidSAML Assertion (13)

Please see attached screen shots.

Thanks

Chris

[Backendsupport]

Did you manage to get this setup?

[Christopher Stock]

Yep it works now.

Thank

Christopher Stock

Visit us online www.infiniteIT.ca

[Backendsupport]

any chance you can share the solution to the problem? I'm going to try to setup this myself. What guides did you use?

[jason.berwick]

Hi,

If anyone manages to get AD FS 2.0 allowing single sign-on to WebEx Connect using SAML 2.0 or even WS-Federation 1.0 I'd love to know how you did it! I've got WebEx Connect SSO working with AD FS 1.0 but with 2.0 it just wont play ball. The ADFS event logs seem to suggest that server is doing what it needs to, but there is no logging that I can see within the WebEx Connect admin console to see if/why it's rejecting the login attempts.

Any pointers appreciated.

Thanks

Jason

[topher1086]

We have the EXACT same setup.  Based on your screenshot, I've got my claim rules configured the EXACT same way you do.  After getting the "Invalid SAML Assertion (13)" error, I started looking for answers....  What did you have to do to get this to work?

Thanks a ton in advance...

Chris

[charles21]

We have the same setup, and I spent a week getting this working. Attached is a screenshot from Cisco support that helped me get going. Please also note that you need to create a seperate claim with the name "nameid" set to whaever AD object you used for uid in ADFS 2.0; we used Email Addresses so the second claim rule used this as well. You cannot simply add this as an additional assertion on top of the required (uid, firstname, lastname, email); it needs to be a second claim. If you need any additional help just let me know.

[twyant]

Hi Charles,

Could you post a screenshot of your rules?

Thanks!

Tom

[orbe12345]

Here is the current configuration we use for meetings/connect.

Meetings : AuthSignature and Token Encryption  is enabled

Connect : Only AuthSignature, Token Encryption is currently broken. The desktop client fails to log if enabled.

SSO is enabled for both of them (check the red rectangle for syntax, it is only available with ADFS 2.0)

To enable Token Encryption go to the Signature tab (properties relaying party trust), export the cert. Import it again  from the Encryption Tab.

Orb

[Christopher Stock · Accepted solution]

Hello All,

So I did get this to work in the end.

Here are my settings.

I have 3 rules in ADFS:

1. 1. NameID format
2. 2. Transform the incoming claim from Email to NameID (I did this instead of their solution in the ADFS2.0 Document that wants you to change a setting in all of ADFS)
3. 3. Auto User Creation rules (Doesn’t Seem to work).

Rule Screen Shots

Cisco WebEx Metting Center Properties

Federation Settings

To get the any other browser to work other than IE you will also need this

http://stackoverflow.com/questions/5436441/adfs-authentication-ie8-works-chrome-fails

In the event viewer you will see an 'Audit Failure' event with "Status: 0xc000035b". You can circumvent this problem by switching off 'Extended Protection' for the adfs/ls web application.

There are several articles on the Web on this, for example the "0xc000035b error during windows integrated login" thread on Microsoft's AD FS forum. Quoting:

To turn Extended Protection off, on the AD FS server, launch IIS Manager, then, on the left side tree view, access Sites -> Default Web Site -> adfs -> ls. Once you’ve selected the "/adfs/ls" folder, double-click the Authentication icon, then right-click Windows Authentication and select Advanced Settings… On the Advanced Settings dialog, choose Off for Extended Protection.

This issue occurs in several situations that I know of: when using Firefox 3.5+ or Chrome, using some specific NTLM configuration for which I don't have the details at hand, and when using Fiddler (see the"AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger" TechNet article post, and the "Fiddler and Channel-Binding-Tokens" blog post which contains more technical background information).

(Note that nowhere I could find any information how to make NTLM authentication to AD FS from, e.g., Google Chrome and Firefox 3.5+ work without switching off 'Extended Protection'. I mean, Internet Explorer works with 'Extended Protection', why don't Chrome or Firefox? Or is this a Chrome/Firefox implementation bug/restriction, e.g., in their use of the Windows NTLM library?)

[orbe12345]

Christopher,

You are right the only way I have found to have Chrome/Firefox to work with a login (not automatic) is to have the Extented protection off on IIS 7.0/7.5. The browser is supposed to support Kerberos (https://developer.mozilla.org/En/Integrated_Authentication) but maybe the extented protection broke that.

You may notice in this article the authors mentions NTLM pass user informations and it is considered as a weak protocol.  Since the default official client for our users is IE and automatic login was a requierement I never really digged into that problem.

Another thing that could occur is Windows 7 / IE8  with the right settings see a pop up as well and refuses to login unless you disable IWA.The solution is to remove a reg key on the client. This reg key is supposed to be only applied on Windows XP machines with a hotfix. W7/2008R2 does has that mechanism integrated.

Remove the followin key fix it.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection

More info are availble here.

Extended Protection for Authentication

http://blogs.technet.com/b/srd/archive/2009/12/08/extended-protection-for-authentication.aspx

Extended Protection for Authentication

http://support.microsoft.com/kb/968389

Orb

PS : You made your configuration complicated.I only needed a mapping of the incoming. Everything fit in one rule

[roy_cichon]

Olivier...or anyone on the thread...

I have the SSO working with WebEx Connect, but it prompts for the account password every time they initially login. I am wanting it to just pass through and log them in without prompting for a password on their account since they are already logged into their laptop.

Can anyone tell me if there is a setting I am missing to allow it to pass through?

Thanks!

Roy

[d.pennington]

make sure you're using internet explorer.  also in internet explorer there is a setting that allows to automatically pass through credentials.

[d.pennington]

1. In Internet Explorer, please go to the Tools -> Internet Options -> Advanced tab and check the “Enable Integrated Windows Authentication” check-box.

2. Next, switch to the security tab and click Local Intranet -> Custom Level and select “Automatic log-on with current user name and password” (under User Authentication, Log-on).

3. Click OK on all windows and restart Internet Explorer (close all IE windows and open it again).

[roy_cichon]

Sorry...I wasn't paying enough attention to the fact that you guys were discussing WebEx...not WebEx Connect. That is where I am having the issue. When ever the user starts WebEx Connect, the client checks SSO status, then prompts for their password.

I am not sure why it just doesn't pass through.

Any thoughts on that?

Thanks!