Configurer SAML SSO sur Cisco Unified Communications Manager avec ADFS 3.0

Introduction

Ce document décrit les étapes à suivre pour configurer l'authentification unique avec Active Directory Federation Service (ADFS 3.0) avec l'utilisation de Windows 2012 R2 sur Cisco Unified Communication Manage (CUCM), Cisco Unity Connection (CUC) et les produits Expressway. Les étapes de configuration de Kerberos sont également incluses dans ce document.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître les produits SSO (Single Sign-On) et Windows.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CUCM 11,5
• CUC 11,5
• Expressway 12
• Windows 2012 R2 Server avec les rôles suivants :
• Services de certificats Active Directory
• Services de fédération 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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Vérification préalable de la configuration

Avant d'installer ADFS3, ces rôles de serveur doivent déjà exister dans l'environnement :

Contrôleur de domaine · et DNS

· Tous les serveurs doivent être ajoutés en tant qu'enregistrements A avec leur enregistrement Pointer (type d'enregistrement DNS qui résout une adresse IP en un domaine ou un nom d'hôte)

Enregistrements A

Dans fhlab.com. hosts cmpubhcsc, cmsubhcsc, cucpubhcsc, cucsubhcsc, expwyc, expwye, impubhcsc et imsubhcsc ont été ajoutés.

Enregistrements de pointeur (PTR)

Les enregistrements SRV doivent être en place pour Jabber Discovery Services

• Autorité de certification racine (en supposant que les certificats seront signés par l'Autorité de certification d'entreprise)

Un modèle de certificat doit être créé en fonction du modèle de certificat du serveur Web, le premier est dupliqué, renommé et sous l'onglet Extensions, les stratégies d'application sont modifiées en ajoutant une stratégie d'application d'authentification du client. Ce modèle est nécessaire pour signer tous les certificats internes (CUCM, CUC, IMP et Expressway Core) dans un environnement LAB, l’autorité de certification interne peut également signer les demandes de signature de certificat (CSR) Expressway E.

Le modèle créé doit être émis pour pouvoir signer CSR.

Sur le site Web des certificats de l'Autorité de certification, sélectionnez le modèle créé précédemment.

CUCM, IMP et CUC Multi-Server CSR doivent être générés et signés par l'autorité de certification. L'objectif du certificat doit être défini.

Le certificat racine CA doit être téléchargé vers Tomcat Trust et le certificat signé vers tomcat.

• IIS

Sinon, cette section va passer par l'installation de ces rôles. Sinon, ignorez cette section et accédez directement au téléchargement d'ADFS3 à partir de Microsoft.

Après avoir installé Windows 2012 R2 avec DNS, faites passer le serveur à un contrôleur de domaine.

La tâche suivante consiste à installer les services de certificats Microsoft.

Accédez à Gestionnaire de serveur et ajoutez un nouveau rôle :

Sélectionnez le rôle Services de certificats Active Directory. 

Déployez d'abord ces services - Service Web de stratégie d'inscription de certificat d'autorité de certification. Une fois ces deux rôles installés, configurez-les, puis installez Certificate Enrollment Web Service et Certificate Authority Web Enrollment. Configurez-les. 

Des fonctions et services de rôle supplémentaires requis, tels que IIS, seront également ajoutés lors de l'installation de l'autorité de certification.

Selon votre déploiement, vous pouvez sélectionner Entreprise ou Autonome.

  

Pour le type d'autorité de certification, vous pouvez sélectionner Autorité de certification racine ou Autorité de certification subordonnée. Si aucune autre autorité de certification n'est déjà en cours d'exécution dans l'organisation, sélectionnez Autorité de certification racine.

L'étape suivante consiste à créer une clé privée pour votre CA.

Cette étape n'est nécessaire que si vous installez ADFS3 sur un Windows Server 2012 distinct. Après avoir configuré l'autorité de certification, les services de rôle pour IIS doivent être configurés. Ceci est nécessaire pour l'inscription Web sur l'AC. Pour la plupart des déploiements ADFS, un rôle supplémentaire dans IIS, cliquez sur ASP.NET sous Développement d'applications est requis.

Dans le Gestionnaire de serveurs, cliquez sur Serveur Web > IIS, puis cliquez avec le bouton droit sur Site Web par défaut. La liaison doit être modifiée pour autoriser également HTTPS en plus du protocole HTTP. Ceci est fait pour prendre en charge HTTPS. 

