LINUX.ORG.RU
ФорумAdmin

Kerberos проблема настройки. Squid + AD.

 , , , ,


0

1

Доброго всем времени суток.

Инфо о системе: CentOS 6.7 x64 SQUID 3.5.11 AD Windows 2008

Сквид работает отлично. Авторизация NTLM. Но вот беда хром в 47ой версии рушит всё счастье.

Помогите настроить Kerberos авторизацию.

Думаю что моя ошибка где то на стороне Windows AD.

Получаю keytab файл:

ktpass -princ HTTP/sq.mydomain.name@MYDOMAIN.NAME -mapuser squid3 -pass Pa$$word123 -ptype KRB5_NT_PRINCIPAL -out C:\123\squid3.keytab

Вроде бы все верно. Милион статей с этой командой.

Возможно моя ошибка в неправильном файле krb5.conf


[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MYDOMAIN.NAME
 dns_lookup_realm = no
 dns_lookup_kdc = no
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 arcfour-rc4-md5 rc4-hmac des-cbc-crc des-cbc-md5
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 arcfour-rc4-md5 rc4-hmac des-cbc-crc des-cbc-md5
 permitted_enctypes = aes256-cts-hmac-sha1-96 arcfour-rc4-md5 rc4-hmac des-cbc-crc des-cbc-md5
 default_keytab_name = /etc/squid/squid3.keytab

[realms]
 MYDOMAIN.NAME = {
  kdc = ad1.mydomain.name
  kdc = ad2.mydomain.name
  admin_server = ad1.mydomain.name
  default_domain = mydomain.name
 }

[domain_realm]
 .mydomain.name = MYDOMAIN.NAME
 mydomain.name = MYDOMAIN.NAME

[appdefaults]
 pam = {
 debug = false
 ticket_lifetime = 36000
 renew_lifegime = 36000
 forwardable = true
 krb4_conver = false
}

Сомневаюсь только в enctypes параметрах. Перебирал разные варианты.

Проверяю работоспособность этой командой

kinit -V -k -t /etc/squid/squid3.keytab HTTP/sq.mydomain.name@MYDOMAIN.NAME

И вот моя ошибка:

kinit: Keytab contains no suitable keys for HTTP/sq.mydomain.name@MYDOMAIN.NAME while getting initial credentials

Пробовал получать keytab файл через msktutils. Время сихронизированно, resolv.conf правильный.

Может есть у более опытных товарищей какие либо идеи? Спасибо за любую помощь и участие в обсуждении.

Ответ на: комментарий от mcduck

kinit -V -k -p не выполнилось (справку вывело) kinit -V -k -t /etc/squid/squid3.keytab HTTP/sq.mydomain.name

Такая же ошибка.

kinit: Keytab contains no suitable keys for HTTP/sq.mydomain.name@MYDOMAIN.NAME while getting initial credentials

Free4ert
() автор топика
Ответ на: комментарий от mcduck

Есть только вот так получается должно быть:

kinit -V -k -p HTTP/sq.mydomain.name

Либо kinit -V -k -p HTTP/sq.mydomain.name -t /etc/squid/squid3.keytab

Да в этой статье я был.. Думаю что у меня какой то неправильный keytab файл...

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

Думаю что у меня какой то неправильный keytab файл...

Если есть такие подозрения то смотри что в файле:

ktutil -k /etc/squid/squid3.keytab list

menzoberronzan
()
Ответ на: комментарий от Free4ert

ktpass -princ HTTP/sq.mydomain.name@MYDOMAIN.NAME -mapuser squid3 -pass Pa$$word123 -ptype KRB5_NT_PRINCIPAL -out C:\123\squid3.keytab

ЕМНИП когда делаешь mapuser надо указывать имя пользователя с доменом

ktpass -princ HTTP/sq.mydomain.name@MYDOMAIN.NAME -mapuser squid3@mydomain.name -pass Pa$$word123 -ptype KRB5_NT_PRINCIPAL -out C:\123\squid3.keytab
Я бы в данном случае удалил пользователя squid3, пересоздал и заново сгенерировал keytab.

menzoberronzan
()
Ответ на: комментарий от menzoberronzan

Client Not Found in Kerberos database..

Теперь такое сообщение.

Но зато в файле ключей точно есть HTTP/sq.mydomain.name@MYDOMAIN.NAME.

Т.е. теперь нету такого пользователя в базе керберос..

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

kinit squid3 - выдает запрос пароля kinit HTTP/sq.mydomain.name - пишет нету такого пользователя. хотя это поидее ведь новый логин ..

Free4ert
() автор топика

В конфиг добавить «allow_weak_crypto = true»? Может, линуксовый кербер банально не хочет то, что хочет винда (des-cbc-crc или des-cbc-md5)? Винда часом не 2003?

viewizard ★★
()
Ответ на: комментарий от viewizard

windows 2008. Использую сейчас только rc4-hmac шифрование. Версия кербера - 1.10.3-42 новее нету на CentOS 6.7 в штатных репах.

Попробую добавить allow_weak_crypto = true.

У меня тоже подозрения на шифрование какое либо или же конфиг krb5.conf

Ведь просто kinit Admin - работает. Билет есть всё ок. По файлу не пускает только.

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

Нюанс в том, что без allow_weak_crypto, использование des-cbc-crc и des-cbc-md5 отключили и в mit, и в heimdal. Точнее, заблокировали их использование по умолчанию этим самым allow_weak_crypto. Если пишешь одно - пиши обязательно и другое.

viewizard ★★
()
Ответ на: комментарий от viewizard

Да это я понял. Но эти операции не помогли.

Если выполнить kinit Admin Авторизоваться по паролю. Дальше Kerberos авторизация будет работать в сквиде.

Единственный камень предкновения этот keytab файл.

Напишу что я делал для его получения. Мб что не так:

Создал DNS записи на linux сервер и обратные DNS записи Синхронизировал время на linux с AD Создал учетную запись в домене Windows 2008 squid3 Поставил её не истекаемый пароль

Получил keytab файл следующей компандой:

ktpass -princ HTTP/sq.mydomain.name@MYDOMAIN.NAME -mapuser squid3@MYDOMAIN.NAME -pass Pa$$word -ptype KRB_NT_PRINCIPAL -crypto ALL -out c:\123\squid3.keytab

(Пытался сделать через учетную запись ПК sq$@MYDOMAIN.NAME) (Пытался сделать через msktutils) (Пытался сделать через samba , net ads )

Получаю два типа ошибок. 1. Client Not Found in Kerberos database.. (не найден пользователь) 2. Keytab contains no suitable keys (не найдена пара ключей в файле)

Вот еще мой конфиг файл krb5.conf

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MYDOMAIN.NAME
 dns_lookup_realm = no
 dns_lookup_kdc = no
 ticket_lifetime = 24h
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
 default_keytab_name = /etc/squid/squid3.keytab
 allow_weak_crypto = true

[realms]
 MYDOMAIN.NAME = {
  kdc = ad1.mydomain.name
  kdc = ad2.mydomain.name
  admin_server = ad1.mydomain.name
  #admin_server = ad2.mydomain.name
  default_domain = mydomain.name
 }

[domain_realm]
 .mydomain.name = MYDOMAIN.NAME
 mydomain.name = MYDOMAIN.NAME

[appdefaults]
 pam = {
 debug = false
 ticket_lifetime = 36000
 renew_lifegime = 36000
 forwardable = true
 krb4_conver = false
}

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

net ads kerberos renew - может обновить тот самый klist net ads kerberos kinit - через пароль авторизоваться можно..

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

А «klist -ek /etc/squid/squid3.keytab» что выдает? Я просто понять не могу, почему он не находит, почему «Keytab contains no suitable keys...». Небольшое уточнение, у вас 2008 или 2008r2? 2008r2 и выше нужны AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96 и RC4-HMAC (там как раз DES-CBC-MD5 и DES-CBC-CRC заблокировали по дефолту). AES128-CTS-HMAC-SHA1-96 - вот этого не вижу в конфиге, попробуйте добавить и сгенерировать по новой.

viewizard ★★
()
Ответ на: комментарий от viewizard

Вообщем разобрался я в итоге утром )) Дело было в том что я двумя дорогами шел к одной цели. А как известно за двумя зайцами гонятся бесполезное занятие.

В итоге. Я удалил всех пользователей на которых делал мапинг keytab через ktpass. Проверил командой на AD: stspn -Q HTTP/sq.mydomain.name , что данный принципиал никуда не привязан.

Переввел samba в домен еще раз. Создал keytab файл через samba, предварительно я авторизовался в домене через kinit admin, получив билет, это избавило от ввода пароля позднее, если этого не сделать надо везде писать -U admin

net ads keytab flush - очистить кейтаб
net ads keytab create - создать кейтаб
net ads keytab add HTTP - добавим принципал HTTP для прокси или веб сервера
net ads keytab list - посмотрим что получилось

kdestroy - очистим все прошлые попытки логона. kinit -V -k -t /etc/krb5.keytab HTTP/sq.mydomain.name@MYDOMAIN.NAME Проверим что возможно войти по kytab файлу.

Дальше уже можно возвращаться в манулалы по сквиду.

Free4ert
() автор топика
Ответ на: комментарий от Free4ert

Только проблему хрома это всё равно не решило. Обещали сделать обновление в следущей версии.. Придется значит пока что без хрома.

Free4ert
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.