Configuración de SAML SSO en Cisco Unified Communications Manager con ADFS 3.0

Introducción

Este documento describe los pasos para configurar el inicio de sesión único con el servicio de federación de Active Directory (ADFS 3.0) con el uso de Windows 2012 R2 en los productos Cisco Unified Communication Manager (CUCM), Cisco Unity Connection (CUC) y Expressway. Los pasos para configurar Kerberos también se incluyen en este documento.

Prerequisites

Requirements

Cisco recomienda que conozca los productos Single Sign-On (SSO) y Windows.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• CUCM 11.5
• CUC 11.5
• Expressway 12
• Servidor Windows 2012 R2 con estas funciones:
• Servicios de certificados de Active Directory
• Servicios de federación de Active Directory

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Comprobación previa de la configuración

Antes de instalar ADFS3, estas funciones de servidor ya deben existir en el entorno:

· Domain Controller y DNS

· Todos los servidores deben agregarse como registros A junto con su registro de puntero (un tipo de registro DNS que resuelve una dirección IP en un dominio o nombre de host)

A Records

En fhlab.com. se han agregado los hosts cmpubhcsc, cmsubhcsc, cucpubhcsc, cucsubhcsc, expwyc, expwye, impubhcsc e imsubhcsc.

Registros de puntero (PTR)

Se necesitan registros SRV para Jabber Discovery Services

• CA raíz (suponiendo que los certificados sean Enterprise CA-signed)

Es necesario crear una plantilla de certificado basada en la plantilla de certificado de servidor Web, la primera se duplica, se cambia el nombre y, en la ficha Extensiones, se modifican las políticas de aplicación agregando una política de aplicación de autenticación de cliente. Esta plantilla es necesaria para firmar todos los certificados internos (CUCM, CUC, IMP y núcleo de Expressway) en un entorno LAB, la CA interna también puede firmar las solicitudes de firma de certificados (CSR) de Expressway E.

La plantilla creada debe emitirse para poder firmar CSR.

En la Web de certificados de CA, seleccione la plantilla que se ha creado anteriormente.

CUCM, IMP y CUC Multi-Server CSR deben ser generados y firmados por la CA. El propósito del certificado debe ser tomcat.

El certificado raíz de la CA debe cargarse en Tomcat Trust y el certificado firmado en tomcat.

• IIS

Si no es así, esta sección atravesará la instalación de estas funciones. De lo contrario, omita esta sección y continúe directamente con la descarga de ADFS3 de Microsoft.

Después de instalar Windows 2012 R2 con DNS, promueva el servidor a un controlador de dominio.

La siguiente tarea será instalar Microsoft Certificate Services.

Navegue hasta Administrador de servidores y agregue una nueva función:

Seleccione la función Servicios de certificados de Active Directory. 

E implemente estos servicios - Certificate Authority Certificate Enrollment Policy Web Service primero. Después de instalar esas dos funciones, configúrelas e instale Servicio Web de Inscripción de Certificados y Inscripción Web de Autoridad de Certificados. Configurarlos. 

También se agregarán servicios de rol y funciones adicionales requeridos, como IIS, cuando se instale la Autoridad de certificación.

En función de la implementación, puede seleccionar Empresa o Independiente.

  

Para el tipo de CA, puede seleccionar CA raíz o CA subordinada. Si no hay otra CA en ejecución en la organización, seleccione CA raíz.

El siguiente paso es crear una clave privada para su CA.

Este paso sólo es necesario si instala el ADFS3 en un Windows Server 2012 independiente. Después de configurar la CA, es necesario configurar los servicios de función para IIS. Esto es necesario para la inscripción Web en la CA. Para la mayoría de las implementaciones de ADFS, una función adicional en IIS, haga clic en ASP.NET en Desarrollo de aplicaciones.

En Administrador de servidores, haga clic en Servidor Web > IIS y, a continuación, haga clic con el botón secundario en Sitio Web predeterminado. El enlace debe cambiarse para permitir también HTTPS además de HTTP. Esto se hace para admitir HTTPS. 