Sélectionnez Modifier les liaisons.  

Ajoutez une nouvelle liaison de site et sélectionnez HTTPS comme type. Pour le certificat SSL, sélectionnez le certificat du serveur qui doit avoir le même nom de domaine complet que votre serveur AD. 

Tous les rôles requis sont installés dans l'environnement. Vous pouvez donc maintenant installer les services ADFS3 Active Directory Federation Services (sur Windows Server 2012). 

Pour le rôle de serveur, accédez à Gestionnaire de serveur > Gérer > Ajouter des rôles et des fonctionnalités de serveur, puis sélectionnez Services de fédération Active Directory si vous installez le PCI à l'intérieur du réseau du client, sur le réseau local privé. 

Une fois l'installation terminée, vous pouvez l'ouvrir à partir de la barre des tâches ou du menu Démarrer. 

Configuration initiale ADFS3

Cette section va passer par l'installation d'un nouveau serveur de fédération autonome, mais elle peut également être utilisée pour l'installer sur un contrôleur de domaine 

Sélectionnez Windows et tapez AD FS Management afin de lancer la console de gestion ADFS comme indiqué dans l'image.

Sélectionnez l'option Assistant Configuration du serveur de fédération AD FS 3.0 afin de démarrer la configuration de votre serveur ADFS. Ces captures d'écran représentent les mêmes étapes dans AD FS 3.

Sélectionnez Créer un nouveau service de fédération et cliquez sur Suivant.

Sélectionnez Serveur de fédération autonome et cliquez sur Suivant comme indiqué dans l'image.

Sous Certificat SSL, sélectionnez le certificat auto-signé dans la liste. Le nom du service de fédération est renseigné automatiquement. Cliquez sur Next (Suivant).

Vérifiez les paramètres et cliquez sur Suivant pour les appliquer. 

Confirmez que tous les composants ont été terminés et cliquez sur Fermer pour terminer l'Assistant et revenir à la console de gestion principale. Cela pourrait prendre quelques minutes.

ADFS est désormais activé et configuré en tant que fournisseur d'identité (IdP). Ensuite, vous devez ajouter CUCM en tant que partenaire de confiance. Avant de pouvoir faire cela, vous devez d'abord effectuer une configuration dans l'administration CUCM. 

Configurer SSO sur CUCM avec ADFS

Configuration LDAP

Le cluster doit être intégré à LDAP avec Active Directory et l'authentification LDAP doit être configurée avant d'aller plus loin. Accédez à l'onglet Système > Système LDAP comme indiqué dans l'image.

Ensuite, accédez à l'onglet Système > Répertoire LDAP.

Une fois que les utilisateurs Active Directory ont été synchronisés avec CUCM, l'authentification LDAP doit être configurée.

Un utilisateur final de CUCM doit avoir certains groupes de contrôle d'accès affectés à son profil d'utilisateur final. L'ACG est un super utilisateur CCM standard. L'utilisateur sera utilisé pour tester SSO lorsque l'environnement est prêt.

Métadonnées CUCM

Cette section affiche le processus du serveur de publication CUCM.

La première tâche consiste à obtenir les métadonnées CUCM, pour lesquelles vous devez accéder à l'URL ; https://<CUCM Pub FQDN> :8443/ssosp/ws/config/adata/sp ou il peut être téléchargé à partir de l'onglet Système > Authentification unique SAML. Cela peut être fait par noeud ou à l'échelle du cluster. Préférable pour faire ce cluster Wide.

Enregistrez les données localement avec un nom significatif tel que sp_cucm0a.xml, vous en aurez besoin après.

Configurer la partie de confiance ADFS

Revenir à la console de gestion AD FS 3.0.

Cliquez sur Assistant Ajout d'approbation de partie de confiance.

Cliquez sur Démarrer pour continuer.  

Sélectionnez le fichier XML de métadonnées federationmedatada.xml que vous avez enregistré précédemment et cliquez sur Suivant.

Utilisez CUCM_Cluster_Wide_Relying_Party_trust comme nom d'affichage et cliquez sur Suivant.

Sélectionnez la première option et cliquez sur Suivant.

