06.04.2006

»зучаем принцип работы Ќеimdal Kerberos

image

 ак только ваша подконтрольна€ локальна€ сеть начнет развиватьс€ и расшир€тьс€, возникнут новые задачи:  ак синхронизировать системные учетные записи растущего числа пользователей?  ак управл€ть доступом пользователей к сетевым сервисам внутри локальной сети?

ћихаил  ондрин

ќпубликовано в журнале "—истемный администратор", є6-2005г.

ћихаил  ондрин

 ак только ваша подконтрольна€ локальна€ сеть начнет развиватьс€ и расшир€тьс€, возникнут новые задачи:  ак синхронизировать системные учетные записи растущего числа пользователей?  ак управл€ть доступом пользователей к сетевым сервисам внутри локальной сети? ѕри этом сервисы могут работать на разных компьютерах, а определенные службы держат собственные учетные записи дл€ авторизованных пользователей. –ешением послужит введение единой системы регистрации в локальной сети с помощью протокола Kerberos.

„тобы подробнее разобратьс€ с возникающими задачами, рассмотрим ситуацию с организацией распределенной вычислительной системы. –азумеетс€, чем больше компьютеров вход€т в кластер, тем выше его вычислительна€ мощность. Ќаиболее распространненные системы кластерных вычислений на сегодн€ Ц Parallel Virtual Machine и Message Passing Interface. ќбе позвол€ют пользователю, в данном случае разработчику программ, пересылать куски данных, нуждающихс€ в обработке, между узлами кластера и синхронизировать получение результатов с разных узлов. Ёто фасад системы. «а кулисами происходит обращение к удаленному командному интерпретатору и вызов определенных программ в нем. “о есть администратору такой системы необходимо добитьс€, чтобы пользователи кластера имели доступ к командному интерпретатору на узлах кластера и, более того, этот доступ должен быть беспарольным дл€ каждой пары компьютеров в кластере. Ќе очень-то удобна система, где запуск нескольких параллельных копий программы требует от пользовател€ регистрации на каждом из узлов кластера.

“аким образом, во-первых, информаци€ о пользовател€х должна совпадать на всех этих компьютерах. ќдин из вариантов решени€ Ц иметь одинаковые копии /etc/passwd и /etc/shadow на каждом из узлов с их последующим обновлением с помощью скриптов при добавлении нового пользовател€. ¬о-вторых, если в качестве удаленного командного интерпретатора используетс€ rsh, то добитьс€ беспарольного входа с помощью внесени€ всех компьютеров, вход€щих в этот кластер, в файл /etc/hosts.equiv (этот файл также должен совпадать на всех узлах кластера). ќднако использование rsh гарантирует вам проблемы с безопасностью, если предположить возможность доступа к кластеру извне локальной сети, который, как вы помните, должен быть беспарольным. ћожно сконфигурировать доступ по адресу компьютера (с помощью tcp-wrappers) и боротьс€ с ip-spoofing внешними средствами или настраивать openssh в качестве удаленного командного интерпретатора. ¬ последнем случае вам придетс€ миритьс€ с тем, что процессорные циклы будут расходоватьс€ не на расчет, а на кодирование/раскодирование блоков данных. “ем не менее ни одно из этих решений нельз€ считать удачным.

ƒалеко не каждому из вас приходитс€ сталкиватьс€ с настройками вычислительных кластеров. Ќо именно эта проблема построени€ распределенной вычислительной системы Athena заставила в начале 80-х годов программистов из ћассачусетского технологического института разработать и внедрить протокол удаленной аутентификации пользователей.  омбинирование специальных криптографических средств позвол€ло, с одной стороны, свести на нет веро€тность перехвата паролей и иметь шифрованный канал дл€ передачи данных между компьютерами (эта возможность могла отключатьс€ по желанию пользовател€). ј с другой Ц иметь систему с единой регистрацией (single sign-on), что дает возможность пользователю регистрироватьс€ один раз при входе в систему и в дальнейшем иметь свободный доступ к сетевым ресурсам на основе этой регистрации.