Seleccione Editar enlaces.  

Agregue un nuevo enlace de sitio y seleccione HTTPS como tipo. Para el certificado SSL, elija el certificado de servidor que debe tener el mismo FQDN que su servidor AD. 

Todos los roles previos se instalan en el entorno, por lo que ahora puede continuar con la instalación de ADFS3 Active Directory Federation Services (en Windows Server 2012). 

Para la función de servidor, navegue hasta Administrador de servidores > Administrar > Agregar funciones y características de servidor y luego seleccione Servicios de federación de directorios activos si instala el IDP dentro de la red del cliente, en la LAN privada. 

Una vez finalizada la instalación, puede abrirla desde la barra de tareas o desde el menú de inicio. 

Configuración inicial de ADFS3

Esta sección atravesará la instalación de un nuevo servidor de federación independiente, pero también se puede utilizar para instalarlo en un controlador de dominio 

Seleccione Windows y escriba AD FS Management para iniciar la consola de administración de ADFS como se muestra en la imagen.

Seleccione la opción Asistente de configuración del servidor de federación AD FS 3.0 para iniciar la configuración del servidor ADFS. Estas capturas de pantalla representan los mismos pasos en AD FS 3.

Seleccione Create a new Federation Service y haga clic en Next.

Seleccione Servidor de federación independiente y haga clic en Siguiente como se muestra en la imagen.

En el certificado SSL, seleccione el certificado autofirmado de la lista. El nombre del servicio de federación se rellenará automáticamente. Haga clic en Next (Siguiente).

Revise la configuración y haga clic en Siguiente para aplicar la configuración. 

Confirme que todos los componentes se han completado correctamente y haga clic en Cerrar para finalizar el asistente y volver a la consola de administración principal. Esto puede tardar unos minutos.

Ahora, ADFS está habilitado y configurado como proveedor de identidad (IdP). A continuación, debe agregar CUCM como partner de confianza. Antes de poder hacer esto, primero debe realizar alguna configuración en CUCM Administration. 

Configuración de SSO en CUCM con ADFS

Configuración LDAP

El clúster debe estar integrado LDAP con Active Directory y la autenticación LDAP debe configurarse antes de continuar. Navegue hasta la pestaña Sistema > Sistema LDAP como se muestra en la imagen.

A continuación, navegue hasta ficha Sistema > Directorio LDAP.

Una vez que los usuarios de Active Directory se han sincronizado con CUCM, se debe configurar la autenticación LDAP.

Un usuario final de CUCM debe tener determinados grupos de control de acceso asignados a su perfil de usuario final. El ACG es superusuarios de CCM estándar. El usuario se utilizará para probar SSO cuando el entorno esté listo.

Metadatos de CUCM

En esta sección se muestra el proceso del editor de CUCM.

La primera tarea es obtener los metadatos de CUCM, para lo cual debe buscar la URL; https://<CUCM Pub FQDN>:8443/ssosp/ws/config/metadatos/sp o se puede descargar desde la ficha System > SAML Single Sign-on. Esto se puede hacer por nodo o por clúster. Es preferible hacer esto en todo el clúster.

Guarde los datos localmente con un nombre significativo como sp_cucm0a.xml, lo necesitará después.

Configuración de la persona que confía en ADFS

Vuelva a la consola de administración de AD FS 3.0.

Haga clic en el Asistente para agregar confianza de terceros.

Haga clic en Inicio para continuar.  

Seleccione el archivo XML de metadatos federationmedatada.xml que guardó anteriormente y haga clic en Siguiente.

Utilice CUCM_Cluster_Wide_Relying_Party_trust como nombre para mostrar y haga clic en Siguiente.

Seleccione la primera opción y haga clic en Siguiente.

Seleccione Permitir que todos los usuarios accedan a esta persona de confianza y haga clic en Siguiente como se muestra en la imagen.

