Configurazione di SAML SSO su Cisco Unified Communications Manager con ADFS 3.0

Introduzione

In questo documento viene descritto come configurare Single Sign-On con Active Directory Federation Service (ADFS 3.0) con l'utilizzo di Windows 2012 R2 su prodotti Cisco Unified Communications Manager (CUCM), Cisco Unity Connection (CUC) ed Expressway. In questo documento sono inoltre illustrati i passaggi per configurare Kerberos.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei prodotti Single Sign-On (SSO) e Windows.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• CUCM 11.5
• CUC 11.5
• Expressway 12
• Server Windows 2012 R2 con questi ruoli:
• Servizi certificati Active Directory
• Active Directory Federation Services

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Controllo preliminare della configurazione

Prima di installare ADFS3, è necessario che questi ruoli server esistano già nell'ambiente:

· Controller di dominio e DNS

· Tutti i server devono essere aggiunti come record A insieme al relativo record puntatore (un tipo di record DNS che risolve un indirizzo IP in un dominio o un nome host)

Record A

In fhlab.com. sono stati aggiunti gli host cmpubhcsc, cmsubhcsc, cucpubhcsc, cucsubhcsc, expwyc, expwye, impubhcsc e imsubhcsc.

Record puntatore (PTR)

I record SRV devono essere installati per i servizi di rilevamento Jabber

• CA radice (supponendo che i certificati siano firmati dall'autorità di certificazione dell'organizzazione)

È necessario creare un modello di certificato basato sul modello di certificato del server Web, il primo viene duplicato, rinominato e nella scheda Estensioni i Criteri di applicazione vengono modificati aggiungendo un criterio di applicazione per l'autenticazione client. Questo modello è necessario per firmare tutti i certificati interni (CUCM, CUC, IMP ed Expressway Core) in un ambiente LAB. La CA interna può inoltre firmare le richieste di firma del certificato (CSR) di Expressway E.

È necessario emettere il modello creato per poter firmare CSR.

Nel sito Web del certificato CA selezionare il modello creato in precedenza.

CUCM, IMP e CUC Multi-Server CSR devono essere generati e firmati dalla CA. Lo scopo del certificato deve essere tomcat.

Il certificato radice CA deve essere caricato in Tomcat Trust e il certificato firmato in Tomcat.

• IIS

In caso contrario, la sezione procederà all'installazione di questi ruoli. In caso contrario, ignorare questa sezione e procedere direttamente al download di ADFS3 da Microsoft.

Dopo l'installazione di Windows 2012 R2 con DNS, innalzare il server a controller di dominio.

La prossima operazione sarà installare Servizi certificati Microsoft.

Passare a Server Manager e aggiungere un nuovo ruolo:

Selezionare il ruolo Servizi certificati Active Directory. 

E distribuire questi servizi - Servizio Web di informazioni sulle registrazioni di certificati di Autorità di certificazione. Dopo aver installato questi due ruoli, configurarli e quindi installare Servizio Web di registrazione certificati e Registrazione Web Autorità di certificazione. Configurarle. 

Quando si installa l'Autorità di certificazione, verranno inoltre aggiunti i servizi ruolo e le funzionalità aggiuntivi necessari, ad esempio IIS.

A seconda della distribuzione, è possibile selezionare Enterprise o Standalone.

  

Per Tipo CA, è possibile selezionare CA radice o CA subordinata. Se nell'organizzazione non sono già in esecuzione altre CA, selezionare CA radice.

Il passaggio successivo consiste nella creazione di una chiave privata per la CA.

Questo passaggio è necessario solo se si installa ADFS3 in un Windows Server 2012 separato. Dopo aver configurato la CA, è necessario configurare i servizi ruolo per IIS. Questa operazione è necessaria per la registrazione Web sulla CA. Per la maggior parte delle distribuzioni ADFS, è necessario un ruolo aggiuntivo in IIS, fare clic su ASP.NET in Sviluppo applicazioni.

In Server Manager fare clic su Server Web > IIS, quindi fare clic con il pulsante destro del mouse su Sito Web predefinito. È necessario modificare il binding per consentire anche HTTPS oltre a HTTP. Questa operazione viene eseguita per supportare HTTPS. 

Selezionare Modifica associazioni.  

Aggiungere una nuova associazione sito e selezionare HTTPS come tipo. Per il certificato SSL, selezionare il certificato server che deve avere lo stesso FQDN del server AD. 

