"Доверительные отношения между... и основным доменом не удались" в аутентификации MVC5

У меня есть приложение ASP.NET MVC5, в котором я не использую проверку подлинности Windows.

Все работало нормально, пока я не попытался запустить приложение за пределами домена, в котором оно разрабатывалось, и (по какой-либо причине) получило:

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

когда я пытаюсь сделать User.IsInRole("Admin").

Я использую пользовательские Identity, Role, IdentityStore, RoleStore и т.д. Из.NET Identity и вижу, что данные о пользователях и RoleStore правильно извлекаются из базы данных (MongoDB).

Есть много вопросов по этой проблеме, но они от людей, которые хотят использовать Windows Auth. и олицетворение в своих приложениях MVC:

Так почему именно я получаю это SystemException если я не использую Active Directory и (насколько я знаю) не делаю ничего, что может зависеть от домена ПК? Я что-то пропустил (в моем файле Web.config или IIS Express)?

РЕДАКТИРОВАТЬ:

Хорошо, так что немного сузить

Моя строка User.IsInRole("Admin") находится внутри оператора if() в моем _Layout.cshtml View (т. _Layout.cshtml Чтобы узнать, что показывать в панели навигации в зависимости от роли).

Теперь я знаю, что я получаю ошибку только выше, когда ни один пользователь не аутентифицирован, и я не в домене, который использовал для dev. Если я помещу точку останова в эту строку, я смогу увидеть, что объект User является System.Security.Principal.WindowsIdentity а его базовый Identity - System.Security.Principal.WindowsIdentity.

С другой стороны, если пользователь проходит проверку подлинности, то объектом User и ts Identity являются System.Security.Claims.ClaimsPrincipal и System.Security.Claims.ClaimsIdentity.

Почему он вообще использует Windows Identity (если он не прошел проверку подлинности) и как его отключить?

ОТВЕТЫ

Ответ 1

Итак, основываясь на моем EDIT, я изменил свой _Layout.cshtml, чтобы вместо

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

У меня

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

который, как представляется, решает проблему.

Я считаю, что проблема заключалась в том, что ASP .NET Identity использует пустой WindowsIdentity, когда пользователь не аутентифицирован, и когда я пытаюсь проверить User.IsInRole, тогда он попытается проверить роли WindowsIdentity в отношении Active Directory, которых у меня нет. Очевидно, я должен сначала проверить, не был ли пользователь даже зарегистрирован, прежде чем пытаться проверить его роли, поэтому mea culpa.

Но, хотя изменение выше, похоже, исправляет мой код, мне было бы очень интересно узнать больше об этом поведении: почему он использует пустой System.Security.Principal.WindowsIdentity, когда пользователь не аутентифицирован. Я приму любой ответ, который объясняет это.

Ответ 2

У меня была эта проблема - мне не удалось, если бы я протестировал активную группу каталогов, которой не было.

Убедитесь, что вы используете существующую группу!

Ответ 3

Сообщение об ошибке "доверительное отношение между основным доменом и рабочей станцией не удалось". usaully требует, чтобы компьютер был удален из домена, а затем вернулся. Теперь есть несколько способов сделать это. Как указано в ссылке выше, приведены инструкции о том, как это сделать либо на компьютере, отображающем ошибку, либо удаленно. Вы также можете сделать это в Active Directory и в PowerShell.

Ответ 4

<authorization>
            <allow roles="pri\Domain Users" users="pri\domain_user" />
            <deny users="?" />
</authorization>
  • убедитесь, что у вас есть указанная выше строка в файле web.config и заполните поле пользователя с правильным именем пользователя.

Ответ 5

У нас была такая же проблема на новом производственном сервере. Использование Framework Identity Framework и ограничение доступа к определенному каталогу с файлом web.config, запрещающим пользователям, не прошедшим проверку подлинности. Когда пользователи, не прошедшие проверку подлинности, попытались получить доступ к странице в этом каталоге, содержащем какой-либо код User.IsInRole("RoleName"), они получали ошибку "Trust relationship...".

Ни одна из исправлений, упомянутых в других ответах SO, не сработала для нас.

Оказывается, нам просто нужно включить проверку подлинности в IIS - проблема решена.

Ответ 6

Я только что решил это в наших системах, к сожалению, ни один из других предложений не работал у меня. Проблема была вызвана сиротским SID в сетевой папке, к которой пытался получить доступ код. После удаления он снова начал работать.

Ответ 7

У меня был точно такой же сценарий с настраиваемым модулем аутентификации и той же ошибкой при выполнении IsInRole. Решение самого высокого уровня (User.Identity.IsAuthenticated & &...) НЕ помогло. Итак, я немного поиграл с этим. Наконец, я обнаружил, что мне пришлось удалить атрибут (preCondition = "managedHandler" ) из моего объявления модуля в файле web.config. Итак, вместо:

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

Мне нужно было бы:

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

Это помогло!

Ответ 8

Для меня отсутствовали целые теги конфигурации провайдера членства. После того, как я скопировал их из одного из наших предыдущих приложений, все заработало нормально.

  <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>