Revise la configuración y haga clic en Next como se muestra en la imagen.

Desactive la casilla y haga clic en Cerrar. 

Con el botón secundario del ratón, seleccione la configuración Confianza en el usuario que acaba de crear y Editar reglas de reclamación, como se muestra en la imagen.

Haga clic en Agregar regla como se muestra en la imagen. 

Seleccione Enviar atributos LDAP como justificantes y haga clic en Siguiente.

Configure estos parámetros:

Nombre de regla de reclamación: ID de nombre 

Almacén de atributos: Active Directory (doble clic en la flecha del menú desplegable)

Atributo LDAP: SAM-Account-Name 

Tipo de reclamación saliente: uid 

Haga clic en FINISH/OK para continuar.

Tenga en cuenta que uid no se encuentra en minúsculas y no existe ya en el menú desplegable. Escriba.

Haga clic en Agregar regla de nuevo para agregar otra regla.

Seleccione Enviar justificantes de venta mediante una regla personalizada y haga clic en Siguiente.

Cree una regla personalizada llamada Clúster_Side_Claim_Rule.

Copie y pegue este texto en la ventana de reglas directamente desde aquí. A veces, los presupuestos se cambian si se editan en un editor de texto y eso hará que la regla falle cuando se prueba 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");

Haga clic en Finalizar para continuar.

Ahora debe tener dos reglas definidas en ADFS. Haga clic en Aplicar y Aceptar para cerrar la ventana de reglas.

CUCM se ha agregado correctamente como parte de confianza a ADFS.

Antes de continuar, reinicie el servicio ADFS. Vaya a Menú Inicio > Herramientas administrativas > Servicios.

Metadatos de IDP

Debe proporcionar a CUCM información sobre nuestro IdP. Esta información se intercambia mediante metadatos XML. Asegúrese de realizar este paso en el servidor donde está instalado ADFS.

En primer lugar, debe conectarse a ADFS (IdP) mediante un navegador Firefox para descargar los metadatos XML. Abra un explorador en https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml y GUARDE los metadatos en una carpeta local.

Ahora, vaya a la configuración de CUCM al menú del sistema > menú SAML Single Sign-On.

Vuelva a la administración de CUCM y seleccione SYSTEM > SAML Single Sign-On.

Seleccione Enable SAML SSO.

Haga clic en Continuar para aceptar la advertencia.

En la pantalla SSO y haga clic en Browse. para importar el archivo XML de metadatos FederationMetadata.xml que guardó anteriormente, como se muestra en la imagen.

Seleccione el archivo XML y haga clic en Abrir para cargarlo en CUCM desde las Descargas bajo Favoritos. 

Una vez cargado, haga clic en Importar metadatos IdP para importar la información de IdP a CUCM. Confirme que la importación se ha realizado correctamente y haga clic en Next (Siguiente) para continuar.

Seleccione el usuario que pertenece a los superusuarios de CCM estándar y haga clic en RUN SSO TEST.

Cuando se presenta con un cuadro de diálogo de autenticación de usuario, inicie sesión con el nombre de usuario y la contraseña adecuados.

Si todo se ha configurado correctamente, debería ver un mensaje que dice SSO Test Succeeded (Prueba de SSO satisfactoria).

Haga clic en CERRAR y FINALIZAR para continuar. 

Hemos completado con éxito las tareas de configuración básicas para habilitar SSO en CUCM mediante ADFS. 

Configuración de SSO en CUC

Se puede seguir el mismo proceso para habilitar SSO en Unity Connection.

Integración de LDAP con CUC.

Configuración de la autenticación LDAP.

Importe los Usuarios de LDAP que tendrán asignado el buzón de voz y también el usuario que servirá para probar SSO.

Navegue hasta Usuarios > Editar > Funciones como se muestra en la imagen.

Asigne al usuario de prueba la función de administrador del sistema.