ѕон€тно, что число пользователей, которым така€ функциональность была бы удобна, значительно превышает число нуждающихс€ в распределенных системах, и в дальнейшем этот протокол, получивший название Kerberos (по имени трехголового пса из древнегреческих мифов, стерегущего вход в царство мертвых), стал широко примен€тьс€ независимо от Athena как система регистрации в крупных финансовых и академических учреждени€х.

Kerberos с точки зрени€ пользовател€

Ќа пользовательском уровне все реализации Kerberos выгл€д€т однотипно, поэтому рассмотрим, как это происходит в моем случае. –егистраци€ в Kerberos осуществл€етс€ командой kinit, котора€ автоматически вызываетс€ при моем входе на рабочую станцию под управлением Windows XP. ¬ результате мне выдаетс€ основной документ, удостовер€ющий мою личность в Kerberos, Ц Ђсупербилетї, билет, гарантирующий получение доступа к сетевым службам (или TGT Ц ticket granting ticket). ѕри этом у мен€ всегда есть возможность зарегистрироватьс€ в Kerberos под другим именем с помощью все той же команды kinit, что приводит к обновлению начального билета. “еперь предположим, что € хочу посмотреть логи на своем router/firewall под управлением Linux. я открываю терминал cygwin. ѕервое, что можно сделать, Ц просмотреть имеющиес€ билетики:

mike@alex ~\$ klist
Credentials cache: FILE:/tmp/krb5cc_1017
Principal: mike@HPPI.TROITSK.RU
 
Issued Expires Principal 
May 29 22:18:22 May 30 22:18:22 krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU

¬ списке, как вы видите, имеетс€ только один билет Ц тот самый TGT. Credential Cache Ц это файл, в котором хран€тс€ полученные мной сертификаты. ѕо умолчанию его название Ц это комбинаци€ /tmp/krb5cc_ и id пользовател€. —рок действи€ любого билетика ограничен по времени Ц это снижает интерес к его перехвату со стороны злоумышленника. “еперь € запускаю командный интерпретатор на удаленном компьютере:

\$ telnet -F relay
Trying 192.168.1.254...
Connected to relay.hppi.troitsk.ru.
Escape character is '^]'.
Waiting for encryption to be negotiated...
[ Trying mutual KERBEROS5 (host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU)... ]
[ Kerberos V5 accepts you as ``mike@HPPI.TROITSK.RU'' ]
[ Kerberos V5 accepted forwarded credentials ]
Encryption negotiated.
\$klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: mike@HPPI.TROITSK.RU
Issued Expires Principal 
May 29 22:21:16 May 30 22:18:22 krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU

¬от пример магии Kerberos в действии Ц воспользовавшись моим супербилетом, Kerberos прозрачно дл€ пользовател€ организует доступ к сетевому ресурсу (в данном случае он фигурирует под именем host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU) и более того Ц telnet при помощи Kerberos автоматически шифрует весь сетевой трафик между клиентом и сервером. —писок билетов при этом не мен€етс€ Ц ключ -F позвол€ет перемещать имеющиес€ у мен€ билетики с компьютера на компьютер. «акрытие telnet-сессии автоматически очищает кэш на удаленном компьютере с помощью вызова команды kdestroy, так что вы можете не опасатьс€, что ваш кэш может быть использован кем-то еще. “ак как супербилет по-прежнему со мной, то это позвол€ет мне получить доступ к другому компьютеру, серверу Kerberos.

\$telnet -F kenga
Trying 192.168.1.253...
Connected to kenga.hppi.troitsk.ru.
Escape character is '^]'.
Waiting for encryption to be negotiated...
[ Trying mutual KERBEROS5 (host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU)... ]
[ Kerberos V5 accepts you as ``mike@HPPI.TROITSK.RU'' ]
[ Kerberos V5 accepted forwarded credentials ]
Encryption negotiated.
mike@kenga:~\$
“очно так же € могу получить доступ к любому сетевому сервису Ц например, к локальному ftp-серверу.

mike@kenga:~\$ ftp kenga
Connected to kenga.hppi.troitsk.ru.
220 kenga FTP server (Version 6.00+Heimdal 0.6.3) ready.
Trying GSSAPI...
Authenticated to 
Authentication successful.
 
