10-27-2014 06:04 AM - edited 03-19-2019 08:47 AM
Hello,
We recently updated our CUCM/CUPS/CUC system to 10.5 in order to take advantage of the SSO capabilities that are now built in. All of the documentation points to ADFS 2.0, and we have an ADFS 3.0 implementation. I am trying to figure out if this is an issue with the Claims Rule code, or if CUCM simply doesn't support ADFS 3.0.
We have gone through the following links:
https://supportforums.cisco.com/video/12155556/cucm-10x-samlsso-adfs20
But we are having trouble configuring the Custom Claims Rule, we get the attached error.
The rule we are applying is as follows, but with actual server names:
"c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, Originallssuer = c.Originallssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:3.0:nameid-format: transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://adfsserver.domain.com/adfs/com/adfs/service/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "phoneservername.domain.com");"
Solved! Go to Solution.
01-07-2015 06:04 AM
Hi,
i have exactly same issue. I cant enable the SAML Single Sign-On as i came not across the "Run SSO Test" .
First time i test i got a prompt for login and than after some time i have also "Error while processing SAML Response." and the SSO Test timed out in the background.
@Mark
Could you make it run ?
Any idea someone?
01-07-2015 06:09 AM
No, mine seems to fail almost immediately. I have had a TAC case open, and it finally got escalated yesterday afternoon. I have a WebEx scheduled for noon EST today and will relay anything we find out.
My hunch is, it is something to do with certificates, or some silly misconfiguration on our end in CUCM.
01-07-2015 06:59 AM
I fixed the Problem.
For me it was a time issue. The ADFS Server was 10 minutes in the future and the CUCM was correct. :-) Thats because i tried this in LAB with no really time Server :-)
In RTMT traces (SSO_log4j) we saw this one:
01-07-2015 07:11 AM
Our servers are within a second of each other, since we use NTP. We are getting the following error in our logs.
2015-01-06 16:01:37,805 ERROR [http-bio-443-exec-276] authentication.SAMLAuthenticator - Error while processing saml responseInvalid Status code in Response.
01-07-2015 07:33 AM
When you're on the SAML SSO configuration page are your servers listed by IP address or FQDN? I'm curious if this has to do with your "System -> Server" setting. There might be a correlation between the two.
01-07-2015 07:35 AM
The very first SAML SSO page shows them with the FQDN, which seems like that would be right. I was kind of thinking the same thing as you, but changing that settings has so many more ramifications that I won't be trying it unless TAC is on the line. :)
01-07-2015 07:44 AM
Indeed. That does impact a few other things. The primary thing is to make sure all your endpoints have DNS servers and a DNS suffix search. Once the callmanager process is operating via FQDN everything needs to be able to resolve the CUCM nodes. Obviously changing it requires service restarts.
That shouldn't be directly related to what is happening between Tomcat and the browser so I was going out on a limb.
01-07-2015 12:00 PM
TAC basically suggested I use OpenAM, which isn't really an option.
The one thing they did point out is in the documentation (which is specific to OpenAM) it has a series of steps for creating a circle of trust. It was my understanding that the circle of trust was created when you go through the process of enabling SSO. Did I skip a step? Also, was there anything specific I needed to do with the CA signed certs to "enable them for SSO"? I don't think so, but that was another thing that was mentioned.
Thanks again,
Mark
01-07-2015 12:02 PM
WOW! That is a terrible suggestion since the documentation covers ADFS.
http://docwiki.cisco.com/wiki/SAML_SSO_Configure_Microsoft_Active_Directory_Federation_Services_Identity_Provider_on_Windows_Platform
Also the related links at the bottom cover ADFS configuration
01-07-2015 12:21 PM
Holy crap, apparently, I must have had something off in my claim rule despite it being accepted successfully. I copied the one from that document, and now it's working!!! THANK YOU!!!
01-07-2015 12:54 PM
Awesome!
08-09-2015 03:14 AM
Hi,
I've got the same behavior, what was the exact solution?
Thanks!
08-10-2015 05:54 AM
Our issue was with the claims rule. I followed this document, copied the claim rule and it worked perfectly.
http://docwiki.cisco.com/wiki/SAML_SSO_Configure_Microsoft_Active_Directory_Federation_Services_Identity_Provider_on_Windows_Platform
03-09-2019 09:07 AM
I have exactly the same issue, my sso is working for selfcare portal but for acess cucm administration page it asks always for credentials. Cucm is 11.0 and adfs3.0 . It Looks more certificate issue than sso issue. I dont see sso errors. Can someone help?
05-21-2015 10:23 PM
Dear All,
We are integrating CUCM 10.5 with ADFS 3.0 for SSO, while running SSO test from CUCM we are getting following error and ADFS event log attached.
Please suggest your view on this.... thanks in advance.
When we test the ADFS SSO using - https://<ADFS FQDN>/adfs/ls/IdpInitiatedSignon.aspx is working fine.
We have followed below url configuration procedure:
http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118771-configure-samlsso-00.html
http://docwiki.cisco.com/wiki/SAML_SSO_Configure_Microsoft_Active_Directory_Federation_Services_Identity_Provider_on_Windows_Platform#sthash.rlonShgn.dpuf
"
Description:
The SAML authentication request had a NameID Policy that could not be satisfied.
Requestor: ISIN2022.Domain.COM.SG
Name identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient
SPNameQualifier: ISIN2022.Domain.COM.SG
Exception details:
MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token.
Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient SPNameQualifier: ISIN2022.Domain.COM.SG. Actual NameID properties: Format: urn:oasis:names:tc:SAML:2.0:nameid−format:transientoasis:names:tc:SAML:2.0:nameid−format:transient, NameQualifier: http://adfs.Domain.com.sg/adfs/com/adfs/services/trust SPNameQualifier: ISIN2022.Domain.COM.SG, SPProvidedId: .
This request failed. "
best regards,
Naveen
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide