Les utilisateurs Enterprise Single Sign-On dans Office 365 ne peuvent pas se connecter à Skype Entreprise Online depuis leur réseau d’entreprise

PROBLÈME

Prenons l’exemple du scénario suivant :

• Un Office 365 pour les entreprises, Office 365 pour l'éducation, ou Office 365 client d'affaires met en place une seule connexion (SSO) dans Active Directory Federation Services (AD FS) 2.0.

• Les utilisateurs fédérés qui se connectent depuis l'intérieur de leur réseau d'entreprise ne peuvent pas se connecter à Skype for Business Online (anciennement Lync Online) à partir de Lync 2013, et ils reçoivent le message d'erreur suivant :

  Impossible de se connecter parce que le serveur est temporairement indisponible.

Remarque Ce problème ne s'applique qu'aux utilisateurs Enterprise SSO qui se connectent à Skype for Business Online en utilisant Lync 2013 depuis l'intérieur de leur réseau d'entreprise. Le problème ne s'applique pas aux utilisateurs de Microsoft Lync 2010, aux utilisateurs qui ne sont pas sur Skype pour Business Online, ou aux utilisateurs qui se connectent à partir de l'extérieur de leur réseau d'entreprise.

SOLUTION

Important Suivez attentivement les étapes de cette section. Des problèmes graves peuvent se produire si vous modifiez le registre de manière incorrecte. Avant de le modifier, sauvegarder le registre de restauration en cas de problèmes. Parce qu'il ya beaucoup de causes possibles, il est préférable de travailler à travers toutes les solutions suivantes, puis vérifier la configuration.

1. Lorsque vous déployez une ferme AD FS 2.0 Federation Server, vous devez spécifier un compte de service basé sur le domaine qui nécessite un SPN enregistré pour activer l'authentification Kerberos pour fonctionner correctement. Pour plus d'informations, consultez le wiki TechNet suivant :

   AD FS 2.0: Comment configurer le SPN (servicePrincipalName) pour le compte de serviceLes raisons pour lesquelles vous devrez peut-être configurer le SPN manuellement sur le compte de service AD FS 2.0 sont les suivantes :

   • L'enregistrement SPN a échoué lors de la configuration initiale de la ferme.

   • Le nom du Service de la Fédération a été changé.

   • Le compte de service a été modifié.

2. Assurez-vous que le service AD FS 2.0 est exécuté sous le compte de service basé sur le domaine qui a été mentionné dans l'étape précédente. Par exemple, dans l'image suivante, TRLABV3 est le nom d'hôte interne, et ADFSSvc est le compte de service :

3. Configurez le serveur AD FS 2.0 pour accepter les en-têtes de demande de plus de 40 kilooctets (KB). Vous devrez peut-être le faire lorsque l'utilisateur est membre de nombreux groupes d'utilisateurs de services de domaine d'annuaire actif (AD DS). Lorsqu'un utilisateur est membre de nombreux groupes AD DS, la taille du jeton d'authentification Kerberos pour l'utilisateur augmente. La demande HTTP que l'utilisateur envoie au serveur Internet Information Services (IIS) contient le jeton Kerberos dans l'en-tête WWW-Authenticate. Par conséquent, la taille de l'en-tête augmente à mesure que le nombre de groupes augmente. Si l'en-tête ou la taille du paquet HTTP augmente au-delà des limites configurées dans IIS, IIS peut rejeter la demande et envoyer une erreur en réponse. Pour plus d'informations, voir l'article suivant Microsoft Knowledge Base :

   2020943 "HTTP 400 - Bad Request (Request Header too long)" erreur dans les services d'information Internet (IIS)Pour contourner ce problème, appliquez l'une des méthodes suivantes :

   1. Diminuez le nombre de groupes d'utilisateurs AD DS dont l'utilisateur est membre.

   2. Modifier les valeurs de registre MaxFieldLength et MaxRequestBytes sur le serveur qui exécute IIS afin que les en-têtes de demande de l'utilisateur ne soient pas considérés trop longtemps. Ces deux valeurs de registre sont situées sous la sous-clé du registre suivante :

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

4. Si vous avez déployé plusieurs serveurs AD FS 2.0 dans une ferme et que vous les faites charger en équilibre, le client Lync 2013 peut ne pas être en mesure de diriger la demande vers le serveur AD FS 2.0. L'ajout d'une entrée pour le serveur AD FS 2.0 au fichier Hôtes sur le client qui pointe directement vers le serveur AD FS 2.0 contournera l'adresse IP virtuelle de l'équilibriste de charge.

5. Si les solutions précédentes n'ont pas résolu le problème et le déclassement à Lync 2010 n'est pas une option, suivez ces étapes pour contourner le problème. Remarque Si un compte d'administrateur local n'existe pas déjà sur l'ordinateur, vous devrez en créer un pour que cette solution fonctionne.

   1. Parcourir le Lync 2013 exécutable dans Windows Explorer:

       C:\Program Files\Microsoft Office 15\root\office15 

   2. Maintenez la clé Shift, puis cliquez à droite Lync.exe.

   3. Cliquez sur Exécuter en tant qu'utilisateur différent.

   4. Entrez les informations d'identification d'un compte d'administrateur local sur l'ordinateur, puis appuyez sur Entrez.

INFORMATIONS SUPPLÉMENTAIRES

Ce problème se produit généralement en raison d'une mauvaise configuration dans AD FS 2.0. D'autres services tels que Microsoft Exchange Online peuvent fonctionner correctement malgré cette configuration. Les causes habituelles sont énumérées ici :

• Le Nom principal du service (SPN) n'est pas configuré correctement. Les raisons en sont les suivantes :

  • L'enregistrement SPN a échoué lors de la configuration initiale de la ferme.

  • Le nom du Service de la Fédération a été changé.

  • Le compte de service a été modifié.

• Le service AD FS 2.0 ne s'exécute pas sous le compte de service correct.

• L'en-tête de demande de Lync 2013 est rejeté par IIS et le serveur AD FS 2.0 parce que l'en-tête est trop grand. Ce problème peut se produire parce que le compte utilisateur est membre d'un trop grand nombre de groupes d'utilisateurs AD DS.

• La ferme serveur AD FS 2.0 est équilibrée et la demande n'atteint pas le serveur AD FS 2.0.

Pour plus d'aide pour le déploiement de l'AD FS 2.0 pour une utilisation avec SSO dans Office 365, consultez le site Web TechNet suivant :

Planifier et déployer AD FS pour une utilisation avec une seule connexionDans le cas où l'utilisateur est membre d'un trop grand nombre de groupes AD DS, l'entrée suivante est saisie dans les journaux de trace Microsoft Online Services Log-In Assistant (ces journaux sont généralement situés dans C : MSOSSPTrace):

##TestHook: URL-https://<ADFSServer>/adfs/services/trust/2005/windowstransport@transport.cpp_245..........<HTML><HEAD><TITLE>Bad Request</TITLE><META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD><BODY><h2>Bad Request - Request Too Long</h2><hr><p>HTTP Error 400. The size of the request headers is too long.</p></BODY></HTML> 

Encore besoin d'aide ? Accédez à Microsoft Community.