Tutti i ruoli prerequisiti sono installati nell'ambiente, quindi è possibile procedere con l'installazione di ADFS3 Active Directory Federation Services (in Windows Server 2012). 

Per il ruolo Server, passare a Server Manager > Gestisci > Aggiungi ruoli server e funzionalità e quindi selezionare Active Directory Federation Services se si installa l'IDP nella rete del cliente, nella LAN privata. 

Al termine dell'installazione, sarà possibile aprirla dalla barra delle applicazioni o dal menu Start. 

Configurazione iniziale di ADFS3

Questa sezione consente di installare un nuovo server federativo autonomo, ma può essere utilizzata anche per installarlo in un controller di dominio 

Selezionare Windows e digitare Gestione ADFS per avviare la console Gestione ADFS, come illustrato nell'immagine.

Selezionare l'opzione Configurazione guidata server federativo ADFS 3.0 per avviare la configurazione del server ADFS. Questi screenshot rappresentano gli stessi passaggi in ADFS 3.

Selezionare Crea nuovo servizio federativo e fare clic su Avanti.

Selezionare Server federativo autonomo e fare clic su Avanti, come illustrato nell'immagine.

In Certificato SSL selezionare il certificato autofirmato dall'elenco. Il nome del servizio federativo verrà popolato automaticamente. Fare clic su Next (Avanti).

Verificare le impostazioni e fare clic su Avanti per applicarle. 

Verificare che tutti i componenti siano stati completati correttamente e fare clic su Chiudi per terminare la procedura guidata e tornare alla console di gestione principale. L'operazione potrebbe richiedere alcuni minuti.

ADFS è ora effettivamente abilitato e configurato come provider di identità (IdP). Successivamente, è necessario aggiungere CUCM come Relying Partner attendibile. Prima di eseguire questa operazione, è necessario eseguire alcune operazioni di configurazione in Amministrazione CUCM. 

Configurare SSO su CUCM con ADFS

Configurazione LDAP

Il cluster deve essere integrato con LDAP con Active Directory e prima di procedere è necessario configurare l'autenticazione LDAP. Passare alla scheda Sistema > Sistema LDAP come mostrato nell'immagine.

Quindi, passare alla scheda Sistema > LDAP Directory.

Dopo la sincronizzazione degli utenti di Active Directory con CUCM, è necessario configurare l'autenticazione LDAP.

Un utente finale in CUCM deve disporre di determinati gruppi di controllo di accesso assegnati al proprio profilo utente finale. ACG è una versione standard di CCM Super Users. L'utente verrà utilizzato per eseguire il test dell'SSO quando l'ambiente è pronto.

Metadati CUCM

In questa sezione viene illustrato il processo per l'editore CUCM.

La prima attività consiste nell'ottenere i metadati CUCM, in modo da poter individuare l'URL; https://<CUCM Pub FQDN>:8443/ssosp/ws/config/metadata/sp o può essere scaricato dalla scheda Sistema > SAML Single Sign-On. Questa operazione può essere eseguita per nodo o a livello di cluster. Preferibile eseguire questa operazione a livello di cluster.

Salvare i dati localmente con un nome significativo, ad esempio sp_cucm0a.xml, che sarà necessario utilizzare in seguito.

Configura componente ADFS

Tornare alla console di gestione di AD FS 3.0.

Fare clic su Aggiunta guidata attendibilità componente.

Fare clic su Start per continuare.  

Selezionare il file XML di metadati federationmedatada.xml salvato in precedenza e fare clic su Avanti.

Utilizzare CUCM_Cluster_Wide_Relying_Party_trust come nome visualizzato e fare clic su Avanti.

Selezionare la prima opzione e fare clic su Avanti.

Selezionare Permetti a tutti gli utenti di accedere a questo componente e fare clic su Avanti, come mostrato nell'immagine.

Esaminare la configurazione e fare clic su Next (Avanti), come mostrato nell'immagine.

Deselezionare la casella e fare clic su Chiudi. 

Con il pulsante secondario del mouse, selezionare l'attendibilità componente appena creata e modificare la configurazione delle regole attestazione come mostrato nell'immagine.

Fare clic su Add Rule (Aggiungi regola) come mostrato nell'immagine. 

Selezionare Invia attributi LDAP come attestazioni e fare clic su Avanti.

Configurare i seguenti parametri:

Nome regola attestazione: IDNome 

Archivio attributi: Active Directory (fare doppio clic sulla freccia del menu a discesa)

Attributo LDAP: Nome-Account-SAM 

Tipo attestazione in uscita: uid 