Name (kenga:mike): 
S:232-Linux 2.4.25.
S:232 User mike logged in.
S:230 Password not necessary
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bye
S:221 Goodbye.

«аметьте, что во всех случа€х мне не потребовалс€ ввод парол€. ƒоступ ко всем компьютерам мне предоставл€лс€ на основании моего TGT. ¬се операции c Kerberos (выдача билетов, добавление/удаление пользователей и т. д.) фиксируютс€ в его логах, и можете убедитьс€, что вс€ мо€ активность с перемещени€ми от компьютера к компьютеру зафиксирована в файле /var/log/krb5kdc.log. ƒл€ удобства € разделил кусок log-файла на 4 части, соответствующие процессам получени€ доступа к моей рабочей станции, удаленного доступа к двум серверам и серверу ftp.

2005-05-29T22:18:22 AS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU
2005-05-29T22:18:22 Using des-cbc-crc/des-cbc-md5
2005-05-29T22:18:22 Requested flags: renewable_ok, renewable, forwardable
2005-05-29T22:18:23 sending 574 bytes to IPv4:192.168.1.45
2005-05-29T22:18:23 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [renewable, forwardable]
2005-05-29T22:18:23 sending 593 bytes to IPv4:192.168.1.45
......
2005-05-29T22:21:15 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for host/relay.hppi.troitsk.ru@HPPI.TROITSK.RU
2005-05-29T22:21:16 sending 546 bytes to IPv4:192.168.1.45
2005-05-29T22:21:16 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.45 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]
2005-05-29T22:21:16 sending 589 bytes to IPv4:192.168.1.45
......
2005-05-29T22:21:43 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.254 for host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU
2005-05-29T22:21:44 sending 550 bytes to IPv4:192.168.1.254
2005-05-29T22:21:44 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.254 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]
2005-05-29T22:21:44 sending 593 bytes to IPv4:192.168.1.254
......
2005-05-29T22:22:27 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for ftp/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU
2005-05-29T22:22:27 Server not found in database: ftp/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU: No such entry in the database
2005-05-29T22:22:27 sending 145 bytes to IPv4:192.168.1.253
2005-05-29T22:22:27 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for host/kenga.hppi.troitsk.ru@HPPI.TROITSK.RU
2005-05-29T22:22:27 sending 550 bytes to IPv4:192.168.1.253
2005-05-29T22:22:28 TGS-REQ mike@HPPI.TROITSK.RU from IPv4:192.168.1.253 for krbtgt/HPPI.TROITSK.RU@HPPI.TROITSK.RU [forwarded, forwardable]
2005-05-29T22:22:28 sending 546 bytes to IPv4:192.168.1.253

¬ы можете сказать: Ђ ак же так Ц протоколы telnet и ftp небезопасны и правильнее использовать openssh. » ничего удивительного в беспарольной аутентификации нет Ц ту же самую функциональность обеспечивает ssh, предоставл€€ возможность регистрироватьс€ по парам публичных/секретных ключейї. ¬се правильно. “олько дл€ того, чтобы в сети из N компьютеров обеспечить доступ по ssh с любого из этих компьютеров на любой другой, вам придетс€ в общем случае проделать 2N*{число пользователей} перемещений публичных ключей (кажда€ пара компьютеров в сети обмениваетс€ публичными ключами пользователей), что в случае больших сетей трудноосуществимо. ¬ то же врем€ с помощью Kerberos вам нужно только зарегистрировать каждый из компьютеров на сервере Kerberos и иметь один ключ на каждом из хостов (в отличие от ssh в Kerberos используетс€ симметричное шифрование) Ц итого 2N операций. „то же касаетс€ первой части вопроса, то € использую специальный Ђкерберизованныйї вариант telnet, что защищает соединени€ между хостами не хуже, чем ssh. √лавный недостаток стандартного telnet (и не только его) состоит в том, что при аутентификации на удаленном компьютере telnet пересылает пароль пользовател€ по сети в виде открытого текста, что позвол€ет злоумышленнику перехватить его. Ssh обходит эту опасность с помощью несимметричного шифровани€ парол€. ј каким же образом Kerberos удаетс€ избегать брешей в защите св€занных с удаленной аутентификацией?

