конфигурация google-chrome для kerberos authentication с ldap-сервером

браузер посылал запрос в ldap-сервер на получение ticket по kerberos-протоколу?

ой.

1. Сам по себе хром ни к какому ldap-серверу обращаться не будет. Если речь идёт о линуксе, то на клиенте должен быть указан соответствующий керберос-сервер. Винда должна быть заведена в соответствующий домен.
2. Далее ты получаешь на клиенте керберос-тикет kinit username@DOMAIN.
3. Далее, для chromium нужно создать политику:

   cat << EOF > /etc/chromium/policies/recommended/negotiate.json
   {
       "AuthServerWhitelist":              "server.domain"
   }
   

4. Это скажет хрому, что на данный сайт можно отправлять тикеты.
5. Если нужна делегация тикетов, то дописываешь в политику

   "AuthNegotiateDelegateWhitelist": "server.domain"
   

HTTP/1.1 401 Access Denied\r\nWWW-Authenticate: Negotiate\r\n\r\n

Там должно быть 'Unauthorized', но не уверен, что это на что-то влияет. Вполне вероятно, браузер смотрит только на статус.

ну я профан в этих делах... а что не так?

спасибо за ответ... на самом деле то у меня клиент на виртуалке на винде, соответственно, хром тоже на ней, и access directory тоже на виртуалке на винде, только лишь собственный сервер(с логикой) на линуксе... с ldap вообще никогда не работал, полное дно

Сам по себе хром ни к какому ldap-серверу обращаться не будет

в статейке пишется что будет... т.е. вследствие пришедшего «NOT Authorized» браузер получает токен из kdc, потом отправляет его на сервер и получаем доступ... а если браузер сам ничего не отправляет, тогда я логики не понимаю

Далее ты получаешь на клиенте керберос-тикет

да вроде ж браузер и есть клиент в данном случае?

Первое: ldap и kerberos - разные вещи. ldap может работать без кербероса, керберос может работать без лдапа.

Второе: Если у тебя есть домен active directory (что такое access directory?), и винда, заведённая в этот домен, то при входе под доменной учётной записью, она сама получает тикет.

Третье: Как на винде включить керберос аутентификацию в хроме нагугли сам, там примерно тоже, что и в линупсе, только где-то в глубинах реестра.

Четвертое: Клиент кербероса - это твоя винда. Если ты вдруг заведёшь хрома в домен, отдельно от винды, так чтобы он мог самостоятельно получать тикеты, то тогда он станет клиентом кербероса. Покуда он лишь использует тикеты хоста - клиентом кербероса он не является.

Пятое: Вообще непонятно, что непонятного написано в первом посте, и что мешает немного подумать, погуглить, и сделать всё как надо. Ты либо говори конкретно, что не получается, либо RTFM, пока не начнёшь понимать, что происходит. Ты вообще про то, что такое керберос читал?

Ты вообще про то, что такое керберос читал?

ну так, смутновато конечно

Клиент кербероса - это твоя винда

хм, если клиент винда, то как тогда узнать и переслать серверу с логикой этот токен? его ж надо как-то узнать в таком случае... и отправить... я думал браузер это делает автоматом

ну так, смутновато конечно

Ну очевидно, что надо более подробно изучить, что такое керберос, как он работает и для чего используется. Тогда большая часть твоих вопросов отпадёт сама.

я думал браузер это делает автоматом

Ты заблуждался.

хм, а когда мы заходим в учетную запись на винде, то мы, получается, получаем TGT уже? а для взаимодействия с сервером нам нужен TGS, правильно?

когда мы заходим в учетную запись на винде, то мы, получается, получаем TGT уже?

Ну по идее да. Когда ты вводишь логин/пароль, винда передаёт его на kdc, а оттуда приходит tgt. Вся остальная аутентификация в сервисах ведётся с использованием уже полученного тикета.

а для взаимодействия с сервером нам нужен TGS, правильно?

С каким сервером? Непонятно, что ты имеешь ввиду.

С каким сервером? Непонятно, что ты имеешь ввиду.

ну имел ввиду свой сервер с логикой, на линуксе

и снова к вопросу о самопосылании KRB_TGS_REQ браузером: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/csec_SPNEGO_explain.html ну вроде как может браузер сам посылать то... разве нет?

ну имел ввиду свой сервер с логикой, на линуксе

Твой сервис на «сервере с логикой, на линуксе» должен иметь возможность проверить тот токен, который засылает ему клиент в качестве аутентификации. Для этого у него должен быть собственный keytab, полученный на том же kdc.

Так же, как я понимаю, клиент проверяет, известен ли service principal твоего сервиса kdc и проверяет его подлинность. Но тут не уверен, бывают ли исключения. У меня такое получалось только заводя линукс в домен AD. Хотя можно пошаманить в AD и создать принципал и keytab для сервиса самому.

и снова к вопросу о самопосылании KRB_TGS_REQ браузером

The client requests a Service Ticket (TGS_REQ).

ну вроде как может браузер сам посылать то... разве нет?

А что он по-твоему посылает?

Твой сервис на «сервере с логикой, на линуксе» должен иметь возможность проверить тот токен, который засылает ему клиент в качестве аутентификации

всмысле нужно проверить маркер времени из TGS(TGS сервиса посылает ему клиент т.к. их два приходят от KDC клиенту)? или что-то еще?

А что он по-твоему посылает?

хм, думаю пакет KRB_TGS_REQ по протоколу kerberos5, если не ошибаюсь

всмысле нужно проверить маркер времени из TGS(TGS сервиса посылает ему клиент т.к. их два приходят от KDC клиенту)? или что-то еще?

Учитывая, что TGS - это ticket granting server, часть kdc, твоё предложение выглядит сомнительно и не поддаётся расшифровке.

Сервису нужно проверить, что токен, присланный клиентом - не какая-то херня, а правильный токен, содержащий валидный мандат для аутентификации именно на этом сервисе именно этого клиента.

хм, думаю пакет KRB_TGS_REQ по протоколу kerberos5, если не ошибаюсь

А что такое KRB_TGS_REQ?

Учитывая, что TGS - это ticket granting server, часть kdc, твоё предложение выглядит сомнительно и не поддаётся расшифровке.

ну я это смотрел: https://www.techdays.ru/videos/3239.html, хотя там коммент как раз есть подходящий.

ну смысл в чем: от active directory к клиенту приходят два сеансовых билета(сразу сервису ничего не приходит). один из них передается сервису от клиента... сеансовый билет состоит из общего ключа для клиента и сервера, имя пользователя, маркер времени, и сколько времени может жить билет... так вот, когда этот сеансовый билет попадает к серверу от клиента, то он расшифровывается, из него берется этот самый маркер времени, по которому мы удостоверяемся что клиент валиден. я понял так, возможно что-то опять не правильно...

А что такое KRB_TGS_REQ?

отсюда все https://habrahabr.ru/post/321962/

то он расшифровывается, из него берется этот самый маркер времени, по которому мы удостоверяемся что клиент валиден.

Ну сервис удостоверяется в валидности клиента по самому факту расшифровки. Маркер времени это доп. проверка для защиты от повторов и способ подтвердить сервису свою подлинность. А так всё правильно, вроде.

отсюда все https://habrahabr.ru/post/321962/

Разговор ушёл куда-то в дебри.

Короче, чтобы получить tgt тебе нужен пароль пользователя. Ты его можешь получить только при входе в систему. Вот именно тогда хост и получает свой tgt, а далее его вовремя обновляет.

Хром никакого tgt не получает. Он берёт tgt от хоста(твоей винды), и запрашивает у kdc ( у tgs) сеансовый билет сервиса (он же мандат сервиса), и отдельно сеансовый ключ. Всё. Дальше он общается только с сервисом, покуда срок действия мандата не истечёт.

Хром никакого tgt не получает. Он берёт tgt от хоста(твоей винды),

вот это самое не понятное: как хром может его получить от оси? хотя бы на линуксе

хм, и еще вопрос: мой сервак, я так понимаю, надо тоже регистрировать в AD?

вот это самое не понятное: как хром может его получить от оси?

Он получается пользователем, и вполне логично, что он доступен ему для чтения. Иначе зачем он вообще нужен?

хотя бы на линуксе

Ну в моей центоси по дефолту тикеты хранятся в KEYRING:persistent:%{uid}, так что видимо как-то так. Для общего понимания, можешь потыкать kinit/klist/kvno. Для их работы необходим tgt, но на kdc его получает только kinit.

Он получается пользователем, и вполне логично, что он доступен ему для чтения. Иначе зачем он вообще нужен?

хм, ну вот смотрите: у меня есть изначальная задача сделать sso авторизацию через ldap на пользование моим(ну не совсем моим, разумеется) сервером, я выбрал через kerberos и нагуглил ту статейку на хабре выше... я хотел повторить что есть в ней, и вот понимаю, что чтобы посылался сеансовый билет серверу, то у меня не сделано что-то... а почему там SPNEGO еще прикручен? я так понял spnego это вообще отдельный протокол не связанный с kerberos

Ты свой сайт хрому в белый список добавил?

имеется ввиду домен active directory? да, вроде как добавил, если конечно все правильно

хм, и еще вопрос: мой сервак, я так понимаю, надо тоже регистрировать в AD?

Тебе надо, чтобы kdc знал о существовании твоего сервиса на этом сервере. Т.е. должна быть запись вида HTTP/server.domain@DOMAIN.

Сделать это можно разными путями. Т.к. AD создаёт записи HTTP/... по дефолту, то самый простой способ - завести линукс в домен. Проверено на Centos 7 + realmd, nginx + python3 - sso работает.

После добавления в домен, нужно экспортировать keytab для сервиса с контроллера домена на сервер, либо выдать права веб-серверу для чтения host-keytab и заменить в коде service principal с HTTP/... на HOST/... .

Имеется ввиду аналог вот этого:

cat << EOF > /etc/chromium/policies/recommended/negotiate.json
{
    "AuthServerWhitelist":              "server.domain"
}

для виндового реестра. Вроде как хром может ориентироваться на групповые политики ie, но в виндовых политиках я профан.

Вроде как хром может ориентироваться на групповые политики ie, но в виндовых политиках я профан

да я тоже профан, но, насколько в гугле объяснено, в свойствах обозревателя устанавливаем список белых сайтов и их использует и хром

Ну тогда тебе надо добавить service principal в AD, доставить keytab веб-серверу и смотреть, что происходит.

а вот еще такие вопросы: вот нашел я кое-что http://www.alsigned.ru/?p=2907 в общем все понятно кроме двух вещей: для убунты krb5-workstation напрочь отсутствует и в статейке создается krb5.conf, где указывается некий realm, нужно ли мне создавать этот файл? я так понимаю, что в моем случае просто положить keytab из винды и все

для убунты krb5-workstation напрочь отсутствует

Значит соответствующие утилиты там сложены в какой-то другой пакет.

я так понимаю, что в моем случае просто положить keytab из винды и все

Попробуй. Скорее всего достаточно.

Т.к. AD создаёт записи HTTP/... по дефолту, то самый простой способ - завести линукс в домен.

Да ладно. При заведении в домен создается машинный аккаунт, к которому привязан SPN вида HOST/..., а не HTTP/.

хм, есть active directory с доменом test.local... хочу я, убунтой, допустим, зайти в AD под пользователем ub... мне в AD сгенерировать SPN-имя какое? HTTP/ub.test.local@TEST.LOCAL или какое?

к которому привязан SPN вида HOST/..., а не HTTP/.

В AD и HTTP/ тоже по дефолту создаётся. Инфа 92%.

