Как новое делегирование параметров аутентификации повышает безопасность

Опубликовано: 14 Апреля, 2023

Понимание делегирования аутентификации


Когда мы обсуждаем аутентификацию или процесс подтверждения личности для предоставления доступа, мы обычно думаем о пользователях и компьютерах, которые должны пройти аутентификацию. Однако когда службам (программам, предоставляющим функциональные возможности для поддержки других программ) необходимо получить доступ к сетевым ресурсам для выполнения своей работы, они также должны быть аутентифицированы. Если бы они этого не сделали, это создало бы огромную дыру в безопасности, которую можно было бы использовать.


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


Настраивать делегирование могут только администраторы, имеющие полномочие Включить доверенные учетные записи компьютеров и пользователей для делегирования. Администраторы домена и администраторы предприятия имеют эту привилегию. Процедура разрешения пользователю быть доверенным для делегирования зависит от уровня функциональности домена. На функциональном уровне Windows 2000 или Windows Server 2003 это делается в инструменте «Пользователи и компьютеры Active Directory» (ADUC), выбирая контейнер «Пользователи», щелкая правой кнопкой мыши учетную запись пользователя, которому вы хотите доверять делегирование, и щелкая «Свойства». Разница заключается в используемой вкладке: в домене Windows Server 2003 это вкладка «Делегирование» ; в собственном домене Windows 2000 это вкладка «Учетная запись». В любом случае вы просто устанавливаете флажок Учетная запись доверена для делегирования.


Где находится вкладка «Делегирование»?


В случае функционального уровня Windows Server 2003 вы не увидите вкладку «Делегирование», если для учетной записи не зарегистрировано имя участника-службы (SPN). Обычно имена участников-служб регистрируются только для учетных записей служб. Обычные учетные записи пользователей не имеют имени участника-службы по умолчанию, но вы можете зарегистрировать его с помощью средства Setspn, входящего в состав средств поддержки на установочном компакт-диске Windows Server 2003.


Для этого вам необходимо сначала установить инструменты поддержки, если вы еще этого не сделали. Затем откройте командную строку и введите setspn. Это покажет вам синтаксис и переключатели для команды.


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



Setspn - Боб http/bobjones


В этом примере «http/bobjones» — это SPN, а bob — это имя учетной записи пользователя в Active Directory.


Вывод этой команды показан на рисунке А.



Изображение 26194
РИСУНОК А


Доверие учетной записи для делегирования


Вы можете доверять учетной записи для делегирования любой службе или одной или нескольким определенным службам, как показано на рисунке B. Если вы доверяете учетной записи для делегирования определенной службе, вы можете указать, что будет использоваться только проверка подлинности Kerberos, или вы можете разрешить использование любого протокола аутентификации.



Изображение 26195
РИСУНОК Б


Если вы решите доверять определенным службам, вам нужно будет добавить службы, нажав кнопку «Добавить». Затем выберите имя компьютера, на котором запущена служба, и выберите из списка службы, которым вы хотите делегировать полномочия, как показано на рисунке C.



Изображение 26196
РИСУНОК C


Так что же нового в Windows Server 2003? В Windows 2000 делегирование аутентификации могло использовать только протокол аутентификации Kerberos. Теперь это ограничение больше не действует. Благодаря новой функции, называемой сменой протокола, клиент может аутентифицироваться на сервере с использованием других протоколов аутентификации ( если вы разрешили использование любого протокола, по умолчанию по-прежнему используется только Kerberos). Если вы разрешите любой протокол проверки подлинности, будет использоваться протокол, который использовался для первоначальной проверки подлинности «клиент-сервер». Это может быть NTLM, сопоставление сертификатов SSL или дайджест-аутентификация.


Еще одна новая функция — ограниченное делегирование. Это то, что позволяет администраторам доверять учетной записи для делегирования, не позволяя делегировать ее какой-либо службе. В Windows 2000 не было возможности указать, каким именно SPN может быть делегирована учетная запись. Вместо этого все службы под локальной системной учетной записью на компьютере были доверенными для делегирования. Возможность указать только определенные службы для делегирования неизмеримо повышает безопасность ваших учетных записей и, следовательно, сети в целом.


Также отличается то, что происходит под капотом, когда вы используете аутентификацию Kerberos. В Windows 2000 для делегирования требовался сервисный билет. Билет на предоставление билета пользователя (TGT) был встроен в сервисный билет. TGT использовался учетной записью, которой доверяли, для запроса служебных билетов к другим службам. Теперь, с Windows Server 2003, нет необходимости в TGT. Это еще одна особенность перехода протокола.



Резюме


Windows Server 2003 улучшила и усилила безопасность во многих отношениях — как в том, что видно пользователю и администратору, так и в том, что происходит «под капотом». Делегирование аутентификации стало намного более гибким благодаря новой функции перехода протокола, которая позволяет вам использовать протоколы, отличные от Kerberos, а также благодаря новой возможности ограничивать или ограничивать делегирование, чтобы вы могли контролировать службы, которым учетная запись может делегировать.


Делегирование является важной частью стратегии проверки подлинности вашей сети, поэтому администраторы Windows приветствуют эти функции.