Идентификаторы безопасности в windows 2000 представляют собой

SID stands for Security Identifier and is used within NT/2000 as a value to uniquely identify an object such as a user or a group. The SID assigned to a user becomes part of the access token, which is then attached to any action attempted or process executed by that user or group. If a duplicate SID did exist then all users with this SID would authenticate as what would be seen as the same user. It is possible for cloned machines to have the same SID, which would be seen by the authentication mechanism as the same machine. The SID under normal operation will be unique and will identify an individual object such as a user, group or a machine.

A SID contains:

User and group security descriptors
48-bit ID authority
Revision level
Variable sub-authority values
For example: S-1-5-21-917267712-1342860078-1792151419-500

Below is a list of the values for SIDs on a default NT 4 installation;

Notice the unique value 500 for Administrator and 501 for Guest.

— Built-In Users

DOMAINNAME\ADMINISTRATOR

S-1-5-21-917267712-1342860078-1792151419-500 (=0x1F4)

DOMAINNAME\GUEST

S-1-5-21-917267712-1342860078-1792151419-501 (=0x1F5)

— Built-In Global Groups

DOMAINNAME\DOMAIN ADMINS

S-1-5-21-917267712-1342860078-1792151419-512 (=0x200)

DOMAINNAME\DOMAIN USERS

S-1-5-21-917267712-1342860078-1792151419-513 (=0x201)

DOMAINNAME\DOMAIN GUESTS

S-1-5-21-917267712-1342860078-1792151419-514 (=0x202)

— Built-In Local Groups

BUILTIN\ADMINISTRATORS S-1-5-32-544 (=0x220)

BUILTIN\USERS S-1-5-32-545 (=0x221)

BUILTIN\GUESTS S-1-5-32-546 (=0x222)

BUILTIN\ACCOUNT OPERATORS S-1-5-32-548 (=0x224)

BUILTIN\SERVER OPERATORS S-1-5-32-549 (=0x225)

BUILTIN\PRINT OPERATORS S-1-5-32-550 (=0x226)

BUILTIN\BACKUP OPERATORS S-1-5-32-551 (=0x227)

BUILTIN\REPLICATOR S-1-5-32-552 (=0x228)

— Special Groups

\CREATOR OWNER S-1-3-0

\EVERYONE S-1-1-0

NT AUTHORITY\NETWORK S-1-5-2

NT AUTHORITY\INTERACTIVE S-1-5-4

NT AUTHORITY\SYSTEM S-1-5-18

NT AUTHORITY\authenticated users S-1-5-11 *

* For Windows NT 4.0 Service Pack 3 and later only

These values can be displayed by using the utility Getsid.exe from the Windows NT Resource Kit.

C:\>getsid \\MACHINE ACCOUNT \\MACHINE ACCOUNT

The SID for account MACHINE\ ACCOUNT matches account MACHINE\ ACCOUNT

The SID for account MACHINE\ ACCOUNT is

S-1-5-21-1271857391-537538043-240200450-4294967295

The SID for account MACHINE\ ACCOUNT is

S-1-5-21-1271857391-537538043-240200450-4294967295

For more information, see Q. How can I tell which User has which SID? and Q. What are the problems with
workstations having the same SID? — www.ntfaq.com

For more other information, see

http://support.microsoft.com/support/kb/articles/Q163/8/46.asp

For information on extracting the SID from an ACE see

http://support.microsoft.com/support/kb/articles/q102/1/01.asp

For information on how to associate a Username with a Security Identifier (SID) see

http://support.microsoft.com/support/kb/articles/Q154/5/99.asp

46. Если средства защиты могут быть преодолены только государственной спецслужбой, то согласно «Европейским критериям» безопасность считается:
• высокой

47. Если средство защиты способно противостоять корпоративному злоумышленнику, то согласно «Европейским критериям» безопасность считается:
• средней

48. Если средство защиты способно противостоять отдельным атакам, то согласно «Европейским критериям» безопасность считается:
• базовой

49. Задачей анализа модели политики безопасности на основе анализа угроз системе является:
• минимизация вероятности преодоления системы защиты