”даленна€ аутентификаци€ в Kerberos

ƒелаетс€ это с помощью уже упоминавшихс€ ранее билетиков/сертификатов (tickets/credentials Ц оба слова используютс€ как синонимы) Ц специальным образом изготовленных и упакованных шифровальных ключей. ¬ Kerberos как пользователь, так и сетева€ служба не различаютс€ между собой и именуютс€ principal (принципал Ц юридический термин, означающий лицо, поручающее агенту совершить сделку от его имени), что весьма точно описывает функции принципалов в Kerberos. ѕринципалы определ€ютс€ своим именем и паролем, причем в случае сетевой службы в качестве этого парол€ выступает ключ, хран€щийс€ на том же компьютере, где работает защищаемый сервис. Ѕаза данных принципалов хранитс€ на сервере Kerberos, и при необходимости проверить аутентичность пользовател€ или сервиса, компьютеры, объединенные в сектора (realms), соедин€ютс€ с этим сервером. ѕо поводу терминологии: точный перевод Ђrealmї (Ђцарствої) применительно к Kerberos не прижилс€, а иногда используемый термин Ђдоменї не кажетс€ мне удачным, поскольку слово и так перегружено. “ак же, как и в случае с DNS, главный контроллер сектора Kerberos (Key Distribution Center, KDC, центр выдачи ключей) может иметь как дополнительные, slave, контроллеры (что позвол€ет обеспечить бесперебойную работу при выходе из стро€ основного контроллера), так и в одиночку держать несколько секторов. “ипичное им€ принципала, например, сервиса удаленного доступа к командному интерпретатору компьютера, выгл€дит таким вот образом: host/kdc.myrealm.ru@MYREALM.RU, что обозначает сервис с основным именем (primary name) host и характеристикой (instance) kdc.myrealm.ru, принадлежащий сектору MYREALM.RU. –азделение имен принципалов на несколько частей позвол€ет различать, с одной стороны, разные службы, работающие на одном хосте (с помощью primary name, host в нашем случае). ј с другой Ц среди нескольких однотипных служб, работающих в сети, выбирать конкретную, запущенную на определенном сервере (с помощью пол€ instance, котора€ в нашем случае совпадает с именем компьютера). Ќазвание секторa не об€зано повтор€ть доменное им€ сети, но именно такое правило наименований считаетс€ усто€вшейс€ практикой.

“еперь посмотрим, что происходит, если пользователь joeuser (а точнее, принципал joeuser@MYREALM.RU Ц поле instance дл€ Ђживыхї пользователей обычно не используетс€) пытаетс€ получить доступ к этому серверу. ѕредполагаетс€, что как клиентска€ программа telnet, так и telnetd демон собраны с поддержкой Kerberos (обе эти программы вход€т в дистрибутив Heimdal). –азумеетс€, как сам сервер, так и пользователь должны быть зарегистрированы в одном и том же секторе Kerberos.  ак обычно, сеанс подключени€ к серверу начинаетс€ с того, что пользователь запускает telnet со своим регистрационным именем и именем удаленного компьютера telnet -l joeuser kdc.myrealm.ru.  лиентска€ программа после этого обращаетс€ к KDC с просьбой предоставить дл€ joeuser доступ к хосту kdc.myrealm.ru. Kerberos генерирует по определенным правилам шифровальный ключ (session key) и разыскивает по своей базе данных принципалов joeuser и host/kdc.myrealm.ru, а также их пароли (ключи). ≈сли пароли найдены (в противном случае сеанс заканчиваетс€ аварийно Ц т.к. кто-то из этих двух принципалов не зарегистрирован в секторе Kerberos), Kerberos приступает к генерированию сессионного ключа (session key). — помощью ключа принципала host/kdc.myrealm.ru он шифрует сгенерированный session key вместе с именем пользовател€ joeuser, потом прилагает к зашифрованному блоку вторую копию того же session key и снова шифрует получившийс€ билетик с помощью парол€ пользовател€. ѕосле этого пакет отсылаетс€ клиентской программе. ≈сли к этому времени пользователь набрал свой пароль и он совпадает с паролем, использованным Kerberos при шифровке, то клиентска€ программа сумеет расшифровать билетик. ƒалее, половина билетика (с session key) остаетс€ пользователю, а втора€, котора€ не может быть расшифрована клиентом, поскольку ключ сервера ей неизвестен, пересылаетс€ на сервер. —ервер расшифровывает ее с помощью своего ключа и таким образом узнает как session key, так и им€ пользовател€, что позвол€ет серверу авторизовать его своими собственными средствами. «аметим, что помимо регистрации в этом случае имеетс€ возможность использовать полученный session key, поскольку в итоге он известен как клиенту, так и серверу, дл€ шифровани€ сетевого трафика в рамках данной сессии, чем многие приложени€ и пользуютс€. —хематически процесс обмена сертификатами показан на рис. 1.

