web-dev-qa-db-fra.com

"La relation de confiance entre ... et le domaine principal a échoué" dans l'authentification MVC5

J'ai une application ASP .NET MVC5 dans laquelle je n'utilise pas à l'aide de l'authentification Windows.

Tout fonctionnait bien jusqu'à ce que j'essaye d'exécuter l'application en dehors du domaine dans lequel elle était développée et (pour une raison quelconque), d'obtenir un:

The trust relationship between this workstation and the primary domain failed.

quand j'essaie de faire User.IsInRole("Admin").

J'utilise custom Identity, Role, IdentityStore, RoleStore, etc. à partir de Identity .NET et je vois que les données sur l'utilisateur et le rôle sont correctement extraites de la base de données (MongoDB).

Il y a beaucoup de questions sur ce problème, mais ce sont des gens qui veulent utiliser utiliser Windows Auth. et emprunt d'identité dans leurs applications MVC:

Alors, pourquoi ai-je exactement cette SystemException si je n'utilise pas Active Directory et (autant que je sache) ne fais rien qui puisse dépendre du domaine du PC? Est-ce qu'il me manque une configuration (dans mon Web.config ou dans IIS Express)?

MODIFIER:

Ok, alors réduisons un peu ...

Ma ligne User.IsInRole("Admin") se trouve dans une instruction if() dans ma vue _Layout.cshtml (c’est-à-dire savoir quoi afficher dans la barre de navigation en fonction du rôle).

Je sais maintenant que je ne reçois l'erreur ci-dessus que si aucun utilisateur n'est authentifié et que je ne suis pas dans le domaine que j'ai utilisé pour dev. Si je place un point d'arrêt sur cette ligne, je peux voir que l'objet User est un System.Security.Principal.WindowsIdentity et que sa Identity sous-jacente est System.Security.Principal.WindowsIdentity. 

Par contre, si l'utilisateur est authentifié, l'objet User et ts Identity sont System.Security.Claims.ClaimsPrincipal et System.Security.Claims.ClaimsIdentity.

Pourquoi utilise-t-il Windows Identity (s'il n'est pas authentifié) et comment puis-je le désactiver?

asp.netasp.net-mvcasp.net-mvc-5asp.net-identity
26
user1987392

Donc, sur la base de mon EDIT, j'ai modifié mon _Layout.cshtml afin qu'au lieu d'avoir

@if(User.IsInRole("Admin"))  {...}

J'ai

@if(User.Identity.IsAuthenticated && User.IsInRole("Admin")) {...}

qui semble résoudre le problème.

Je crois que le problème était que ASP .NET Identity utilise un vide WindowsIdentity quand aucun utilisateur n'est authentifié et lorsque j'essaie de rechercher User.IsInRole, il essaiera de vérifier les rôles d'un WindowsIdentity par rapport à un Active Directory que je ne connais pas. ne pas avoir. Évidemment, je devrais d'abord vérifier si l'utilisateur est même connecté avant de tenter de vérifier ses rôles, donc mea culpa.

Mais, même si la modification ci-dessus semble corriger mon code, j'aimerais en savoir plus sur ce comportement: pourquoi utilise-t-il un System.Security.Principal.WindowsIdentity vide alors qu'aucun utilisateur n'est authentifié. Je vais accepter toute réponse qui explique cela.

27
user1987392

J'ai eu ce problème - Cela a échoué pour moi si j'ai testé un groupe Active Directory qui n'existait pas. 

Assurez-vous que vous utilisez un groupe qui existe!

4
David McEleney

Nous avions le même problème sur un nouveau serveur de production. Utilisation d’Identity Framework et restriction de l’accès à un répertoire spécifique avec un fichier web.config refusant les utilisateurs non authentifiés Lorsque des utilisateurs non authentifiés tentaient d'accéder à une page de ce répertoire contenant un code User.IsInRole("RoleName"), ils obtenaient l'erreur "Trust relationship ...".

Aucune des corrections mentionnées dans d'autres réponses SO n'a fonctionné pour nous.

Il s'avère que nous devions simplement activer l'authentification par formulaire dans IIS - le problème était résolu.

0
Scotty

Le message d'erreur "La relation de confiance entre le domaine principal et le poste de travail a échoué" nécessite généralement que l'ordinateur soit supprimé du domaine, puis rejoint . Maintenant, il y a plusieurs façons de le faire. Comme indiqué dans le lien ci-dessus, vous trouverez des instructions sur la procédure à suivre, soit sur l'ordinateur affichant l'erreur, soit à distance. Vous pouvez également le faire dans Active Directory et dans PowerShell.

0
Laura

Je viens de résoudre ce problème dans nos systèmes. Malheureusement, aucune des autres suggestions ne m'a été utile. Le problème était dû à un SID orphelin dans un dossier réseau auquel le code tentait d'accéder. Une fois retiré, il a recommencé à fonctionner.

0
Jon

Pour moi, il manquait toutes les balises de configuration du fournisseur d'adhésion. Après avoir copié celles de nos applications précédentes, cela a bien fonctionné.

  <system.web>
<authentication mode="Windows" />
<compilation debug="true" targetFramework="4.7.1" />
<httpRuntime targetFramework="4.7.1" />
<httpModules>
  <add name="TelemetryCorrelationHttpModule" type="Microsoft.AspNet.TelemetryCorrelation.TelemetryCorrelationHttpModule, Microsoft.AspNet.TelemetryCorrelation" />
  <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>
  <profile defaultProvider="DefaultProfileProvider">
  <providers>
    <add name="DefaultProfileProvider" type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" applicationName="/" />
  </providers>
</profile>
<membership defaultProvider="DefaultMembershipProvider">
  <providers>
    <add name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" />
  </providers>
</membership>
<roleManager defaultProvider="CustomRoleProvider" enabled="true" cacheRolesInCookie="false">
  <providers>
    <add name="CustomRoleProvider" type="ABC.ABCModels.ABCRoleProvider" />
  </providers>
</roleManager>
<sessionState mode="InProc" customProvider="DefaultSessionProvider">
  <providers>
    <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" />
  </providers>
</sessionState>

0
venu
<authorization>
            <allow roles="pri\Domain Users" users="pri\domain_user" />
            <deny users="?" />
</authorization>
  • assurez-vous que vous avez la ligne ci-dessus dans votre fichier web.config et complétez le champ utilisateur avec le nom d'utilisateur correct. 
0
albin.varghese

J'ai eu exactement le même scénario avec le module d'authentification personnalisé et la même erreur lorsque je fais IsInRole. La solution la mieux classée (User.Identity.IsAuthenticated && ...) n’a PAS aidé. Alors, j'ai pas mal joué avec ça. Enfin, j'ai découvert que je devais supprimer un attribut (preCondition = "managedHandler") de ma déclaration de module dans le fichier web.config. Donc, au lieu de:

  <system.webServer>
    ...
    <modules>
          ...
          <add name="CompanyAuthentication" type="Company.Authentication.AuthHttpHandler" preCondition="managedHandler" />
    </modules>

Je devrais avoir:

  <system.webServer>
    ...
    <modules>
          ...
          <add name="CompanyAuthentication" type="Company.Authentication.AuthHttpHandler" />
    </modules>

Cela a fait le tour pour moi!

0
Greg Z.