50. Запись определенных событий в журнал безопасности сервера называется:
• аудитом

51. Защита информации, определяющей конфигурацию системы, является основной задачей средств защиты
• встроенных в ОС

52. Защита исполняемых файлов обеспечивается:
• обязательным контролем попытки запуска

53. Защита от программных закладок обеспечивается:
• аппаратным модулем, устанавливаемым на системную шину ПК

54. Защита от форматирования жесткого диска со стороны пользователей обеспечивается:
• аппаратным модулем, устанавливаемым на системную шину ПК

55. Защита с применением меток безопасности согласно «Оранжевой книге» используется в системах класса
• В1

56. Идентификаторы безопасности в Windows 2000 представляют собой …
• двоичное число, состоящее из заголовка и длинного случайного компонента

57. Из перечисленного ACL-список содержит:
• домены, которым разрешен доступ к объекту
• тип доступа

58. Из перечисленного аутентификация используется на уровнях:
• прикладном
• сетевом
• транспортном

59. Из перечисленного базовыми услугами для обеспечения безопасности компьютерных систем и сетей являются:
• аутентификация
• контроль доступа
• причастность
• целостность

60. Из перечисленного в автоматизированных системах используется аутентификация по:
• паролю
• предмету
• физиологическим признакам

8.6.1. Основные понятия

Операци­онная
система Windows
2000 обладает рядом достаточно совершенных
и эффективных свойств безопасности,
включая следующие:

1. Безопасная
регистрация в системе с мерами
предосторожности против по­пыток
применения фальшивой программы
регистрации.

2. Дискреционное
управление доступом.

3. Управление
привилегированным доступом.

4. Защита
адресного пространства для каждого
процесса.

5. Обнуление
страниц перед выделением их процессу.

6. Аудит
безопасности.

Безопасная
регистрация означает, что системный
администратор может потре­бовать ото
всех пользователей наличия пароля для
входа в систему. Дискреционное управление
доступом позволяет владельцу файла или
другого объекта указать, кто может
пользоваться объектом и каким образом.
Средства управления привилегированным
доступом позволяют системному
администрато­ру (суперпользователю)
получать доступ к объекту, несмотря на
установленные его владельцем разрешения
доступа. Под защитой адресного пространства
имеется в виду лишь то, что у каждого
процесса есть собственное защищенное
виртуаль­ное адресное пространство,
недоступное для любого неавторизованного
процесса. Следующий пункт означает, что
при увеличении стека выделяемые для
него стра­ницы заранее обнуляются,
так что процесс не может обнаружить в
них информа­ции, помещенной предыдущим
владельцем страницы памяти (страницы
подаются процессам из списка обнуленных
страниц). Наконец, аудит безопасности
следует понимать как регистрацию
системой в журнале опре­деленных
событий, относящихся к безопасности.
Впоследствии этот журнал может
просматривать системный администратор.

У
каждого пользователя (и группы)
операционной системы Windows
2000 есть идентификатор безопасности SID
(Security
IDentifier),
по которому операцион­ная система
отличает его от других пользователей.
Идентификаторы безопаснос­ти
представляют собой двоичные числа с
коротким заголовком, за которым следу­ет
длинный случайный компонент. Каждый
SID
должен быть уникален в пределах всей
планеты. Когда пользователь запускает
процесс, этот процесс и его потоки
работают под идентификатором пользователя.
Большая часть системы безопасно­сти
спроектирована так, чтобы гарантировать
предоставление доступа к каждому объекту
только потокам с авторизованными
идентификаторами безопасности.

У
каждого процесса есть маркер
доступа, в
котором указывается SID
и другие свойства. Как правило, он
назначается при регистрации в системе
процедурой winlogon.
Заголовок маркера содержит некоторую
админи­стративную информацию. По
значению поля срока действия можно
определить, когда маркер перестанет
быть действительным. Поле Groups
(группы) указывает группы, к которым
принадлежит процесс. Это поле необходимо
для соответствия требованиям стандарта
POSIX.
Поле Default
DACL
(Default
Discretionary
Access
Control
List
– список разграничительного контроля
доступа по умолчанию) представляет
собой список управ­ления доступом,
назначаемый объектам, созданным
процессом, если не опреде­лены другие
списки ACL.
Идентификатор безопасности пользователя
указывает пользователя, владеющего
процессом. Ограниченные идентификаторы
SID
по­зволяют ненадежным процессам
принимать участие в заданиях вместе с
надеж­ными процессами, но с меньшими
полномочиями и меньшими возможностями
причинения ущерба.

