Комментарии 19
Во ?. Но будем чесны, "простых слов" тут маловато ?. Второй раз читаю и уже начинает болеть голова, но всегда хотел разобраться с темой kerberos, да все руки не доходили. Предлагаю следующую статью выпустить под темой "Завозим krb на виртуалке" - либо что-то подобное.
Изначально я делал статью на гораздо более простом уровне объяснений. Что-то вроде «Kerberos для бухгалтеров». Но в процессе мне стало так скучно, что я даже был вынужден взять перерыв и заняться другими делами. В конце концов написал как можно более просто и в достаточной мере интересно для себя.
Поверьте, это вообще мало кто знает. Меня недавно наши безопасники спрашивали - а как вы аутентифицируете сервер (KDC) при запросе TGT или TGS. Я им навскидку отвечаю - а никак. Мы ему просто доверяем. А вот попробуйте доказать с документами, что это именно так, а не иначе.
Два простых вопроса:
у вас есть строгое описание формата keytab?
знаете ли вы алгоритм выбора KDC, если в krb5.conf написано dns_lookup_kdc?
Предлагаю вам самостоятельно поискать скажем в Google. К моей статье эти вопросы не имеют отношения.
Уж поверьте, я гуглил много раз - количество информации по этой теме довольно скудное.
Я без претензий, вы могли на чей-то код опираться, но вы вот вроде утверждаете, что реализовали что-то типа kinit. А как же вы его реализовали, если не знаете, какой формат у keytab? Где-то же вы информацию брали?
А, кажется я понял. PKINIT, да...
А вообще я где-то встречал описание keytab. Может завтра найду ещё раз. А по второму вопросу: в статье я описал, как ищется адрес KDC с помощью DNS. То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.
Ну я нашел некую структуру в терминах C. Но к ней не было никаких слов пояснения.
То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.
Я поясню, в чем у меня проблема. У меня DNS георезервированный. Т.е. если я в одном ЦОД, он мне вернет один список KDC, если в другом - другой. И этих KDC там будет штук 30-40, причем с разными весами и приоритетами. Вот этот самый множественный выбор все и осложняет. А некоторые KDC при этом точно брать нельзя, потому что они TGT не выдают (я это априори знаю). А так-то сам список я знаю как достать, это давно реализовано.
Такие нюансы надо смотреть непосредственно в коде клиента Kerberos на вашей ОС. Если уж разговор про krb5.conf, то это *nix. А там вроде всё открытое.
https://www.ioplex.com/utilities/keytab.txt - формат keytab
Юрий, большое спасибо за статью! У меня вопрос по поводу U2U. Когда мы используем U2U сервисный билет будет зашифрован сессионным ключом KDC пользователя-"сервера" , который он получит в ходе Kerberos аутентификации (Например при интерактивном входе в систему на своем компьютере). Сам сессионный ключ KDC пользователя-сервера будет получен путем передачи TGT билета пользователя-сервера пользователю-клиенту, когда стандартный запрос AP-REQ к серверу будет отклонен. Этот запрос отклоняется по причине того что, пользователь-сервер не может найти свои "долгосрочные" ключи (или нет?) и таким образом ему необходимо использовать сессионный ключ. Вопрос в том, что я не понимаю почему пользователь-сервер не может найти свои "долговременные" ключи? По идее эти ключи хранятся в LSA, а если быть более точным, в сессии пользователя-сервера. Соответственно пользователь-сервер имеет доступ к этой части LSA (ведь там же хранятся билеты и сессионные ключи) И, если, например, мы выполняем интерактивный вход на компьютер-сервер посредством пароля, то в сессии пользователя-сервера помимо билетов, также сохраняются ключи в формате rc4, aes. Именно эти ключи, насколько я понимаю, и считаются "долговременными". А, если вход на компьютер-сервер был осуществлен посредством сертификатов, разве в LSA не будет лежать наш rc-4 ключ, который по идее можно было бы использовать для расшифровки TGS при определенных условиях?
При U2U в сессии сервиса нет информации об имени пользователя и пароле. Такая ситуация возникает, например, когда сервис аутенцифицируется с использованием PKINIT. При использовании PKINIT сервису нет необходимости знать имя пользователя и его пароль. Вместо этого для шифрования пре-аутентификационных сообщений используется закрытый ключ сертификата. KDC возвращает NTLM хэш в TGT полученном по PKINIT, однако реализация стандартного сервиса Kerberos этот хэш нигде не сохраняет и не использует. Расширение U2U используется не всегда, оно просто предназначено для специального случая когда сервис прошёл аутентификацию без использования имени пользователя и пароля.
Спасибо.
Не знаю почему, но наткнувшись на статью стало интересно)
Пришлось перегуглить десятка два-три терминологий, попутно сворачивая в познавательные ссылки.
Даже залогинился, что бы сказать "спасибо" за 4 часа познавательной годноты!)
P.s. статью победил, умнее чуточку стал.
Публикации
Kerberos простыми словами