Страницы: 1 .. 7 8 9 10 11 .. 16

Глава 8. Защита Active Directory
Одна из основных причин развертывания службы каталога Active Directory состоит в обеспечении безопасности корпоративной сети. Каждая компания хранит важнейшую для своего бизнеса информацию на файловых серверах в сети. Управление безопасным доступом к информации должно гарантировать, что доступ к данным получат только должным обраЗЬм уполномоченные пользователи. Почти все компании развертывают почтовые серверы типа Microsoft Exchange 2000 Server, и они должны гарантировать пользователям безопасный доступ к почтовым ящикам. Служба Active Directory Microsoft Windows Server 2003 обеспечивает такой уровень защиты.
Эта глава начинается с введения в основы безопасности Active Directory. Служба каталога Active Directory использует несколько основных концепций для обеспечения безопасности сети Windows Server 2003. После введения в основы защиты будет показан основной компонент этой защиты, состоящий из аутентификации и функций разрешения, который используется в Active Directory для обеспечения гарантии того, что пользователи действительно являются теми, кем они себя представляют (аутентификация), и для обеспечения доступа к тем ресурсам, к которым пользователь должен иметь доступ (разрешение). Система Windows Server 2003, подобно Microsoft Windows 2000, использует Kerberos в качестве основного протокола защиты, поэтому большая часть этой главы посвящена роли Kerberos в аутентификации и разрешениях.
Основы защиты Active Directory
Существуют некоторые основные концепции, необходимые для понимания принципов защиты Active Directory в сети Windows Server 2003. Защита Active Directory строится на двух типах объектов и на взаимодействии между ними. Первый объект - участник безопасности, который представляет пользователя, группу, службу или компьютер, который нуждается в доступе к некоторому ресурсу в сети. Второй объект -это сам ресурс, являющийся объектом, к которому нужно получить доступ участнику безопасности. Чтобы обеспечить надлежащий уровень защиты, служба Active Directory должна идентифицировать участников безопасности, а затем предоставлять правильный уровень доступа к ресурсам.
Участники безопасности
Только участники безопасности службы Active Directory могут входить в Active Directory и получать разрешения на доступ к ресурсам сети. Участник безопасности - это объект Active Directory, который представляет пользователя, группу, службу или компьютер. Каждому участнику безопасности при создании объекта назначается идентификатор защиты (SID). Идентификатор SID составлен из двух частей. Первая часть -идентификатор домена, все участники безопасности в домене имеют один и тот же идентификатор домена. Вторая часть идентификатора SID -относительный идентификатор (RID), который является уникальным для каждого участника безопасности в домене Active Directory.
Идентификатор SID является основным компонентом конфигурирования защиты для ресурсов, расположенных в сети Windows Server 2003. При выдаче разрешения на доступ к ресурсу вы используете отображаемое имя участника безопасности, но Windows Server 2003 фактически использует SID для управления доступом к ресурсу. Когда пользователь пытается обратиться к ресурсу, расположенному на сервере в домене, операционная система предоставляет разрешение идентификатору SID пользователя, а не имени человека. Это означает, что если отображаемое имя пользователя изменено, разрешения, представленные пользователю, не изменяются. Однако если пользовательский объект удален, а затем создан заново с тем же самым именем, пользователь не сможет обращаться к ресурсам, так как SID изменится.
Списки управления доступом
Еще один компонент, включенный в защиту Active Directory, - это объект, к которому участник безопасности должен обращаться. Этот может быть другой объект Active Directory, например, организационная единица (OU), принтер или участник безопасности. Объект может быть файлом на сервере с системой Windows Server 2003 или почтовым ящиком на сервере с Microsoft Exchange 2000 Server.
Разрешения, которые предоставляются этим объектам, расположены в списке управления доступом (ACL - Access Control List), также называемом дескриптором защиты (security descriptor). Каждый объект в Active Directory или в разделе файловой системы NTFS имеет дескриптор защиты. Дескриптор защиты включает идентификатор SID участника безопасности, который владеет объектом, а также SID для основной группы объекта. Кроме того, каждый объект имеет два отдельных списка ACL: список управления разграничительным доступом (DACL — Discretionary Access Control List) и список управления системным доступом (SACL - System Access Control List). Список DACL перечисляет участников безопасности, которым были назначены разрешения на доступ к объекту, а также уровень разрешений, которые были назначены
каждому участнику безопасности. Список DACL состоит из записей управления доступом (АСЕ — Access Control Entries). Каждая запись АСЕ содержит идентификатор SID и определяет уровень доступа к объекту, который разрешен данному SID. Список АСЕ включает записи для всех типов участников безопасности. Например, учетная запись пользователя может иметь разрешение Read (Чтение) для файла, а группа защиты -разрешение Full Control (Полное управление). Список DACL для файла имеет, по крайней мере, две записи АСЕ, одну - на предоставление пользователю разрешения Read, другую - на предоставление группе разрешения Full Control.
Список SACL перечисляет участников безопасности, чей доступ к ресурсу должен подвергаться аудиту. Список записей АСЕ в SACL указывает, чей доступ должен подвергаться аудиту, а также необходимый уровень аудита.
Примечание. Список DACL может содержать записи АСЕ, которые предоставляют доступ к ресурсу, а также АСЕ, которые запрещают доступ. Записи АСЕ, которые запрещают доступ, всегда перечисляются первыми в ACL, так что подсистема защиты сначала оценивает их. Если АСЕ запрещает доступ к ресурсу, то подсистема защиты не оценивает другие записи АСЕ, т.е. запись АСЕ, запрещающая доступ к ресурсу, всегда отменяет любую запись АСЕ, которая предоставляет доступ определенному идентификатору SID.
Лексемы доступа
Связующей точкой между SID участника безопасности и ACL является лексема доступа. Когда пользователь аутентифицируется через Active Directory, в процессе входа в систему ему назначается лексема доступа. Эта лексема включает основной SID пользователя, идентификаторы SID всех групп, которым принадлежит пользователь, а также права и привилегии пользователя.
Лексема доступа используется подсистемой защиты всякий раз, когда пользователь пытается обратиться к ресурсу. В этом случае лексема предъявляется компьютером клиента любому процессу или приложению, которые запрашивают информацию, касающуюся безопасности, перед получением доступа к ресурсу. Например, когда пользователь пытается обратиться к почтовому ящику сервера, на котором выполняется Exchange 2000 Server, лексема доступа предъявляется серверу. Подсистема защиты Exchange 2000 Server сравнивает идентификаторы SID в лексеме доступа с разрешениями, которые были предоставлены в списке ACL. Пользователь сможет открыть почтовый ящик, если это позволяют разрешения, предоставленные данному идентификатору SID.
Аутентификация
Чтобы процессы защиты, включающие использование идентификаторов SID и записей ACL, работали должным образом, должен существовать какой-то способ, которым пользователь получает доступ к сети. По существу, пользователи должны иметь возможность доказать, что они являются теми, кем они себя представляют, чтобы извлечь свою лексему доступа с контроллера домена. Этот процесс называется аутентификацией.
Аутентификация происходит перед входом клиента в систему. Когда пользователь садится за компьютер с системами Windows 2000 или Microsoft Windows XP Professional и вводит Ctrl+Alt+Del, служба Winlogon локального компьютера переключается на экран входа в систему и загружает файл Graphic Identification and Authentication (GINA) (Графическая идентификация и аутентификация) из библиотеки динамической компоновки (DLL). По умолчанию этот файл — Msgina.dll. Однако сторонние производители могут создавать альтернативные файлы GINA (например, клиент системы Netware использует файл Nwgina.dll). После того как пользователь впечатал имя пользователя, пароль и выбрал домен, GINA передает введенные «верительные грамоты» службе Winlogon. Winlogon передает информацию локальной службе безопасности LSA (Local Security Authority). Служба LSA немедленно применяет к паролю пользователя операцию одностороннего кэширования и удаляет понятный текстовый пароль, который пользователь напечатал. Затем вызывается соответствующий провайдер защиты (SSP — Security Support Provider) через интерфейс провайдеров защиты (SSPI - Security Support Provider Interface). Windows Server 2003 обеспечивает двух основных SSP-провайдеров для сетевой аутентификации — KerbeVos SSP и NT LAN Manager (NTLM) SSP. Если клиенты с системой Windows 2000, или более поздней, входят в сеть системы Windows 2000 или Windows Server 2003, выбирается SSP Kerberos, и информация передается SSP. Затем SSP связывается с контроллером домена для подтверждения подлинности пользователя. Опознавательный процесс с использованием протокола Kerberos будет описан далее в этой главе.
Если процедура входа в систему прошла успешно, значит, пользователь аутентифицирован, и ему предоставлен доступ к сети. Если пользователь вошел в домен и все ресурсы, к которым пользователю нужно обратиться, находятся в том же самом лесу, то это единственный момент аутентификации пользователя. Пока пользователь не выйдет из системы, все разрешения, которые он получит в сети, будут основаны на начальной аутентификации.
Разрешение
Разрешение (authorization) — это второй шаг в процессе получения доступа к сетевым ресурсам, он происходит после аутентификации. В про-
цессе аутентификации вы доказываете свою идентичность, впечатывая правильное имя пользователя и пароль. В процессе разрешения вам дается доступ к сетевым ресурсам. В процессе аутентификации для вас создается лексема доступа. В процессе разрешения вы предъявляете лексему доступа серверу или службе и запрашиваете доступ к ресурсу. Если идентификатор SID в вашей лексеме доступа соответствует идентификатору SID в записи ACL, которая предоставляет доступ, вам предоставляется доступ к ресурсу.
Защита с использованием протокола Kerberos
До сих пор в этой главе описывались основы защиты Active Directory без обсуждения фактического механизма, который осуществляет защиту. Основной механизм аутентификации в Active Directory — это протокол Kerberos. Протокол Kerberos был впервые разработан инженерами Массачусетского Технологического института (MIT) в конце 80-х годов. Текущая версия Kerberos - это версия 5 (Kerberos v5), которая описана в документе RFC 1510. Реализация Kerberos в Windows Server 2003 полностью совместима с документом RFC-1510 с некоторыми расширениями для аутентификации открытых (public) ключей.
Протокол Kerberos является заданным по умолчанию опознавательным протоколом для Active Directory систем Windows 2000 Windows Server 2003. Всякий раз, когда клиент с системой Windows 2000, или более поздней, подтверждает свою подлинность в Active Directory, он использует протокол Kerberos. Другой протокол, использующийся для подтверждения подлинности в Active Directory, - это NTLM, который поддерживается для обратной совместимости с клиентами, пользующимися более старыми версиями операционных систем. Протокол Kerberos имеет множество преимуществ по сравнению с NTLM.

