topic The very first SAML SSO page in Unified Communications Infrastructure

SSO with CUCM 10.5 and ADFS 3.0

mbaker33 — Tue, 19 Mar 2019 15:47:17 GMT

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:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/administration/guide/10xcucsagx/10xcucsag112.html#32035

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");"

Mark,Try removing external

Mateusz Pagacz — Mon, 27 Oct 2014 19:40:33 GMT

Mark,

Try removing external quotes. My test rule, albeit for AD FS 2.0, looks like this:

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, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =

"urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =

"http://dc.example.local/adfs/com/adfs/service/trust",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =

"cucm.example.local");

-Mateusz

I had tried it without the

mbaker33 — Mon, 27 Oct 2014 21:25:09 GMT

I had tried it without the Quotes before, but something with your formatting is different, because it worked after updating server information!! Thank you very much Mateusz!

Edit:

I think I spoke too soon. When running the SSO test, I get "Error while processing SAML Response." in the results window. I can see that the login was successful on the ADFS server, however, it doesn't seem right on the CUCM server.

Mark

Mark,I'm not sure if you got

Joshua Warcop — Mon, 29 Dec 2014 22:27:00 GMT

Mark,

I'm not sure if you got this worked out but this can be related to a different entityID being used with ADFS 3.0. The correct entityID can be found in the downloaded FederationMetadata.xml from your server https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml

Open that XML file and copy the entityID "https://adfs.domain.com/adfs/services/trust" to the location in the custom claim rule for namequalifier.

Previous rules may look like "http://adfs.domain.com/adfs/com/adfs/service/trust”.

So the updated would look like this -

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, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =

"urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =

"https://adfs.domain.com/adfs/services/trust",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =

"cucm.example.local");

I thought you were going to

mbaker33 — Mon, 05 Jan 2015 16:54:43 GMT

I thought you were going to be the hero. I checked and found that the line in question was indeed wrong. I adjusted it, and it had no affect at all. Back to the drawing board....

Edit:

Also, if I test it from the ADFS test site https://adfs.domain.com/adfs/ls/idpinitiatedsignon, I can sign into ADFS fine, but when signing into the CUCM service, I get "The re-direction url is not available in saml response." which seems like a CUCM issue, but I can't say 100%.

Thanks,

Mark

That is still correct because

Joshua Warcop — Tue, 06 Jan 2015 20:16:18 GMT

That is still correct because signing into ADFS first and selecting the CUCM site will fail. You have to go to the CUCM web page and click the link from there.

Are you doing the "Run SSO Test" from the SAML SSO configuration page?

Yes, I am. I assumed that

mbaker33 — Tue, 06 Jan 2015 20:32:13 GMT

Yes, I am. I assumed that was the case, and wasn't terribly concerned. I received a response from TAC indicating he is seeing ‘SSO metadata test time out’ in the logs. He sent me the steps to go through the SAML Single Sign-On Configuration, which I had been doing already.

I bumped the logging to debug level, and got the following error in the log:

2015-01-06 15:20:35,715 ERROR [http-bio-443-exec-236] authentication.SAMLAuthenticator - Error while processing saml responseInvalid Status code in Response.

com.sun.identity.saml2.common.SAML2Exception: Invalid Status code in Response.

at com.sun.identity.saml2.common.SAML2Utils.verifyResponse(SAML2Utils.java:418)

at com.sun.identity.saml2.profile.SPACSUtils.processResponse(SPACSUtils.java:1051)

at com.sun.identity.saml2.profile.SPACSUtils.processResponseForFedlet(SPACSUtils.java:2108)

at com.cisco.cpi.sso.saml.sp.security.authentication.SAMLAuthenticator.processResponse(SAMLAuthenticator.java:74)

at com.cisco.cpi.sso.saml.sp.security.authentication.SAMLAuthenticator.process(SAMLAuthenticator.java:58)