Наконец,
перечисленные в маркере привилегии
(если они перечислены) дают процессу
особые полномочия, такие как право
выключать компьютер или полу­чать
доступ к файлам, к которым в противном
случае в этом доступе процессу было бы
отказано. Привилегии позволяют разбить
полномочия системного админист­ратора
на отдельные права, которые могут
предоставляться процессам по отдель­ности.
Таким образом, пользователю может быть
предоставлена часть полномо­чий
суперпользователя, но не все его
полномочия. Итак, маркер доступа содержит
информацию о том, кто владеет процессом
и какие умолчания и полномочия
ассо­циированы с ним.

Когда
пользователь регистрируется в системе,
процесс winlogon
назначает
мар­кер доступа начальному процессу.
Последующие процессы, как правило,
наследу­ют этот маркер. Маркер доступа
процесса изначально применяется ко
всем пото­кам процесса. Однако поток
во время исполнения может получить
другой маркер доступа. В этом случае
маркер доступа потока перекрывает
маркер доступа про­цесса. В частности,
клиентский поток может передать свой
маркер доступа сервер­ному потоку,
чтобы сервер мог получить доступ к
защищенным файлам и другим объектам
клиента. Такой механизм называется
перевоплощением.

Другим
основным понятием является дескриптор
защиты. У
каждого объекта есть ассоциированный
с ним дескриптор защиты, содержащий
список пользова­телей и групп, имеющих
доступ к данному объекту. Дескриптор
защиты состоит из заголовка, за которым
следует список DACL
с одним или несколькими элемен­тами
АСЕ
(Access
Control
Entry
– элемент списка контроля доступа ACL).
Два основных типа элементов списка –
это разрешение и запрет доступа.
Разрешаю­щий элемент содержит SID
пользователя или группы и битовый
массив, опре­деляющий набор операций,
которые процессы с данным идентификатором
SID
могут выполнять с определенным объектом.
Запрещающий элемент работает ана­логично,
но совпадение идентификаторов означает,
что обращающийся процесс не может
выполнять перечисленные операции.

Кроме
списка DACL
у дескриптора защиты есть также список
SACL
(System
Access
Control
List
– системный список контроля доступа),
который похож на DACL,
только вместо пользователей и групп,
имеющих доступ к объекту, в нем
перечисляются операции с этим объектом,
регистрируемые в специальном журна­ле.
В операционной системе Windows
2000 также пре­доставляются дополнительные
возможности аудита для регистрации
доступа к объектам.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Станет ли новый основной протокол аутентификации достойным своего статуса?

В древнегреческой мифологии трехглавый пес, охранявший вход в подземное царство, назывался Цербер (Kerberos). В компьютерном мире с этим именем связаны не столь мрачные ассоциации. В IETF RFC 1510 приводится описание базового протокола Kerberos, разработанного в Массачусетском технологическом институте как часть проекта Athena, и рассматриваются аспекты аутентификации пользователя. Microsoft встроила протокола Kerberos в Windows 2000 в качестве протокола аутентификации по умолчанию. В данной статье мы рассмотрим ключевые особенности этой реализации протокола Kerberos.

Основы

Когда два объекта (например, пользователь и серверный ресурс) пытаются установить подлинность друг друга, они нуждаются в своего рода посреднике, которому и тот и другой объект могут доверять. В Windows 2000 в роли такого посредника выступает Kerberos Key Distribution Center (KDC). KDC добавляет масштабируемость в протокол Kerberos и реализован в виде службы, которая запускается на каждом контроллере домена. Служба KDC устанавливается одновременно с Active Directory (AD). AD, в свою очередь, содержит копию учетных сведений безопасности пользователя, т. е. хеш-код его паролей, которые задействованы в протоколе Kerberos во время процесса аутентификации.