Metadatos CUC

Ya debería haber descargado los metadatos CUC, creado el FiyingPartyTrust para CUC y cargado los metadatos CUC y creado las reglas I AD FS en ADFS 3.0

Vaya a Inicio de sesión único SAML y active SAML SSO.

Configuración de SSO en Expressway

Importar metadatos a Expressway C

Abra un explorador en https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml y GUARDE los metadatos en una carpeta local

Cargar en Configuración > Unified Communications > IDP.

Exportar metadatos de Expressway C

Vaya a la configuración -> Unified Communications -> IDP -> Exportar datos SAML

El modo de clúster utiliza un certificado autofirmado (con una duración prolongada) que se incluye en el SAML

metadatos y utilizados para firmar solicitudes SAML

• En el modo de todo el clúster, para descargar el único archivo de metadatos de todo el clúster, haga clic en Descargar

• En el modo por peer, para descargar el archivo de metadatos de un peer individual, haga clic en Descargar junto al par. Para exportar todo en un archivo .zip, haga clic en Descargar todo.

Adición de confianza de una persona que confía en Cisco Expressway-E

En primer lugar, cree Confianzas de Parte Confiable para Expressway-Es y, a continuación, agregue una regla de reclamación para enviar la identidad como atributo UID.

OAuth con actualización de inicio de sesión

En Cisco CUCM Enterprise Parameters, se habilita el parámetro Verify OAuth with Refresh login flow . Vaya a Administración de Cisco Unified CM > Parámetros empresariales > Configuración de SSO y OAuth.

Ruta de autenticación

• Si la ruta de autenticación se establece en "autenticación SAML SSO", sólo los clientes Jabber que utilicen un clúster de Unified CM habilitado para SSO podrán utilizar MRA en este Expressway. Esta es una configuración sólo de SSO. 
• La compatibilidad con MRA de Expressway para todos los teléfonos IP, todos los terminales de TelePresence y cualquier cliente Jabber que se aloje en un clúster de Unified CM no configurado para SSO requerirá la ruta de autenticación para incluir la autenticación de UCM/LDAP. 
• Si uno o más de los clústeres de Unified CM son compatibles con Jabber SSO, seleccione "SAML SSO y UCM/LDAP" para permitir la autenticación básica y SSO. 

Arquitectura SSO

SAML es un formato de datos abierto estándar basado en XML que permite a los administradores acceder a un conjunto definido de aplicaciones de colaboración de Cisco sin problemas después de iniciar sesión en una de esas aplicaciones. SAML SSO utiliza el protocolo SAML 2.0 para ofrecer un inicio de sesión único entre dominios y productos para las soluciones de colaboración de Cisco. 

Flujo de inicio de sesión en las instalaciones

Flujo de inicio de sesión de MRA 

OAuth

OAuth es un estándar que admite la autorización. Se debe autenticar a un usuario antes de que pueda autorizarse. El flujo de concesión de código de autorización proporciona un método para que un cliente obtenga acceso y actualice tokens para acceder a un recurso (servicios de Unified CM, IM&P, Unity y Expressway). Este flujo también se basa en la redirección y, por lo tanto, requiere que el cliente pueda interactuar con un agente de usuario HTTP (navegador web) controlado por el usuario. El cliente realizará una solicitud inicial al servidor de autorización mediante HTTPS. El servidor OAuth redirige al usuario a un servicio de autenticación. Esto puede estar ejecutándose en Unified CM o en un IdP externo si SAML SSO está habilitado. Según el método de autenticación que se utilice, se puede presentar al usuario final una vista de página web para que se autentique. (La autenticación Kerberos es un ejemplo que no mostraría una página web.) A diferencia del flujo de concesión implícito, un flujo de concesión de código de autenticación exitoso resultará en que los servidores OAuth emitan un "Código de autorización" al navegador web. Se trata de un código único de un solo uso y de corta duración que se devuelve del navegador web al cliente. El cliente proporciona este "código de autorización" al servidor de autorización junto con un secreto previamente compartido y recibe a cambio un "token de acceso" y un "token de actualización". El secreto de cliente utilizado en este paso permite al servicio de autorización limitar el uso sólo a clientes registrados y autenticados. Los tokens se utilizan para los siguientes fines: 