• Взаимная аутентификация. При использовании протокола NTLM аутентификация происходит только в одном направлении, т.е. сервер подтверждает подлинность клиента. При использовании протокола Kerberos клиент может также подтверждать подлинность сервера, гарантируя, что сервер, который отвечает на запрос клиента, является правильным сервером.
• Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то сервер, на котором расположен ресурс, должен контактировать с контроллером домена для проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos, клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен соединяться с контроллером домена.
• Улучшенное управление доверительными отношениями. Доверительные отношения NTLM всегда односторонние, не транзитивные, они конфигурируются вручную. Доверительные отношения Kerberos конфигурируются автоматически, поддерживаются между всеми доменами леса и являются транзитивными и двусторонними. Кроме того, доверительные отношения Kerberos могут быть сконфигурированы между лесами и доменами Kerberos Windows Server 2003 и другими реализациями протокола Kerberos.
• Делегированная аутентификация. Когда клиент подключается к серверу, используя аутентификацию NTLM, сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным только на локальном сервере. С аутентификацией Kerberos сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным на другом сервере.

Примечание. Windows Server 2003 поддерживает аутентификацию через протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security — Защищенные сокеты/Защита транспортного уровня), аутентификацию Digest и аутентификацию Passport. Так как эти службы используются в среде интернета для аутентификации служб информационного интернет-сервера от Microsoft (IIS - Internet Information Services) версии 6.0, то эти опознавательные опции обсуждаться не будут.
Введение в протокол Kerberos
В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент, который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные пользователи могут получать доступ к ресурсу. Третий компонент — центр распределения ключей (KDC - Key Distribution Center), который служит центральным местом хранения пользовательской информации и главной службой, подтверждающей подлинность пользователей.
Протокол Kerberos определяет то, как эти три компонента взаимодействуют между собой. Это взаимодействие основано на двух ключевых принципах. Прежде всего, Kerberos работает, основываясь на предположении, что опознавательный трафик между рабочей станцией и сервером пересекает незащищенную сеть. Это означает, что никакой конфиденциальный опознавательный трафик никогда не посылается по сети открытым, незашифрованным текстом, а пользовательский пароль никогда не посылается по сети, даже в зашифрованной форме. Второй
принцип состоит в том, что протокол Kerberos имеет в своей основе опознавательную модель с общим секретом. В этой модели клиент и опознающий сервер владеют общим секретом, который неизвестен кому-либо еще. В большинстве случаев общий секрет — это пароль пользователя. Когда пользователь входит в сеть, защищенную протоколом Kerberos, пароль пользователя используется для шифрования пакета информации. Когда сервер Kerberos получает пакет, он расшифровывает информацию, используя копию пароля, хранящегося на сервере. Если расшифровка прошла успешно, то опознающий сервер знает, что пользователю известен общий секрет, и ему предоставляется доступ.
Примечание. Когда пользователь входит в систему, он обычно впечатывает свой пароль. Контроллер домена проверяет точность пароля. Однако поскольку Kerberos работает в предположении, что сеть не защищена, то эта проверка делается без пересылки пароля по сети.
Одной из проблем общего секрета является то, что пользователь и сервер, управляющий сетевым ресурсом, должны иметь какой-либо способ владения общим секретом. Если пользователь пробует получить доступ к ресурсу на определенном сервере, то учетная запись пользователя может быть создана на сервере с паролем, который знает только пользователь. Когда пользователь попытается обратиться к ресурсам на этом сервере, он может представить общий секрет (пароль) и получить доступ к ресурсу. Однако в корпоративной среде могут быть тысячи пользователей и сотни серверов. Управление различными общими секретами всех этих пользователей было бы непрактичным. Протокол Kerberos справляется с этой проблемой, используя центр распределения ключей (KDC - Key Distribution Center). Служба KDC выполняется как служба сервера в сети и управляет общими секретами всех пользователей в сети. KDC имеет одну центральную базу данных для всех учетных записей пользователей сети и хранит общий секрет каждого пользователя (в форме одностороннего кэша пароля пользователя). Когда пользователю требуется получить доступ к сети и сетевым ресурсам, служба KDC подтверждает, что пользователь знает общий секрет, а затем подтверждает подлинность пользователя.
Примечание. В терминологии Kerberos центральным сервером, управляющим учетными записями пользователя, является служба KDC. В реализации Kerberos сервера Windows Server 2003 этот сервер называется контроллером домена. Каждый контроллер домена Active Directory является KDC. В Kerberos граница, определенная пользовательской базой данных, расположенной на одном KDC, называется областью (realm). В терминологии Windows Server 2003 эта граница называется доменом.
Каждая служба KDC состоит из двух отдельных служб: службы аутентификации (AS - Authentication Service) и службы предоставления билетов (TGS — Ticket-Granting Service). Служба AS отвечает за начальный вход клиента в систему и выдает билет TGT (TGT - Ticket-Granting Ticket) клиенту. Служба TGS отвечает за все билеты сеанса, которые используются для доступа к ресурсам в сети Windows Server 2003.
Служба KDC хранит базу данных учетных записей, которая используется для аутентификации протоколом Kerberos. В реализации Kerberos Windows Server 2003 база данных управляется агентом системы каталога (DSA - Directory System Agent), который выполняется в пределах процесса LSA на каждом контроллере домена. Клиенты и приложения никогда не получают прямой доступ к базе данных учетных записей - все запросы идут через агента DSA, используя один из интерфейсов Active Directory. Каждый объект в пределах базы данных учетных записей (фактически, каждый атрибут каждого объекта) защищен с помощью списка ACL. Агент DSA гарантирует, что любые попытки обращения к базе данных учетных записей должным образом санкционированы.
Совет. Когда Active Directory устанавливается на первом контроллере домена в домене, создается специальная учетная запись, которая называется krbtgt. Эта учетная запись не может быть удалена или переименована, ее никогда нельзя разрешать (enable). При создании этой записи назначается пароль, который регулярным образом автоматически изменяется. Этот пароль используется для создания секретного ключа, предназначенного для шифрования и расшифровки билетов TGT, выдаваемых всеми контроллерами домена в домене.
Аутентификация на базе протокола Kerberos
На компьютерах с системой Microsoft Windows 2000 Professional или Windows XP Professional, на серверах с Windows 2000 Server или Windows Server 2003 аутентификация по протоколу Kerberos начинается с того, что служба LSA вызывает провайдера защиты Kerberos. Когда пользователь входит в систему, впечатывая имя пользователя и пароль, компьютер клиента применяет одностороннее хэширование к паролю пользователя для создания секретного ключа, который кэшируется в надежной памяти на компьютере. Одностороннее хэширование означает, что пароль не может быть восстановлен исходя из хэш-значения (hash).
Для осуществления процесса входа клиента в систему клиент и сервер выполняют следующие действия.

