SSO for CUIC 11.6 Enablement

[SEAN NILSEN]

I am wondering what secret sauce anyone has for enabling SSO Users in CUIC 11.6.

I am doing a fresh install. SSO for Finesse is working 100% AOK; I can login with SSO Creds all day long.

My IDS (Co-resident CUIC, LD, IDS) also reports in Test that both Finesse and CUIC are "green checkmark" and is in Hybrid mode.

My problem at this point is that I am clearly missing a step somewhere that says: "This is how to let CUIC know that a User is SSO enabled" because I've tried CLI and a few other things to get an AD user to be able to sign-in but it just doesn't seem to want to go.

I have NOT set the AD Params in CUIC because I believe from the docs that I've read that this is unnecessary when using SSO.

Any suggestions?

===Edit 1===

To clarify the issue slightly, in the CUIC Users drawer, I can see that my Supervisor and Agent users appear there. 

The appropriate users have the SSO Enabled checkbox shown as checked (and greyed out).

When I attempt to login as these users, the username that successfully triggers an SSO login redirect in Finesse, does not produce the SSO login redirect in CUIC. 

Meaning that CUIC isn't popping the Auth correctly and continues to the "local" password prompt instead of heading off down the IdS/IdP path.

[SEAN NILSEN · Accepted solution]

Circling around on this for anyone else who has the issue. The thing I finally tried was turning everything to SSO mode. This let me login AOK with SSO Creds.

When I flipped everything back to Hybrid, both SSO and CCE and/or CUIC users can both login appropriately.

There is a weird IdS/IdP clock issue going on but that's separate.

[david.macias]

Kudos for answering your own question and actually letting the world know. +5

david

[Omar Deen]

---

@SEAN NILSEN wrote:

There is a weird IdS/IdP clock issue going on but that's separate.

---

Me and a colleague ran into clock/time issues as well. Long story short, we had a time skew issue and while it's not documented, we learned that you should use five NTP sources which can be both internal and external. For a workaround, we followed the solution from this blog post: http://rmichaelmead.com/adfs-not-before-time-skew/

Our setup was PCCE 11.6, Hybrid SSO, ADFS 3.0

[bill.king1]

Out of curiosity, was your time issue related specifically to SSO or other items like Finesse for instance in general?

[SEAN NILSEN]

Hey Bill,

It's specific to the IdS which is coresident on CUIC.

The issue appears to be that all of our machines are sync'ing to a single NTP source.

In the IdP response (ADFS 2.0 on the domain controller) I'm seeing a failure of:

2019-01-02 14:54:55.414 CST(-0600) [IdSEndPoints-SAML-13] INFO com.cisco.ccbu.ids SAML2SPAdapter.java:82 - SSO Failure response from fedlet

<...snip...>

<Conditions NotBefore="2019-01-02T20:54:55.624Z" NotOnOrAfter="2019-01-02T21:54:55.624Z">

<...snip...>

<AuthnStatement AuthnInstant="2019-01-02T20:54:55.542Z"

<snip>

This produces this error:

2019-01-02 14:54:55.414 CST(-0600) [IdSEndPoints-SAML-13]         ERROR com.cisco.ccbu.ids IdSSAMLAsyncServlet.java:302 - SAML response processing failed with exception com.sun.identity.saml2.common.SAML2Exception: The time in the Assertion's Condition is invalid.

By the rules of how SAML works, NotBefore is a time instant that says the request can not be confirmed before that time  and NotOnOrAfter is another time instant after which the subject can no longer be confirmed.

So I can see where the assertion is going sideways because its restricted to a very limited window.

I'm looking into the above suggestion of using multiple NTP sources at this time though I'm not entirely sure how that might solve it.

What I *do* know that works is rebooting the CUIC/IdS node, which allows successful responses for a period of time.

That's obviously not optimal so I am still looking for a real fix.

I believe that it may have to do with modifying the SAML response to allow a broader NotBefore value but will report back here once I confirm either of the above (NTP or NotBefore)

[SEAN NILSEN]

I can confirm at this time that changing the NotBefore to skew by 1-2 minutes resolves the clock issue.

Some Domain Admins likely won't allow this, but, I'm in a lab at the moment, so it's fine.

In any case, to account for the overly zealous lockdown of the instants involved, you can skew your NotBefore time to some other period of time besides 0 (the default).

This param isn't exposed by the ADFS GUI (at least in ADFS 2.0; unconfirmed in 3.0) so you have to use Powershell.

The relevant commands are:

List all Relying Party Trusts	Get-ADFSRelyingPartyTrust
List the specific Relying Party Trust	Get-ADFSRelyingPartyTrust -identifier <the "Identifier" you found above>
Change the NotBefore Skew	Set-ADFSRelyingPartyTrust -TargetIdentifier<the "Identifier" again> -NotBeforeSkew 2

The value is in minutes.

As soon as I changed the Skew, I hit F5 on the browser and the previously failing response was successful.

[SEAN NILSEN]

Yep, this is totally it for that issue. Very undocumented. I added some more details and the relevant logs/other commands below.

5 time sources seems overkill.

Segal's Law: A man with a watch knows what time it is. A man with two watches is never sure.

Much appreciate the pointers though.

Did you wind up using the Skew or the Multiple NTP Servers or both?

This is an article on setting up the functionality re: multiple NTP Services. I didn't use it because the skew solved it for me.

https://blogs.msdn.microsoft.com/w32time/2008/02/26/configuring-the-time-service-ntpserver-and-specialpollinterval/

I feel like using this config with SAML might confuse the issue more since it's pretty clearly some kind of latency/process time issue, IMO, instead of just a clock sync issue.