–исунок 1. ѕроцесс обмена сертификатами

„то еще интересного в используемом Kerberos механизме аутентификации? ƒело в том, что Kerberos оказываетс€ еще более параноидальным, чем мы предполагали вначале, т.е. считает ненадежными не только сетевые соединени€ (ни один из паролей, как вы могли заметить, не передаетс€ в открытую по сети), но и клиентский, и даже серверный компьютер. ƒл€ каждого из них ключ/пароль партнера так и остаетс€ неизвестным Ц только session key, который дл€ потенциального взломщика интереса не представл€ет, поскольку используетс€ только в данной сессии.  ак известно, безопасность и удобство пользователей вещи взаимоисключающие. Ќо ученым из ћ“» удалось найти удачный компромисс, придумав еще одну замечательную вещь Ц ticket granting ticket (TGT). ≈сли пытатьс€ переводить этот термин на русский Ц Ђбилет дл€ выдачи других билетовї, что-то вроде единого проездного. —мысл его в том, что пользователь сети проходит полностью процедуру регистрации (с вводом имени и парол€) в своем секторе только один раз, а сертификат, полученный в результате, затем используетс€ клиентскими приложени€ми как эквивалент пользовательского парол€ дл€ получени€ доступа к сетевым сервисам. ѕроцесс выдачи “GT ничем не отличаетс€ от описанного выше, только в качестве службы, к которой пользователь получает доступ, выступает сам Kerberos Ц его Ticket Granting Service. ѕосле получени€ TGT записываетс€ в кэш-файл на диске клиентского компьютера и затем по мере надобности извлекаетс€ оттуда. ¬ схеме, описанной выше, session-key, закодированный в TGT используетс€ вместо парол€ пользовател€ при шифровании сертификата, предоставл€емого дл€ доступа к сетевому ресурсу. » хот€ TGT хранитс€ в кэше на диске рабочей станции пользовател€, угроза, св€занна€ с его перехватом, не столь уж серьезна, поскольку его действенность ограничена по времени. TGT позвол€ет организовать в корпоративной сети single sign-on (система единой регистрации) систему. Ќапример, с помощью замены системного login на керберизованный аналог (программа с тем же именем входит в состав Heimdal Kerberos) при входе на рабочую станцию пользователь получает TGT, который затем используетс€ дл€ генерировани€ билетиков, специфичных дл€ какой-нибудь из сетевых служб.

“аким образом, следует помнить, что при любой аутентификации в Kerberos всегда участвуют два принципала Ц один соответствует пользователю, пытающемус€ получить доступ к сервису, а второй Ц самому этому сервису. ћы не будем рассматривать более сложный механизм аутентификации, так называемый user-to-user, когда сетевой сервис не имеет собственной записи в базе данных Kerberos, а использует сертификаты пользовател€, запустившего сервис. јутентификаци€ user-to-user могла бы быть полезна, например, дл€ X-серверов, но и дл€ них эта методика не получила большого распространени€.

“ак в общих чертах выгл€дит принцип работы Kerberos. ћногие детали реализации протокола Kerberos при этом пришлось опустить. ¬ частности, формат сертификата в действительности более сложен, чем описано здесь. ¬ него входит врем€ выдачи и срок годности сертификата, адрес компьютера, на который отсылаетс€ сертификат, и флажки, позвол€ющие контролировать использование сертификатов и тем самым настраивать политику безопасности внутри сектора Kerberos. —кажем, с помощью сн€ти€ флажка forwardable можно Ђприв€затьї сертификат к одному компьютеру и запретить его перемещение на другие хосты. ѕример, рассмотренный в начале статьи, был бы невозможен в этом случае Ц после получени€ удаленного доступа мне каждый раз потребовалось бы вводить пароль дл€ запроса нового TGT.

