1

We have a brand new deployment going on, where our University has purchased WebEx MeetingPlace. We have the Cisco CallManager component working, but the integration with Single Sign On with ADFS 2.0 has been nothing short of torture. The biggest problem I'm working with is that we use Split-Brain DNS, and our internal domain name versus external domain name is different. Trying to determine what credentials are getting passed back and forth, certificate errors for using the self-signed certificate, etc.

Does anyone have any experience with this, or something similar? Do you have any tips, or watch-out-for-this, etc.? I've not worked with a Federated Authentication system before, and this scenario is very black-box-esque. Sorry, I'm also partially ranting as I'm frustrated.

DavisTasar
  • 174
  • 1
  • 3
  • 16

1 Answers1

0

Yes! I went through this torture a few months ago. There is a secret (well not really secret, but not easy to find) integration guide that is pretty much step-by-step. Find it here: https://support.webex.com/MyAccountWeb/knowledgeBase.do?root=Tools&parent=Knowledge&articleId=WBX63102

The best place to ask questions about this if you are having random issues is the developer community board, here: http://developer.cisco.com/web/webex-developer/forum/-/message_boards/category/4828392

smithian
  • 1,746
  • 14
  • 15
  • I appreciate your response, I've actually received this document. My problem is that it doesn't cover not using self-signed certificates, and we're running split-brain DNS, which causes problems between the SAML assertion and things like server URLs. I will, however, check out that message board, the Cisco folks tend to help me much more than my CSR. – DavisTasar Oct 18 '12 at 00:53
  • We are also using real certs and split DNS, what issues are you having? – smithian Oct 18 '12 at 06:14
  • Windows machines bound to our Active Directory domain are unable to authenticate, however, Linux boxes, Macs, and Non-Bound Windows boxes can authenticate. Edit: I should add that we're using the same credentials across all machines, and that they all reach the ADFS server and I can see their failed/success attempts in the Security Log. – DavisTasar Oct 18 '12 at 12:37
  • Sounds like you need to add an additional item to your AuthnContextClassRef value in the webex portal. You can add more than one in the field, semicolon-delimited. what does your AuthnContextClassRef value look like? – smithian Oct 18 '12 at 13:05
  • The value I have in the WebEx portal is: "urn:federation:authentication:windows" I sincerely appreciate this assistance. It's been a very trying time, and to have someone say, "Oh, it sounds like this" is just very helpful. – DavisTasar Oct 18 '12 at 13:06
  • Hmm. I would expect teh symptoms to be reversed in that case, so maybe that's not what you are running into. But you can try this anyway and see if it works: urn:federation:authentication:windows;urn:oasis:names:tc:SAML:2.0:ac:classesasswordProtectedTransport – smithian Oct 18 '12 at 13:12
  • Are you getting an "invalid SAML Assertion 13" error? – smithian Oct 18 '12 at 13:12
  • That AuthnContextClassRef reports that it's invalid. And no, it's just failed authentications. User account that is known good and working on a windows machine bound to the domain attempts to authenticate, and it fails. The Security Event log records the attempt, coming back with a NULL SID, the correct account name, and if I specified the domain (domain\username format), the domain appears. Error 0xc000035b failure reason. – DavisTasar Oct 18 '12 at 13:23
  • I've also found this article related to that error message (http://stackoverflow.com/questions/5436441/adfs-authentication-ie8-works-chrome-fails), and I've confirmed that Extended Authentication is off. – DavisTasar Oct 18 '12 at 13:31
  • If it's configured correctly, you shouldn't get the opportunity to enter credentials on the windows machines, it will just automatically log you in. I made a typo (pasteo?) on the AuthnContextClassRef, it should be urn:federation:authentication:windows;urn:oasis:names:tc:SAML:2.0:ac:classes:Passw‌​ordProtectedTransport – smithian Oct 18 '12 at 13:36
  • You're absolutely right. Turns out I had to restart the server (I restarted IIS but it didn't take effect), but when I restarted the ADFS server with the Extended Authentication turned off (mentioned in the comment above), it worked! And I don't even see the prompts for user logins. – DavisTasar Oct 18 '12 at 13:44