Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe la configuración en el proveedor de la identidad (IdP) para activar la sola muestra encendido (SSO).
Modelos de despliegue de los IdS de Cisco
Producto | Despliegue |
UCCX | Co-residente |
PCCE | Co-residente con CUIC (centro unificado Cisco de la inteligencia) y LD (datos vivos) |
UCCE | Co-residente con CUIC y el LD para las implementaciones 2k. Independiente para las implementaciones 4k y 12k. |
Cisco recomienda que tenga conocimiento sobre estos temas:
Nota: Este documento se refiere a UCCX a las capturas de pantalla y a los ejemplos, no obstante la configuración es similar en cuanto al servicio de Cisco Identitify (UCCX/UCCE/PCCE) y al IdP.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Cisco proporciona muchos servicios en diversas formas y como usuario final, usted quiere ingresar solamente una vez para tener el acceso a todos los Servicios de Cisco. Si usted quiere encontrar y manejar los contactos de la aplicación de Cisco ua de los y de los dispositivos, leveraging todas las fuentes posibles (los contactos Corporate Directory (Directorio corporativo), de la perspectiva, del móvil, Facebook, LinkedIn, historial), y las hace rendir en un campo común y una manera coherente que proporcione a la información requerida para conocer su Disponibilidad y cómo mejor entrarlas en contacto con.
SSO usando SAML (lenguaje de marcado de la aserción de la Seguridad) apunta este requisito. SAML/SSO proporciona a la capacidad para que los usuarios registren en los dispositivos múltiples y los servicios con una identidad común de la cuenta y de la autorización llamada el IdP. Las funciones SSO están disponibles en UCCX/UCCE/PCCE 11.5 hacia adelante.
Los soportes del servicio de la identidad de Cisco forman solamente la autenticación basada del proveedor de la identidad.
Refiera por favor estos artículos MSDN para aprender cómo activar la autenticación de la forma en ADFS.
Nota: El servicio 11.6 de la identidad de Cisco y arriba utiliza la autenticación y la autenticación de Kerberos basadas forma. Para que la autenticación de Kerberos trabaje, usted debe inhabilitar la forma basada autenticación.
Para onboarding y permitir a las aplicaciones utilizar el servicio de la identidad de Cisco para solo Muestra-en, realice el intercambio de los meta datos entre el servicio de la identidad (IdS) e IdP.
Éste es el procedimiento para cargar por teletratamiento los meta datos de los IdS y para agregar las reglas de la demanda. Esto se resume para ADFS 2.0 y el 3.0
Paso 1. En el servidor ADFS navegue a, comienzo > todos los programas > las herramientas administrativas > Administración FS 2.0 del ANUNCIO, tal y como se muestra en de la imagen:
Paso 2. Navegue para agregar el ANUNCIO FS 2.0 > relación de confianza > confianza de confianza del partido, tal y como se muestra en de la imagen:
Paso 3. Tal y como se muestra en de la imagen, seleccione los datos de la importación de la opción sobre el partido de confianza de un fichero.
Paso 4. Complete el establecimiento de la confianza de confianza del partido.
Paso 5. En las propiedades de la confianza de confianza del partido, seleccione el identificador cuadro.
Paso 6. Fije el identificador como el hostname calificado completamente del servidor de la identidad de Cisco del cual se descarga sp.xml.
Paso 7. Haga clic derecho en la confianza de confianza del partido y después haga clic en corrigen las reglas de la demanda.
Usted necesita agregar dos reglas de la demanda, una es cuando se corresponden con los atributos LDAP (protocolo lightweight directory access) mientras que el segundo está con las reglas de encargo de la demanda.
uid - Este atributo es necesario para que las aplicaciones identifiquen al usuario autenticado.
user_principal - Este atributo es necesitado por el servicio de la identidad de Cisco para identificar el reino del usuario autenticado.
Regla 1 de la demanda:
Agregue una regla por nombre NameID de tipo (envíe los valores del atributo LDAP como demandas):
Ejemplo de configuración cuando SamAccountName debe ser utilizado como identificación del usuario:
Ejemplo de configuración cuando UPN tiene que ser utilizado como identificación del usuario -
Ejemplo de configuración cuando PhoneNumber tiene que ser utilizado como identificación del usuario -
Nota: Necesitamos asegurarnos de que el atributo LDAP configurado para la identificación del usuario en la sincronización CUCM LDAP haga juego qué se configura como el atributo LDAP para el uid en la regla NameID de la demanda ADFS. Esto está para el funcionamiento apropiado de Cisco unificó la clave del centro (CUIC) y de la delicadeza de la inteligencia.
Nota: Este documento se refiere a los apremios en los nombres del nombre y de la visualización de la regla de la demanda tales como NameID, FQDN de UCCX, del etc. Aunque los campos y los nombres de encargo pueden ser aplicables en las diversas secciones, los nombres de la regla de la demanda y los nombres de la visualización se mantienen estándar en todas partes para mantener el estado coherente y para las mejores prácticas en la convención para nombres.
Regla 2 de la demanda:
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 Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");
Paso 8. Haga clic derecho en la confianza de confianza del partido y entonces haga clic en las propiedades y seleccione la tabulación avanzada, tal y como se muestra en de la imagen.
Paso 9. Tal y como se muestra en de la imagen, seleccione el Secure Hash Algorithm (SHA) como SHA-1.
Paso 10. AUTORIZACIÓN del tecleo.
Paso 1. En el servidor ADFS navegue a, administrador de servidor > las herramientas > Administración FS del ANUNCIO.
Paso 2. Navegue al ANUNCIO FS > relación de confianza > confianza de confianza del partido.
Paso 3. Seleccione los datos de la importación de la opción sobre el partido de confianza de un fichero.
Paso 4. Complete el establecimiento de la confianza de confianza del partido.
Paso 5. En las propiedades de la confianza de confianza del partido, seleccione el identificador cuadro.
Paso 6. Fije el identificador como el hostname calificado completamente del servidor de la identidad de Cisco del cual se descarga sp.xml.
Paso 7. Haga clic derecho en la confianza de confianza del partido y después haga clic en corrigen las reglas de la demanda.
Usted necesita agregar dos reglas de la demanda, una es cuando se corresponden con los atributos LDAP (protocolo lightweight directory access) mientras que el segundo está con las reglas de encargo de la demanda.
uid - Este atributo es necesario para que las aplicaciones identifiquen al usuario autenticado.
user_principal - Este atributo es necesitado por el servicio de la identidad de Cisco para identificar el reino del usuario autenticado.
Regla 1 de la demanda:
Agregue una regla por nombre NameID de tipo (envíe los valores del atributo LDAP como demandas):
Ejemplo de configuración cuando SamAccountName debe ser utilizado como identificación del usuario:
Ejemplo de configuración cuando UPN tiene que ser utilizado como identificación del usuario -
Ejemplo de configuración cuando PhoneNumber tiene que ser utilizado como identificación del usuario -
Nota: Necesitamos asegurarnos de que el atributo LDAP configurado para la identificación del usuario en la sincronización CUCM LDAP haga juego qué se configura como el atributo LDAP para el uid en la regla NameID de la demanda ADFS. Esto está para el funcionamiento apropiado de Cisco unificó la clave del centro (CUIC) y de la delicadeza de la inteligencia.
Nota: Este documento se refiere a los apremios en los nombres del nombre y de la visualización de la regla de la demanda tales como NameID, FQDN de UCCX, del etc. Aunque los campos y los nombres de encargo pueden ser aplicables en las diversas secciones, los nombres de la regla de la demanda y los nombres de la visualización se mantienen estándar en todas partes para mantener el estado coherente y para las mejores prácticas en la convención para nombres.
Regla 2 de la demanda:
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 Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");
Paso 8. Haga clic derecho en la confianza de confianza del partido y entonces haga clic en las propiedades y seleccione la tabulación avanzada
Paso 9. Tal y como se muestra en de la imagen, seleccione el Secure Hash Algorithm (SHA) como SHA-1.
Paso 10 - AUTORIZACIÓN del tecleo.
Estos pasos son obligatorios después del paso 10.
Paso 1. Haga clic el comienzo y ingrese el powershell al powershell de las ventanas abiertas.
Paso 2. Agregue ADFS CmdLet al powershell funcionando con el comando agregan-PSSnapin Microsoft.Adfs.Powershell.
Paso de 3 carreras el comando, conjunto-ADFSRelyingPartyTrust - Confianza <Relying Name> del partido de TargetName
- SamlResponseSignature “MessageAndAssertion”.
Nota: El paso 2 puede no ser necesario si usted está utilizando el 3.0 ADFS puesto que el CmdLet está instalado ya como parte de que agrega los papeles y las características.
Nota: La confianza <Relying Identifier> del partido es con diferenciación entre mayúsculas y minúsculas, así que hace juego (caso incluyendo) con qué se fija en la tabulación del identificador de las propiedades de confianza de confianza del partido.
Nota: Soportes del servicio SHA-1 de la identidad de Cisco. Las aplicaciones de confianza SHA-1 de la confianza del partido para firmar la petición de SAML y esperan que ADFS haga lo mismo en la respuesta.
En caso de la federación en ADFS, donde un dominio ADFS particularmente proporciona a la autenticación federada de SAML para los usuarios en otros dominios configurados, éstas son las configuraciones adicionales que son necesarias.
Para esto las secciones, el término ADFS primario refieren al ADFS que tiene que ser utilizado en los IdS. El ADFS federado término indica esos ADFS, cuyos se permite a usuarios abrirse una sesión vía los IdS y así, es el ADFS primario.
En cada uno del ADFS federado, la confianza de confianza del partido tiene que ser creada para ADFS primario y las reglas de la demanda configuradas como se menciona en la sección anterior.
Para ADFS primario, aparte de la confianza de confianza del partido para los IdS, la configuración adicional siguiente es necesaria.
Agregue la confianza del proveedor de la demanda con el ADFS al cual la federación tiene que ser puesta.
En la confianza del proveedor de la demanda, asegúrese de que el paso a través o filtre las reglas entrantes de una demanda se configuran con el paso con todos los valores de la demanda como la opción
En la confianza de confianza del partido para los IdS, agregue el paso sin embargo o filtre las reglas entrantes de una demanda con el paso con todos los valores de la demanda como la opción.
La autenticación de Windows integrada (AIT) proporciona al mecanismo para la autenticación de los usuarios, pero no permite que las credenciales sean transmitidas sobre la red. Cuando usted activa la autenticación de Windows integrada, trabaja en base de los boletos para permitir los Nodos que comunican sobre una red no-segura para probar su identidad a otra en una forma segura. Permite que los usuarios se abran una sesión a un dominio después de la clave en sus máquinas de las ventanas.
Nota: La autenticación de Kerberos se utiliza solamente a partir del 11.6 y arriba.
Registrarán a los Domain User que se registran ya en el regulador del dominio (DC) inconsútil en los clientes SSO sin la necesidad de entrar las credenciales de nuevo. Para los usuarios del no-dominio, el AIT recurre a NTLM (encargado de red de área local de la tecnología nueva) y el diálogo de la clave aparece. La calificación para los IdS con la autenticación AIT se hace con el Kerberos contra el 3.0 ADFS.
Paso 1. Ventanas abiertas comando prompt y funcionamiento como usuario Admin de registrar el servicio HTTP con el comando del setspn
setspn - <domain> del url> s http/<ADFS \ name> del <account.
Paso 2. Inhabilite la autenticación de la forma y active la autenticación de Windows para los sitios del Intranet. Vaya a la Administración > a las políticas de autenticación > a la autenticación primaria > a las configuraciones globales ADFS > corrigen. Bajo el Intranet, asegúrese de que solamente la autenticación de Windows esté controlada (Uncheck la autenticación de la forma).
Paso 1. Asegúrese de que el Internet Explorer > avanzara > autenticación de Windows integrada permiso esté controlado.
Paso 2. El URL ADFS necesita ser agregado a las zonas del >Intranet de la Seguridad > a los sitios (winadcom215.uccx116.com es URL ADFS)
Paso 3. Asegúrese de que > Security (Seguridad) de Exporer de Internet > las configuraciones > autenticación de usuario locales del > Security (Seguridad) del Intranet - el inicio se configura para utilizar las credenciales abiertas una sesión para los sitios del intranet.
Paso 1. Ingrese en el modo de la configuración para Firefox. Abra Firefox y ingrese alrededor: config en el URL. Valide la declaración de los riesgos.
Paso 2. Busque para el ntlm y active el network.automatic-ntlm-auth.allow-non-fqdn y fíjelo para verdad.
Paso 3. Fije el network.automatic-ntlm-auth.trusted-uris al dominio o explícitamente al ADFS URL.
Google Chrome en Windows utiliza las configuraciones del Internet Explorer, así que configure dentro del diálogo de opciones del >Internet de las herramientas del Internet Explorer, o del panel de control bajo opciones de Internet dentro de la red y de Internet de la subcategoría.
Este documento describe la configuración del aspecto de IdP para que SSO integre con el servicio de la identidad de Cisco. Para otros detalles, refiera a las guías de configuración de producto individual:
Este procedimiento se utiliza para determinar si la confianza de confianza del partido se establece correctamente entre los IdS de Cisco e IDP.
Nota: La página de la lista de verificación que aparece pues una parte del proceso de verificación es un no error sino una confirmación que la confianza está establecida correctamente.
Para el Troubleshooting refiera - el https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.html