Access/Refresh Token

Token de acceso: Este token lo emite el servidor de autorización. El cliente presenta el token a un servidor de recursos cuando necesita acceder a los recursos protegidos en ese servidor. El servidor de recursos puede validar el token y confía en las conexiones mediante el token. (El valor predeterminado de los tokens de acceso de Cisco es de 60 minutos de duración) 

Actualizar token: El servidor de autorización vuelve a emitir este token. El cliente presenta este token al servidor de autorización junto con el secreto del cliente cuando el token de acceso ha caducado o va a caducar. Si el token de actualización sigue siendo válido, el servidor de autorización emitirá un nuevo token de acceso sin necesidad de otra autenticación. (Los tokens de actualización de Cisco tienen como valor predeterminado una duración de 60 días). Si el token de actualización ha caducado, se debe iniciar un nuevo flujo de concesión de código de autorización OAuth completo para obtener nuevos tokens. 

El flujo de concesión de código de autorización de OAuth es mejor

En el flujo de concesión implícito, el token de acceso se pasa al cliente Jabber a través de un agente de usuario HTTP (navegador). En el flujo de concesión de código de autorización, el token de acceso se intercambia directamente entre el servidor de autorización y el cliente Jabber. El token se solicita desde el servidor de autorización mediante un código de autorización único y limitado en tiempo. Este intercambio directo del token de acceso es más seguro y reduce la exposición al riesgo. 

El flujo de concesión de código de autorización OAuth admite el uso de tokens de actualización. Esto ofrece una mejor experiencia al usuario final, ya que no necesita volver a autenticarse con la misma frecuencia (de forma predeterminada, 60 días) 

Configurar Kerberos

Seleccionar autenticación de Windows

Administrador de Internet Information Services (IIS) > Sitios > Sitio Web predeterminado > Autenticación > Autenticación de Windows > Configuración avanzada.

1. Desmarque Enable Kernel-mode authentication .

2. Asegúrese de que la protección ampliada está desactivada.
   
   

ADFS admite Kerberos NTLM

Asegúrese de que AD FS versión 3.0 admita tanto el protocolo Kerberos como el protocolo NT LAN Manager (NTLM) porque todos los clientes que no son de Windows no pueden utilizar Kerberos y confían en NTLM.

En el panel derecho, seleccione Proveedores y asegúrese de que Negotiate y NTLM estén presentes en Proveedores habilitados:

Configurar Microsoft Internet Explorer

Asegúrese de que Internet Explorer > Advanced > Enable Integrated Windows Authentication esté activado.

Agregar URL de ADFS en Seguridad > Zonas de Intranet > Sitios

Agregar nombres de host de CUCM, IMP y Unity a Security > Trusted Sites

Autenticación de usuario 

Asegúrese de que Internet Explorer > Security > Local Intranet > Security Level para esta Zona > Custom Level > User Authentication - Logon > Automatic Logon in Intranet Zone.

Inicio de sesión de Jabber en SSO

No se requieren cambios de configuración para Cisco Jabber. Si Unified CM se ha configurado para utilizar SAML SSO con un IdP externo, es posible que se muestre la pantalla de inicio de sesión del IdP en lugar de la pantalla de inicio de sesión de Unified CM. 

Troubleshoot

La mayor parte de la lección aprendida fue durante la configuración de nuestro laboratorio.

Internet Explorer (IE)

Asegúrese de que puede iniciar sesión en CUCM/IM&P mediante SSO en el navegador IE como requisito previo para probar Jabber SSO.

Sitios que se agregan al IE