В состав Windows 2000 входит провайдер аутентификации клиента Windows 2000 по протоколу Kerberos, а также поддержка других клиентов, таких, как Windows 9x. Для того чтобы клиент на базе Windows 9x использовал во время аутентификации протокол Kerberos, следует установить на рабочем месте клиента службу Directory Services. Если в качестве рабочего места выступает Windows NT 4.0, то для аутентификации клиента по протоколу Kerberos необходимо заменить версию Windows NT 4.0 на Windows 2000 Professional.

Доступ к объектам в протоколе Kerberos

В основе работы протокола Kerberos лежит уникальная технология предоставления доступа к объектам системы, ускоряющая процесс аутентификации, по сравнению с предыдущими версиями NT. В реализации протокола Kerberos предусмотрен безопасный способ передачи по сети сеансового ключа шифрования, в котором содержится основная информация для проведения аутентификации пользователя. В протоколе Kerberos аутентификация основана на шифровании с применением симметричного ключа. Предположим, что Алиса и Боб совместно владеют сеансовым ключом, который они используют в процессе аутентификации. Когда Алиса собирается обратиться к Бобу, она с помощью сеансового ключа шифрует свое имя и текущее время и посылает пакет с закодированной информацией Бобу. (В терминологии Kerberos такой закодированный пакет носит название аутентификатор — authenticator.) Боб использует сеансовый ключ, который известен только ему и Алисе, для расшифровки пакета. Если в результате расшифровки будет восстановлено имя Алисы и соответствующее время, то Боб может быть уверен в том, что только одна Алиса могла отослать ему данный пакет. В протоколе Kerberos для безопасного обмена сеансовым ключом по сети применяются пакеты определенного типа — так называемые «билеты» (ticket).

В реализации протокола Kerberos, выполненной компанией Microsoft, все сеансовые ключи генерируются службой KDC. Эта же служба формирует связанные с ключами билеты и передает их клиенту, а затем и ресурсному серверу через того же клиента. (Ресурсный сервер — это компьютер, к ресурсам которого обращается пользователь.) Билет представляет собой зашифрованную версию сеансового ключа, расшифровать который может только ресурсный сервер и домен-контроллер Windows 2000. KDC рассылает билеты через клиентов, что позволяет произвести запись этой информации в кэш рабочей станции клиента, а в дальнейшем при необходимости многократно использовать. (Клиент хранит билеты в специальной области памяти, содержимое которой никогда не сбрасывается на диск.) Однако билеты имеют ограниченный период восстановления (renewal) и время жизни (lifetime). В течение периода восстановления KDC незаметно для пользователя обновляет билеты. Если же период восстановления истек, пользователю предстоит заново пройти всю последовательность регистрации (logon sequence).

Когда ресурсный сервер получает от клиента билет и аутентификатор, он уже может приступить к процедуре аутентификации. В системе NT 4.0 для того, чтобы подтвердить корректность аутентификации клиента, ресурсному серверу необходимо было связаться с контроллером домена. Благодаря протоколу Kerberos в системе Windows 2000 это уже не требуется. Такой подход ускоряет проведение процесса аутентификации, но при этом приводит к большей загрузке станции клиента.

Доступ к объектам, реализованный в протоколе Kerberos, осуществляется с помощью билетов двух типов: ticket-granting ticket (TGT) и service or resource ticket (SRT). Для выполнения регистрации в домене Windows 2000 пользователь должен задать свой пароль (master key в терминологии Kerberos). Когда регистрация пользователя в домене завершена, служба KDC генерирует TGT и отсылает его данному пользователю. TGT гарантирует безопасность передачи сеансового ключа, который KDC использует для аутентификации. Применение в протоколе Kerberos сеансового ключа и TGT ограничивает возможность успешной аутентификации, если при этом используется только пароль, что снижает вероятность грубого «взлома» пакетов, зашифрованных паролем пользователя. Во время процедуры первой регистрации и каждый раз при обновлении TGT пользователь применяет свой пароль для выполнения аутентификации с KDC. В последующих запросах пользователи уже задействуют сеансовый ключ, содержащийся в TGT, для аутентификации с KDC. Следовательно, если пользователь изменяет свой пароль во время сеанса работы, для получения нового TGT ему придется заново ввести свои атрибуты — идентификатор пользователя и пароль.

