2009-09-08 25 views
0

Avoir un problème avec des individus aléatoires essayant d'accéder à un site intranet avec un certificat de sécurité. La plupart des utilisateurs peuvent simplement sélectionner leur certificat de carte à puce/CAC, entrer le numéro d'identification et accéder ensuite aux pages du site. Cependant, des individus aléatoires entrent leur code PIN et sont immédiatement rappelés par le dialogue d'alerte IE pour entrer leur nom d'utilisateur et mot de passe de domaine. S'ils n'indiquent pas le nom d'utilisateur et le mot de passe de leur domaine réseau, ils reçoivent un 401.1 non autorisé.La connexion à la carte CAC n'authentifie pas les utilisateurs aléatoires qui doivent utiliser leurs fenêtres utilisateur et pwd

Je suis confus quant à pourquoi certains utilisateurs (qui sélectionnent les mêmes certificats que ceux qui réussissent) sont invités pour leur nom de domaine/pwd. En outre, ils sont en mesure d'accéder à d'autres sites qui nécessitent un CAC pour passer le certificat de sécurité.

Possible qu'un jeton d'utilisateur ne puisse pas être établi via une carte CAC pour le site particulier, mais vous ne savez pas pourquoi. Comme ces utilisateurs obtiennent un 401.1, leur identité associée à leurs identifiants CAC n'est pas validée. En IIS: Les utilisateurs anonymes ne sont pas autorisés (non cochés). Un cryptage 128 bits est requis avec SSL. L'authentification Windows intégrée est vérifiée. Accepter les certificats clients Dans le fichier web.config du site, tous les utilisateurs sont autorisés et seuls les accès anonymes sont refusés. La même configuration est présente sur la boîte de développement sans aucun problème, ce qui indique que le problème réside dans la capacité du serveur de production à recevoir/gérer correctement les informations CAC de ces individus ou que quelque chose de funky se passe avec la façon dont le certificat de sécurité se rapporte au certificat CAC x.509 du client. Un peu plus d'informations utiles: l'invite du navigateur qui demande initialement le CAC n'a rien à voir avec le code du site, mais est activée en appliquant le certificat de sécurité à un site dans IIS; m'indiquant ainsi qu'il y a quelque chose d'écrit dans le certificat qui cherche des certificats clients liés à l'agent ActivClient via le navigateur ???

Là encore, je n'ai probablement aucune idée de ce dont je parle, juste jeter un os ici pour voir si quelqu'un a eu le même problème ou a des idées.

Merci d'avance pour toute contribution, question ou idée.

Répondre

1

Le problème était une DLL puante qui permet d'analyser de longues URL avec de nombreux alias (points). La DLL défectueuse avait été écrite dans la ré-image de beaucoup de gens de leurs ordinateurs. Les rafraîchissements de l'ordinateur en infraction contenaient une ancienne version d'une DLL utilisée par Internet Explorer, appelée URLMON.dll. La version de la DLL dont vous avez besoin doit se terminer par '21073', mais celle incluse sur les images défectueuses énumérées ci-dessus se termine par '19 ..... '.

Vous pouvez confirmer en allant dans IE7 et en cliquant sur Aide> A propos d'Internet Explorer> Informations système (NDB en bas)> Paramètres Internet> Internet Explorer> Versions de fichier> urlmon.dll

Mise à jour de cette DLL a montré pour résoudre le problème avec les sites SSL sécurisés ayant des problèmes de validation de l'entrée CAC/pin ayant des entrées DNS longues (telles que https://something.something.something.something.something.something).

Il existe un correctif IE7 pour cela, mais il ne sera installé que si vous n'avez pas ServicePack 3. Si vous avez SP3, vous ne pouvez pas exécuter le correctif nécessaire, car il suppose que SP3 a déjà mis en place la DLL correcte. 1. Désinstallez SP3 2. Redémarrez 3. Installez le correctif IE7 4. Redémarrez 5. Exécutez Microsoft mises à jour via le site MS Window mises à jour

Sucks, mais c'est ce que vous obtenez avec le logiciel merdique comme IE exécuté sur un système d'exploitation déficient, puis couplé avec un logiciel qui est limité dans ses capacités à vraiment parler au système d'exploitation.

0

Vérifiez le fonctionnement de la carte avec d'autres applications.

Vérifiez également que les certificats sont valides (non périmés) et par ailleurs semblable - même émetteur, PIN pas verrouillé, etc.

+0

C'est la partie frustrante, la carte fonctionne sur toutes les autres applications et même sur les sites SSL sur d'autres serveurs qui affichent une invite CAC. Je crois que nous avons confirmé que les certificats associés à la carte et au navigateur sont valides jusqu'en 2015 (ou plus dans certains cas), et sont les mêmes, étant donné qu'il s'agit du même certificat x509 de la carte ... comme DOD Email CA-15 (bien que le DOD CA-15 régulier fonctionne également). Encore une fois, peut-être quelque chose avec le fait qu'il est isolé à un serveur de production, quelque chose avec le certificat SSL. sur cet URL ou l'accès de l'utilisateur ?? – aimlessWonderer

0

Je comprends votre environnement de développement fonctionne comme vous voulez et que votre environnement de production n'est pas.

Avez-vous essayé de reproduire l'erreur dans un autre environnement pour confirmer quel comportement est cohérent?

+0

Nous avons essayé de reproduire le problème dans les environnements de test et de développement, mais heureusement, malheureusement, nous n'avons pas pu reproduire ce problème. En outre, cela élude un problème qui peut être isolé du serveur de production, des utilisateurs qui y accèdent et/ou du certificat appliqué à ce site Web SSL sur ce serveur. – aimlessWonderer

0

Avait un problème très similaire qui a été résolu en contournant le serveur proxy. Essayez de l'ajouter à la liste d'exemptions.

Dans IE, allez à:

Outils | Options Internet | Connexions | Paramètres réseau | Avancé

Ajouter un site à la liste d'exemptions.

Peut ne pas fonctionner pour vous, mais pourrait valoir la peine d'essayer. Comme je l'ai dit, cela a fonctionné pour moi avec un problème très similaire.