1. Провайдер Kerberos SSP на рабочей станции посылает опознавательное сообщение службе KDC (см. рис. 8-1). Это сообщение включает: •   имя пользователя;
• область (realm) пользователя (имя домена);
• запрос на TGT-билет;
• предварительные опознавательные данные, которые включают метку времени.

Предварительные опознавательные данные зашифрованы с помощью секретного ключа, полученного из пользовательского пароля.

Рис. 8-1. Получение билета Kerberos TGT

2. Когда сообщение достигдет сервера, сервер исследует имя пользователя, а затем проверяет базу данных каталога в поисках своей копии секретного ключа, связанного с данной учетной записью пользователя. Сервер расшифровывает зашифрованные в сообщении данные с помощью секретного ключа и проверяет временную метку. Если расшифровка прошла успешно, и временная метка отличается от текущего времени на сервере в пределах 5 минут, сервер готов подтвердить подлинность пользователя. Если расшифровка окажется неудачной, это означает, что пользователь ввел неправильный пароль, и аутентификация потерпит неудачу. Если временная метка отличается более чем на 5 минут от текущего времени на сервере, то аутентификация также потерпит неудачу. Причина такой маленькой разницы во времени состоит в том, что она должна предотвратить возможную попытку перехвата опознавательного пакета с последующим повторением его в более позднее время. Заданная по умолчанию максимальная допустимая разница во времени, составляющая 5 минут, может быть сконфигурирована в политике защиты домена.
3. После аутентификации пользователя сервер посылает клиенту сообщение, которое включает ключ сеанса и TGT (см. рис. 8-1). Ключ сеанса - это ключ шифрования, который клиент будет использовать для взаимодействия с KDC вместо секретного ключа клиента. TGT — это билет сеанса, который предоставляет пользователю доступ к контроллеру домена. В течение срока службы TGT клиент предъявляет TGT контроллеру домена всякий раз, когда ему требуется обратиться к сетевым ресурсам. Полное сообщение от сервера зашифровано с помощью секретного ключа пользователя. Кроме того, билет TGT зашифрован с помощью долгосрочного секретного ключа сервера.
4. Когда пакет прибывает на компьютер клиента, секретный ключ пользователя используется для расшифровки пакета. Если расшифровка прошла успешно и временная метка допустима, то компьютер пользователя предполагает, что центр KDC надежно идентифицировал пользователя, потому что ему знаком его секретный ключ. Ключ сеанса затем кэшируется на локальном компьютере, пока не кончится срок его действия или пока пользователь не сделает выход из системы рабочей станции. Этот ключ сеанса будет использоваться для шифрования всех будущих подключений к центру KDC, т.е. клиент больше не должен помнить секретный ключ, и он удаляется из кэша рабочей станции. Билет TGT сохраняется в зашифрованной форме в кэше рабочей станции.