Для аутентификации с ресурсным сервером пользователю необходим другой сеансовый ключ. В протоколе Kerberos для безопасной передачи по сети этого сеансового ключа используется тип пакета SRT. Он формируется службой KDC на основе хранящегося в кэше клиента TGT. Когда пользователь «предъявляет» TGT и аутентификатор, служба KDC «знает», что однажды контроллер домена проводил аутентификацию этого пользователя, и она завершилась успешно, поэтому KDC разрешает выдать SRT.

Картинка с сайта: www.osp.ru

ЭКРАН 1. Использование утилиты Windows 2000 Klist для просмотра билетов Kerberos.

В состав Windows 2000 SDK входит программа Klist, с помощью которой можно просмотреть билеты, размещенные в кэше клиентского компьютера, а также присущие им характеристики (см. Экран 1). Кроме того, можно воспользоваться утилитой Windows 2000 Group Policy Object (GPO) для установки значений время жизни TGT, время жизни SRT и максимальный период обновления, как это изображено на Экране 2. Установки по умолчанию следующие: 30 дней для TGT, 29 дней для SRT и 60 дней для обновления билетов. Значение параметра «время жизни TGT», который пользователь может установить на своем рабочем месте, должно быть больше, чем для параметра «время жизни SRT», а максимальный период обновления должен превышать время жизни как TGT, так и SRT. В том же каталоге, как показано на Экране 2, можно установить максимальный временной интервал, который допускается ресурсным сервером, с момента, когда клиент сформировал билет, до того момента, когда ресурсный сервер его получил. Протокол Kerberos использует временные метки для защиты от многократно повторяющихся попыток вскрытия пакетов, поэтому увеличение значения этого параметра повышает риск подобных атак.

Для систем Windows 2000 корпорация Microsoft включила данные авторизации пользователя в поле данных авторизации, которое присутствует в каждом билете протокола Kerberos. Разработчики Microsoft назвали такое поле Privilege Attribute Certificate (PAC). В Windows 2000 добавлением данных PAC в билеты занимается служба KDC, а формируемые вслед за тем запросы на получение TGT, SRT и запросы на обновление билетов наследуют эту информацию. Вместе с тем KDC сохраняет данные авторизации на время сеанса работы пользователя. Поэтому, например, если принадлежность группам для некоторого пользователя изменилась, ему необходимо выполнить процедуру logoff, а затем logon для того, чтобы KDC сформировала новый билет и передала его пользователю.

Взаимная аутентификация

Для того чтобы установить подлинность клиента, в системах NT 4.0 применяется метод аутентификации по принципу запрос/ответ, в соответствии с которым сервер посылает клиенту запрос, клиент вычисляет ответ, а сервер этот ответ проверяет. Таким образом, в NT 4.0 создаются ситуации, когда пользователь может, не осознавая того, предъявить свои полномочия (учетные сведения безопасности) поддельному серверу. Для того чтобы избежать возникновения подобных ситуаций, в протоколе Kerberos поддерживается взаимная аутентификация: клиент запрашивает подлинность сервера, а сервер должен убедиться в подлинности клиента.

Транзитивные доверительные отношения

Как и в NT 4.0, в доменах Windows 2000 понятие доверительные отношения (trust — ситуация, когда некоторые «секреты» известны контроллерам двух различных доменов), присутствует, что упрощает перекрестный доступ к ресурсам различных доменов. Другое проявление доверительных отношений — возможность совместно использовать базы данных учетных записей пользователей. Разработчики из Microsoft упростили процедуру установления и обслуживания доверительных отношений в доменах Windows 2000. В процессе создания иерархии доменов Windows 2000 все необходимые доверительные отношения и их транзитивность устанавливаются автоматически.

