Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

SSO with CUCM 10.5 and ADFS 3.0

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

 

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

WOW! That is a terrible

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

 

 

28 REPLIES
Cisco Employee

Mark,Try removing external

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

 

New Member

I had tried it without the

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

New Member

Mark,I'm not sure if you got

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

New Member

I thought you were going to

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

New Member

That is still correct because

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?

New Member

Yes, I am.  I assumed that

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)

New Member

What browser are you using to

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

New Member

I have tried IE, Chrome and

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.

New Member

Are you expecting it to

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.

New Member

That is exactly what I was

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.

New Member

Interesting. Are you

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

New Member

We use an internal CA for the

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.

New Member

Have you also checked the

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.

New Member

I had checked the ADFS XML,

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.

New Member

Hi,i have exactly same issue.

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?

New Member

No, mine seems to fail almost

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.

New Member

I fixed the Problem.For me it

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.
New Member

Our servers are within a

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.

New Member

When you're on the SAML SSO

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.

New Member

The very first SAML SSO page

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.  :)

New Member

Indeed. That does impact a

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.

New Member

TAC basically suggested I use

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

New Member

WOW! That is a terrible

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

 

 

New Member

Holy crap, apparently, I must

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!!!

New Member

Awesome! 

Awesome!
 

New Member

Hi,I've got the same behavior

Hi,

I've got the same behavior, what was the exact solution?

Thanks!

 

 

New Member

Our issue was with the claims

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

 

Dear All, We are integrating

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

7220
Views
15
Helpful
28
Replies
CreatePlease login to create content