locked
UAG et deux SharePoint : HTTP 401 Unauthorized RRS feed

  • Question

  •  

    Bonjour,

     

    Nous utilisons UAG pour publier une application SharePoint.

    Tout fonctionne mis à part la fonction "Switch user" qui renvoie une erreur lors de la tentative d'affichage de la page de login : "Vous n'êtes pas autorisé à afficher ce dossier ou cette page".

    Dans les logs d'UAG je retrouve : "Secure=1 failed because the request was unable to reply to an HTTP 401 request from application [...] of type SharePoint2007AAM".

    Pour aller plus loin, j'ai réalisé un snif WireShark, et je retrouve deux paquet :

    ·     Du frontal SharePoint 1 à UAG : HTTP/1.1 401 Unauthorized ;

    ·     Du frontal SharePoint 2 à UAG : HTTP/1.1 401 Unauthorized.

    Si je fais le test en me connectant directement sur le SharePoint, et il n'y a aucun problème.

    Notre UAG est configuré en SP1 Update 1 avec un Hotfix fourni par le support Microsoft pour corriger un problème lié au NLB et trunk HTTP-to-HTTPS.

     

    EDIT : Nous venons de nous rendre compte que le problème était du à la publication d'un deuxième site SharePoint. En le désactivant dans UAG, le problème n’apparaît plus. La question est donc maintenant pourquoi l'ajout d'une deuxième application MOSS impliquerait cette erreur ? Sachant que cela provient de l'authentification/désauthentification.


    mardi 24 janvier 2012 10:17

Réponses

  • Nous avons trouvé une "solution" :

    Dans UAG, sur la configuration du trunk dans la partie authentication, nous avons décoché "Send the application server response to the browser" ce qui permet à UAG d'afficher lui même une page qui sert de message de logoff. Cela suffit à ne plus avoir l'erreur, cependant, le bouton "Switch User" et "Déconnection" renvoie tout les deux sur une page pour se ré-authentifier (alors que déconnection fermait la session, supprimait le cookies et proposait de fermer la page). Nous gardons cela en attendant.

    Par contre, cette correction provoquait un autre bug uniquement sous Chrome : une belle erreur 500. Un coup d'oeil dans les logs IIS pour se rendre compte que Chrome lançait une double requête sur le favicon du site ... qui n'existait pas ! Et du coup UAG renvoyait une erreur 500 uniquement si les deux applications SharePoint étaient activées. La création du favicon a réglé le problème. A ne rien n'y comprendre ...


    Notre problème est donc résolu en attendant de réussir à trouver une alternative pour avoir une vrai page de déconnexionMerci à tous pour votre aide !


    mardi 13 mars 2012 15:31

