J'ai une application qui utilise ActiveDirectoryMemberShipProvider pour accorder l'accès aux utilisateurs. L'application est hébergée sur une machine non domaines, avec un pare-feu entre le serveur d'applications et le contrôleur de domaine.
Nous avons ouvert le port LDAP à la DC sur le réseau intérieur - pourtant, quoi que nous essayions, nous finissons Avec une erreur indiquant "Le domaine ou le serveur spécifié n'a pas pu être contacté" P>
Quelqu'un a-t-il des suggestions sur la façon dont je peux résoudre ce problème? Nous avons essayé tout ce que nous pouvons penser et ne deviennent pas nulle part. p>
Ma chaîne de connexion est la suivante: p>
<add name="ActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider"
connectionStringName="ADConnectionString"
attributeMapUsername="SAMAccountName"
connectionProtection="None"
connectionUsername="LdapUser"
connectionPassword="LdapPassword" />
6 Réponses :
Avez-vous été testé avec un outil de navigation LDAP, à partir de la boîte distante pour voir s'il peut se connecter avec les critères utilisés ici? C'est à dire. Est-ce un problème de connectivité ou quelque chose d'autre?
Oui, nous sommes en mesure d'interroger à l'aide d'un outil LDAP en utilisant les mêmes informations. Ceci me dérange. Une chose étrange que j'ai remarquée, c'est que le fournisseur d'adhésion de la publicité tente d'obtenir le nom NetBIOS du serveur que vous vous connectez (creusez-le avec un réflecteur) - et que pendant qu'il y a un essai / attrape qui jette le message exact que nous obtenons. Je ne sais pas pourquoi le fournisseur pense qu'il a besoin du nom NetBIOS du serveur.
On dirait que la solution est d'ouvrir le port 445.
Nous ne sommes pas autorisés à ouvrir, alors je suppose que je suis coincé.
L'ouverture du port 445 a fait le tour pour moi. Je pourrais me connecter via System.DirectoryServices.directoryenterry (...) Tout simplement à l'aide de ma chaîne de connexion LDAP, mais toutes les tentatives de connexion via le ActiveDirectoryMembershipProvider produiraient l'erreur suivante: Le domaine ou le serveur spécifié n'a pas pu être contacté . L'ouverture de ce port a résolu le problème.
Vous pouvez utiliser ces deux articles, peut être résolu votre problème
www.ddj.com/windows/184406424
forums.asp.net/t/1408268.aspx
et vérifier vos pare-feu
L'application est hébergée sur une machine non domaines, avec un pare-feu entre le serveur d'applications et le contrôleur de domaine.
Puisque vous pouvez interroger directement à l'aide d'un outil LDAP, ce qui suggère que le pare-feu est ouvert correctement. Toutefois, gardez à l'esprit que le
ActiveDirectoryMembershipProvider n'utilise pas un ancien LDAP uni, il utilise Microsoft Technologies. Par exemple, si vous définissezconnexionProtection = "Secure" , ADMP essaiera d'utiliser SSL et le port 636, si cela échoue, il utilisera la signature IPsec intégrée de Microsoft (voirCet article Pour plus de détails). Quoi qu'il en soit, cela me permet de m'interroger sur quelques choses:
- Le domaine de l'annonce a-t-il une stratégie IPSec "requise" qui refuse des connexions d'ordinateurs non-domaines / non configurés? (Probablement pas, car vous êtes connecté avec un LDAP uni, mais cela vaut la peine d'être enquêté.)
- Avez-vous ajouté le nom NetBIOS du contrôleur de domaine sur votre fichier LMHOSTS et son nom DNS dans votre fichier d'hôtes? (De nombreux protocoles vérifient que le nom signalé par leur cible correspond au nom que vous avez essayé de vous connecter.)
- Beaucoup de personnes ont noté des problèmes à l'aide de l'ADMP entre différents domaines et la solution requise par une fiducie à sens unique. Comme cela ressemble à votre ordinateur client n'est pas dans un domaine, vous ne pouvez pas avoir cette fiduciaire - sauf indication non (a), il s'agit d'un membre d'un domaine différent d'une fiducie à sens unique ou (B), il est membre de Le même domaine et donc la confiance du serveur client est implicite.
Votre deuxième point m'a conduit à une solution! Apparemment, le nom du DNS a été modifié sur notre serveur de test qui a entraîné l'échec de l'ADMP, tandis que toutes les autres méthodes fonctionnaient! Cependant, la solution de contournement actuelle pour moi était d'avoir l'adresse IP au lieu d'un nom d'hôte dans la chaîne de connexion LDAP, exactement Scott l'a configuré (mais je ne fournis pas le numéro de port, je le laisse choisir automatiquement) .
J'ai eu cette erreur et j'ai réussi à le réparer. Il y a plusieurs raisons qui peuvent conduire à cela, voici une liste de tâches à faire pour identifier le problème de l'exercice:
Créer une application micro, avec membre de la méthode unique.getalUsers (), Exécutez sur la machine à l'extérieur Active Directory (AD), avec mot de passe incorrect dans la chaîne de connexion, vérifiez si vous obtenez une exception de mot de passe incorrecte. Si vous ne l'obtenez pas, vous ne pouvez pas vous connecter à votre serveur d'annonces, vérifiez le pare-feu, si vous obtenez une exception de mot de passe invalide, goto prochaine étape.
Si vous le pouvez, essayez d'exécuter la même application, localy sur le serveur AD, d'abord avec un mot de passe incorrect, qu'avec correct, l'exécution de l'application fournit localement une exception plus détaillée, ce qui ne va pas (pour moi cette exception me conduise à la réparation de problèmes. ). Dans mon cas, cela m'a dit que le service de serveur n'est pas démarré que ce service de poste de travail n'est pas démarré.
Certaines réflexions sur le fait que les services de serveur et de poste de travail nécessitaient des services de serveur: Afaik Server Service est utilisé pour le partage de fichiers Windows (NetBIOS sur TCP) et utilise 445 ports, de sorte que ce port doit être que ce port doit être ouvert en plus du port LDAP. Ma deuxième observation était cet événement si 445 ports ouverts (NetStat -AN), il ne peut toujours pas fonctionner, Winows déposera tous les paquets à ce port si les cases à cocher Windows Client et Sharing des fichiers et d'imprimantes ne sont pas cochées sur l'adaptateur d'interface réseau qui a rendu ces paquets. . Cochez "telnet externe_ip 445". C'est toutes les informations que j'ai rassemblées en luttant avec ce problème.
Au cas où quelqu'un trébuche sur cela et veut écraser la tête sur un mur ... récemment essayé de faire tout cela pour un serveur public que mon entreprise avait dans un domaine différent de celui du contexte actuel. Utilisé l'IP fournie et obtenait des échecs comme indiqué ici. Même a utilisé un outil tel que Softerra LDAP admin et cela a fonctionné bien, mais la gestion de compte a échoué.
Nous avions une URL exposée publiquement accrochée à cette adresse IP (n'autorisant toujours que certaines IP de faire des appels). Une fois que j'ai remplacé la propriété intellectuelle avec l'URL fournie, cela fonctionnait comme un charme.
J'espère que cela sauver quelqu'un les heures de la tête qui se brise-moi, je viens de me mettre à travers.