Примечание. Протокол Kerberos включает в себя Authentication Service (AS) Exchange (Коммутатор аутентификационной службы), который является подпротоколом, предназначенным для выполнения начальной аутентификации пользователя. Только что описанный процесс использует подпротокол AS Exchange. Начальное сообщение, посланное клиентом к центру KDC, называется сообщением KRB_AS_REQ. Ответ сервера клиенту называется сообщением KRB_AS_REP.             *•

5. Пользователь был опознан, но он все еще не имеет никакого доступа к сетевым ресурсам. TGT - это билет сеанса, который предоставляет доступ к центру KDC, но чтобы получить доступ к каким-либо другим сетевым ресурсам, пользователь должен получить другой билет сеанса от KDC центра (см. рис. 8-2.) Рабочая станция клиента посылает запрос на билет сеанса к центру KDC. Запрос включает имя пользователя, билет TGT, предоставленный в процессе аутентификации, имя сетевой службы, к которой пользователь хочет получить доступ, и временную метку, которая зашифрована с использованием ключа сеанса, полученного в процессе AS Exchange.

Рис. 8-2. Получение билета сеанса Kerberos для сетевого ресурса

6. Служба KDC расшифровывает билет TGT, используя свой долгосрочный ключ. Затем она извлекает ключ сеанса из билета TGT и расшифровывает временную метку, чтобы убедиться, что клиент использует правильный ключ сеанса, и гарантировать, что временная метка допустима. Если ключ сеанса и временная метка приемлемы, то KDC готовит билет сеанса для доступа к сетевой службе.
7. Билет сеанса включает две копии ключа сеанса, который клиент будет использовать для соединения с требуемым ресурсом. Первая копия ключа сеанса зашифрована, используя ключ сеанса клиента, полученный в процессе начального входа в систему. Вторая копия ключа сеанса предназначена для сетевой службы и включает информацию о доступе пользователя. Эта часть билета сеанса зашифрована, используя секретный ключ сетевой службы, который неизвестен рабочей станции клиента, но известен и службе KDC и сетевой службе, потому что сервер, на котором расположен ресурс, является членом сферы KDC.
8. Рабочая станция клиента кэширует обе части билета сеанса в памяти.

Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса, посланный клиентом, называется сообщением KRB_TGS_REQ; ответ сервера - сообщением KRB_TGS_REP.

9. Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис. 8-3.)

Рис. 8-3. Доступ к сетевой службе

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

Примечание. Процесс, описанный в шагах 9 и 10, использует под-протокол Client/Server (CS) Exchange. Запрос клиента называется сообщением KRB_AP_REQ.
В предположении, что аутентификация и проверка разрешения прошли успешно, клиенту предоставляется доступ к ресурсам сервера. Если клиент нуждается в дальнейшем использовании ресурса или службы, то билет сеанса перемещается из кэша, предназначенного для билета клиента, и передается на целевой сервер ресурса. Если срок действия билета сеанса истек, клиент должен обратиться к KDC для получения нового билета.
Дополнительная информация. Вы можете посмотреть содержимое кэша клиента, используя инструменты, доступные для загрузки на веб-сайте Microsoft. Инструмент KList.exe предоставляет интерфейс командной строки для просмотра и удаления билетов Kerberos. Инструмент Kerberos Tray (Kerbtray.exe) обеспечивает для просмотра билетов графический интерфейс пользователя (GUI). На рисунке 8-4 показан пример информации, предоставленной инструментом Kerberos Tray. Инструмент Kerberos Tray доступен по адресу http://www.microsoft.com/ windows2000/techinjo/reskit/tools/existing/kerbtray-o.asp , а инструмент KList доступен по адресу http://www.microsoft.co7n/windows2000/techinfo/reskit/tools/ existing /klist-o. asp.

Рис. 8-4. Просмотр билетов Kerberos с помощью инструмента Kerberos Tray
Процесс получения доступа к сетевому ресурсу показывает, что центр KDC вовлечен только в процесс начального входа в систему клиента, когда клиент первый раз пробует обращаться к ресурсу, расположенному на определенном сервере. Когда пользователь впервые входит в систему, ему выдается билет TGT, который предоставляет клиенту доступ к центру KDC в течение срока службы билета. Когда клиент пробует соединиться с сетевым ресурсом, он снова входит в контакт с KDC и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный пользователь.

Аутентификация, пересекающая границы домена
Тот же самый опознавательный процесс применяется и в том случае, когда при подтверждении подлинности пользователя пересекаются границы домена. Например, компания может иметь лес с тремя доменами, как показано на рисунке 8-5.

Рис. 8-5. Аутентификация, пересекающая границы домена
Если пользователь, имеющий учетную записью в домене Fabrikam.com, перейдет в домен NAmerica.Contoso.com и попытается войти в сеть, рабочая станция клиента сможет соединиться с контроллером домена в домене Fabrikam.com. В этом случае компьютер клиента посылает начальный запрос входа в систему на контроллер домена NAmerica.Contoso.com. Контроллер домена определяет, что учетная запись пользователя расположена в домене Fabrikam.com, так что нужно переправить запросы рабочей станции клиента к этому домену. Если все домены были сконфигурированы с прямыми доверительными отношениями (shortcut trusts), то контроллер домена может напрямую направить компьютер клиента к контроллеру домена в домене Fabrikam.com. Однако если прямых доверительных отношений не было создано, то нет и прямого доверительного отношения между доменами NAmerica.Contoso.com и Fabrikam.com. В этом случае контроллер домена NAmerica направит компьютер клиента к контроллеру домена в домене Contoso.com. Направление включает ключ сеанса, предоставляющий доступ к контроллеру домена в домене Contoso.com. Ключ сеанса создается, когда домен NAmerica добавляется к лесу Contoso.com и создаются начальные доверительные отношения между этими двумя доменами. Ключ сеанса гарантирует, что запрос на вход в систему исходит от доверенного домена. Затем компьютер клиента посылает опознавательный запрос к домену Contoso.com. Теперь клиент направляется к контроллеру домена в домене Fabrikam.com. Снова это направление включает ключ сеанса, необходимый для доступа к контроллеру домена. Далее компьютер клиента посылает запрос TGT на свой домашний контроллер домена в Fabrikam.com.
Аналогичный процесс происходит тогда, когда клиент пробует получить доступ к ресурсу, расположенному за пределами домашнего домена пользователя. В этом случае клиент должен получить билет сеанса от контроллера домена, расположенного в том домене, где находится ресурс, пока он не сможет соединиться с правильным контроллером домена.
Опознавательный процесс влияет на проект леса, особенно если пользователи часто входят на домены, к которым они сами не принадлежат, или обращаются к ресурсам других доменов. Если вы разрабатываете лес с несколькими доменами, клиенту, вероятно, придется пересекать весь путь доверительных отношений между доменами. Если это случается часто, нужно поместить контроллеры домена корневых доменов ближе к пользователям. Можно также использовать прямые доверительные отношения, чтобы направления контроллера домена посылались нужным доменам напрямую.
Делегирование аутентификации
Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может быть распределена между несколькими серверами. Например, клиент для получения информации соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы пользователь получил доступ только к санкционированной информации, для обращения к крайнему серверу базы данных должны использоваться «верительные грамоты» пользователя (вместо «верительных грамот» сервера внешнего интерфейса). В системе Windows 2000 протокол Kerberos обеспечивает это двумя способами: путем использования прокси-билетов (proxy tickets) и ретранслированных билетов (forwarded tickets). Если прокси-билеты разрешены, то клиент пошлет запрос на билет сеанса к центру KDC, требуя доступ к крайнему серверу. Служба KDC предоставит билет сеанса и установит на билете флажок PROXIABLE. Затем клиент представит билет сеанса серверу внешнего интерфейса, который использует его для доступа к информации, расположенной на крайнем сервере. Главная проблема с про-кси-билетами состоит в том, что клиент должен знать отличительные характеристики крайнего сервера. Другой вариант состоит в использовании ретранслированных билетов. Если эти билеты разрешены, то кли-
ент посылает запрос AS Exchange к центру KDC, требуя билет TGT, позволяющий серверу внешнего интерфейса обратиться к крайним серверам. Служба KDC создает билет TGT и посылает его клиенту для пересылки серверу внешнего интерфейса, который использует билет TGT для получения билета сеанса, позволяющего обратиться к крайнему серверу от имени клиента.
Имеется два существенных недостатка, связанных с реализацией делегирования аутентификации в системе Windows 2000. Первый недостаток состоит в том, что делегирование аутентификации может использоваться только в том случае, если клиент аутентифицирован через протокол Kerberos. Клиенты с системами Windows NT, Microsoft Windows 95 и Windows 98 не могут использовать делегирование аутентификации. В Windows Server 2003 клиент может использовать любой опознавательный протокол. Второй недостаток системы Windows 2000 касается защиты делегирования. В Windows 2000 после получения сервером внешнего интерфейса ретранслированного билета от центра KDC он может использовать его для доступа к любой сетевой службе от имени клиента. Windows Server 2003 имеет опцию, ограничивающую делегирование, т.е. учетную запись можно сконфигурировать так, что это делегирование будет применяться только для определенных сетевых служб (основываясь на основных именах служб). Ограниченное делегирование доступно в случае, если функциональный уровень домена установлен на функциональный уровень Windows Server 2003.
Для успешного делегирования аутентификации нужна гарантия, что и учетная запись пользователя, и учетная запись компьютера (или службы) сконфигурированы так, чтобы поддерживать делегирование аутентификации. Для этого обратитесь к окну Properties (Свойства) пользователя через инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), выберите вкладку Account (Учетная запись), а затем просмотрите список Account Options (Опции учетной записи). Удостоверьтесь, что oпция Account Is Sensitive And Cannot Be Delegated (Учетная запись точна и не может быть делегирована) не выбрана. (По умолчанию опция не выбрана.) Чтобы сконфигурировать учетную запись службы для делегирования, нужно определить, является ли учетная запись, используемая службой для входа в систему, нормальной учетной записью пользователя, или она является учетной записью LocalSystem. Если служба выполняется под нормальной учетной записью пользователя, обратитесь к вкладке Account пользователя и удостоверьтесь, что опция Account Is Sensitive And Cannot Be Delegated не выбрана. (По умолчанию она не выбрана.) Если служба выполняется под учетной записью LocalSystem, то делегирование было сконфигурировано в окне Properties компьютерной учетной записи (см. рис. 8-6). Чтобы реализовать уровень аутентификации Windows 2000, выберите опцию Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру при делегиро-
вании к любой службе (Только протокол Kerberos)). Чтобы реализовать усовершенствованный уровень аутентификации Windows Server 2003, выберите опцию Trust This Computer For Delegation To Specified Services Only (Доверять этому компьютеру только при делегировании к указанной службе). Затем укажите, должен ли клиент подтверждать подлинность только с использованием протокола Kerberos, или он может использовать любой другой протокол, а затем выбрать службы (основываясь на основных именах служб, зарегистрированных в Active Directory), которым компьютер может представлять делегированные «верительные грамоты».

Рис. 8-6. Конфигурирование ограниченного делегирования для учетной записи компьютера
Конфигурирование Kerberos в Windows Server 2003
Как говорилось выше, протокол Kerberos по умолчанию задан в качестве опознавательного протокола для клиентов с системами Windows 2000, или более поздними, которые входят в Active Directory. Вы можете сконфигурировать несколько свойств Kerberos через политику безопасности домена. Чтобы обратиться к параметрам настройки политики Kerberos, откройте пункт Domain Security Policy (Политика безопасности домена) из инструментов администрирования и разверните папку Account Policies (Политики учетных записей) (см. рис. 8-7). Вам станут доступны следующие политики.

Рис. 8-7. Конфигурирование параметров настройки протокола Kerberos через Domain Security Policy (Политика безопасности домена)

• Enforce User Logon Restrictions (Усиление ограничений пользовательского входа в систему). Эта политика устанавливает опцию службы KDC, по которой при каждом запросе на билет сеанса проверяются установки прав пользователя на целевом компьютере. Если эта политика включена, то пользователь, запрашивающий билет сеанса, должен иметь права Allow Log On Locally (Разрешить локальный вход), если он вошел в систему в интерактивном режиме, или права Access This Computer From The Network (Доступ к этому компьютеру из сети) на целевом компьютере. Эти права назначаются в меню Local Policies\User Rights Assignment (Локальные политики\ Назначение прав пользователей) в пункте Domain Security Policy (Политика безопасности домена). По умолчанию эта политика включена.
• Maximum Lifetime For Service Ticket (Максимальный срок годности служебного билета). Эта политика устанавливает максимальное время (в минутах), в течение которого билет сеанса может использоваться для доступа к определенной службе. Если установлен нуль минут, то срок годности билета никогда не окончится. Если установлено ненулевое количество минут, то оно должно быть больше, чем 10 минут, и меньше или равно значению, установленному для параметра Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). По умолчанию эта установка составляет 600 минут (10 часов).
• Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). Эта политика устанавливает максимальное время (в часах), в течение которого может использоваться TGT-билет пользователя. После того как истечет срок годности TGT-биле-та, существующий билет должен быть возобновлен, иначе нужно затребовать новый билет в центре KDC. По умолчанию эта установка составляет 10 часов.
• Maximum Lifetime For User Ticket Renewal (Максимальный срок, в течение которого возможно обновление пользовательского билета). Эта политика устанавливает время (в днях), в течение которого TGT-билет может быть возобновлен (вместо получения нового TGT-биле-та). По умолчанию эта установка составляет 7 дней.
• Maximum Tolerance For Computer Clock Synchronization (Максимально допустимое расхождение в показаниях компьютерных часов). Эта политика устанавливает максимальную разницу во времени (в минутах) между временем на компьютере клиента и временем на контроллере домена, обеспечивающем аутентификацию по протоколу Kerberos, которую протокол Kerberos считает допустимой. Если разница во времени между показаниями этих двух компьютеров больше, чем допустимый уровень, все билеты Kerberos будут отвергнуты. По умолчанию эта установка составляет 5 минут. Имейте в виду, что в случае изменения этой установки при перезапуске компьютера она возвратится к заданному по умолчанию значению.