Toutes les réponses

  • Bonjour,

    la 2ème application est-elle publiée sur un nouveau Trunk utilisant donc une nouvelle adresse IP?

    Le mode SSO est-il configuré?

    A+

     


    Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info
    mardi 24 janvier 2012 12:38
  • Les deux applications se trouvent sur le même trunk, et le SSO est activé pour les deux.

    Nous avons suivi ce sujet pour les configurer : http://technet.microsoft.com/en-us/library/dd857229.aspx

    mardi 24 janvier 2012 12:51
  • Bonjour,

    Avez-vous configuré correctement les AAM de SharePoint en adéquation avec les urls externes dans UAG ?


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.
    lundi 6 février 2012 14:30
  • Les AAM de SharePoint sont effectivement bien configurée.

     

    Petit détail, pour la déconnexion, nous utilisons les pages LogOff de UAG et non celles par défaut de SharePoint (qui ne nous permettent pas une déconnexion propre). Le problème pourrait-il venir de là ? 

    Car si oui, je ne vois pas du tout comment fixer cela !

    lundi 6 février 2012 16:02
  • En fait, c'est UAG qui véhicule ton identité jusqu'à SharePoint (SSO). Donc c'est la raison pour laquelle d'ailleurs, après être connecté à UAG avec l'utilisateur toto tu es automatiquement connecté avec ce même user sur SharePoint.

    Comme UAG gère l'identitification, si tu devais vider les cookies ou autre manip équivalentes pour changer d'identités, UAG te réinvitera à te connecter et tu seras donc déconnecté à la fois de SharePoint et d'UAG !

    J'avais pas souvenir d'une possibilité pour passer d'une identité à une autre via UAG pour SharePoint ... Mais avant d'aller plus loin, peux-tu justement décocher la partie SSO dans UAG pour ton application SharePoint et de rééssayer. Cela te donnera donc une double authentification au démarrage forcément (UAG puis SharePoint), et essaye de faire un switch user. Cela nous permettra de cibler ton problème.

     

    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.
    lundi 6 février 2012 17:13
  • Je viens donc de faire plusieurs tests.

    Pour mieux comprendre, on va dire que OSS1 est le SharePoint principal du site (qui s'ouvre après la page de Logon) et OSS2 est un SharePoint qui sert à stocker un mini-site personnel.

    Voici mes tests :

    • SSO désactivé sur OSS1 : impossible de me connecter
    • SSO désactivé sur OSS2 : le problème persiste
    • SSO désactivé sur les deux : le problème persiste
    • OSS2 désactivé : le problème disparait.
    mardi 7 février 2012 12:06
  • Bonjour,

    Quelle est la différence entre :

    • SSO désactivé sur OSS2 : le problème persiste
    • OSS2 désactivé : le problème disparait.

    Tu désactives l'application OSS2 dans UAG ?

    Tu as bien deux AAM différents pour ces deux applications SharePoint ?


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.

    mardi 7 février 2012 13:09
  • Oui voila, le deuxième c'est carrément l'application désactivée dans UAG. Pour le premier, juste le SSO désactivé dans les options d'authentification UAG.

    On a effectivement deux AAM différents qui collent avec les adresses externe dans UAG.

    Pour OSS1 : externe.nomde.domaine

    Pour OSS2 : public.auth.nomede.domaine



    • Modifié itsoas mardi 7 février 2012 15:43
    mardi 7 février 2012 13:16
  • Alors, cela n'a peut être rien à voir, mais j'ai jamais eu ce cas par expérience.

    Est-ce possible de voir avec un FQN de OSS2 sans un sub level supplémentaire, par exemple public.nomde.domaine (cela te demande de le changer au niveau de la central admin de SharePoint aussi)


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.

    mardi 7 février 2012 13:25
  • Nous venons de changer le FQDN pour éviter un niveau supplémentaire : sans résultat.

    Le problème est qu'en plus nous avons modifié l'AppWrap du Portail pour remplacer les fonctions de switch user et déconnection de base de SharePoint par les pages de LogOff d'UAG.

    On reste toujours au points que nous sommes quasiment sûrs que ce problème provient du fait que la déconnection se passe mal sur une appli ou un module.

    Nous allons continuer de chercher de notre côté, et en cas de nécessité ouvrir un call au près de Microsoft ...

    mardi 7 février 2012 15:46
  • Ok, tiens nous au courant c'est toujours intérressant de connaître la suite ;)

    @+,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.

    mardi 7 février 2012 16:40
  • Nous avons trouvé une "solution" :

    Dans UAG, sur la configuration du trunk dans la partie authentication, nous avons décoché "Send the application server response to the browser" ce qui permet à UAG d'afficher lui même une page qui sert de message de logoff. Cela suffit à ne plus avoir l'erreur, cependant, le bouton "Switch User" et "Déconnection" renvoie tout les deux sur une page pour se ré-authentifier (alors que déconnection fermait la session, supprimait le cookies et proposait de fermer la page). Nous gardons cela en attendant.

    Par contre, cette correction provoquait un autre bug uniquement sous Chrome : une belle erreur 500. Un coup d'oeil dans les logs IIS pour se rendre compte que Chrome lançait une double requête sur le favicon du site ... qui n'existait pas ! Et du coup UAG renvoyait une erreur 500 uniquement si les deux applications SharePoint étaient activées. La création du favicon a réglé le problème. A ne rien n'y comprendre ...


    Notre problème est donc résolu en attendant de réussir à trouver une alternative pour avoir une vrai page de déconnexionMerci à tous pour votre aide !


    mardi 13 mars 2012 15:31
  • En tout cas ravi que tu ai trouvé la solution, et surtout merci pour le partage et le retour.

    A très bientôt,

    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog Note : Si ma réponse vous a été utile, ou apporté une résolution; merci de voter ou de la marquer comme réponse.

    mardi 13 mars 2012 16:11