Kerberos - добавление имени участника-службы для пользователя домена
При добавлении нового имени участника-службы в домен Kerberos у вас есть возможность сопоставить имя участника-службы с пользователем. В общем, я присоединяюсь к домену через встроенную проверку подлинности Windows, и это создает новую учетную запись компьютера для службы, но сейчас я хотел бы попробовать использовать Kerberos без IWA.
Я полагаю, что у меня есть полное понимание того, как Kerberos проверяет подлинность клиентов для хоста компьютера (достаточно хорошо для того, что я пытаюсь сделать) - но что именно делает сопоставление имени участника-службы с пользователем домена?
Изменить: я не спрашиваю о том, как SPN работают в целом. Я спрашиваю конкретно о деталях сопоставления имени участника-службы с пользователем домена.
Ответ:
- Kerberos позволит этому конкретному пользователю ХОСТИНГ этой службы - вместо аутентификации с использованием учетной записи хоста компьютера сервер будет присоединен к домену Kerberos под этим конкретным пользователем. Аутентификация происходит через этого пользователя.
Любая дополнительная информация будет принята с благодарностью.
3 ответа
Учетная запись пользователя AD будет иметь имя участника службы, только если оно используется для запуска службы. Таким образом, большинство учетных записей пользователей AD не будут иметь имен участников службы. Наиболее распространенным примером случаев, когда учетная запись пользователя AD будет иметь имена участников-служб, является случай, когда эта учетная запись пользователя используется в качестве учетной записи службы для запуска MS SQL, IIS и т. Д. Если учетная запись пользователя AD используется для работы службы, но имя участника-службы не используется. зарегистрирован в AD, то этот сервис не может использовать Kerberos.
В отличие от учетных записей пользователей AD всегда будет иметь имя пользователя.
Имена участников службы связаны с субъектом безопасности (пользователем или группами), в контексте которого выполняется служба. SPN используются для поддержки взаимной аутентификации между клиентским приложением и службой. Имя участника-службы составляется из информации, которую клиент знает об услуге. Или он может получить информацию от доверенной третьей стороны, такой как Active Directory. Имя участника службы связано с учетной записью, и учетная запись может иметь много имен участников службы.
Вам следует прочитать документацию MSDN, если вы даже не уверены, какие проблемы решают SPN. Это тщательно и полно.
Чтобы немного восполнить пробелы, если ваша служба должна работать в контексте учетной записи пользователя.domain, то эта учетная запись пользователя должна иметь имя участника-службы.
Это обычно встречается в пулах приложений IIS. Если у вас есть несколько серверов IIS для приложения за балансировщиком нагрузки, у вас может быть не SPN, назначенный конкретному серверу, а учетная запись пользователя домена, и пулы приложений IIS запускаются в контексте этой учетной записи. Это будет особенно верно, если вы хотите выдать себя за аутентифицированного пользователя с помощью токена уровня "делегирование" и получить доступ к другой службе на удаленном компьютере.
То, как вы получаете токен аутентифицированного пользователя, не обязательно важно. Это может быть либо встроенный токен авторизации, либо токен, который вы создаете с использованием предоставленных учетных данных пользователя, например, с помощью аутентификации форм. Если используется ограниченное делегирование, вы можете выдать себя за пользователя без существующего токена авторизации или пароля, все что вам нужно - это имя пользователя.
Но для того, чтобы все это работало, SPN всегда требуется.