Если ты хочешь, чтобы убунта видела доменных пользователей, и их аутентифицировала, то придётся заводить её в домен (ну либо ldap-авторизацию самому сделать, но нафига?). Можно samba4+winbind, но по моему опыту, лучше всего работает realmd.

Что-то в стиле:

realm discover test.local
realm join test.local -U admin

В AD и HTTP/ тоже по дефолту создаётся. Инфа 92%.

Не может того быть. Вот SPN для Win7 и RHEL7. В обоих случаях никаких HTTP/.

C:\> setspn -l WIN7
Registered ServicePrincipalNames for CN=WIN7,OU=<skipped>,DC=domain,DC=local

        WSMAN/WIN7.domain.local
        WSMAN/WIN7
        CmRcService/WIN7.domain.local
        CmRcService/WIN7
        TERMSRV/WIN7.domain.local
        TERMSRV/WIN7
        RestrictedKrbHost/WIN7
        HOST/WIN7
        RestrictedKrbHost/WIN7.domain.local
        HOST/WIN7.domain.local

C:\> setspn -l RHEL7
Registered ServicePrincipalNames for CN=RHEL7,OU=<skipped>,DC=domain,DC=local
        HOST/rhel7.domain.local
        HOST/RHEL7

Не может того быть. Вот SPN для Win7 и RHEL7. В обоих случаях никаких HTTP/.

Действительно. Похоже, что spn AD не создаёт. Только вот kvno HTTP/server.domain работает, даже если нет spn с http/.

В общем что-то с AD мутное, и она, видимо считает, что HOST/ и HTTP/ одно и тоже.

И sso работает без HTTP/ spn, в том числе с винды. Лучше убедиться ещё раз, но это только завтра.

Если ты хочешь, чтобы убунта видела доменных пользователей, и их аутентифицировала, то придётся заводить её в домен (ну либо ldap-авторизацию самому сделать, но нафига?). Можно samba4+winbind, но по моему опыту, лучше всего работает realmd.

я чет в замешательстве: если мы сделали kinit ub, ввели пароль этого самого ub, все прошло нормально, через klist увидели tgt, то разве мы уже не зашли в домен? нужно еще что-то делать?

Просто под зашли в домен мы подразумеваем разные вещи. Если получения тикета тебе достаточно, то больше делать ничего не надо.

я вот так машины в домен ввожу
net ads join -U domainadmin -D TEST.LOCAL

хм, я сделал два разных действия: 1) в AD зарегистрировал пользователя ub, сделал для него keytab и можно, в принципе по ssh его перекинуть на убунты(но пока не делал)... из убунты сделал kinit ub - получил tgt такой:

Default Principal: ub@TEST.LOCAL

2)на убунте зашел из самбы: sudo net ads join -U admin

создал в убунте keytab файл: sudo net ads keytab create -U admin

добавил туда HTTP принципиалы: sudo net ads keytab add HTTP -U admin

посмотрел sudo klist -ek: много принципиалов и с HTTP и с HOST и именем пользователя убунты, но нет ни слова о ub... нормально ли это?

Если kvno HTTP/server.domain работает, то это не трюки AD, а просто значит, что такой SPN есть в AD, однозначно.
Команда setspn -Q HTTP/server.domain (с винды) покажет, в каком аккаунте этот SPN находится.

setspn -Q HTTP/m-lib.domain.local
Проверка домена DC=domain,DC=local

Такое SPN не найдено.

$ kvno HTTP/m-lib.domain.local
HTTP/m-lib.domain.local@DOMAIN.LOCAL: kvno = 12

SSO работает. ldapsearch по AD так же spn'а такого не находит.

Более того, у меня kvno по http/ работает для простых рабочих станций на винде.

Случайно встретил объяснение, и решил отписать.
Это действительно трюки AD, т.н. implicit или automatic SPN mapping. Там по умолчанию около полусотни SPN, которые мапятся в HOST/, если они явно не определены. Среди них HTTP и WWW. Посмотреть их полный список или поменять их можно в атрибуте sPNMappings в CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.