Sélectionnez Autoriser tous les utilisateurs à accéder à cette partie de confiance et cliquez sur Suivant comme indiqué dans l'image.

Vérifiez la configuration et cliquez sur Suivant comme indiqué dans l'image.

Décochez la case et cliquez sur Fermer. 

À l'aide du bouton secondaire de la souris, sélectionnez la configuration Confiance de la partie de confiance que vous venez de créer et modifiez les règles de revendication comme indiqué dans l'image.

Cliquez sur Ajouter une règle comme indiqué dans l'image. 

Sélectionnez Envoyer les attributs LDAP en tant que revendications et cliquez sur Suivant.

Configurez ces paramètres :

Nom de la règle de demande : IDNom 

Magasin d'attributs : Active Directory (double-cliquez sur la flèche du menu déroulant)

Attribut LDAP : Nom du compte SAM 

Type de demande sortante : uid 

Cliquez sur FINISH/OK pour continuer.

Veuillez noter que uid n'est pas en minuscules et n'existe pas déjà dans le menu déroulant. Tapez-le.

Cliquez à nouveau sur Ajouter une règle afin d'ajouter une autre règle.

Sélectionnez Envoyer des revendications à l'aide d'une règle personnalisée et cliquez sur Suivant.

Créez une règle personnalisée appelée Cluster_Side_Request_Rule.

Copiez et collez ce texte dans la fenêtre de règle directement à partir d'ici. Parfois, les guillemets sont modifiés sur un éditeur de texte et la règle échouera lorsque vous testez 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");

Cliquez sur Terminer pour continuer.

Vous devez maintenant avoir deux règles définies sur ADFS. Cliquez sur Appliquer et OK pour fermer la fenêtre des règles.

CUCM est maintenant ajouté en tant que partie de confiance à ADFS.

Avant de continuer, redémarrez le service ADFS. Accédez au menu Démarrer > Outils d'administration > Services.

Métadonnées PCI

Vous devez fournir à CUCM des informations sur notre IdP. Ces informations sont échangées à l'aide de métadonnées XML. Assurez-vous d'effectuer cette étape sur le serveur sur lequel ADFS est installé.

Tout d'abord, vous devez vous connecter à ADFS (IdP) à l'aide d'un navigateur Firefox pour télécharger les métadonnées XML. Ouvrez un navigateur sur https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml et ENREGISTREZ les métadonnées dans un dossier local.

Maintenant, accédez à la configuration CUCM jusqu'au menu système > menu d'authentification unique SAML.

Retournez à l'Administration CUCM et sélectionnez SYSTEM > SAML Single Sign-On.

Sélectionnez Activer SAML SSO.

Cliquez sur Continuer pour accuser réception de l'avertissement.

Sur l'écran SSO et cliquez sur Parcourir. afin d'importer le fichier XML de métadonnées FederationMetadata.xml que vous avez enregistré précédemment, comme indiqué dans l'image.

Sélectionnez le fichier XML et cliquez sur Ouvrir afin de le télécharger vers CUCM à partir des téléchargements sous Favoris. 

Une fois téléchargé, cliquez sur Import IdP Metadata pour importer les informations IdP dans CUCM. Confirmez que l'importation a réussi et cliquez sur Suivant pour continuer.

Sélectionnez l'utilisateur appartenant aux super utilisateurs CCM standard et cliquez sur EXÉCUTER LE TEST SSO.

Lorsqu'une boîte de dialogue d'authentification utilisateur s'affiche, connectez-vous avec le nom d'utilisateur et le mot de passe appropriés.

Si tout a été correctement configuré, vous devriez voir un message indiquant que le test SSO a réussi !

Cliquez sur FERMER et FINISH pour continuer. 

Nous avons maintenant terminé les tâches de configuration de base pour activer SSO sur CUCM à l'aide d'ADFS. 

Configurer SSO sur CUC

Le même processus peut être suivi pour activer SSO dans Unity Connection.

Intégration LDAP avec CUC.

Configurez l'authentification LDAP.

Importez les utilisateurs LDAP auxquels la messagerie vocale sera affectée, ainsi que l'utilisateur qui servira à tester SSO.

Accédez à Utilisateurs > Modifier > Rôles comme indiqué dans l'image.

Attribuez à l'utilisateur de test le rôle Administrateur système.