Fare clic su FINISH/OK per continuare.

Si noti che l'UID non è in lettere minuscole e non esiste già nel menu a discesa. Digitalo.

Per aggiungere un'altra regola, fare nuovamente clic su Aggiungi regola.

Selezionare Invia attestazioni utilizzando una regola personalizzata e fare clic su Avanti.

Creare una regola personalizzata denominata Cluster_Side_Claim_Rule.

Copiare e incollare il testo nella finestra della regola direttamente da qui. A volte, le virgolette vengono modificate se modificate in un editor di testo e questo renderà la regola errata quando si esegue il test SSO:

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://<ADFS FQDN>/adfs/com/adfs/services/trust", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = 
"<CUCM Pub FQDN>");

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://AD.fhlab.com/adfs/services/trust", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = 
"cmpubhcsc.fhlab.com");

Fare clic su Fine per continuare.

In ADFS dovrebbero essere definite due regole. Fare clic su Apply (Applica), quindi su OK per chiudere la finestra delle regole.

CUCM è stato aggiunto come componente attendibile ad ADFS.

Prima di continuare, riavviare il servizio ADFS. Selezionare Menu Start > Strumenti di amministrazione > Servizi.

Metadati IDP

Devi fornire a CUCM informazioni sul nostro IdP. Queste informazioni vengono scambiate utilizzando metadati XML. Assicurarsi di eseguire questa operazione sul server in cui è installato ADFS.

Innanzitutto, è necessario connettersi ad ADFS (IdP) utilizzando un browser Firefox per scaricare i metadati XML. Aprire un browser in https://<FQDN ADFS>/FederationMetadata/2007-06/FederationMetadata.xml e SALVARE i metadati in una cartella locale.

Passare alla configurazione CUCM dal menu di sistema > SAML Single Sign-On.

Tornare alla pagina Amministrazione CUCM e selezionare SYSTEM > SAML Single Sign-On (SISTEMA > Single Sign-On SAML).

Selezionare Abilita SSO SAML.

Per confermare l'avviso, fare clic su Continue (Continua).

Nella schermata SSO e fare clic su Sfoglia.. per importare il file XML di metadati FederationMetadata.xml salvato in precedenza, come mostrato nell'immagine.

Selezionare il file XML e fare clic su Apri per caricarlo in CUCM dal menu Download in Preferiti. 

Una volta caricati, fare clic su Importa metadati IdP per importare le informazioni IdP in CUCM. Confermare che l'importazione è riuscita e fare clic su Avanti per continuare.

Selezionare l'utente appartenente agli utenti privilegiati CCM standard e fare clic su ESEGUI TEST SSO.

Quando viene visualizzata una finestra di dialogo di autenticazione utente, effettuare il login con il nome utente e la password appropriati.

Se tutto è stato configurato correttamente, dovrebbe essere visualizzato un messaggio che indica che il test SSO è riuscito.

Fare clic su CLOSE e FINISH per continuare. 

Le attività di configurazione di base per l'abilitazione dell'SSO su CUCM tramite ADFS sono state completate. 

Configura SSO su CUC

È possibile seguire lo stesso processo per abilitare l'SSO in Unity Connection.

Integrazione LDAP con CUC.

Configurare l'autenticazione LDAP.

Importare gli utenti da LDAP a cui verranno assegnati i messaggi vocali e l'utente che verrà utilizzato per il test dell'SSO.

Passare a Utenti > Modifica > Ruoli come mostrato nell'immagine.

Assegnare all'utente che esegue il test il ruolo di amministratore di sistema.

Metadati CUC

A questo punto è necessario scaricare i metadati CUC, creare RelyingPartyTrust per CUC e caricare i metadati CUC e creare le regole in ADFS 3.0

Andare a SAML Single Sign-On e abilitare SAML SSO.

Configura SSO su Expressway

Importa metadati in Expressway C

Aprire un browser in https://<FQDN ADFS>/FederationMetadata/2007-06/FederationMetadata.xml e SALVARE i metadati in una cartella locale

Caricare in Configuration > Unified Communications > IDP.

Esporta metadati da Expressway C

Andare alla configurazione -> Unified Communications -> IDP -> Export SAML Data (Esporta dati SAML)

La modalità cluster utilizza un certificato autofirmato (con durata prolungata) incluso nel SAML

metadati e utilizzati per firmare le richieste SAML

• In modalità cluster, per scaricare il file di metadati a livello di cluster singolo, fare clic su Scarica

