2009-03-09 6 views
1

Nous sommes en train de configurer un portail pour utiliser ISA Server en tant que fournisseur de sécurité frontale.
Nous utilisons donc ISA Server 2006 SP1.Erreur lors de l'accès à des pages non compilées à l'aide d'ISA Server 2006 SP1

Malheureusement, lorsque nous accédons à des applications .net via ISA Server, c'est la première fois qu'on y accède.
Ils ne sont pas encore compilés, l'erreur suivante apparaît:
Code d'erreur: 500 Erreur interne du serveur. Le paramètre est incorrect. (87)

Dans les journaux de surveillance ISA, cela montre:

Échec de la connexion Tentative
Type de journal: Proxy Web (marche arrière)
Statut: 87 Le paramètre est incorrect.

Une fois l'application compilée, l'erreur n'apparaît jamais.
Est-ce que quelqu'un sait comment résoudre ce problème, donc le site fonctionne correctement la première fois?

Quelques informations supplémentaires:

  • Les sites accessibles sont en cours d'exécution sur Windows Server 2008 64 bits - édition standard, et se produit pour Sharepoint ainsi que des sites standards .net.
  • ISA Server est en cours d'exécution sur Windows Server 2003 R2 SP2 eidtion standard
  • Le pare-feu de la zone Windows Server 2008 autorise tous les accès. (Pour l'exclure.)
  • Rien d'étrange n'apparaît dans les journaux IIS ou les journaux de pare-feu.
+0

Avez-vous regardé @This (http://support.microsoft.com/kb/931762) –

+0

Désolé, je ne vois pas comment cet article a trait à mon problème. – Bravax

+0

Je suppose que vous utilisez IIS derrière ISA. Avez-vous vérifié les journaux IIS pour ce qui se passe pendant la demande initiale. Il est possible que ISA bloque quelque chose comme une redirection HTTP 3XX. J'ai vu des systèmes où cela peut arriver sur le premier accès au site. –

Répondre

0

Ce problème a été causé par la valeur de la délégation d'authentification dans ISA Server étant réglé sur NTLM alors que IIS est configuré pour accepter l'authentification Windows. Cette combinaison semble être un problème dans mon environnement.

La modification de l'authentification de base, ou toute autre combinaison valide fonctionne correctement, donc je vais avec un paramètre de délégation d'authentification différent.

+0

Content que vous ayez pu le résoudre! (Dang, j'aurais pu gottent ça :) –

+0

J'ai eu le même problème aujourd'hui mais l'authentification de base n'était pas une option pour moi. Voir ma réponse pour plus de détails. – x0n

0

Vous pouvez pre-complie the web site. C'est plus d'un travail autour.

Avez-vous essayé d'effacer le répertoire de sortie de compilation pour ASP.NET? Vous pourriez avoir un conflit là-bas.

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files 
+0

Oui, j'ai suggéré cela, mais comme personne d'autre ne semble avoir ce problème, il semble que quelque chose ne va pas avec ma configuration, alors je préfère le réparer correctement. – Bravax

+1

L'effacement des fichiers temporaires ASP.NET n'a pas résolu le problème. – Bravax

0

J'ai eu le même problème aujourd'hui (ISA 2006/SP1 publiant SharePoint via ISA HTML Form Auth, passant par l'authentification NTLM) et passé plusieurs heures à le déboguer. Vous avez raison, c'est la nécessité de compiler la page qui le déclenche et seul un IISRESET provoque le problème; Le recyclage d'une piscine d'applications ne l'est pas. L'authentification de base fonctionne, mais pas NTLM. Lisez la suite pour le correctif.

Si vous regardez dans votre journal IIS, vous verrez qu'il y est quelque chose étrange, à savoir une 401 réponse de IIS pour la requête HTTP particulière avec un petit indice:

... GET /auth.aspx - 80 - ... Mozilla/4.0+(compatible;...) 401 1 2148074254 734 

Notez le code d'erreur 2148074254 (0x8009030e SEC_E_NO_CREDENTIALS).Dans un échange régulier de challenge/réponse, cela devrait être "5". Cela m'a conduit à d'autres chemins de débogage sinueux et finalement j'ai découvert que le problème était dû au fait que l'authentification en mode noyau d'IIS 7 était activée par défaut. Si vous l'éteignez:

%windir%\system32\inetsrv\appcmd set config -section:windowsAuthentication -useKernelMode:false 

... le problème disparaît. Il y a suffisamment d'informations dans ce post pour que quelqu'un puisse en trouver les raisons techniques, alors je ne vais pas me donner la peine de régurgiter ici.

-Oisin

Questions connexes