Métadonnées CUC

Vous devez maintenant avoir téléchargé les métadonnées CUC, créé le RelyingPartyTrust pour CUC et téléchargé les métadonnées CUC et créé les règles I AD FS sur ADFS 3.0

Accédez à Connexion unique SAML et activez SAML SSO.

Configuration de SSO sur Expressway

Importer des métadonnées sur Expressway C

Ouvrez un navigateur sur https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml et ENREGISTREZ les métadonnées dans un dossier local

Télécharger vers Configuration > Unified Communications > IDP.

Exporter les métadonnées à partir d’Expressway C

Accéder à la configuration -> Communications unifiées -> PDI -> Exporter les données SAML

Le mode cluster utilise un certificat auto-signé (avec une longue durée de vie) inclus dans le SAML

Métadonnées et utilisées pour la signature de requêtes SAML

• En mode cluster, pour télécharger le fichier de métadonnées unique à l'échelle du cluster, cliquez sur Télécharger

• En mode par homologue, pour télécharger le fichier de métadonnées d'un homologue individuel, cliquez sur Télécharger en regard de l'homologue. Pour exporter tout dans un fichier .zip, cliquez sur Télécharger tout.

Ajouter une approbation de partie de confiance pour Cisco Expressway-E

Tout d’abord, créez des approbations de partie de confiance pour l’Expressway-Es, puis ajoutez une règle de revendication pour envoyer l’identité en tant qu’attribut UID.

OAuth avec actualisation de la connexion

Dans les paramètres d'entreprise de Cisco CUCM, le paramètre de flux de connexion Verify OAuth with Refresh est activé. Accédez à Cisco Unified CM Administration > Enterprise Parameters > SSO and OAuth Configuration.

Chemin d'authentification

• Si le chemin d’authentification est défini sur “ authentification SAML SSO ” seuls les clients Jabber utilisant une grappe Unified CM activée par SSO pourraient utiliser MRA sur cet Expressway. Il s'agit d'une configuration SSO uniquement. 
• La prise en charge MRA d’Expressway pour tous les téléphones IP, tous les terminaux TelePresence et tous les clients Jabber hébergés dans un cluster Unified CM non configuré pour SSO nécessitera le chemin d’authentification pour inclure l’authentification UCM/LDAP. 
• Si un ou plusieurs clusters Unified CM prennent en charge Jabber SSO, sélectionnez le ” SAML SSO et UCM/LDAP “ pour autoriser l'authentification de base et SSO. 

Architecture SSO

SAML est un format de données XML standard ouvert qui permet aux administrateurs d'accéder de manière transparente à un ensemble défini d'applications de collaboration Cisco après s'être connectés à l'une de ces applications. SAML SSO utilise le protocole SAML 2.0 pour offrir une connexion unique interdomaine et interproduit pour les solutions de collaboration Cisco. 

Flux de connexion sur site

Flux de connexion MRA 

OAuth

OAuth est une norme qui prend en charge l'autorisation. Un utilisateur doit être authentifié avant d'être autorisé. Le flux d’octroi de code d’autorisation fournit une méthode permettant à un client d’obtenir des jetons d’accès et d’actualisation pour accéder à une ressource (services Unified CM, IM&P, Unity et Expressway). Ce flux est également basé sur la redirection et nécessite donc que le client puisse interagir avec un agent-utilisateur HTTP (navigateur web) contrôlé par l'utilisateur. Le client fera une demande initiale au serveur d'autorisation à l'aide de HTTPS. Le serveur OAuth redirige l'utilisateur vers un service d'authentification. Cela peut être exécuté sur Unified CM ou un IdP externe si SAML SSO est activé. Selon la méthode d'authentification utilisée, une page Web peut être présentée à l'utilisateur final pour s'authentifier. (L'authentification Kerberos est un exemple qui n'afficherait pas de page Web.) Contrairement au flux de subvention implicite, un flux de subvention de code d'authentification réussi entraînera l'émission par les serveurs OAuth d'un code d'autorisation “ ” au navigateur Web. Il s'agit d'un code unique à usage unique, de courte durée, qui est ensuite transféré du navigateur Web au client. Le client fournit ce code d'autorisation “ ” au serveur d'autorisation avec un secret pré-partagé et reçoit en échange un ” de jeton d'accès “ et un ” de jeton d'actualisation “. Le secret client utilisé dans cette étape permet au service d'autorisation de limiter l'utilisation aux clients enregistrés et authentifiés uniquement. Les jetons sont utilisés aux fins suivantes : 