Транзитивность доверительных отношений означает, что если, например, компания europe.company.com и us.company.com доверяют company. com, то и europe.company.com доверяет (неявным образом) компании us.company.com. Транзитивность доверительных отношений сокращает число доверительных связей, необходимых для процедуры аутентификации. Пример того, как транзитивность упрощает процесс аутентификации, приведен во врезке.

Таблица 1. Типы транзитивных доверительных отношений, поддерживаемых протоколом Kerberos

Транзитивность доверительных отношений — всего лишь логическая концепция, так как в действительности нет никаких «общих тайн», известных контроллерам доменов, между которыми установлено доверие «по транзитивности». Установление транзитивных доверительных отношений означает, что процесс аутентификации между двумя различными сущностями на противоположных концах транзитивной связи протекает не через всю цепочку выстроенного доверительного маршрута, а через специальный «путь доверия» (trust path) в дереве объектов. Разработчики Microsoft утверждают, что алгоритм аутентификации, реализованный таким образом, не оказывает серьезного влияния на сетевой трафик. Реально формируемый при этом трафик, по данным Microsoft, сопоставим с тем, который генерируется в NT 4.0 во время сквозной (pass-through) аутентификации. Вместе с тем очевидно, что для больших распределенных вычислительных сред, к которым, например, можно отнести Internet, возможностей протокола Kerberos уже недостаточно для аналогичной реализации процесса аутентификации. Kerberos предназначен для аутентификации в сетях intranet.

В Windows 2000 предусмотрено пять базовых типов доверительных отношений, они перечислены в Таблице 1. Можно выяснить характеристики доверительных отношений, обратившись к описанию свойств домена, как это показано на Экране 3, или же посредством утилиты командной строки trustdom.exe. Кроме того, с помощью этой утилиты можно явным образом установить доверительные отношения между доменами. Конечные пользователи, работающие со станций, операционные системы которых поддерживают протокол Kerberos, могут «прочувствовать» наличие транзитивных отношений во время выполнения процесса регистрации. Такие пользователи в качестве регистрирующего домена могут выбрать любой из списка доменов, с которыми их «родной» домен имеет или прямые доверительные отношения, или опосредованные (т. е. транзитивные). Для NT 4.0 конечный пользователь в процессе регистрации «видит» лишь те домены, с которыми были установлены прямые доверительные отношения.

В соответствии с протоколом Windows 2000 Kerberos доверительные отношения, установленные внутри одного и того же леса доменов, явные или неявные — значения не имеет, по умолчанию являются транзитивными. В Windows 2000 beta 2 предусматривалась возможность управления включением/выключением транзитивности в доверительных отношениях. Однако в следующей бета-версии системы, Windows 2000 beta 3, этой возможности уже нет. Явные доверительные отношения, установленные между лесами доменов, или же доверительные отношения в доменах Windows 2000, например в доменах Unix, поддерживающих протокол Kerberos, по умолчанию считаются нетранзитивными. Таким образом, при необходимости провести аутентификацию между двумя доменами, которые принадлежат различным лесам доменов, следует вручную установить между ними доверительные отношения.

Делегирование аутентификации

Используя механизм делегирования аутентификации, пользователь А может предоставить право на проведение аутентификации с сервером приложений С некоторому посреднику — машине В, как если бы за машиной В находился непосредственно сам пользователь А. Установка делегирования означает, что сервер приложений С во время процесса аутентификации будет «принимать решение» о предоставлении или отказ в доступе на основании факта идентичности учетной записи пользователя А, но не на основании учетной записи рабочей станции В. Описанный процесс делегирования аутентификации также известен под названием «продвижение аутентификации» (authentication forwarding). В соответствии с протоколом Kerberos, при выполнении процедуры делегирования пользователь А пересылает билет станции-посреднику В, которая в свою очередь использует билет пользователя А для выполнения процесса аутентификации с сервером приложений С.