• In modalità peer, per scaricare il file di metadati per un singolo peer, fare clic su Scarica accanto al peer. Per esportare tutto in un file zip, fare clic su Scarica tutto.

Aggiungi un trust della relying party per Cisco Expressway-E

Creare innanzitutto i trust della relying party per Expressway-E e quindi aggiungere una regola attestazione per inviare l'identità come attributo UID.

OAuth con accesso aggiornato

In Cisco CUCM Enterprise Parameters, Verificare OAuth con il parametro Aggiorna flusso di accesso è abilitato. Andare a Cisco Unified CM Administration > Enterprise Parameters > SSO and OAuth Configuration.

Percorso di autenticazione

• Se il percorso di autenticazione è impostato su "Autenticazione SSO SAML", solo i client Jabber che utilizzano un cluster Unified CM abilitato a SSO saranno in grado di utilizzare MRA in questo Expressway. Si tratta di una configurazione SSO only. 
• Il supporto MRA di Expressway per tutti i telefoni IP, tutti gli endpoint TelePresence e qualsiasi client Jabber ospitato in un cluster Unified CM non configurato per SSO richiederà che il percorso di autenticazione includa l'autenticazione UCM/LDAP. 
• Se uno o più cluster MCM unificato supportano SSO Jabber, selezionare "SAML SSO and UCM/LDAP" per consentire sia l'autenticazione SSO che l'autenticazione di base. 

Architettura SSO

SAML è un formato di dati basato su XML basato su standard aperti che consente agli amministratori di accedere senza problemi a un set definito di applicazioni di collaborazione Cisco dopo aver eseguito l'accesso a una di tali applicazioni. SAML SSO utilizza il protocollo SAML 2.0 per offrire Single Sign-On tra domini e prodotti diversi per le soluzioni di collaborazione Cisco. 

Flusso di login in locale

Flusso di accesso MRA 

OAuth

OAuth è uno standard che supporta l'autorizzazione. Per poter essere autorizzati, gli utenti devono essere autenticati. Il flusso di concessione del codice di autorizzazione fornisce a un client un metodo per ottenere l'accesso e aggiornare i token per accedere a una risorsa (servizi Unified CM, IM&P, Unity ed Expressway). Questo flusso è basato anche sul reindirizzamento e pertanto richiede che il client sia in grado di interagire con un agente utente HTTP (browser Web) controllato dall'utente. Il client invierà una richiesta iniziale al server di autorizzazione utilizzando HTTPS. Il server OAuth reindirizza l'utente a un servizio di autenticazione. Questa operazione può essere eseguita su Unified CM o un IdP esterno se SAML SSO è abilitato. A seconda del metodo di autenticazione utilizzato, è possibile che all'utente finale venga visualizzata una pagina Web per autenticarsi. L'autenticazione Kerberos è un esempio che non consente di visualizzare una pagina Web. A differenza del flusso di concessione implicito, un flusso di concessione del codice di autenticazione riuscito farà sì che i server OAuth emettano un "codice di autorizzazione" al browser Web. Si tratta di un codice univoco monouso di breve durata che viene quindi passato dal browser Web al client. Il client fornisce questo "codice di autorizzazione" al server di autorizzazione insieme a un segreto già condiviso e riceve in cambio un "token di accesso" e un "token di aggiornamento". Il segreto client utilizzato in questo passaggio consente al servizio di autorizzazione di limitare l'utilizzo ai soli client registrati e autenticati. I token vengono utilizzati per i seguenti scopi: 

Token di accesso/aggiornamento

Token di accesso: Token rilasciato dal server di autorizzazione. Il client presenta il token a un server delle risorse quando deve accedere alle risorse protette su tale server. Il server delle risorse è in grado di convalidare il token e considera attendibili le connessioni che utilizzano il token. (la durata predefinita dei token di accesso Cisco è di 60 minuti) 

Token di aggiornamento: Questo token viene nuovamente rilasciato dal server di autorizzazione. Il client presenta questo token al server di autorizzazione insieme al segreto client quando il token di accesso è scaduto o sta per scadere. Se il token di aggiornamento è ancora valido, il server di autorizzazione rilascerà un nuovo token di accesso senza richiedere un'altra autenticazione. Per impostazione predefinita, i token di aggiornamento Cisco hanno una durata di 60 giorni. Se il token di aggiornamento è scaduto, è necessario avviare un nuovo flusso di concessione del codice di autorizzazione OAuth completo per ottenere nuovi token. 

Il flusso di concessione del codice di autorizzazione OAuth è migliore

