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.
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.
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.
So I did get this to work in the end.
Here are my settings.
I have 3 rules in ADFS:
- 1. NameID format
- 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. Auto User Creation rules (Doesn’t Seem to work).
Rule Screen Shots
Cisco WebEx Metting Center Properties
To get the any other browser to work other than IE you will also need this
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?)
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.
More info are availble here.
Extended Protection for Authentication
Extended Protection for Authentication
PS : You made your configuration complicated.I only needed a mapping of the incoming. Everything fit in one rule
Sorry to ressurect an older thread, but I'm curious if any of you were able to get this working using an ADFS 2.0 Proxy server. It works great while on the internal LAN, but externally, when going through the proxy server, I'm stilling getting the invalid SAML assertion error from WebEx. My understanding is that the proxy server simply forwards and does not modify the claim, but I'm wondering if I might have to set up an additional claim rule for the proxy server.