я вас не понял вы сами сказали что керберос для того чтоб логин и пароль ни каким случаем не передается а на видео точнее 14:12 говорит клиент передает свой логин и пароль на KDC в зашифрованном формате как так?
а если там же сказать, что пароль передается в зашифрованном виде, то получается, что один и тот же логин и пароль должны передаваться на КДЦ в одном виде, если хеш и метод шитья не передаются на КДЦ, как будет расшифровываться эта информация для уточнения?
Клиент не передает свой пароль в зашифрованном формате. Хэш пароля используется в качестве ключа криптографической функции, а аргументом этой функции является текущее время. Это несколько другое))
Автор сам свои слайды видел? Откуда на последнем слайде у клиента TGS_s, если KDC клиенту только TGS_c передает? Мог бы хоть демо какое-нибудь придумать на докерах, если стандарт открытый
Майкрософт ничего тут не придумал, керберос гораздо старше их продуктов и выдержал проверку временем. Мути здесь никакой нет. Это совершенно логичная схема, которая прекрасно работает, прекрасно масштабируется, и с точки зрения безопасности дает точные гарантии и имеет хорошо известные слабости, которые компенсируются дизайном окружающей среды.
Нужно уточнять, что сам протокол Керберос действительно создан чтобы не светить паролями, но передача например от фронта в бэк веб-сервисов все еще уязвима, тем не менее TLS без проблем это нейтрализует. Не стоит путать аутентификацию (это как раз задача Kerberos на основании реквизитов) и авторизацию (это всякие там политики AD по аналогии с PAM в линукс, всякие там разрешения к чему-либо). Не хватает еще важной темы - credential cache, которой пренебрегают треш-модули Oracle для Java. И не раскрыта тема расширений S4U2Proxy и S4U2Self
Спасибо автору, было познавательно!
Хотелось бы больше прикладной информации, например, про SSO, работу с SPN, Keytab и про делегирование.
Спасибо, что выложили
Мне стало понятнее!
Всё интересно слушать! Спасибо!
все понятно. спасибо ! в дополнение к теории было бы неплохо примеры тикетов: как они выглядят, как диагностируются в системе, что у них внутри
Я не понимаю, почему так мало лайков при таком количестве просмотров? Материал очень годный, уже не первый раз захожу сюда, чтобы освежить знания.
Это скорее риторический вопрос
Потому что пересмотреть можно несколько раз, а лайк только один
@@user-kb6ii4dw4q тоже верно
спасибо
Спасибо огромное! Крутой урок, крутой препод :)
Отличное видео. Не примитивно, ничего принципиального не упущено - но и и не настолько глубоко, чтобы запутаться. Спасибо!!!
Хорошо объяснение, спасибо
Клевые картинки, спасибо.
Спасибо
Хорошая лекция, только преподаватель несколько раз называл KDC сервером(он, в принципе, им и является), что немного сбивало с толку.
как намудрили с этим шифрованием
однако нормальное подробное объяснение
на 2 картинке сам запутался
Хорошо объясняет, но протокол очень замудрённый)
Пишу из 23-го, у нас тут намечаются проблемы с AD =)
почему?
Проблем с ad нет, если проблемы с поддержкой этого барахла в линуксе))
я вас не понял вы сами сказали что керберос для того чтоб логин и пароль ни каким случаем не передается а на видео точнее 14:12 говорит клиент передает свой логин и пароль на KDC в зашифрованном формате как так?
а если там же сказать, что пароль передается в зашифрованном виде, то получается, что один и тот же логин и пароль должны передаваться на КДЦ в одном виде, если хеш и метод шитья не передаются на КДЦ, как будет расшифровываться эта информация для уточнения?
Клиент не передает свой пароль в зашифрованном формате. Хэш пароля используется в качестве ключа криптографической функции, а аргументом этой функции является текущее время. Это несколько другое))
Автор сам свои слайды видел? Откуда на последнем слайде у клиента TGS_s, если KDC клиенту только TGS_c передает? Мог бы хоть демо какое-нибудь придумать на докерах, если стандарт открытый
информация вообще не сходится сильно
Только Майкрософт могли такую муть придумать
Майкрософт ничего тут не придумал, керберос гораздо старше их продуктов и выдержал проверку временем. Мути здесь никакой нет. Это совершенно логичная схема, которая прекрасно работает, прекрасно масштабируется, и с точки зрения безопасности дает точные гарантии и имеет хорошо известные слабости, которые компенсируются дизайном окружающей среды.
Нужно уточнять, что сам протокол Керберос действительно создан чтобы не светить паролями, но передача например от фронта в бэк веб-сервисов все еще уязвима, тем не менее TLS без проблем это нейтрализует. Не стоит путать аутентификацию (это как раз задача Kerberos на основании реквизитов) и авторизацию (это всякие там политики AD по аналогии с PAM в линукс, всякие там разрешения к чему-либо). Не хватает еще важной темы - credential cache, которой пренебрегают треш-модули Oracle для Java. И не раскрыта тема расширений S4U2Proxy и S4U2Self