Nel flusso di concessione implicito, il token di accesso viene passato al client Jabber tramite un agente utente HTTP (browser). Nel flusso di concessione del codice di autorizzazione, il token di accesso viene scambiato direttamente tra il server di autorizzazione e il client Jabber. Il token viene richiesto dal server di autorizzazione utilizzando un codice di autorizzazione univoco con limiti di tempo. Questo scambio diretto del token di accesso è più sicuro e riduce l'esposizione al rischio. 

Il flusso di concessione del codice di autorizzazione OAuth supporta l'utilizzo dei token di aggiornamento. In questo modo l'utente finale può beneficiare di un'esperienza migliore, poiché non deve eseguire la nuova autenticazione con la stessa frequenza (per impostazione predefinita 60 giorni) 

Configura Kerberos

Seleziona autenticazione di Windows

Gestione Internet Information Services (IIS) > Siti > Sito Web predefinito > Autenticazione > Autenticazione di Windows > Impostazioni avanzate.

1. Deselezionare Attiva autenticazione in modalità kernel.

2. Assicurarsi che la protezione estesa sia disattivata.
   
   

ADFS supporta sia Kerberos che NTLM

Verificare che AD FS versione 3.0 supporti sia il protocollo Kerberos che il protocollo NTLM (NT LAN Manager), poiché tutti i client non Windows non possono utilizzare Kerberos e si basano su NTLM.

Nel riquadro di destra, selezionare Provider e assicurarsi che Negotiate e NTLM siano presenti in Provider abilitati:

Configurare Microsoft Internet Explorer

Verificare che Internet Explorer > Avanzate > Abilita autenticazione integrata di Windows sia selezionato.

Aggiungi URL ADFS in Protezione > Aree Intranet > Siti

Aggiungi nomi host CUCM, IMP e Unity a Protezione > Siti attendibili

Autenticazione utente 

Verificare che Internet Explorer > Protezione > Intranet locale > Livello di protezione per l'area > Livello personalizzato > Autenticazione utente - Accesso > Accesso automatico nell'area Intranet.

SSO accesso Jabber

Non sono necessarie modifiche alla configurazione di Cisco Jabber. Se Unified CM è stato configurato per utilizzare SAML SSO con un IdP esterno, è possibile che venga visualizzata la schermata di accesso dell'IdP anziché quella di Unified CM. 

Risoluzione dei problemi

La maggior parte delle lezioni apprese sono state durante la configurazione del nostro laboratorio.

Internet Explorer

Accertarsi di poter accedere a CUCM/IM&P utilizzando SSO nel browser IE come prerequisito per testare l'SSO Jabber.

Siti da aggiungere a IE

Fare clic su Opzioni Internet in Internet Explorer e selezionare la scheda Protezione. Fare clic su Intranet locale > Siti > Avanzate. Aggiungere i siti Web all'area (ad esempio, aggiungere FQDN IDP al SITO).

Problema non sincronizzato

Se si riceve un errore per non sincronizzato qualcosa come questo.

Risposta SAML non valida. Ciò può verificarsi quando il tempo non è sincronizzato tra Cisco Unified Communications Manager e i server IDP. Verificare la configurazione NTP su entrambi i server. Eseguire "utils ntp status" dalla CLI per verificare questo stato su Cisco Unified Communications Manager. In caso di mancata corrispondenza tra CUCM e IdP, viene visualizzato il seguente messaggio di errore: "Risposta SAML non valida." Questo errore potrebbe essere causato da un tempo di sincronizzazione non corretto tra i server CUCM e IdP. Affinché SAML SSO funzioni, è necessario installare la corretta configurazione NTP e assicurarsi che la differenza di tempo tra l'IdP e le applicazioni Unified Communications non superi i tre secondi.

Per garantire che gli utenti non siano interessati da problemi di sincronizzazione del server, impostare uno sfasamento di almeno due minuti sull'attributo "NotBefore" seguendo le istruzioni:

• Aprire PowerShell in ADFS.

• Controllare il NotBeforeSkew corrente eseguendo il comando seguente in Powershell:

Get-ADFSRelyingPartyTrust - identificatore "FQDN applicazione"

Get-ADFSRelyingPartyTrust - identificatore "cmpubhcsc.fhlab.com" 

* NotBeforeSkew deve essere impostato su "3".

NOTA: È inoltre possibile importare i metadati dall'IDP all'SP (ad esempio CUCM).

Revoca un token 

https://
     
     
       :8443/ssosp/token/revoke?user_id= 
       
     