В большинстве случаев параметры настройки протокола Kerberos, заданные по умолчанию, являются приемлемыми. В средах с высоким уровнем безопасности можно уменьшить сроки службы билетов. Однако в этом случае клиенты должны будут более часто подключаться к центру KDC, создавая дополнительный сетевой трафик и лишнюю нагрузку на контроллерах домена.
Интеграция с инфраструктурой открытых ключей
В основе протокола Kerberos лежит опознавательная модель с общим секретом. Это обеспечивает превосходную защиту, но налагает одно важное ограничение на обеспечение доступа к сети Windows Server 2003. Это ограничение состоит в том, что каждый пользователь, который обращается к сети, должен иметь учетную запись в базе данных учетных записей службы KDC. Если пользователь не существует в базе данных, ему нельзя предоставить доступ к сети.
Эта модель хорошо работает в тех компаниях, в которых все пользователи, входящие в сеть, известны, и учетная запись может быть создана для каждого пользователя. Однако многие компании расширяют список пользователей, имеющих доступ к сетевым ресурсам, включая в него пользователей, которые не являются служащими. Компания может вступить в краткосрочное партнерство с другой компанией, и ей потребуется обеспечить доступ к сетевым ресурсам для служащих другой компании. Или компания захочет предоставить доступ к ресурсам, имеющимся в сети компании, определенным клиентам. В этих сценариях список людей, которым требуется доступ к сети, может быть очень длинным, так что создание учетной записи для каждого из пользователей будет непрактичным.
Инфраструктура открытых ключей (PKI - Public Key Infrastructure) стала основным средством для решения проблемы предоставления доступа к сети пользователям, не имеющим учетной записи пользователя. Система PKI отходит от модели аутентификации с общим секретом и заменяет ее опознавательной моделью, основанной на сертификате. В системе PKI пользователи аутентифицируются на основании того факта, что они имеют правильный сертификат. Система PKI основана на трех основных концепциях: открытые (public) и личные (private) ключи, цифровые сертификаты и сертификационные власти (СА - certificate authorities). PKI начинается с концепции, согласно которой каждый пользователь или компьютер, вовлеченный в информационный обмен, имеют два ключа: личный ключ и открытый ключ. Личный ключ известен только одному пользователю. Его можно сохранить на жестком диске компьютера, как часть роумингового (roaming) профиля, или на устройстве типа смарт-карты. Открытый ключ доступен любому, кто его попросит. Личные и открытые ключи связаны, но нет никакого способа извлечь личный ключ из открытого ключа. Эти ключи используются различными способами.
Один из способов состоит в шифровке информации при пересылке ее по сети. Открытый ключ пользователя используется для шифровки сообщения. Поскольку открытый ключ доступен любому, кто его запросит, то все могут посылать сообщение, зашифрованное с помощью открытого ключа пользователя. Однако, единственный ключ, с помощью которого можно расшифровать сообщение, — это личный ключ пользователя. Он является единственным человеком, способным расшифровывать сообщение. Кто-то другой, перехвативший этот пакет в сети, не имеет правильного личного ключа и не сможет прочитать сообщение.
Другой способ применения состоит в использовании цифровой подписи и печати для сообщений, посылаемых между двумя пользователями. Цифровая подпись используется для гарантии подлинности отправителя сообщения и целостности сообщения. Чтобы создать цифровую подпись, все сообщение подвергается математическому хэшированию. Хэш является «сверткой сообщения», или цифровым дайджестом (digest), который зашифрован с помощью личного ключа отправителя сообщения. Зашифрованный хэш посылается вместе с сообщением как цифровая подпись. Когда адресат получает сообщение, к нему применяется тот же самый хэш, создавая второй дайджест сообщения. Затем используется открытый ключ отправителя для расшифровки цифровой подписи. Если дайджест сообщения получателя идентичен расшифрованной подписи, то целостность и подлинность сообщения подтверждены.
Второй компонент PKI — цифровой сертификат. Цель применения сертификата состоит в том, чтобы идентифицировать владельца сертификата. Когда человек или компания обращаются к сертификационным властям (СА) для получения сертификата, СА-власти подтверждают подлинность человека или компании, запрашивающей сертификат. Когда
пользователю предоставляется сертификат, он получает соответствующий открытый ключ, а также личный ключ для сертификата. Сертификат подписан сертификационными властями с помощью цифровой подписи, добавляя к сертификату штамп подлинности СА-властей. Текущий стандарт для сертификатов -Х.509 v3. Сертификат включает информацию о человеке, компьютере или службе, для которых он был выпущен, информацию о самом сертификате (дата истечения срока годности) и информацию об СА-властях, выпустивших данный сертификат.
Сертификаты, необходимые для инфраструктуры PKI, выпускаются властями СА, которые являются сетевыми серверами, управляющими предоставлением и отменой удостоверений. Из-за важности PKI для интернета в настоящее время доступно множество СА-властей, включая популярные коммерческие СА типа Verisign и Thawte. Большинство интернет-клиентов, таких как Microsoft Internet Explorer, автоматически сконфигурированы доверять удостоверениям, выпущенным коммерческими властями С А. Вы можете установить свои собственные СА-вла-сти, используя Windows Server 2003. Сертификационная служба, поставляемая с Windows Server 2003, является СА-властью с полной функциональностью, которая может использоваться для выдачи удостоверений людям, работающим в пределах вашей компании, представляющим организации партнера.
Дополнительная информация. Планирование и развертывание инфраструктуры PKI требует значительных усилий. Windows Server 2003 обеспечивает опцию для создания PKI с использованием СА-властей предприятия, интегрированных в Active Directory. Развертывая СА-власти предприятия, можно сконфигурировать политики для автоматизации большинства административных усилий, связанных с выдачей и возобновлением удостоверений. Веб-сайт компании Microsoft и Help And Support Center (Центр справки и поддержки) в Windows Server 2003 содержат детальную информацию, необходимую для установки инфраструктуры PKI.
Одна из главных причин использования сертификатов состоит в том, чтобы позволить пользователям, не имеющим учетной записи в Active Directory, получать доступ к ресурсам в сети Windows Server 2003. Например, вы захотите установить безопасный веб-сайт, чтобы партнерские организации или клиенты могли получить доступ к некоторой конфиденциальной информации, касающейся вашей сети. Однако в Windows Server 2003 разрешение на доступ к сетевым ресурсам можно предоставлять только участникам безопасности. Нет никакой опции, позволяющей назначить разрешения, основываясь исключительно на сертификатах. Вы можете предоставить доступ к ресурсам для пользователей, имеющих удостоверения и не имеющих учетных записей пользователя Active
Directory, путем отображения сертификата на учетную запись пользователя и использованием учетной записи для назначения разрешений.
Windows Server 2003 обеспечивает два различных способа отображения сертификата на учетную запись пользователя.

• Однозначное отображение. В этом случае один сертификат отображается на одну учетную запись пользователя Windows Server 2003. При однозначном отображении вы должны назначить сертификат и создать учетную запись для каждого пользователя. Это может быть хорошим решением, если вы хотите дать доступ удаленным служащим компании к безопасным ресурсам через безопасный веб-сайт. Это не упрощает ваше администрирование, тем не менее, с помощью однозначного отображения имен можно управлять уровнем доступа каждого пользователя.
• Многозначное отображение. В этом случае несколько сертификатов отображаются на одно имя учетной записи Active Directory. Например, если вы создаете партнерские отношения с другой компанией, и служащим компании нужен доступ к безопасному веб-сайту, вы можете создать одну учетную запись пользователя. Затем вы можете с этой учетной записью связать такое количество сертификатов, какое захотите. Например, если та компания имеет свою собственную власть СА, вы можете создать правило, по которому все выданные ею удостоверения будут отображаться на одну учетную запись пользователя в вашем домене. Затем, используя эту запись, вы сможете назначать разрешения на сетевые ресурсы.