Метод делегирования аутентификации можно использовать при обращении к таким многозвенным (multitier) приложениям, как, например, Outlook Web Access (OWA). Для того чтобы воспользоваться услугами OWA, пользователи обращаются к своим почтовым ящикам с помощью браузера. В большинстве случаев сервер Microsoft Exchange Server, который поддерживает работу почтовых ящиков пользователей, не производит обмен информацией с сервером Microsoft Internet Information Server (IIS). Это означает, что IIS должен провести аутентификацию с сервером Exchange, как если бы IIS был обычным пользователем. В сетях NT 4.0 при использовании для аутентификации протокола NT LAN Manager (NTLM) при установлении связи в обе стороны осуществить подобный сценарий без проблем было нелегко. (Напомним, что такой подход соответствует попытке установить связь между браузером и IIS, а также между IIS и сервером Exchange.) Протокол NTLM, как известно, не поддерживает механизм делегирования.

Можно установить делегирование как для учетной записи пользователя Windows 2000, так и для учетной записи компьютера с помощью параметра Account is trusted for delegation в диалоговом окне, отображающем свойства учетной записи, как показано на Экране 4. Кроме того можно установить делегирование аутентификации.

Регистрация с помощью кредитной карты

В Windows 2000 реализована поддержка регистрации с помощью кредитных карт (smart card logon), что обеспечивает больший уровень безопасности, нежели аутентификация с помощью пароля. Это происходит из-за того, что регистрация с помощью кредитной карты основывается на двухэтапной аутентификации. Для того чтобы зарегистрироваться в системе, пользователю необходимо иметь саму кредитную карту, а также знать ее персональный идентификационный номер (PIN-код). Кроме того, регистрация с помощью кредитной карты блокирует попытки несанкционированного входа в систему по принципу работы вируса-«троянца», когда программа-взломщик пытается «снять» пароль пользователя непосредственно из памяти системы.

Для того чтобы обеспечить возможность регистрации с помощью кредитной карты, разработчики Windows 2000 реализовали расширение протокола Kerberos, получившее название PKINIT. Во время выполнения последовательности регистрации на базе этого расширения, PKINIT заменяет пароль пользователя содержимым его открытого ключа, которое хранится на кредитной карте.

Для того чтобы воспользоваться возможностью регистрации с помощью кредитной карты, следует установить Windows 2000 Certificate Server, который для своей работы подгружает необходимые сертификационные шаблоны регистрации. Пользователю нужно иметь собственно кредитную карту и устройство считывания. В настоящее время Windows 2000 поддерживает кредитные карты компаний Gemplus и Schlumberger (оба производителя предоставляют свои службы в виде модуля расширения Microsoft CryptoAPI8).

Протокол Kerberos — открытый стандарт

Корпорация Microsoft разработала свою реализацию протокола Kerberos на основе открытого стандарта RFC 1510 (т. е. версии Kerberos V5), а это означает, что протокол Kerberos может обеспечить межсетевую аутентификацию между Windows 2000 и другими операционными системами, которые также отвечают требованиям стандарта RFC 1510.

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

Реализация межсетевой аутентификации представляет собой достаточно сложный процесс, он требует от администраторов систем дополнительных усилий. Например, для того чтобы организовать межплатформенные доверительные отношения для проведения межсетевой аутентификации между платформами Windows 2000 и Unix, нужно описать точные соответствия между каждой учетной записью Unix, которой необходим доступ к ресурсам домена Windows 2000, и учетной записью Windows 2000, как это показано на Экране 5. Нужно установить соответствие для каждой учетной записи Unix, поскольку названия учетных записей Unix в протоколе Kerberos для домена Windows 2000 ровным счетом ничего не значат. В среде Windows 2000 для отождествления учетных записей используются так называемые идентификаторы безопасности — SID. В диалоговом окне Security Identity Mapping показаны подобные соответствия, которые являются частью дополнительных свойств объекта User.