https://10.89.228.146:8443/ssosp/token/revoke?user_id=farfar

{"revoked_tokens":{"status":"success","user_id":"farfar","clientID_tokens":
[{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"fa8ff04aabb4a40bc493f810f9fff09a8f735d24fb05df7c9191f294611710a3"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"9ecf6a5092f1167df085f018320e2135b487f585b9cbb3e59474a0643f1a961f"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"30ab864ce41c78b9b4324a46f865dd47add4b16d7717986d715405496119bc87"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"33d025dd7b88fefe99173757a54ada771821d763a23b71cc9ca233e1c91ffd65"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"a5f0d293d3dbbbe4ef1af9379a78df04ed9a168c450de42982e3796cef758c0f"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"252912f2af65346f7ec2887505aef7d0ee2cd918f0253662b9b53ebf45e490e8"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"28c33fcbbc4d47bc6d658855f0699bbe1b3c264c0ed7a04eedc578f6b89fd4de"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"cb5269c40cdf4cc4e2e0a0f520d719851f132691d609ffe65c143952a3f7d2d7"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"acd338a0858c8f140866962e1150bcfd1768b3d8fd959700ed70ea5bff571e83"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"3acee9b52c039e58a0be060c20b8134aea5445ba141d6daedc9fb2366e0eb4d0"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"4a4ac2e56c4663ff20797228b3e67511a56ae3fd1f831303df3642206f8a9742"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"db9ae2351f51e85a01a0dc64b35fa75f052eaa6b3793a29f9dfdb86d589dc97a"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"1118b7fbcaa407541dc8e21ed70ccc581f3e7f58a31fdb94c637d7ac1279a6b8"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"2f33962f1671acc9c7acfb6cff6dff3d9ddf7e2df0a5d7747020347c08e8f18a"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"70a46c24974499c1f87b1b167795c4654460e665f2f5f1696b0a93e2887ae442"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"c05fb1c913a0cbd2984d370365d085ad8315b916a5651511401a695d17129584"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"47ba99793ededfe1cba3f0b83a2738c0a79f1833979ad3c6c362291f92f8fdf8

Eseguire una sincronizzazione LDAP manuale o eliminare l'utente dal database per impedire immediatamente all'utente di utilizzare Jabber. Anche se un client Jabber presenta un token di accesso o di aggiornamento valido al servizio UDS su CUCM, l'utente deve essere "attivo" nel database utenti CUCM per essere autenticato.

La modifica del parametro Enterprise del timer di scadenza del token di aggiornamento comporta la revoca automatica di tutti i token di aggiornamento rilasciati dal cluster CUCM.

File bootstrap

Gli utenti Jabber vengono indirizzati al cloud WebEx Connect per l'autenticazione, anziché a un server IM&P (Instant Messaging and Presence) locale o tramite un Expressway (Collaboration Edge) configurato per l'accesso remoto e mobile (MRA).

Nel file Jabber-bootstrap.properties, disponibile in C:\ProgramData\Cisco Systems\Cisco Jabber, è possibile escludere webex 

ServiziIndividuazioneEsclusi: Webex

Errore SSO dovuto a MSIS7066

In uno scenario di errore dell'SSO, Quando si esegue un test di accesso SSO a CUCM sul browser Firefox, viene reindirizzato a IdP, vengono immesse le credenziali, ma CUCM visualizza il seguente errore:

Codice di stato non valido nella risposta. Ciò può essere causato da un errore di configurazione nell'IDP. Controllare i registri e la configurazione di IDP

Osservare il Visualizzatore eventi ADFS (IDP) nella posizione seguente

Visualizzatore eventi -> Registri applicazioni e servizi -> AD FS -> Amministrazione

Di seguito è riportato un estratto dell'errore:

Dettagli eccezione:

Microsoft.IdentityServer.RequestFailedException: MSIS7066: Autenticazione non riuscita per la richiesta. —> System.Security.SecurityException: Nome utente o password non corretta.

Dopo l'operazione di scavo è stato rilevato che le credenziali amministrative del controller di dominio sono state modificate ma i servizi ADFS non sono stati aggiornati

1. Aprire la finestra Configurazione servizi, accessibile dal Pannello di controllo di Windows > Strumenti di amministrazione o dal menu Start quando si digitano i servizi.

2. Individuare il servizio (Active Directory Federation Services) e fare doppio clic su di esso per aprirne le proprietà oppure fare clic con il pulsante destro del mouse sul servizio e scegliere Proprietà.