Jeton d'accès/d'actualisation

Jeton d'accès : Ce jeton est émis par le serveur d'autorisation. Le client présente le jeton à un serveur de ressources lorsqu'il a besoin d'accéder à des ressources protégées sur ce serveur. Le serveur de ressources peut valider le jeton et approuve les connexions à l'aide du jeton. (Les jetons d'accès Cisco ont une durée de vie de 60 minutes par défaut) 

Actualiser le jeton : Ce jeton est à nouveau émis par le serveur d'autorisation. Le client présente ce jeton au serveur d'autorisation ainsi que le secret du client lorsque le jeton d'accès a expiré ou arrive à expiration. Si le jeton d'actualisation est toujours valide, le serveur d'autorisation émettra un nouveau jeton d'accès sans nécessiter une autre authentification. (Les jetons d'actualisation Cisco ont une durée de vie de 60 jours par défaut). Si le jeton d'actualisation a expiré, un nouveau flux complet d'octroi de code d'autorisation OAuth doit être lancé pour obtenir de nouveaux jetons. 

Le flux de subvention du code d'autorisation OAuth est meilleur

Dans le flux de subvention implicite, le jeton d'accès est transmis au client Jabber via un agent utilisateur HTTP (navigateur). Dans le flux d'octroi de code d'autorisation, le jeton d'accès est échangé directement entre le serveur d'autorisation et le client Jabber. Le jeton est demandé au serveur d'autorisation à l'aide d'un code d'autorisation unique limité dans le temps. Cet échange direct du jeton d'accès est plus sûr et réduit l'exposition aux risques. 

Le flux de subvention du code d'autorisation OAuth prend en charge l'utilisation de jetons d'actualisation. Cela offre une meilleure expérience à l'utilisateur final puisqu'il n'a pas besoin de se réauthentifier aussi fréquemment (par défaut, 60 jours) 

Configurer Kerberos

Sélectionner l'authentification Windows

Gestionnaire des services Internet (IIS) > Sites > Site Web par défaut > Authentification > Authentification Windows > Paramètres avancés.

1. Décochez la case Activer l'authentification en mode noyau.

2. Assurez-vous que la protection étendue est désactivée.
   
   

ADFS prend en charge Kerberos NTLM

Assurez-vous qu'AD FS version 3.0 prend en charge le protocole Kerberos et le protocole NTLM (NT LAN Manager), car tous les clients non Windows ne peuvent pas utiliser Kerberos et utiliser NTLM.

Dans le volet de droite, sélectionnez Fournisseurs et assurez-vous que Negotiate et NTLM sont présents sous Fournisseurs activés :

Configurer Microsoft Internet Explorer

Assurez-vous que Internet Explorer > Advanced > Enable Integrated Windows Authentication est coché.

Ajouter une URL ADFS sous Sécurité > Zones intranet > Sites

Ajouter des noms d'hôte CUCM, IMP et Unity à Security > Trusted Sites

Authentification utilisateur 

Assurez-vous que Internet Explorer > Sécurité > Intranet local > Niveau de sécurité pour cette zone > Niveau personnalisé > Authentification utilisateur - Connexion > Connexion automatique dans la zone intranet.

Connexion Jabber dans SSO

Aucune modification de configuration n'est requise pour Cisco Jabber. Si Unified CM a été configuré pour utiliser SAML SSO avec un IDP externe, l'écran de connexion de l'IdP peut s'afficher plutôt que l'écran de connexion Unified CM. 

Dépannage

La plupart des leçons apprises ont été tirées lors de la configuration de nos travaux pratiques.

Internet Explorer (IE)

Assurez-vous que vous pouvez vous connecter à CUCM/IM&P à l'aide de SSO dans le navigateur IE comme condition préalable pour tester Jabber SSO.

Sites ajoutés à IE

Cliquez sur Options Internet de l'IE et accédez à l'onglet Sécurité. Cliquez sur Intranet local > Sites > Avancé. Ajoutez les sites Web à la zone (c'est-à-dire ajoutez le nom de domaine complet PCI au SITE).

Problème hors synchronisation

Si vous obtenez une erreur pour désynchronisé quelque chose comme ceci.

Réponse SAML non valide. Cela peut être dû au fait que le temps est désynchronisé entre les serveurs Cisco Unified Communications Manager et IDP. Vérifiez la configuration NTP sur les deux serveurs. Exécutez « utils ntp status » à partir de l'interface de ligne de commande pour vérifier cet état sur Cisco Unified Communications Manager. En cas d'incompatibilité temporelle entre CUCM et IdP, vous recevez cette erreur : « Réponse SAML non valide. » Cette erreur peut être provoquée lorsque le temps n'est pas synchronisé entre les serveurs CUCM et IdP. Pour que SAML SSO fonctionne, vous devez installer la configuration NTP correcte et vous assurer que la différence de temps entre l'IDP et les applications Unified Communications ne dépasse pas trois secondes.

Afin de vous assurer que vos utilisateurs ne sont pas affectés par des problèmes de synchronisation du serveur, définissez une lacune d'au moins deux minutes sur l'attribut « NotBefore » en suivant les instructions :

• Ouvrez votre Powershell dans ADFS.

• Vérifiez le NotBeforeSkew actuel en exécutant la commande suivante dans Powershell :

Get-ADFSRelyingPartyTrust -identificateur “ application ” FQDN

Get-ADFSRelyingPartyTrust -identifier « cmpubhcsc.fhlab.com » 

* La valeur NotBeforeSkew doit maintenant être définie sur “ 3 ”.

NOTE: Vous pouvez également importer les métadonnées du PCI vers le SP (c.-à-d. CUCM).

Révoquer un jeton 

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

Effectuez une synchronisation LDAP manuelle ou supprimez l'utilisateur de la base de données pour empêcher immédiatement un utilisateur d'utiliser Jabber. Même si un client Jabber présente un accès valide ou un jeton d'actualisation au service UDS sur CUCM, l'utilisateur doit être “ actif ” dans la base de données utilisateur de CUCM pour être authentifié.

La modification du paramètre Refresh Token Expiration Timer Enterprise annule automatiquement tous les jetons Refresh émis par ce cluster CUCM.

Fichier de démarrage

Les utilisateurs Jabber sont dirigés vers le cloud WebEx Connect pour authentification, au lieu d'un serveur de messagerie instantanée et de présence (IM&P) sur site, ou via un Expressway (Collaboration Edge) configuré pour l'accès mobile et distant (MRA).

Dans le fichier Jabber-bootstrap.properties situé à l'adresse suivante : C:\ProgramData\Cisco Systems\Cisco Jabber file we can exclude webex 

ServiceDiscoveryExcludedServices : WebEx

MSIS7066 défaillant SSO

Nous avons rencontré un scénario dans lequel l'OSS a échoué. Lors de l'exécution d'un test de connexion SSO à CUCM sur le navigateur Firefox, il a été redirigé vers IdP, a entré les informations d'identification, puis CUCM a affiché l'erreur suivante :

Code d'état non valide dans Response. Cela peut être dû à une erreur de configuration dans le PCI. Veuillez vérifier les journaux et la configuration du PCI

Jetez un coup d'oeil à l'Observateur d'événements ADFS (p. ex. IDP) à l'emplacement ci-dessous

Observateur d'événements -> Journaux des applications et des services -> AD FS -> Admin

Voici un extrait de l'erreur :

Détails de l'exception :

Microsoft.IdentityServer.RequestFailedException : MSIS7066 : Échec de l'authentification pour la demande. —> System.Security.SecurityException : Le nom d'utilisateur ou le mot de passe est incorrect.

Après avoir creusé, il est apparu que les informations d'identification d'administrateur du contrôleur de domaine ont été modifiées mais que les services ADFS n'ont pas été mis à jour

1. Ouvrez la fenêtre de configuration Services (vous pouvez y accéder à partir du Panneau de configuration Windows > Outils d'administration ou à partir du menu Démarrer lorsque vous tapez services).

2. Recherchez votre service (Services de fédération Active Directory) et double-cliquez dessus pour ouvrir ses propriétés (ou cliquez dessus avec le bouton droit et sélectionnez Propriétés).