Haga clic en Internet Options (Opciones de Internet) del IE y vaya a la ficha Security (Seguridad). Haga clic en Local Intranet > Sites > Advanced. Agregue los sitios web a la zona (es decir, agregue FQDN de IDP al SITIO).

Problema fuera de sincronización

Si obtiene un error por no sincronizar algo como esto.

Respuesta SAML no válida. Esto puede deberse a que el tiempo no está sincronizado entre Cisco Unified Communications Manager y los servidores IDP. Verifique la configuración de NTP en ambos servidores. Ejecute "utils ntp status" desde la CLI para comprobar este estado en Cisco Unified Communications Manager. Si hay una discordancia de tiempo entre CUCM e IdP, recibe este error: "Respuesta SAML no válida". Este error puede deberse a que el tiempo está fuera de sincronización entre los servidores CUCM e IdP. Para que SAML SSO funcione, debe instalar la configuración NTP correcta y asegurarse de que la diferencia de tiempo entre las aplicaciones IdP y Unified Communications no exceda de tres segundos.

Para asegurarse de que los problemas de sincronización del servidor no afectan a sus usuarios, configure un intervalo de al menos dos minutos en el atributo "NotBefore" siguiendo las instrucciones siguientes:

• Abra su PowerShell en ADFS.

• Verifique el NotBeforeSkew actual ejecutando el siguiente comando en el PowerShell:

Get-ADFSRelyingPartyTrust -identificador de "FQDN de aplicación"

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

* El valor de NotBeforeSkew ahora debe establecerse en "3".

NOTE: También puede tener que importar los metadatos del IDP al SP (es decir, CUCM).

Revocar 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

Realice una sincronización LDAP manual o elimine el usuario de la base de datos para evitar inmediatamente que un usuario utilice Jabber. Incluso si un cliente Jabber presenta un token de acceso o actualización válido al servicio UDS en CUCM, el usuario debe estar "activo" en la base de datos de usuarios de CUCM para autenticarse.

Cambiar el parámetro Refresh Token Expiration Timer Enterprise revoca automáticamente todos los tokens de actualización emitidos por ese clúster de CUCM.

Archivo Bootstrap

Los usuarios de Jabber se dirigen a la nube de WebEx Connect para la autenticación, en lugar de a un servidor de mensajería instantánea y presencia (IM&P) en las instalaciones, o a través de Expressway (Collaboration Edge) configurado para el acceso móvil y remoto (MRA).

En el archivo Jabber-bootstrap.properties ubicado en C:\ProgramData\Cisco Systems\Cisco Jabber file we can exclude webex 

ServiceDiscoveryExcludedServices: WebEx

SSO vencido por MSIS7066

Encontramos un escenario donde el SSO falló. Al realizar una prueba de inicio de sesión SSO en CUCM en el navegador Firefox, se redirigió a IdP, se ingresaron las credenciales, pero luego CUCM mostró el siguiente error:

Código de estado no válido en respuesta. Esto puede ser causado por un error de configuración en el IDP. Verifique los registros y la configuración de IDP

Echó un vistazo al visor de eventos ADFS (es decir, IDP) en la siguiente ubicación

Visor de eventos -> Registros de aplicaciones y servicios -> AD FS -> Admin

Aquí hay un extracto del error:

Detalles de la excepción:

Microsoft.IdentityServer.RequestFailedException: MSIS7066: Error de autenticación para la solicitud. —> System.Security.SecurityException: El nombre de usuario o la contraseña son incorrectos.

Después de cavar, se supo que la credencial de administrador del controlador de dominio se cambió pero los servicios ADFS no se actualizaron

1. Abra la ventana Configuración de servicios (puede acceder a ella desde el Panel de control de Windows > Herramientas administrativas o desde el menú Inicio cuando escriba servicios).

2. Busque el servicio (Servicios de federación de Active Directory) y haga doble clic en él para abrir sus propiedades (o haga clic con el botón derecho en él y seleccione Propiedades).