ISA 2006 n'autorise pas le trafic utilisant le nom de domaine complet

2

Je rencontre un problème d’accès à Tomcat avec SSL sous MS ISA 2006.

Lorsque j'accède en utilisant l'adresse IP interne (par exemple, https://10.0.42.136/.. ), Tout fonctionne correctement et localhost_access_log. montrez-moi que la requête renvoie 200.

Cependant, si vous accédez au même serveur à l'aide du nom de domaine complet (par exemple, https : //mydomain.com/... ) Lance un message 403 - Forbidden dans le navigateur. Sur le serveur Tomcat, je trouve une erreur 401 dans la liste, pas 403. En d’autres termes, ISA jette 403 tandis que Tomcat jette 401.

Le serveur hébergeant le Tomcat ainsi que le serveur interrogeant l'application Tomcat ont un accès complet à Internet.

Je pense qu’il pourrait y avoir un problème avec le serveur ISA, car je suppose que le trafic des adresses IP passe directement, tandis que le trafic des noms de domaine complets s’éteint avant de revenir. Mais je ne suis pas sûr de cela.

Tomcat a-t-il besoin d'une configuration supplémentaire pour desservir le trafic https de l'extérieur, par exemple, ajouter l'adresse IP du serveur ISA, puisqu'il fonctionne parfaitement avec l'adresse IP?

Devons-nous faire quelque chose en ce qui concerne les certificats, comme indiqué ici: http://webcache.googleusercontent.com/search?q=cache:Y0BozNSUpN4J:forums.isaserver.org/fb.aspx%3Fm%3D2002034493+tomcat+behind + isa + serveur + certificats & cd = 1 & hl = no & ct = clnk & gl = no ?

Pourquoi le trafic de mon ordinateur client à l'extérieur va-t-il très bien, alors que le trafic du réseau interne échoue?

Sonstabo
la source
Vous êtes-vous assuré que la résolution du nom mydomain.comdonne la bonne adresse IP du serveur? Sinon, vous pourriez être dirigé vers un autre serveur!
Khaled
Étant donné que je peux me connecter au serveur «problématique» de l'extérieur, je pense que cela est pris en charge.
Sonstabo

Réponses:

1

Une hypothèse qui nslookup mycompany.comimprime l'adresse IP du serveur ISA et 10.0.42.136correspond à l'adresse IP du Tomcat (pas de l'ISA).

Ainsi, lorsque vous vous connectez, https://10.0.42.136/vous vous connectez directement à Tomcat (sans ISA). Vous pouvez simplement vérifier si la connexion à Tomcat avec FDQN fonctionne si vous écrivez ce qui suit dans votre fichier hosts :

10.0.42.136     mycompany.com

(Le chemin du fichier est généralement c:\windows\system32\drivers\etc\hostsou /etc/hosts.)

Après cela, vérifiez pingque votre hostsentrée de fichier est exacte. La commande et les résultats devraient ressembler à ceci:

c:\>ping mycompany.com

Pinging mycompany.com [10.0.42.136] with 32 bytes of data:
...

Si ce sont des pings, 10.0.42.136vérifiez https://mycompany.com/dans un navigateur. Peut-être devez-vous redémarrer le navigateur avant de l'utiliser et n'oubliez pas de supprimer la ligne du hostsfichier ultérieurement.

Si le site Web fonctionne bien avec l' hostsentrée de fichier, il s'agit certainement d'un problème de serveur ISA. Sinon, le problème est lié à Tomcat.

palacsint
la source
Je suis presque sûr que c'est un problème ISA: 1. Tout va bien lorsque les 2 serveurs situés derrière le pare-feu communiquent à l'aide de l'IP interne 2. Tout est OK lorsqu'un navigateur extérieur au réseau navigue sur mycompany.com C'est le moment où le trafic entre serveur interne n ° 1, hors du monde, revenant, via ISA et de nouveau au serveur interne n ° 2, la merde frappe le fan: |
Sonstabo
Dans ce cas, modifiez votre question, identifiez-la comme étant ISA au lieu de Tomcat, et changez peut-être aussi le titre.
Palacsint
1
Merci pour votre retour. J'ai changé le titre de la question.
Sonstabo
1

Vous n'avez rien dit à propos du client, et c'est important. Le client doit-il sortir pour accéder au nom de domaine complet? Avez-vous dit qu'il est local, ou qu'il devrait éviter le proxy, pour cette URL? (quel est le client?)

Quoi qu'il en soit, à part cela, je pense que vous pourriez bénéficier d'une protection contre les attaques par réflexion.

Plus classique: si votre jeu de règles n'indique pas que les hôtes internes peuvent parler à d'autres hôtes internes, ils ne le peuvent pas.

Si le nom de domaine complet est conçu pour sortir de votre réseau et y revenir via ISA, un ensemble de règles permettant cette combinaison est nécessaire.

Par conséquent, si vous souhaitez autoriser les clients du réseau interne à se connecter à votre site Web externe HTTPS, essayez une règle du type: Autoriser / HTTP et HTTPS / De: Réseau interne / Vers: IP interne de l'hôte utilisé (vous pouvez également essayer un ensemble d'URL. y compris, mais ce n'est peut-être pas nécessaire.

TristanK
la source
Il y a 2 serveurs impliqués qui sont essentiellement le client et le serveur. Le client se connectera au serveur et demandera l'authentification de l'utilisateur. Le serveur répondra essentiellement Oui / Non. Ce trafic a bien fonctionné en utilisant une adresse IP interne. Mais ne pas utiliser FQDN. J'en ai besoin pour utiliser le nom de domaine complet, car nous sommes en train de passer à une configuration SSO et nous sommes confrontés à des problèmes qui, selon nous, pourraient avoir quelque chose à voir avec le fait que le client essaie de s'authentifier à l'aide de l'IP interne au lieu du nom de domaine complet. problèmes de cookies pour 10.1.1.1! = mycompany.com . Je vais transmettre des informations à mon ASP.
Sonstabo