¬ следующем номере журнала мы перейдем к практической части и развернЄм инфраструктуру Kerberos в локальной сети.

ѕриложение

»стори€ создани€ Kerberos

¬ 1983 году была начата работа по созданию системы Athena. –аботу финансировали компании IBM и DEC, и в 1987 году была выпущена перва€ верси€ протокола Kerberos (Kerberos 4). ƒальнейша€ эксплуатаци€ вы€вила недостатки протокола, и обновленный вариант Kerberos 5 вышел в свет в 1993 году. ¬ насто€щее врем€ 4 верси€ практически не используетс€, но в реализаци€х протокола от ћ“» совместимость с предыдущей версией продолжает сохран€тьс€.   1993 году протокол Kerberos уже завоевал попул€рность, и многие компании, разработчики программного обеспечени€ стремились использовать его в своих программных продуктах. Ќо тут имел место юридический казус Ц дело в том, что в то врем€ в —Ўј еще действовали законы, введенные еще во врем€ холодной войны, запрещающие экспорт военных технологий. ѕоскольку криптографическа€ защита, использованна€ в Kerberos, классифицировалась как военна€ технологи€, это создавало преп€тстви€ дл€ использовани€ его в программных продуктах сторонних фирм и распространени€ его за пределами —Ўј. ƒл€ решени€ этой проблемы была выпущена верси€ протокола Kerberos 4, из которого была изъ€та вс€ сильна€ криптографи€. Ёта реализаци€ Kerberos получила название Bones (кости), и ограничени€ на ее экспорт уже не действовали. ¬ 1997 году группа программистов из —токгольмского  оролевского университета, вз€в за основу Bones, проделала обратную работу и вставила недостающую криптографическую функциональность. ¬от так экспортные ограничени€ —оединенных Ўтатов способствовали развитию европейского hi-tech. ¬последствии ими же была выпущена реализаци€ протокола Kerberos 5, получивша€ название Heimdal. Heimdal (’еймдалль) Ц это божество из скандинавского пантеона, чьи функции состо€ли в охране стратегических коммуникаций, а именно Ц моста, раздел€ющего јсгард и ћидгард. “ак же, как и в случае с древнегреческим прототипом Kerberos, здесь эксплуатируетс€ образ неподкупного стража. »нтересно отметить, что мотивом дл€ программистов из —токгольмского университета, так же как и дл€ их коллег из ћ“», €вл€лась задача обеспечени€ публичного доступа к вычислительному кластеру. ѕоследним эпизодом из истории Kerberos стало объ€вление компанией Microsoft в 1999 году о поддержке Kerberos в своей будущей операционной системе NT 5.0 (впоследствии названной Windows 2000), что действительно было реализовано в качестве компонента Active Directory. ¬ насто€щее врем€ Kerberos €вл€етс€ промышленным стандартом удаленной аутентификации пользователей.

Ћитература, ссылки:

1. √ребенников –. “анцуем —амбу. Ц ∆урнал Ђ—истемный администраторї, є11, но€брь 2004 г. Ц 32-38 с.

2. ‘ундаментальное обсуждение протокола Kerberos (на англ.) можно найти в ссылках на сайте ћассачусетского технологического института: http://web.mit.edu/kerberos/www/papers.html.

ѕроходит конкурсный набор авторов в рубрику Ђ»нформационна€ безопасностьї журнала Ђ—истемный администраторї.

”слови€ участи€: присылайте материал на любую актуальную тему по безопасности, ранее нигде не опубликованный, объемом от 13 до 18 тыс. знаков на адрес Ђsekretar@samag.ruї. Ћучшие материалы будут опубликованы в журнале с выплатой высокого гонорара, с лучшими авторами редакци€ продолжит сотрудничество.

или введите им€

CAPTCHA