Совет. Можно отображать сертификаты на учетные запкси пользователя через инструмент Active Directory Users And Computers или Менеджер информационного сервера интернета (IIS) от Microsoft. В Active Directory Users And Computers используйте опцию Name Mappings (Отображение имен^, которая становится доступной при щелчке правой кнопкой мыши на учетной записи пользователя.
Интеграция со смарт-картами
Смарт-карты обеспечивают другой способ объединения инфраструктуры PKI с аутентификацией по протоколу Kerberos. Когда Kerberos используется без PKI, общий секрет между клиентом и службой KDC используется для шифрования обмена информацией с опознавательной службой при начальном входе в систему. Этот ключ получен из пароля пользователя, тот же самый ключ используется при шифровании и расшифровки информации. Смарт-карты используют модель инфраструктуры PKI, в которой и открытый, и личный ключи используются для шифрования и расшифровки информации, касающейся входа в систему.
Смарт-карта содержит открытый и личный ключи пользователя плюс сертификат Х.509 v3. Все это применяется при использовании пользователем смарт-карты для аутентификации в Active Directory. Процесс входа в систему начинается в тот момент, когда пользователь вставляет смарт-карту в устройство чтения смарт-карт и вводит свой личный идентификационный номер (PIN — personal identification number). Это интерпретируется властями LSA на компьютере как последовательность Ctrl+Alt+Del, и процесс входа в систему начинается.
Номер PIN используется для чтения сертификата пользователя и открытого и личного ключей со смарт-карты. Затем клиент посылает обычный TGT-запрос к службе KDC. Вместо посылки данных предварительной аутентификации (временная метка), зашифрованных с помощью секретного ключа пользователя, полученного из пароля, клиент посылает службе KDC открытый ключ и сертификат. Запрос TGT все еще включает в себя данные предварительной аутентификации, но он подписан с помощью личного ключа пользователя.
Когда сообщение достигает службы KDC, она проверяет сертификат клиента, чтобы убедиться в его правильности и в том, что СА-власти, выдавшие сертификат, являются доверенными властями. Служба KDC проверяет также цифровую подпись данных предварительной аутентификации, чтобы гарантировать подлинность отправителя сообщения и целостность сообщения. Если обе эти проверки дают положительный результат, служба KDC использует основное пользовательское имя (UPN), включенное в сертификат клиента, чтобы искать имя учетной записи в Active Directory. Если учетная запись пользователя правильна, то служба KDC подтверждает подлинность пользователя и посылает в ответ клиенту билет TGT, включающий ключ сеанса. Ключ сеанса зашифрован с помощью открытого ключа клиента, и клиент использует свой личный ключ для расшифровки информации. Затем этот ключ сеанса используется для всех подключений к службе KDC.
Совет. Установка входа в систему вашей сети с использованием смарт-карты требует значительного объема работы. Прежде всего, нужно развернуть СА-власти для выпуска сертификатов. Затем установить станции регистрации смарт-карт, где пользователи смогут получать свои смарт-карты, и где смарт-картам могут быть назначены правильные сертификаты и ключи. После начального развертывания нужно решить административные задачи, связанные с потерянными или забытыми картами. Смарт-карты обеспечивают превосходную дополнительную защиту вашей сети, но эта дополнительная защита связана со значительными административными усилиями.
Способность к взаимодействию с другими системами Kerberos
Поскольку в основе протокола Kerberos лежит открытый стандарт, он обеспечивает превосходные возможности для взаимодействия с другими системами, основанными на протоколе Kerberos. Любой из компонентов, который являются частью реализации протокола Kerberos Windows Server 2003, может быть заменен эквивалентным элементом, не принадлежащим системе Windows. Эти три компонента следующие:

• клиент Kerberos;
• центр распределения ключей Kerberos;
• сетевой ресурс, использующий протокол Kerberos для разрешений.

Имеются четыре возможных сценария взаимодействия.

• Клиенты Windows 2000 или Windows XP Professional могут входить на контроллер домена Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Windows 2000 или Windows XP Professional могут входить на KDC-центры, не принадлежащие Windows-платформе, и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут входить на KDC-центры Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут взаимодействовать с реализациями Kerberos, не принадлежащими Windows-платформе, и иметь доступ к ресурсам, расположенных на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.

Windows Server 2003 можно сконфигурировать для участия в любом из этих сценариев. Самый легкий вариант — это однородное решение, в котором вся среда основана или на Kerberos Windows Server 2003, или на реализации Kerberos, не принадлежащей Windows-платформе.
Однако реализация Kerberos Windows Server 2003 позволяет легко взаимодействовать с другими реализациями Kerberos. Для этого нужно создать доверительные отношения между областями домена Windows Server 2003 и областью Kerberos, не принадлежащей Windows-платформе. Доверительные отношения сферы могут быть сконфигурированы как транзитивные или нетранзитивные, а так же как односторонние или двухсторонние. Чтобы сконфигурировать доверительные отношения с другой областью, откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) и перей-
дите в окно Properties (Свойства) того домена, в котором вы хотите создать доверительные отношения. На вкладке Trusts (Доверительные отношения) щелкните на кнопке New Trust, запустив New Trust Wizard. С помощью мастера вы можете создать доверительные отношения со стороны Windows Server 2003 с другой областью Kerberos. На рисунке 8-8 показано окно Properties доверительного отношения области после его создания.

Рис. 8-8. Конфигурирование доверительного отношения между областями
Дополнительная информация. Microsoft обеспечивает пошаговое руководство для конфигурирования доверительных отношений Kerberos между областями. Это руководство, озаглавленное как «Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability» доступно на веб-сайте Microsoft по адресу http:// www.microsoft.com/technet/prodtechnol/windows2000serv/ howto/kerbstep.asp.
Безопасность протокола NTLM
Второй вариант аутентификации на контроллере домена Windows Server 2003 должен использовать NTLM-аутентификацию. Она поддерживается для совместимости с клиентскими компьютерами, на которых выполняются системы Windows NT 4, Windows 95 и Windows 98. Этот протокол используется в следующих ситуациях.

• Когда компьютер, на котором выполняются системы Windows 95, Windows 98 или Windows NT, подтверждает свою подлинность на контроллере домена Windows Server 2003. На компьютерах с системами Windows 95 и Windows 98 должна быть установлена служба Directory Services Client, или эти операционные системы смогут подтверждать подлинность только с использованием протокола LAN Manager.
• Когда компьютер, на котором выполняются системы Windows XP Professional или Windows Server 2003, подтверждает подлинность на Windows NT 4 Server.
• Когда любой клиент обращается к автономному серверу с системой Windows Server 2003.
• Когда клиент, на котором выполняются системы Windows XP Professional или Windows 2000, пробует войти на контроллер домена с Windows Server 2003, но не способен подтвердить подлинность, используя протокол Kerberos. В этом случае NTLM аутентификация может использоваться как альтернативный протокол.

Протокол NTLM значительно менее безопасен, чем Kerberos. С пакетом Windows NT 4 Service Pack 4 компания Microsoft представила новую версию протокола NTLM с именем NTLMv2. Эта новая версия включает дополнительную защиту, такую как создание уникального ключа сеанса каждый раз при установлении нового подключения, а также расширенный процесс обмена ключами для защиты ключей сеанса.
Резюме
В этой главе сделан краткий обзор основных концепций безопасности службы Active Directory Windows Server 2003, включая участников безопасности, списки управления доступом, аутентификацию и разрешения. Большая часть этой главы посвящена основным средствам обеспечения аутентификации и разрешений службы Active Directory через протокол Kerberos. Протокол Kerberos предлагает безопасный механизм подтверждения подлинности пользователей в Active Directory и получения доступа к сетевым ресурсам. Обсуждена также интеграция протокола Kerberos с инфраструктурой открытых ключей PKI, смарт-картами и другими реализациями Kerberos.

1 .. 7 8 9 10 11 .. 16