User.Identity.Name не возвращает правильные учетные данные при использовании проверки подлинности Windows в ASP.NET MVC

Я использую проверку подлинности Windows в своем приложении ASP.NET MVC, и мне предлагается ввести учетные данные на моем веб-сервере, который является членом домена [у меня есть учетные данные домена, и я могу нормально пройти проверку подлинности], однако, когда действие моего контроллера вызывает «User.Identity.Name» при попытке сравнить значение базы данных с текущим вошедшим в систему пользователем, это возвращает учетную запись SAM с локального компьютера, а НЕ учетную запись SAM из ДОМЕНА:

Имя пользователя локального компьютера (которое возвращает User.Identity.Name): LOCALPC \ username

Что я ожидаю (это то, что я проверяю в AD как): DOMAIN \ username

Это вызывает у меня проблемы, потому что я не могу точно подтвердить пользователя, используя только имя пользователя.

Мне что-то не хватает, есть ли способ вернуть то, что я в настоящее время аутентифицирован на веб-сервере, в отличие от локальной учетной записи SAM на клиентском компьютере?

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


asp.net asp.net-mvc windows-authentication
person Miguel G    schedule 22.04.2009    source источник
comment
При отладке приложения User.Identity показывает, что я аутентифицирован (поэтому я предполагаю, что у него где-то в кеше есть токен Windows), можно ли выдать себя за пользователя, для которого я аутентифицирован, чтобы получить учетную запись SAM этого пользователя?   -  person Miguel G    schedule 22.04.2009
comment
Кстати, я могу использовать олицетворение для достижения этого, но если бы я это сделал, мне понадобился бы способ доступа к учетным данным пользователей, чтобы олицетворять их учетные записи, что не является оптимальным (или даже вариантом для меня прямо сейчас) особенно, поскольку они уже ввели учетные данные, если они находятся за пределами домена. Потому что, опять же, если они получают доступ к сайту с машины, присоединенной к домену, это не проблема, это проблема только с машины, не входящей в домен.   -  person Miguel G    schedule 22.04.2009
comment
Я действительно не хочу кэшировать их учетные данные, если я сам попрошу их выдать себя за свою учетную запись, я предполагаю, что ответ на мой вопрос в основном будет заключаться в доступе к токену, который они используют для аутентификации в первую очередь, и попросить олицетворять их, используя ЭТО токен, чтобы затем получить свою учетную запись SAM (имя учетной записи).   -  person Miguel G    schedule 22.04.2009

Ответы (2)


arrow_upward
0
arrow_downward

При появлении запроса в вашем веб-браузере введите «ДОМЕН \ имя пользователя» вместо просто «имя пользователя» для аутентификации.

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

Это сервер разработки? Проверьте учетную запись, на которой работает IIS. Вы настраивали олицетворение в web.config?

person laktak    schedule 22.04.2009
comment
Если у обоих пользователей одинаковый пароль, да. Если нет, это не должно иметь значения. - person Martin C.; 22.04.2009
comment
Я всегда аутентифицируюсь как DOMAIN \ username, однако User.Identity.Name, по-видимому, не кэширует 'DOMAIN \ username' и просто возвращает 'LOCALPC \ username' при повторном запросе имени (что является проблемой), они не совпадают строки, поэтому их нельзя сравнивать друг с другом. - person Miguel G; 22.04.2009

arrow_upward
2
arrow_downward

Моя ошибка, проблема исправлена, это оказалась ошибка в моем коде, и тот факт, что моя машина не присоединена к домену, заставляло меня думать, что проблема связана со значением User.Identity.Name.

Спасибо всем за предложения, надеюсь, мой следующий вклад в этот сайт будет на менее глупой ноте.

--

Кстати, эта ссылка может помочь людям, которые ищут соответствующую информацию об аутентификации в IIS: http://blog.mike-obrien.net/PermaLink,guid,5e975b20-7b05-472f-bd80-04028ab8b6fa.aspx

person Miguel G    schedule 22.04.2009