Остается добавить, что компании, расположенные за пределами США, должны учитывать экспортное законодательство США при планировании межсетевой аутентификации. Эти законы запрещают экспорт программного обеспечения, в котором задействованы ключи шифрования длиною более 56 разрядов. Стандарт MIT Kerberos V5, доступный через Web-узлы в США для Unix-платформ, использует ключ шифрования длиной 128 разрядов и экспорту не подлежит. Протокол Windows 2000 Kerberos может применяться внутри Соединенных Штатов в не экспортируемом варианте с ключом 128 разрядов и для всего остального мира (экспортный вариант) с длиной ключа 56 разрядов. Выяснить, какая именно версия Windows 2000 установлена на конкретной системе можно, обратившись к свойствам следующих системных файлов: schannel.dll, rsabase.dll, или ndiswan.sys.

Кроме того, хотя разработчики Microsoft реализовали протокол Kerberos как модуль расширения Security Support Provider Interface (SSPI), тем не менее протокол Kerberos поддерживает формат GSS_API, описанный в RFC 1964. И как следствие, Unix-приложения, поддерживающие GSS_API, и приложения Windows 2000 могут сообща использовать протокол Kerberos для аутентификации.

Что дальше

Microsoft, реализовав протокол Kerberos, расширила в системе Windows 2000 возможности процесса аутентификации. Протокол Kerberos в своей основе использует симметричное шифрование, что позволяет применять его в локальных сетях и сетях intranet в качестве протокола аутентификации. Вместе с тем добавление компонента PKINIT можно рассматривать как первый шаг на пути расширения функциональности процесса аутентификации, выполняемого на базе протокола Kerberos с использованием открытого ключа, что расширяет сферу применения самого Kerberos.

ОБ АВТОРЕ

Подробнее о транзитивных доверительных отношениях Kerberos

Предположим, Алиса зарегистрировалась в north.eu108.corp108. com со своим бюджетом, но при этом ей нужно получить доступ к ресурсу на сервере east.na108.corp108.com. Далее, шаг за шагом будет показано, как протекает процесс аутентификации по правилам работы протокола Kerberos в дереве, содержащем пять доменов.

1. Алиса использует свой TGT для того, чтобы попытаться получить билет с KDC1 для доступа к ресурсам на сервере в домене east. KDC1 не уполномочен обслуживать домен east, в котором расположен сервер, и поэтому отсылает Алису в домен, наиболее близкий к домену east, и с которым у домена north имеются доверительные отношения по протоколу Kerberos. Предположим, это домен eu108.

2. KDC2 отсылает Алису к KDC3

3. KDC3 отсылает Алису к KDC4

4. KDC4 отсылает Алису к KDC5

5. KDC5 уполномочен обслуживать домен east, поэтому KDC5 генерирует билет для Алисы.

6. Алиса использует полученный билет для доступа к ресурсному серверу.

С помощью утилиты Klist, входящей в состав Windows 2000 Software Development Kit (SDK), можно просмотреть все билеты, находящиеся в кэше станции Алисы. Вы обнаружите один TGT для каждого домена, один билет для учетной записи рабочей станции Алисы (принадлежащей домену north), а также один билет для сервера ресурсов.

Длину описанного маршрута можно сократить с помощью явного задания доверительных отношений (тип отношений shortcut-trust) между доменами north и east. В этом случае последовательность шагов, необходимая для реализации доступа Алисы к ресурсам сервера в домене east, изменится:

1. Алиса использует свой TGT для того, чтобы попытаться получить билет с KDC1 для доступа к ресурсам на сервере в домене east. KDC1 не уполномочен обслуживать этот домен, где расположен сервер ресурсов, и поэтому отсылает Алису в домен, который наиболее близок к домену east, и с которым у домена north имеются доверительные отношения по протоколу Kerberos.

2. KDC5 уполномочен обслуживать домен east, поэтому KDC5 генерирует билет для Алисы.

3. Алиса использует полученный билет для доступа к серверу ресурсов.

Если после этой последовательности шагов заглянуть в кэш рабочей станции Алисы, то удастся обнаружить лишь четыре билета: один TGT для домена north, один TGT для домена east, один билет для учетной записи рабочей станции Алисы и один билет для сервера ресурсов. Установление отношения shortcut-trust привело к снижению междоменного трафика и уменьшило число билетов, которые необходимо передать пользователю.