it-swarm.com.de

"Vertrauensstellung zwischen ... und der primären Domäne ist in der MVC5-Authentifizierung fehlgeschlagen

Ich habe eine ASP .NET MVC5-Anwendung, in der ich nicht mit der Windows-Authentifizierung bin.

Alles funktionierte gut, bis ich versuchte, die Anwendung außerhalb der Domäne auszuführen, in der sie entwickelt wurde, und (aus welchem ​​Grund auch immer) ein:

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

wenn ich versuche, User.IsInRole("Admin") zu tun.

Ich verwende benutzerdefinierte Identity, Role, IdentityStore, RoleStore usw. von .NET Identity und ich kann sehen, dass die Benutzer- und Rollendaten korrekt aus der (MongoDB) -Datenbank abgerufen werden.

Es gibt viele Fragen zu diesem Problem, aber sie stammen von Personen, die möchten Windows-Auth verwenden. und Identitätswechsel in ihren MVC-Anwendungen:

Warum erhalte ich genau diese SystemException, wenn ich kein Active Directory verwende und (soweit ich weiß) nichts unternimmt, was von der Domäne des PCs abhängt? Fehlt mir eine Konfiguration (entweder in meinem Web.config oder IIS Express)?

BEARBEITEN:

Ok, so dass es ein bisschen eingegrenzt wird ...

Meine User.IsInRole("Admin")-Zeile befindet sich innerhalb einer if()-Anweisung in meiner _Layout.cshtml-Ansicht (d. H. Um zu wissen, was in der Navigationsleiste angezeigt werden soll, abhängig von der Rolle).

Ich weiß jetzt, dass ich nur den obigen Fehler bekomme, wenn kein Benutzer authentifiziert ist und ich mich nicht in der Domäne befinde, die ich für dev verwendet habe. Wenn ich einen Haltepunkt in dieser Zeile platziere, kann ich sehen, dass das User-Objekt ein System.Security.Principal.WindowsIdentity ist und dessen zugrunde liegendes IdentitySystem.Security.Principal.WindowsIdentity ist. 

Ist der Benutzer hingegen authentifiziert, sind das User-Objekt und ts IdentitySystem.Security.Claims.ClaimsPrincipal und System.Security.Claims.ClaimsIdentity.

Warum wird Windows Identity überhaupt verwendet (wenn es nicht authentifiziert wird) und wie kann ich es deaktivieren?

26
user1987392

Also, basierend auf meiner EDIT, habe ich meine _Layout.cshtml so geändert, anstatt dass

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

Ich habe

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

das scheint das Problem zu lösen.

Ich glaube, das Problem war, dass ASP .NET Identity eine empty WindowsIdentity verwendet, wenn kein Benutzer authentifiziert ist und wenn ich versuche, nach der User.IsInRole zu suchen, dann wird versucht, die Rollen einer WindowsIdentity gegen ein von mir freigegebenes Active Directory zu überprüfen nicht haben Natürlich sollte ich zuerst prüfen, ob der Benutzer überhaupt angemeldet ist, bevor ich versuche, seine Rollen zu überprüfen, so mea culpa.

Auch wenn die oben genannte Änderung meinen Code zu korrigieren scheint, wäre ich sehr daran interessiert, mehr über dieses Verhalten zu erfahren: Warum verwendet es einen leeren System.Security.Principal.WindowsIdentity, wenn kein Benutzer authentifiziert ist. Ich akzeptiere jede Antwort, die das erklärt.

27
user1987392

Ich hatte dieses Problem. Es ist fehlgeschlagen, wenn ich eine nicht vorhandene Active Directory-Gruppe getestet habe. 

Stellen Sie sicher, dass Sie eine vorhandene Gruppe verwenden!

4
David McEleney

Wir hatten dasselbe Problem auf einem neuen Produktionsserver. Verwenden des Identity Framework und Beschränken des Zugriffs auf ein bestimmtes Verzeichnis mit einer Datei web.config, durch die alle nicht authentifizierten Benutzer abgelehnt werden. Als nicht authentifizierte Benutzer versuchten, auf eine Seite in diesem Verzeichnis zuzugreifen, die User.IsInRole("RoleName")-Code enthielt, wurde der Fehler "Vertrauensbeziehung" angezeigt.

Keine der Korrekturen, die in anderen SO - Antworten erwähnt wurden, funktionierte für uns.

Es stellte sich heraus, dass wir nur die Formularauthentifizierung in IIS aktivieren mussten - Problem gelöst.

0
Scotty

Die Fehlermeldung "Vertrauensstellung zwischen der primären Domäne und der Arbeitsstation ist fehlgeschlagen" erfordert normalerweise, dass der Computer aus der Domäne entfernt und anschließend neu verbunden wird. Nun gibt es einige Möglichkeiten, dies zu tun. Wie im obigen Link enthalten, erhalten Sie Anweisungen, wie dies entweder auf dem Computer, der den Fehler anzeigt, oder aus der Ferne geschieht. Sie können dies auch in Active Directory und in PowerShell tun.

0
Laura

Ich habe das gerade in unseren Systemen gelöst, leider hat keiner der anderen Vorschläge für mich funktioniert. Das Problem wurde durch eine verwaiste SID in einem Netzwerkordner verursacht, auf den der Code zugreifen wollte. Einmal entfernt, funktionierte es wieder.

0
Jon

Für mich fehlten die Konfigurations-Tags des gesamten Mitgliedschaftsanbieters. Nachdem ich diese von einer unserer vorherigen Apps kopiert habe, hat es gut funktioniert.

  <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>
  • stellen Sie sicher, dass sich in der Datei web.config die obige Zeile befindet, und füllen Sie das Benutzerfeld mit dem richtigen Benutzernamen aus. 
0
albin.varghese

Ich hatte genau das gleiche Szenario mit dem benutzerdefinierten Authentifizierungsmodul und den gleichen Fehler, wenn ich IsInRole durchführte. Die übergeordnete Lösung (User.Identity.IsAuthenticated && ...) hat NICHT geholfen. Also habe ich ziemlich viel damit gespielt. Schließlich stellte ich fest, dass ich ein Attribut (preCondition = "managedHandler") aus meiner Moduldeklaration in der Datei web.config entfernen musste. Also statt:

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

Ich müsste haben:

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

Das hat mir geholfen!

0
Greg Z.