 |
|
|
|
Развёртываем Heimdal Kerberos
Развёртываем Heimdal Kerberos Мы изучили принципы работы Kerberos и взглянули на него с пользовательской точки зрения [1]. Теперь перейдем к практической части и начнем развертывать инфраструктуру Kerberos в локальной сети. Устанавливаем контроллер Kerberos Начнем установку сервера Heimdal на компьютере с ОС Linux. Если Heimdal не включен в состав вашего дистрибутива, то вы можете получить исходный код Heimdal с ftp-сервера Стокгольмского университета (ftp://ftp.pdc.kth.se/pub/heimdal/src), сконфигурировать и скомпилировать его. tar xzvf heimdal-0.6.3.tar.gz cd heimdal-0.6.3 ./configure --prefix=/usr --enable-shared make make install Опции конфигурации позволяют вам собрать Heimdal в виде разделяемых библиотек, что в дальнейшем упрощает сборку программ с поддержкой Kerberos, и установить Heimdal в каталог /usr. При этом пользовательские программы (kinit, klist, telnet и т. д.) записываются в каталог /usr/bin, программы для удаленного администрирования контроллера Kerberos – в /usr/sbin, а серверная часть Kerberos – в /usr/libexec. Если предполагаемое число принципалов невелико (например, порядка сотни), то Heimdal не требует особенно большого количества вычислительных ресурсов. В моем случае в качестве kdc используется 486 компьютер. Желательно тем не менее держать базу данных Kerberos на специально выделенном для этой цели компьютере, т.к. захват злоумышленником этого сервера полностью компрометирует безопасность всей системы. После того как компьютер выбран, на нем нужно создать каталог для хранения баз данных Kerberos. mkdir /var/heimdal chmod 600 /var/heimdal Далее нужно проделать две вещи: создать конфигурационный файл kdc и инициализировать (заселить несколькими основными принципалами) базу данных Kerberos. Конфигурационный файл (/etc/krb5.conf) используется как сервером Kerberos, так и приложениями, собранными с поддержкой Kerberos. Поэтому этот файл (практически без изменений) можно перенести на все компьютеры, входящие в ваш сектор (будем считать, что его доменное имя myreal.ru). [libdefaults] default_realm=MYREALM.RU [realms] MYREALM.RU={ kdc=kdc.myrealm.ru admin_server=kdc.myrealm.ru kpasswd_server = kdc.myrealm.ru } [logging] kdc=FILE:/var/log/krb5kdc.log admin_server=FILE:/var/log/kadmin.log default=FILE:/var/log/krb5.log В этом файле содержится необходимый минимум настроек Kerberos – название сектора по умолчанию (строка, которая будет добавляться к именам принципалов без доменной части), расположение серверов Kerberos : kdc, сервера удаленного администрирования и их лог-файлов. В качестве альтернативы для передачи настроек Kerberos можно использовать службу DNS, для чего в файл зоны для домена myrealm.ru нужно добавить записи (предполагается, что адрес для kdc уже записан в файле зоны): _kerberos TXT "MYREALM.RU" kerberos CNAME kdc _kerberos._udp SRV 0 0 88 kdc _kerberos._tcp SRV 0 0 88 kdc _kerberos-adm._tcp SRV 0 0 749 kdc _kpasswd._udp SRV 0 0 464 kdc Передача настроек Kerberos по DNS полезна при большом числе клиентских компьютеров, когда синхронизировать файлы /etc/krb5.conf вручную сложно. Теперь можно приступать к пополнению баз данных Kerberos. sudo /usr/sbin/kadmin -l kadmin>init MYREALM.RU kadmin>add admin/admin@MYREALM.RU kadmin>add mike@MYREALM.RU kadmin> add --random-key host/kdc.myrealm.ru@MYREALM.RU kadmin>ext */kdc.myrealm.ru@MYREALM.RU Ключ -l позволяет запускать kadmin в локальном режиме без аутентификации в Kerberos. Команда init создает базу данных Kerberos и заселяет ее несколькими принципалами со случайным образом сгенерированными ключами для сервисов, предоставляемых самим Kerberos. Это krbtgt/MYREALM.RU для Ticket Granting Service, kadmin/admin для сервиса kadmind и kadmin/changepw для сервиса kpasswd, позволяющего пользователям менять свой пароли в Kerberos. Принципал kadmin/hprop, также создаваемый при инициализации Kerberos, используется при синхронизации баз данных между дополнительными и основным контроллерами сектора Kerberos, и в нашем случае он не актуален. С помощью команда add в эту вновь созданную базу записываются пользователи и сервисы. В данном случае добавляются пользователи – администратор Kerberos (admin/admin), еще один рядовой пользователь (mike) и принципал для компьютера, на котором работает контроллер Kerberos (host/kdc.myrealm.ru). В отличие от первых двух случаев для сервиса пароль выбирается случайным образом (ключ – random-key), поскольку знать его ни администратору Kerberos, ни тем более рядовым пользователям необязательно. Затем этот ключ извлекается из базы данных Kerberos (команда ext) и дописывается в файл /etc/krb5.keytab. Керберизованные серверные программы знают, что их «пароли» записаны в этом файле и при подключении клиента (см. схему работы Kerberos, изложенную выше) могут извлечь свой пароль оттуда. В данном случае права root для запуска kadmin необходимы, поскольку в результате помимо файла /etc/krb5.keytab в папке /var/heimdal, куда запись простым пользователям запрещена, создается файл heimdal.db с паролями принципалов. Теперь все готово для запуска сервера kdc. Если после команды: /usr/libexec/kdc -c /etc/krb5.conf --detach в log-файле появились сообщения вида:
значит, сервер успешно стартовал и можно переходить к запуску сервера удаленного администрирования kadmind (749/tcp-порт) и службы смены паролей kpasswdd (464/udp-порт). /usr/libexec/kadmind /usr/libexec/kpasswdd Хотя для смены паролей можно использовать программу kadmin (/usr/sbin/kadmin passwd mike), но для пользователей более удобно проделать то же самое с помощью утилиты kpasswd, которая подключается к службе kpasswdd. Поскольку сервис kadmind нужен не очень часто (при добавлении/удалении принципалов), то имеет смысл использовать его вызов в сервере inetd (xinetd). Для этого вам, во-первых, нужно убедиться, что ссылки на сервисы, собранные с поддержкой Kerberos (и kadmind в том числе) присутствуют в файле /etc/services. Необходимые для этого данные содержатся в файле heimdal-0.6.3/etc/services.append в дистрибутиве heimdal. Во-вторых, нужно добавить запись, касающуюся сервера удаленного администрирования, в файл /etc/inetd.conf и перeзапустить inetd. kerberos-adm stream tcp nowait root /usr/libexec/kadmind kadmind В то же время kpasswdd может работать только как самостоятельная служба, и организовать его вызов с помощью inetd невозможно. Контроль доступа к kadmind и управлению пользователями Kerberos обеспечивается списками, хранящимися в файле /var/heimdal/kadmin.acl. Разумная политика – предоставить администратору (admin/admin) полный контроль по управлению записями Kerberos, а всем остальным – позволить лишь менять свои пароли. Для такой цели достаточно иметь такой acl-файл: admin/admin@MYREALM.RU all *@MYREALM.RU cpw Для проверки работоспособности сервера Kerberos попробуйте аутентифицироваться на нем (как администратор) и посмотреть содержимое его баз данных: kinit -p admin/admin
kadmin> list * На этом установку сервера Kerberos можно считать законченной. Настройка же клиентов для использования этого сервера различается в случае рабочей станции и серверов приложений. Разберем два случая – настройку только сервера (компьютера, предлагающего сетевые сервисы) и только рабочей станции (которая не предлагает никаких сервисов и предназначена только для локальной работы). Настраиваем серверные программы Настройка серверов приложений достаточно проста (при условии, что на сервере работает UNIX-подобная система). Во-первых, устанавливайте дистрибутив Heimdal, как описано выше. Этого уже достаточно, чтобы компьютер (предположим, что его сетевое имя server.myrealm.ru) работал как клиент Kerberos, нужно только скопировать файл krb5.conf с сервера Kerberos на настраиваемый компьютер. Конфигурационный файл можно не редактировать – приведенный выше файл подойдет как для серверов, так и рабочих станций. Кроме того, как уже говорилось, на хосте с сетевыми сервисами должен присутствовать файл /etc/krb5.keytab с набором ключей для этих сетевых служб (точнее, для принципалов Kerberos, соответствующим этим сетевым службам). Также сервису должно быть известно имя принципала, который представляет его в Kerberos. Как правило, этот параметр настраивается для каждого сервиса индивидуально (с помощью конфигурационных файлов) или используются какие-то фиксированные значения. В любом случае вам придется изучить документацию, предлагаемую разработчиками программы. Как уже говорилось ранее, для сервисов используются имена, состоящие из трех компонентов – поле instance содержит сетевое имя компьютера, а основное имя обозначает тип предлагаемого сервиса. Предположим, вы хотите установить все сервисы, входящие в дистрибутив Heimdal (telnet, ftp, несколько r*-служб). Для этого регистрируйтесь в Kerberos как администратор, добавляете принципалов host/server.myrealm.ru@MYREALM.RU, ftp/server.myrealm.ru@MYREALM.RU и извлекаете их ключи в локальный /etc/krb5.keytab файл. kinit admin/admin
kadmin>add --random-key host/server.myrealm.ru@MYREALM.RU kadmin>add --random-key ftp/server.myrealm.ru@MYREALM.RU kadmin>ext */server.myrealm.ru@MYREALM.RU Если вы ошиблись – добавили в /etc/krb5.keytab ключ службы, которая не используется на данном компьютере, то для управления ключами в файле /etc/krb5.keytab предназначена утилита ktutil. Удалить лишнюю запись можно командой /usr/sbin/ktut il remove -p ftp/server.myrealm.ru, точно так же, как и просмотреть все записи в keytab-файле (ktutil list) или добавить новый ключ (ktutil get ftp/server.myrealm.ru). Теперь настроим запуск сервисов через демон inetd, для чего нужно добавить следующие строки в файл inetd.conf (не забудьте также добавить записи из файла heimdal-0.6.3/etc/services.append к системному файлу /etc/services): telnet stream tcp nowait root /usr/libexec/telnetd telnetd -L /usr/bin/login ftp stream tcp nowait root /usr/libexec/ftpd ftpd shell stream tcp nowait root /usr/libexec/rshd rshd -vkshell stream tcp nowait root /usr/libexec/rshd rshd -k ekshell stream tcp nowait root /usr/libexec/rshd rshd -kx kx stream tcp nowait root /usr/libexec/kxd kxd Почти все сервисы стандартные, shell/kshell/ekshell – это вариации на тему rshd. Первый из них работает просто как «заглушка», выдает сообщение об ошибке, если пользователь подключается по старинке, без TGT. Второй и третий – керберизованные сервисы, использующие Kerberos в последнем случае с шифрованием трафика. Нестандартным является сервис kx (использует 2111/tcp-порт), который предназначен для организации соединений по X-протоколу через шифрованный канал. Если вы, например, подключитесь к серверу server.myrealm.ru с помощью команды rxtelnet server.myrealm.ru, то при успешном соединении на вашем X-сервере откроется окно xterm с командным интерпретатором, запущенном на удаленном компьютере (server.myrealm.ru). Вся графика при этом будет прозрачно переадресовываться на вашу рабочую станцию. В некотором смысле мы имеем аналог ssh – X server.myrealm.ru. Поскольку время действия любого сертификата Kerberos ограничено, то одной из задач при настройке сектора Kerberos является синхронизация времени между компьютерами в локальной сети. Локальное время компьютера используется клиентами Kerberos при запросе на выдачу билета, и если это время значительно отличается от времени контроллера Kerberos (более чем на 5 минут), то такие запросы отвергаются. Так что бесполезно, например, предлагать контроллеру Kerberos просроченный TGT, просто переведя часы на локальном компьютере. Но с другой стороны, удаленный доступ к какому-то компьютеру также может быть невозможным только потому, что его часы опережают часы контроллера Kerberos, скажем, на 10 минут. Поэтому синхронизация времени внутри сектора необходима для корректного функционирования Kerberos. Если у вас в локальной сети уже работает сервер ntp, то можно воспользоваться им. Об установке и настройке сервера ntpd написано в статье [2]. Однако для целей Kerberos достаточно, если вы выберете какой-то из компьютеров в вашей сети (допустим, тот же самый server.myrealm.ru) в качестве эталонного и будете сверять по нему часы остальных компьютеров (и контроллера Kerberos в том числе) по протоколу time. Служба time уже встроена в сервер inetd, нужно только убедиться, что в файле /etc/inetd.conf не закомментирована строка: time dgram udp wait root internal Синхронизация осуществляется с помощью базовой UNIX-утилиты netdate server.myrealm.ru. Для рабочих станций ее достаточно запускать при загрузке, для серверов, которые перегружаются не так часто, имеет смысл вызывать ее периодически с помощью демона cron. Еще один технический вопрос – вопрос о правах, которые нужно выставить на keytab-файл. Поскольку он содержит пароли сетевых служб, то первая мысль, которая приходит в голову, ограничить к нему доступ так же, как и к /etc/shadow – чтение только для root. Но сервисы тоже должны иметь возможность извлекать свои ключи из этого файла, т.е. Keytab-файл также должен быть открыт для чтения пользователем, с правами которого запущены сервисы. В нашем случае это замечание не столь важно, поскольку все сервисы работают с правами root, но бывает ситуации, когда нужно дать доступ к keytab-файлу непривилегированным службам. В таком случае стоит завести специальную группу и занеcти в нее всех системных пользователей, используемых керберизованными службами, а файл /etc/krb5.keytab открыть для чтения этой группе. Настраиваем рабочие станции Для этого достаточно иметь упоминавшийся выше конфигурационный файл /etc/krb5.conf и собственно сам дистрибутив heimdal. Но бывает также удобно настроить системный login на этой рабочей станции таким образом, чтобы при входе на компьютер, пользователь автоматически получал TGT с контроллера Kerberos. Для рабочих станций под управлением Linux такой функциональности можно добиться, заменив системный login (/bin/login) на керберизованный аналог из состава Heimdal (/usr/bin/login). Проще всего это сделать, отредактировав файл /etc/inittab: c1:123:respawn:/sbin/agetty 38400 tty1 linux c2:123:respawn:/sbin/agetty 38400 tty2 linux k1:5:respawn:/sbin/agetty -l /usr/bin/login 38400 tty1 linux k2:5:respawn:/sbin/agetty -l /usr/bin/login 38400 tty2 linux и заменив default run-level на 5. Таким образом, по умолчанию загрузка компьютера будет осуществляться в керберизованном режиме, а для аварийных ситуаций у администратора компьютера сохраняется возможность заходить на компьютер в стандартном режиме (в run-level 1,2,3). Следует только иметь в виду, что керберизованный login запрашивает помимо собственно супербилета еще и session ticket для доступа к рабочей станции. Как вы понимаете, это требует наличия принципала, соответствующего данной рабочей станции в базе данных Kerberos и ее ключа в файле /etc/krb5.keytab. Заметим также, что если по каким-то причинам аутентификация пользователя на сервере Kerberos закончилась неудачей, то login переключается в стандартный режим и аутентифицирует пользователя по локальному файлу /etc/shadow. Для рабочих станций под управлением Windows2000/XP получить такую же функциональность несколько сложнее. Во-первых, авторы Heimdal не предлагают свой продукт в виде стандартного Windows-приложения, и Heimdal может работать только в Cygwin-окружении (www.cygwin.com) – эмуляторе POSIX-системы для Windows. Вы можете установить Cygwin целиком с помощью установщика, который можно скачать с сайта cygwin и затем скомпилировать исходный код Heimdal. Гораздо проще, однако, взять уже готовые бинарные пакеты Heimdal и урезанную версию Сygwin с ftp-сервера Стокгольмского университета: ftp://ftp.pdc.kth.se/pub/heimdal/binaries/i386-pc-cygwin/latest . Поскольку Cygwin для приложений, запущенных в нем, выглядит как полное UNIX-окружение, то дальнейшая конфигурация ничем не отличается от установки под Linux. После установки Cygwin и Heimdal пользователь по крайней мере может аутентифицироваться на сервере Kerberos, запустив терминал Cygwin и введя команду kinit. Полученный сертификат в дальнейшем может быть использован клиентскими программами из дистрибутива Heimdal (ftp, telnet и т. д.). При этом остаются две проблемы – заставить Heimdal использовать ваше имя и пароль, введенный при входе в Windows для аутентификации на сервере Kerberos, и обеспечить доступ к Kerberos не только для Cygwin, но и Windows-приложений. К сожалению, только средствами Heimdal эти проблемы не решаются. Разберемся со второй проблемой. Хотя библиотеки Cygwin, и библиотеки Heimdal в том числе, являются стандартными, динамически линкуемыми библиотеками Windows, но использование их для приложений Windows невозможно (подробнее об этом написано на сайте cygwin – http://cygwin.com/faq.html). Поэтому для Windows-приложений есть две возможности – или использовать API предлагаемой самой Windows, или использовать библиотеки MIT-Kerberos, которые доступны в Windows-версии, но при этом бесполезны для Cygwin-приложений. Возникает вопрос – какие из библиотек лучше установить на свой компьютер? Правильный ответ – ставить все! Пакет Support Tools от Microsoft [3] включает в себя две утилиты ksetup и kpasswd, с помощью которых можно настроить получение начальных сертификатов Kerberos при входе пользователя на рабочую станцию, а пакет Kerberos-For-Windows от МТИ [5] позволяет обеспечить доступ к этим сертификатам как для библиотек MIT-Kerberos, так и Heimdal. Так что начнем с настройки керберизованного входа в Windows. Я использую WindowsXP-Pro без сервиспаков, но тот же метод работает и для более новых версий Windows. Установка Support Tools не должна вызвать затруднений. Затем вам нужно добавить принципала для этой машины (для определенности назовем ее xp.myrealm.ru) в базу данных Kerberos. Сделать это можно, например, из терминала Cygwin (я полагаю, что вы уже настроили Heimdal в нем), но в отличие от рабочих станций, под управлением LInux вам нужно будет придумать пароль для этого компьютера: kinit admin/admin
kadmin>add -pw passwordforWinXP host/xp.myrealm.ru@MYREALM.RU Затем с помощью утилиты ksetup.exe, зайдя на машину под администраторским логином, из командной строки Windows вы должны указать название сектора Kerberos, адрес контроллера Kerberos и ввести пароль для машины (тот самый, что вы только что придумали): C:> ksetup /setdomain MYREALM.RU C:> ksetup /addkdc MYREALM.RU kdc.myrealm.ru C:> ksetup /setcomputerpassword passwordforWinXP После чего перегрузить компьютер. При загрузке машины обратите внимание, что форма с приглашением входа в Windows изменилась. На ней должно появиться еще одно поле выбора с двумя вариантами – зарегистрироваться на компьютере xp.myrealm.ru или в секторе Kerberos MYREALM.RU. Но второй вариант пока не работоспособен, т.к. вы еще не настроили соответствия между локальными именами пользователей и именами принципалов Kerberos. Так что вам нужно снова войти на компьютер как Администратор и настроить эти соответствия. Тут есть два варианта: C:> ksetup /mapuser * * C:> ksetup /mapuser mike@MYREALM.RU mikeXP В первом случае каждый принципал из базы данных Kerberos отображается на пользователя Windows c тем-же именем (только без доменной части). Во втором случае (если вас такая политика не устраивает) вы разрешаете только определенному пользователю (mikeXP) аутентифицироваться в Kerberos под именем принципала mike@MYREALM.RU. Так или иначе, но теперь вы можете при входе на рабочую станцию одновременно получать сертификаты Kerberos. Но этот сертификат хранится в памяти, а не на дисковом файле, как у Heimdal, и доступ к нему осуществляется посредством API Windows. Чтобы сделать его доступным для Heimdal, нужно воспользоваться утилитой ms2mit из пакета MIT-Kerberos, разработчики которого работают в тесном контакте с Microsoft и поэтому представляют себе особенности ее реализации Kerberos. Установка MIT-Kerberos очень проста. Помимо инсталлятора [4] они предлагают свой пакет в виде обычного zip-архива [6], который можно распаковать в удобный для вас каталог. Не стоит только устанавливать его в директорию Program Files, т.к. она входит в переменную PATH Cygwin, что может привести к конфликтам между одноименными утилитами Heimdal и MIT-Kerberos. Так что лучше распаковать его в какой-нибудь из каталогов на диске C: (у меня это С:kfw-2.6.5). Помимо утилиты ms2mit, в него входят уже знакомый вам набор стандартных утилит Kerberos (kinit, klist, kdestroy) и также графический интерфейс к ним (Leash32). После установки MIT-Kerberos вам нужно настроить Heimdal и MIT-Kerberos таким образом, чтобы они использовали один и тотже кэш сертификатов, с тем чтобы начальный сертификат, полученный с помощью одной из этих библиотек, был бы автоматически доступен и другой. У Heimdal кэш – это (как вы помните) файл с именем krb5cc_ + id пользователя во временном каталоге (временный каталог Cygwin – это С:Cygwin mp), но это название можно поменять с помощью переменной окружения Сygwin KRB5CCNAME. У MIT-Kerberos в дефолтной установке используется кэш в памяти, но его можно настроить на использование дискового файла. Сделать это можно с помощью установки переменной окружения Windows (KRB5CCNAME) и записей в реестре Windows HKCUSoftwareMITKerberos5ccname, HKLMSoftwareMITKerberos5ccname. Системой используется первое непустое значение в этой последовательности или значение по умолчанию – «API:». Я использую bat-файл, запускаемый при входе в Windows, который устанавливает переменную окружения KRB5CCNAME на название файла, используемого Heimdal, и затем перемещает сертификат Windows в этот файл утилитой ms2mit. Для каждого из пользователей Windows этот файл свой, поскольку значение KRB5CCNAME зависит от идентификатора этого пользователя в Сygwin-окружении. set KRB5CCNAME = FILE:C:Cygwin mpkrb5cc_1017 ms2mit То же самое вы можете проделать с помощью программы Leash32 (меню «Action Import Ticket(s)/Token(s)»), так же как просматривать/удалять имеющиеся сертификаты и настраивать кэш сертификатов (меню «Options Kerberos v5 Properties Dialog»). Здесь имеется еще одна ловушка, заботливо расставленная компанией Microsoft. Для большей безопасности в установке по умолчанию Support Tools экспорт начального сертификата из памяти Windows запрещен, что делает его использование бесполезным для MIT-Kerberos и Heimdal. К счастью (точнее, благодаря давлению со стороны разработчиков из MIT), Microsoft оставила ключи в реестре, с помощью которых можно снять этот запрет. Так что, для того чтобы утилита ms2mit работала, в реестре должны быть установлены значения: HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters AllowTGTSessionKey = 0x01 (DWORD) HKLMSYSTEMCurrentControlSetControlLsaKerberos AllowTGTSessionKey = 0x01 (DWORD) Заключение Еще несколько слов о совместимости различных версий Kerberos. Как вы могли только что убедиться, билетики, получаемые от сервера Heimdal, работают во всех версиях клиентов Kerberos (Microsoft, MIT, Heimdal). То же самое верно, если бы в качестве сервера использовался KDC от MIT. Пример же использования библиотеки MIT-Kerberos в домене Windows 2000 c Active Directory, где реализован сервер Kerberos от Microsoft, разобран в статье [7]. Так что на уровне протокола совместимость между реализациями удовлетворительная. В то же время на уровне API совместимость даже между Heimdal и MIT Kerberos оставляет желать лучшего. Для того чтобы приложение (клиент или сервер) могло использовать Kerberos, соответствующая поддержка должна быть заложена в код программы. Реализация протокола Kerberos c нуля сложна, поэтому, как правило, приложение использует динамические библиотеки Kerberos. Реализации от MIT пользуется большей популярностью, поэтому, скорее всего, интересующее вас приложение будет использовать именно ее библиотеки. При этом поддержка Heimdal тоже может быть реализована авторами программы. Хотя заголовки функций Heimdal практически повторяют функции MIT-Kerberos, но структуры данных существенно различны. Поэтому перелинковка приложения, разработанного под MIT Kerberos c библиотеками Heimdal, даже если у вас получится это проделать, скорее всего, приведет к некорректной работе приложения. Таким образом, модификация кода приложения, пусть и небольшая, неизбежна в любом случае. Это замечание особенно актуально для Windows. Многие керберизованные приложения, разработанные под UNIX-системы, можно использовать в Windows в среде Cygwin, поскольку для авторов портирование под Cygwin дается легче, чем перелицовывание программы под полноценное Windows-приложение. Единственная реализация Kerberos, доступная для такого рода программ, – это Heimdal, и вам следует убедиться, что интересующее вас приложение поддерживает Heimdal. Удивительно, хотя MIT-Kerberos и разрабатывается под UNIX-системы, но в Cygwin-окружении он неработоспособен. Исключением является ситуация, когда приложение использует Kerberos не напрямую, а через интерфейс GSSAPI. Примером такого приложения является ftp из дистрибутива Heimdal. GSSAPI (Generic Security Service Application Program Interface) – это интерфейс, обеспечивающий стандартизованный доступ к функциям аутентификации Kerberos. Как MIT-Kerberos, так и Heimdal предлагают свои реализации GSSAPI, поэтому в данном случае обе библиотеки оказываются полностью взаимозаменямыми. На этом установку Kerberos в гетерогенной сети можно считать завершенной. В итоге вы можете управлять регистрационной информацией пользователей из одного места (сервера kdc). Ваши пользователи получают регистрацию в секторе Kerberos при входе на свои рабочие станции, прозрачный доступ к компьютерам внутри сети с помощью команд telnet и rsh, удаленный доступ к файлам при помощи ftp и rcp, шифрованный канал доступа к X-серверам. Разумеется, количество керберизованных сервисов не ограничивается только службами из состава Heimdal, но установка и конфигурирование других сервисов требует отдельного обсуждения. Литература, ссылки:
|
МИХАИЛ КОНДРИНКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
