Как аутентифицировать экземпляр WindowsIdentity?

Question

Я пытаюсь использовать Windows Identity Foundation для авторизации в приложении WPF client/server (WCF), которое может запускаться или не запускаться в той же среде доверия, что и активный каталог, предоставляющий аутентификацию. Например, аутентификация может предоставляться активным каталогом, но приложение может работать в облаке, а роли/разрешения пользователя для профиля будут предоставляться базой данных приложения.

Я чувствую, что не хватает основополагающую часть процесса WIF в моей голове для того, чтобы полностью понять, что я должен делать:

1. журналов пользователей в домене Windows, используя имя пользователя Active Directory/Пароль
2. Пользователь открывает мое приложение.
3. Я ссылаюсь на WindowsIdentity зарегистрированного пользователя и теперь могу посмотреть их токен входа и все их настроенные роли/заявки - но так же, как они могут войти в домен, они могут войти в свою собственную машину и все равно иметь Идентификатор WindowsIdentity.
4. Я могу связать идентификатор пользователя Windows с их профилем пользователя в своей базе данных и предоставить им доступ к определенным функциям моего приложения, которые их профиль позволяет им.

Кусок, который мне не хватает, заключается в том, что у меня есть экземпляр WindowsIdentity из WindowsIdentity.GetCurrent() ... как я могу проверить, что сгенерировало это? то есть он является пользователем локальной машины или пользователем активного каталога, и если это активный пользователь каталога, откуда я знаю, что это мой bona fide active directory server?

Например - несколько сценариев:

Сценарий 1

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

В этом случае у пользователя есть локальная учетная запись пользователя, а не активная учетная запись каталога, и она имеет поддельное удостоверение, созданное для целенаправленной защиты приложения.

Я предполагаю, что есть какой-то способ определить, что это учетная запись локального пользователя Windows, а не пользователя Active Directory? Я мог бы позвонить в мой активный каталог для учетной записи пользователя с именем пользователя, найденным в WindowsIdentity, и сравнить идентификаторы SID, чтобы определить, что на самом деле это поддельная учетная запись пользователя, и пользователю должен быть отказано в доступе.

Это правильный способ сделать это? Есть ли какой-то способ, который я могу сказать из WindowsIdentity, что он был выпущен моим активным каталогом и что это удостоверение не было подделано?

Сценарий 2

1. Пользователь создает поддельный сервер Active Directory с таким же именем, как моя активной директория и создает учетную запись, имитирующую тот же процесс, как локальный пользователь описанную в сценарии 1.

Теперь у меня есть активный пользователь каталога с тем же именем домена и именем пользователя, то же решение, которое я предложил для сценария 1, также решит проблему для этого сценария, но было бы неплохо определить, что этот токен не был создан моим активным директором y, просто изучив токен.

Может кто-то прояснить, что мне не хватает - или я вообще ничего не пропустил? Должен ли я просто позвонить в Active Directory для проверки подлинности, предоставляемой службой WindowsIdentity, доступ к моему приложению?

Answer 1

Простой ответ: Ваш активный каталог идентифицирован не только именем. Когда ваш компьютер присоединяется к домену, он обменивает набор учетных данных. Подмена активного каталога или любого другого компьютера намного сложнее, чем просто создание компьютера с тем же именем. Windows заботится обо всех проверках подлинности между машинами. Ошибки и уязвимости в стороне вы можете быть уверены, что при вызове WindowsIdentity.GetCurrent() существует целая цепочка тяги, поддерживаемая разными учетными данными для аутентификации пользователя.

Более полный ответ: Есть два типа аутентификации Windows:

1. Первый тип среди сверстников в сети (т.е. за пределами домена). В этом случае, когда пользователь на компьютере A подключается к компьютеру B, на самом деле используется локальный пользователь B. Если пользователь из B имеет то же имя и пароль, что и пользователь в A, тогда аутентификация происходит без вмешательства пользователя. Если не появляется экран входа в систему, и пользователю необходимо предоставить учетные данные для некоторого пользователя в B. В любом случае пользователь фактически вступает в систему на компьютер B, а B не нужно доверять или знать о локальном использовании на компьютере A.
2. Второй тип - в домене. Я считаю, что вы можете добавлять пользователей только из домена, если сам компьютер находится в домене или в домене с доверительными отношениями с ним. В любом случае, когда компьютер B будет иметь другой набор учетных данных, который позволяет ему аутентифицировать контроллер (ы) домена. Теперь, когда пользователь с компьютера A хочет подключиться к компьютеру B, запрашивает контроллер домена (который он знает и доверяет) для аутентификации пользователя. Как только он получит OK от контроллера домена, пользователь будет принят.

Windows поддерживает различные протоколы аутентификации, которые являются более новыми и более надежными, чем другие. Сетевой администратор настраивает, какие протоколы принимаются. Большинство (все?) Протоколов не связаны с отправкой фактического пароля по сети (посмотрите на digest authentication для примера такого протокола или читайте о the old NTLM protocols)