at com.cisco.cpi.sso.saml.sp.security.filter.SamlFilter.doFilter(SamlFilter.java:63)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)

at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:341)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:744)

What browser are you using to

Joshua Warcop — Tue, 06 Jan 2015 20:34:12 GMT

What browser are you using to sign into CUCM and is your browser automatically signing you into ADFS during the redirect?

I have tried IE, Chrome and

mbaker33 — Tue, 06 Jan 2015 20:36:12 GMT

I have tried IE, Chrome and Firefox and they all have the same behavior. On initially attempts, I am prompted for credentials. On each subsequent attempt, it caches the credentials unless I close out of the browser session and start a new one.

Are you expecting it to

Joshua Warcop — Tue, 06 Jan 2015 20:39:11 GMT

Are you expecting it to prompt for credentials? If your machine is on the same domain as the ADFS server you shouldn't be getting a password prompt. That somewhat defeats the purpose of SSO if you have to enter credentials. If you're in IE make sure you have adfs.domain.com or your domain in your Local Intranet sites list. Chrome shouldn't be prompting you for credentials either if you're domain joined and you can reach a domain controller.

That is exactly what I was

mbaker33 — Tue, 06 Jan 2015 20:54:38 GMT

That is exactly what I was thinking, but wasn't 100% sure. I am on the same domain (although, on different subnet), and should not be getting prompted.

Another thing I just noticed that seems odd... Look at the attached image and see the arrow pointing out what seems to be an invalid URL? I'm grasping at straws here....

Also, since adding the site to trusted sites, i no longer am prompted for credentials, it just fails. I assume that's a step in the right direction.

Interesting. Are you

Joshua Warcop — Tue, 06 Jan 2015 20:55:39 GMT

Interesting. Are you accessing your CUCM server via FQDN in your browser? Something like https://cucm1.domain.com and is your certificate valid?

We use an internal CA for the

mbaker33 — Tue, 06 Jan 2015 21:05:06 GMT

We use an internal CA for the certificates, and it does not prompt for authenticity. I've also added the FQDN of the CUCM to the intranet sites list. No change thus far.

Have you also checked the

Joshua Warcop — Tue, 06 Jan 2015 21:20:16 GMT

Have you also checked the "spnamequalifer" in your custom claim rule? You can find the value needed here from your downloaded "SPMetadata.zip" file that you download from CUCM. Open the XML file for your node and make sure the entityID matches between that XML file and your custom claim.

I had checked the ADFS XML,

mbaker33 — Tue, 06 Jan 2015 21:27:32 GMT

I had checked the ADFS XML, but for some reason not the one coming from CUCM. Verified they were the same just now (they were) tried again for kicks, no dice.

I'm not sure if it matters, but the actual servername is not ADFS, I created the ADFS name specifically for ADFS to use per best practice. I'm wondering if that has something to do with it. I just can't figure out where that would be. But, then again, SAML works when using the TEST URL.

Hi,i have exactly same issue.

thorstenn — Wed, 07 Jan 2015 14:04:46 GMT

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?

No, mine seems to fail almost

mbaker33 — Wed, 07 Jan 2015 14:09:53 GMT

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.

I fixed the Problem.For me it

thorstenn — Wed, 07 Jan 2015 14:59:00 GMT

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:

2015-01-07 15:28:17,924 ERROR [http-bio-443-exec-180] authentication.SAMLAuthenticator - Error while processing saml responseInvalid SAML Response. SAMLResponse is outside the validity window.
com.sun.identity.saml2.common.SAML2Exception: Invalid SAML Response. SAMLResponse is outside the validity window.

Check your time on CUCM and ADFS Server, maybe ist the same.

Our servers are within a

mbaker33 — Wed, 07 Jan 2015 15:11:09 GMT

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.

When you're on the SAML SSO

Joshua Warcop — Wed, 07 Jan 2015 15:33:10 GMT

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.