В этой части мы рассмотрим порядок настройки Ubuntu Server 14.04 LTS для обеспечения возможности работы с механизмами аутентификации пользователей прокси-сервера Squid 3 по протоколам Kerberos и NTLM в среде домена Active Directory (AD). Для поддержки NTLM наш Linux-сервер будет присоединён к домену AD, а для поддержки Kerberos для сервера в домене будет создана специальная служебная учетная запись пользователя. В дальнейшем при конфигурации Squid, протокол Kerberos будет использоваться как приоритетный, а протокол NTLM будет применяться в случаях когда клиент прокси-сервера по какой-то причине не может использовать Kerberos.
Добавляем поддержку Kerberos
Сначала проверим список установленных пакетов
dpkg-query --list | grep krb
krb5-locales 1.12+dfsg-2ubuntu4 all Internationalization support for MIT Kerberos libgssapi-krb5-2:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries krb5 GSS-API Mechanism libkrb5-26-heimdal:amd64 1.6~git20131207+dfsg-1ubuntu1 amd64 Heimdal Kerberos - libraries libkrb5-3:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries libkrb5support0:amd64 1.12+dfsg-2ubuntu4 amd64 MIT Kerberos runtime libraries - Support library
Можно встретить упоминания о том что нужно установить пакеты krb5-user и libkrb53. Однако в нашем случае установка пакета libkrb53 будет безуспешна и, как я понял, в системе уже присутствует заменяющий пакет libkrb5-3, поэтому мы выполним установку только пакета krb5-user
sudo apt-get install krb5-user
Сохраним на всякий случай появившийся в системе после установки пакета krb5-user конфигурационный файл krb5.conf в krb5.conf.default и откроем исходный файл в текстовом редакторе (с подсветкой синтаксиса):
sudo cp /etc/krb5.conf /etc/krb5.conf.default sudo nano -Y sh /etc/krb5.conf
Очистим содержимое файла (или закомментируем все открытые строки) и впишем туда следующие строки:
[libdefaults]
default_realm = HOLDING.COM
dns_lookup_kdc = no
dns_lookup_realm = no
ticket_lifetime = 24h
default_keytab_name = /etc/squid3/PROXY.keytab
# for Windows 2003
# default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
# default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
# permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
# for Windows 2008 with AES
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
[realms]
HOLDING.COM = {
kdc = kom-ad01-dc01.holding.com
kdc = kom-ad01-dc02.holding.com
admin_server = kom-ad01-dc01.holding.com
default_domain = holding.com
}
[domain_realm]
.holding.com = HOLDING.COM
holding.com = HOLDING.COM
Настраиваем Kerberos
В интернете можно найти разные описания настройки Kerberos на Linux, где зачастую предполагается использование утилиты MSKTUTIL для создания в домене отдельной учетной записи компьютера, которая будет использоваться для аутентификации пользователей домена, а также для периодического изменения пароля этой учетной записи и регенерации keytab файла. В нашем описании мы пойдём по несколько иному пути, чтобы немного упростить схему получения и использования keytab-файла. Далее мы создадим в домене AD служебную учетную запись пользователя, отключим в свойствах учетной записи устаревание пароля и необходимость смены пароля, сгенерируем на контроллере домена для этой учетной записи keytab-файл, который затем скопируем на наш прокси сервер и будем использовать его для аутентификации Kerberos на постоянной основе.
Создаем в домене учетную запись пользователя для службы SQUID. В нашем примере это будет учетная запись KOM\s-KOM-SquidKerb
Отключим для учетной записи требование периодической смены пароля (Password never expires):
Для созданной учетной записи нам нужно сгенерировать keytab-файл на контроллере домена AD (в нашем случае на базе Windows Server 2012 R2) с помощью утилиты ktpass
ktpass -princ HTTP/kom-ad01-squid.holding.com@HOLDING.COM -mapuser KOM\s-KOM-SquidKerb -pass PasSw0rd -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\Temp\PROXY.keytab
Targeting domain controller: KOM-AD01-DC01.holding.com Successfully mapped HTTP/kom-ad01-squid.holding.com to s-KOM-SquidKerb. Password successfully set! Key created. Key created. Key created. Key created. Key created. Output keytab to C:\Temp\PROXY.keytab: Keytab version: 0x502 keysize 83 HTTP/kom-ad01-squid.holding.com@HOLDING.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x...) keysize 83 HTTP/kom-ad01-squid.holding.com@HOLDING.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x...) keysize 91 HTTP/kom-ad01-squid.holding.com@HOLDING.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x....) keysize 107 HTTP/kom-ad01-squid.holding.com@HOLDING.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0x.......) keysize 91 HTTP/kom-ad01-squid.holding.com@HOLDING.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x.....)
Обратите внимание на то, что в параметре –princ в большинстве случаев нужно указывать имя сервера (HOSTNAME), для которого мы собираемся настроить аутентификацию Kerberos (в нашем случае это KOM-AD01-GW10.holding.com) используя выше-обозначенную учетную запись пользователя. Однако вместо этого, я намеренно использую другое имя KOM-AD01-SQUID.holding.com, так как в перспективе есть задача использовать служебную учетную запись пользователя сразу для нескольких серверов SQUID с единой точкой входа для пользователей. Разумеется для имени KOM-AD01-SQUID.holding.com в DNS уже создана статическая A-запись (PTR-запись не создавалась) и эта запись на данный момент указывает на IP-адрес нашего Linux-сервера (10.160.0.0.2).
В процессе генерации keytab-файла в домене в свойствах учетной записи пользователя изменится имя для входа а также будет изменён атрибут servicePrincipalName (будет добавлено значение из параметра -princ)
Теперь нам нужно безопасным способом передать получившийся файл PROXY.keytab с компьютера под управлением Windows на Linux-сервер KOM-AD01-GW10 в каталог /etc/squid3/. Сделать это можно например по протоколу SSH (ранее мы уже запустили службу сервера OpenSSH на KOM-AD01-GW10) с помощью утилиты WinSCP или PSCP.
Передадим файл сначала в каталог /home/user/ (или ~ для краткости):
C:\Tools\PuTTy>pscp -scp C:\Temp\PROXY.keytab user@KOM-AD01-GW10:~/PROXY.keytab
Теперь из каталога /home/user/ нам нужно будет переместить файл в в каталог /etc/squid3/
sudo mv /home/user/PROXY.keytab /etc/squid3/PROXY.keytab
Далее выставляем разрешения на keytab-файл таким образом, чтобы в дальнейшем служба Squid могла получить к нему доступ:
sudo chgrp proxy /etc/squid3/PROXY.keytab sudo chmod 640 /etc/squid3/PROXY.keytab
ls -la /etc/squid3/PROXY.keytab
-rw-r----- 1 user proxy 477 May 31 20:45 /etc/squid3/PROXY.keytab
***
Проверяем возможность аутентификации в AD с помощью Kerberos. Сначала выполняем команду, которая должна отработать без ошибок:
kinit -k HTTP/kom-ad01-squid.holding.com
Затем проверим наличие полученного билета Kerberos командой klist
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/kom-ad01-squid.holding.com@HOLDING.COM
Valid starting Expires Service principal
05/31/2014 21:22:14 06/01/2014 07:22:14 krbtgt/HOLDING.COM@HOLDING.COM
renew until 06/01/2014 21:22:14
Как видим, билет успешно получен. Теперь можем удалить его командой kdestroy
***
Для того чтобы SQUID однозначно знал где искать keytab-файл, создадим файл настроек по умолчанию и откроем его на редактирование:
sudo touch /etc/default/squid3 sudo nano /etc/default/squid3
Впишем в файл следующие сроки:
KRB5_KTNAME=/etc/squid3/PROXY.keytab export KRB5_KTNAME
На этом базовую поддержку Kerberos в рамках нашей задачи можно считать законченной, переходим к NTLM.
Настраиваем поддержку NTLM
Устанавливаем пакеты Samba и Winbind, которые потребуются нам для того, чтобы сделать наш Linux-сервер членом домена AD и задействовать механизмы NTLM-аутентификации:
sudo apt-get install samba winbind samba-common-bin
Останавливаем только что установленные и запущенные службы:
sudo invoke-rc.d winbind stop sudo invoke-rc.d samba stop
Как таковая, файловая служба samba в нашем случае на Linux-сервере не нужна, поэтому отключим её автозапуск (по сути нам нужна только служба winbind, т.к. она отвечает за резолвинг юзеров и групп и авторизацию в домене)
sudo update-rc.d -f samba remove Removing any system startup links for /etc/init.d/samba ...
Сохраняем на всякий случай исходный конфигурационный файл Samba, после чего открываем его на редактирование:
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.default sudo nano -Y sh /etc/samba/smb.conf
Новое содержимое файла:
[global] netbios name = KOM-AD01-GW10 workgroup = KOM security = ADS realm = HOLDING.COM encrypt passwords = yes interfaces = 10.0.0.0/8 bind interfaces only = yes winbind nss info = rfc2307 winbind use default domain = yes winbind enum users = yes winbind enum groups = yes idmap config *:backend = tdb idmap config *:range = 10000-80000 idmap config KOM:backend = rid idmap config KOM:range = 10000-80000 # log level = 9
Проверяем утилитой testparm. Утилита должна распарсить конфигурационный файл без явных ошибок
testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
[global]
workgroup = KOM
realm = HOLDING.COM
interfaces = 10.0.0.0/8
bind interfaces only = Yes
security = ADS
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nss info = rfc2307
idmap config KOM:range = 10000-80000
idmap config KOM:backend = rid
idmap config *:range = 10000-80000
idmap config * : backend = tdb
Чтобы увидеть содержимое текущего конфигурационного файла smb.conf и все параметры Samba по умолчанию применяемые вместе с этим файлом можно выполнить:
testparm -v
***
Создаём в домене учетную запись компьютера для нашего Linux-сервера в том OU, где нам удобно. Эта учетная запись будет использована для ввода сервера в домен AD. После этого выполняем команду ввода сервера в домен:
sudo net ads join -U DomainAdmin osName='Ubuntu Server GNU/Linux' osVer='14.04 LTS'
Вводим пароль доменного пользователя с правами на присоединение к домену (как правило это администратор домена, хотя может быть и другой непривилегированный в домене пользователь)
Enter DomainAdmin's password: Using short domain name -- KOM Joined 'KOM-AD01-GW10' to dns domain 'holding.com'
***
Проверяем запуск службы winbind (должно отработать без ошибок)
sudo invoke-rc.d winbind start
Теперь нужно перезагрузить сервер и убедиться в том, что службы запустились автоматически. При перезапуске я обнаружил запись в /var/log/boot.log:
* Starting SMB/CIFS File and Active Directory Server [fail]
Как я понял, это проблема запуска Samba как ADS-сервера, которая в нашем случае не нужна. Поэтому я отключил выполнение соответствующего конфига в /etc/init/, создав файл переопределений, который объясняет системе Upstart, что данная служба может запускаться только вручную по мере необходимости.
echo 'manual' | sudo tee /etc/init/samba-ad-dc.override
Проверяем статус доверительных отношений с доменом:
sudo wbinfo -t checking the trust secret for domain KOM via RPC calls succeeded
Проверяем аутентификацию пользователя в домене:
sudo wbinfo -a KOM\\artur Enter KOM\artur's password: plaintext password authentication succeeded Enter KOM\artur's password: challenge/response password authentication succeeded
Включим пользователя от имени которого будет работать Squid (proxy) в группу доступа для чтения каталога /var/run/samba/winbindd_privileged
sudo gpasswd -a proxy winbindd_priv Adding user proxy to group winbindd_priv
Забегая вперёд могу сказать, что проделанной настройки Samba4 оказалось недостаточно. Когда дело дошло до тестирования хелперов Squid, хелпер NTLM аутентификации из состава Samba4 (/usr/bin/ntlm_auth) при вызове Squid-ом для любой попытки аутентификации пользователей приводил к одной и той же ошибке:
ERROR: NTLM Authentication validating user. Error returned 'BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL'
Идея решения этой проблемы была найдена здесь [Bug 1304953] Re: ntlm_auth reports Broken Helper: BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL. Как я понял, суть проблемы заключается в том, что Squid версии 3.3.8 при работе с хелпером NTLM аутентификации пытается использовать содержимое каталога /var/run/samba/winbindd_privileged, в то время как в Samba4 его месторасположение изменено на /var/lib/samba/winbindd_privileged. Оказалось, что в системе присутствуют оба каталога:
sudo ls -la /var/run/samba/winbindd_privileged total 0 drwxr-x--- 2 root winbindd_priv 40 Jun 6 18:38 . drwxr-xr-x 7 root root 460 Jun 6 18:38 ..
sudo ls -la /var/lib/samba/winbindd_privileged total 8 drwxr-x--- 2 root root 4096 Jun 6 18:38 . drwxr-xr-x 6 root root 4096 Jun 6 18:38 .. srwxrwxrwx 1 root root 0 Jun 6 18:38 pipe
Для решения проблемы неработающей NTLM аутентификации в Squid пришлось настроить разрешения на каталог /var/lib/samba/winbindd_privileged аналогично тому, как они настроены для каталога /var/run/samba/winbindd_privileged…
sudo chgrp winbindd_priv /var/lib/samba/winbindd_privileged sudo ls -la /var/lib/samba/winbindd_privileged total 8 drwxr-x--- 2 root winbindd_priv 4096 Jun 6 18:38 . drwxr-xr-x 6 root root 4096 Jun 6 18:38 .. srwxrwxrwx 1 root root 0 Jun 6 18:38 pipe
…а также слинковать подкаталог ../pipe из старого месторасположения в новое…
sudo ln -s /var/lib/samba/winbindd_privileged/pipe /var/run/samba/winbindd_privileged/pipe sudo ls -la /var/run/samba/winbindd_privileged total 0 drwxr-x--- 2 root winbindd_priv 60 Jun 6 18:41 . drwxr-xr-x 7 root root 460 Jun 6 18:38 .. lrwxrwxrwx 1 root root 39 Jun 6 18:41 pipe -> /var/lib/samba/winbindd_privileged/pipe
После этих изменений можно перезапустить сервер чтобы “взбодрить” Squid3 и Samba4.
***
Теперь относительно того, что для учетной записи компьютера (не путать с сервисной учетной записью пользователя для поддержки Kerberos) нашего Linux-сервера в домене AD рекомендуется выполнять периодическую смену пароля. Судя по документу Samba manpages - smb.conf.5 параметр machine password timeout отвечает за то, насколько часто процесс smbd будет пытаться выполнить смену пароля учетной записи компьютера в домене. По умолчанию это значение равно 604800 секунд, то есть 7 дней. Таким образом добавлять в планировщик заданий CRON в крон отдельную задачу смены пароля командой “net rpc changetrustpw” мы не станем.
***
На этом минимальную настройку поддержки Kerberos и NTLM в Ubuntu Server 14.04 LTS для использования механизмов аутентификации пользователей домена Active Directory в Squid 3 будем считать законченной. В следующей части рассмотрим базовую настройку самого прокси-сервера Squid.
Дополнительные источники информации:
Samba WIKI - Setup a Samba AD Member Server
Squid-Cache WIKI - Complete FAQ
Bitbinary WIKI - Active Directory Integrated Squid Proxy
RSU WIKI - Настройка proxy-сервера
***
Предыдущие части цикла заметок:
Часть 1. Установка ОС на ВМ Hyper-V Gen2
Часть 2. Настройка диска для кэша Squid
Часть 3. Конфигурация DNS , NTP и установка Squid
Следующие части цикла заметок:
Часть 5. Конфигурация Squid 3
Часть 6. Настройка Proxy Auto Configuration (WPAD)
Часть 7. Кастомизация страниц ошибок
Часть 8. Конфигурация SqStat
Часть 9. Конфигурация LightSquid
Часть 10. Отключаем IPv6
RSS - Записи
Спасибо за проделанную работу! Ждем продолжения))
Привет! Подскажите как побороть ошибку при вводе в домен "Failed to join domain: Failed to set password for machine account (NT_STATUS_WRONG_PASSWORD)"
Если всё делали по описанной конфигурации, то теоретически проблема может быть на стороне AD. Возможно учетная запись компьютера с таким именем уже существует и недоступна вам для изменения по правам. Возможно учетная запись для компьютера есть, но выключена. Как минимум нужно попробовать пересоздать учетную запись.
Все сделано по описанной конфигурации билетик получаю. Создаю учетную запись в AD, после в ubuntu даю команду на ввод в домен. Получаю ошибку выше описанную и учетная запись компьютера исчезает из AD.
Если Вы действительно всё делали по порядку в такой же последовательности, как описано в заметках цикла начиная с первой части, то эта проблема не должна воспроизводится, так как описанную последовательность действий я проверял не один раз.
В таком случае проблема может заключаться вне Lunix-системы. Как минимум можно попробовать включить расширенное логирование (log level = 9) в smb.conf, смотреть логи на контроллере домена, и т.п..Также нужно обратить внимание на то, какой уровень домена используется (в описанном примере контроллеры домена функционируют на Windows Server 2012 R2). Если у вас DC на Windows Server 2003, то потребуется корректировка параметров *_enctypes в файле krb5.conf в соответствии с поддерживаемыми типами ключей в результирующем keytab-файле.
Добрый день! Пытаюсь проделать всё что вы изложили приминимо к Samba4 AD level 2003 win server, squid3 ставлю на Ubuntu server 13.10. На данном этапе не получается авторизоваться по кейтаб файлу... Сам файл создаётся следующей последовательностью:
samba-tool user create squidauth
samba-tool spn add HTTP/proxysrv.domain.lo squidauth
samba-tool domain exportkeytab PROXY.keytab --principal=HTTP/proxysrv.domain.lo Все команды отрабатывают нормально, далее этот файл кидаю на прокси сервер /etc/squid3/PROXY.keytab, изменяю права на файл как описано в статье но при попытке авторизоваться
kinit -k proxysrv.domain.lo пишет что клиент не найден БД Кербероса... Есть мысли? Спасибо за ранее )
Не могу комментировать работу samba-tool, так как не работал с этим инструментом. Где-то читал про проблемы связанные с samba-tool, поэтому решил с ним не заморачиваться. А из того, что Вы написали, первое что бросается в глаза, это то, что kinit надо выполнять используя не имя сервера и имя принципала, как оно было указано при генерации keytab-файла. В статье явно приведён пример. В Вашем случае команда будет такой: kinit -k HTTP/proxysrv.domain.lo
Благодарю за ответ. Я уже как только не пробовал kinit прописывать и так как вы написали тоже пробовал, что-то пока не получается... Думаю может там с алгоритмами шифрования несросты какие. Хотя и на клиенте и на сервере прописал
default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
в общем будем дальше гуглить )) Ведь должно быть решение...)
Обратная ссылка: Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS | Блог IT-KB /
Приветствую. Подскажите пожалуйста. Все делаю по порядку. но споткнулся таки. При запуске команды kinit -k HTTP/ServerProxy.iro.local получаю вот такое сообщение kinit: Keytab contains no suitable keys for HTTP/ServerProxy.iro.local@IRO.LOCAL while getting initial credentials. Проверил все еще раз, ошибок нет =(
Возможно есть расхождения между тем какое шифрование ключей внутри keytab-а и поддерживаемыми методами шифрования перечисленными в krb5.conf. Эти данные должны быть сопоставимы.
Не успел) Ошибка заключалась в команде генерации keytab файла. ktpass -princ HTTP/ServerProxy.iro.local@iro.local -mapuser IRO\ и т.д. и т.п.
После @ домен прописал не верно, нужно было большими буквами) Сгенерировал по новой и получил билет Kerberos. Спасибо, двигаемся дальше...
Нашел ошибку =) Можете не отвечать)
Вот маленький совет для тех у кого будет выдавать ошибку при введении в домен (но возможно это только у меня было )
No DNS domain configured for proxy. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER
Я прописал подкорректировал запись в файле /etc/hosts :
nano /etc/hosts
127.0.0.1 localhost
127.0.1.1 proxy.koa.court.local proxy
когда запускаю команду kinit выдает ошибку, почему то чекает не тот каталог который нужен, как это поправить? kinit: Key table file '/etc/squid/PROXY.keytab' not found while getting initial credentials
спасибо) сам нашел ошибку)))
очевидно я что-то не догоняю. у меня на windows server 2003, пишет что якобы ktpass не опознана(( подскажите что делать как решать?
Недостаточно информации. Телепаты и астрологи - на летних каникулах.
в Общем проблема следующего характера, у меня АД вертиться на windows server 2003, когща я пытаюсь сгенерить keytab файл через командную строку мне выдается ошибка 'kinit' is not recognized as an internal or external command,
operable program or batch file. как это можно исправить? я полазил по форумам, там вроде как говорят что нужен диск установочный и так далее. к сожалению нет возможности это сделать. как то можно по другому пути сгенерить этот файл?
точнее вот эта ошибка, перепутал
'ktpass' is not recognized as an internal or external command,
operable program or batch file.
Для Windows Server 2003 утилита ktpass входит в состав набора утилит Support Tools.
Этот набор без проблем можно загрузить с сайта Microsoft.
Ищите ссылки по названию "Windows Server 2003 Support Tools" в зависимости от версии вашей ОС и уровня обновлений Service Pack.
Например для Windows Server 2003 Service Pack 2 32-bit ссылка на загрузку будет такой:
http://www.microsoft.com/en-us/download/details.aspx?id=15326
Алексей мне снова нужна Ваша помощь. я сгенерил keytab файл. единственное в windows server 2003 ргумент /crypto ALL он не понимает, поэтому пришлось выбирать какой-то один, выбрал RC4-HMAC файл сгенерился нормально вот:
Targeting domain controller: nvs-exch.nvs.mbrd.ru
Using legacy password setting method
Successfully mapped HTTP/nvs-exch2.nvs.mbrd.ru to squidlinux.
Key created.
Output keytab to c:\PROXY.keytab:
Keytab version: 0x502
keysize 73 HTTP/nvs-exch2.nvs.mbrd.ru@NVS.MBRD.RU ptype 1 (KRB5_NT_PRINCIPAL) vn
o 48 etype 0x17 (RC4-HMAC) keylength 16 (0xbc007082d32777855e253fd4defe70ee)
Далее делаю по инструкции выставляю разрешения и пишу в консоли:
kinit -k HTTP/nvs-exch2.nvs.mbrd.ru
на что мне выдает ошибку:
kinit: Keytab contains no suitable keys for HTTP/nvs-exch2.nvs.mbrd.ru@nvs.mbrd.ru while getting initial credentials
в файле krb5.conf у меня прописано
default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
Странно, то что здесь нет такого механизма шифрования..http://technet.microsoft.com/en-us/library/cc776746(v=ws.10).aspx. Вижу только DES-CBC-CRC и DES-CBC-MD5. Попробуйте вообще без этого ключа или если не пойдёт указать дефолтное значение DES-CBC-CRC.
Если смотреть по хелперу в командной строке, то он предлагает 3 ключа шифрования, я пробовал их все. он нормально генерит keytab`ы, если делать без этого значения, то выпадает в ошибку. может я где ошибся ранее, сегодня попробую с самого начала еще раз по мануалу сделать еще раз. О результатах напишу. Спасибо.
Можно попробовать сгенерировать кейтаб-файл на Ubuntu с помощью утилиты ktutil, например как описано здесь http://www.itadmintools.com/2011/07/creating-kerberos-keytab-files.html. Но такой способ я сам не проверял.
Алексей спасибо за советы, не знаю в чем проблема была, да и не стал разбираться. просто переделал всю работу с нуля повнимательней и все получилось, билет я получил. где-то просто не внимательно прошелся по мануалу. Буду дальше собирать.
Алексей у меня получилось, настроил. Проходит авторизация, пускает на сайты, но сайты открывает криво(наполовину) картинки вообще не грузит. что может быть не подскажете? и и на сайте яндекса пишет Дата на вашем компьютере %local_date не совпадает с текущей %current_date. хотя дату я сверял и там, и там стоит одинаковая!
генерирую ключ командой:
ktpass -princ HTTP/proxy5.frunze.local@FRUNZE.LOCAL -mapuser FRUNZE\SquidKerb --pass ******** -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\Temp\PROXY.keytab
подкидываю, запускаю
kinit -k HTTP/proxy5.frunze.local
выводится ошибка:
kinit: Keytab contains no suitable keys for HTTP/proxy5.frunze.local@frunze.local while getting initial credentials
но если делаю:
kinit -k HTTP/proxy5.frunze.local@FRUNZE.LOCAL
то команда проходит без ошибок и генерируется билет
это может помешать дальнейшей работе? и в чем может быть проблема?
Если в дальнейшем настройку хелперов использующих Kerberos, таких как negotiate_wrapper_auth, будете выполнять по аналогии с примером приведённым в следующей части (-s HTTP/kom-ad01-squid.holding.com@HOLDING.COM), то проблем возникнуть не должно.
Алексей, подскажи где можно прочитать про negotiate_wrapper_auth, зачем он нужен и что делает?
Про него в трёх словах я написал в 5 части цикла заметок. А вообще про согласование можно почитать например здесь
Большое спасибо за такие подробные статьи!
Объясните, пожалуйста, почему вы не используете в качестве имени просто s-KOM-SquidKerb, а добавляете KOM\ перед ним? Это для вашего удобства или имеет принципиальное значение? Также с HTTP/ перед kom-ad01-squid.holding.com@HOLDING.COM тоже не очень понятно.
Заранее прошу прощения, если мои вопросы глупые, я в администрировании Windows мало что понимаю, вот пытаюсь разобраться, т.к. просто копипастить не хочется.
Честно говоря не понял ни одного вопроса. Использование "KOM" где именно смущает? Это NetBIOS имя домена и в том, что оно используется, например, в команде ktpass нет ничего особенного. "HTTP/" где именно смущает? Это формат записи SPN (атрибут servicePrincipalName) в домене Active Directory.
Просто сразу не понял почему KOM, а не HOLDING. Обычно NetBIOS имя отличается только отсутствием окончания (.COM например) и это меня смутило.
Также не знал что такое SPN. Спасибо, теперь всё понятно.
На самом деле NetBIOS-имя домена может отличаться от первой части FQDN. В моих примерах рассмотрен как раз такой случай. А в типичной ситуации, да, так и есть, - для FQDN "holding.com", как правило, используется NetBIOS-имя "HOLDING"
Алексей, подскажите пожалуйста, если в сети существуют пользователи двух доменов и перевести всех на один не представляется возможным, то как настроить squid, чтобы и те и другие могли выходить в интернет?
Не подскажу, не имел такого опыта. Но думаю информацию о настройке Squid/Samba/Kerberos для домена с которым установлены доверительные отношения в Интернете найти можно.
Огромное спасибо, доступно, понятно, премного благодарен!
ktpass -princ HTTP/proxy.th.local@TH.LOCAL -mapuser TH\s-KOM-SquidKerb —pass 123 -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\Temp\PROXY.keytab
Делаю такую запись.
Выдает
DsCrackNames returned 0x2 in the name entry for s-KOM-SquidKerb.
ktpass:failed getting target domain for specified user.
В чем беда?
Пишите в форум.
Хотел спросит, а почему в статье Вы создаете учетную запись пользователя, не безопастнее ли создать учетку компьютера ?
Не вижу в чём именно "не безопаснее" такой вариант. В случае использования учетных записей компьютеров будет невозможно использовать общее имя входа для нескольких серверов Squid при условии использования Kerberos. Для этого специально и создаётся сервисная учетная. Об этом в заметке написано.
ну касательно общей точки входа Вы правы про это я как-то не подумал.
Следует добавить в статью небольшое замечание:
"Внимание! Пользователь должен находится в контейнере Users. Иначе будут проблемы при выполнении ktpass."
Иначе будет такая ошибка:
C:\Windows\system32>ktpass -princ HTTP/centi.mlvz.local@MLVZ.LOCAL -mapuser MLVZ\squid -pass PaZc2#s5# -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\Temp\PROXY.keytab
Targeting domain controller: mega.MLVZ.LOCAL
Successfully mapped HTTP/centi.mlvz.local to squid.
Password set failed! 0x00000020
Aborted.
Пользователь squid у меня находился в AD в группе с русским названием.
Взято отсюда http://kaktusenok.blogspot.ru/2012/08/centos-58-squid-31-kerberos-windows.html
У меня пользователь KOMs-KOM-SquidKerb не в контейнере Users и никаких проблем с ktpass не было.
На RHEL7 (CentOS7)
NTLM authentication WILL FAIL if you have “cache_effective_group squid” set, if you do then remove it! As this overrides the effective group and squid then isn’t seen as part of the ‘wbpriv’ group which breaks authentication!
На более ранних версиях группа использовалась squid, и поэтому не получалось аунтифицироваться по NTLM.
Очень благодарен автору за статью, особенно понравилось с разбиением на группы.
Подскажите вот что, настроил squid с авторизацией пользователей через ad (kerberos) но возник вопрос, когда пользователь переходит по http ссылке в логах squid видно что это за пользователь, но если переходит по https то имени не видно, скажите как это исправить можно. Спасибо
Подскажите в конфиге самбы "workgroup = KOM" можно заменить на свою рабочую группу? А то с такой записью получаю ошибку:
Failed to join domain: Invalid configuration ("workgroup" set to 'KOM', should be 'MYDOMEN') and configuration modification was not requested
И если поставить свою группу то в этих строчках тоже поменять:?
idmap config KOM:backend = rid
idmap config KOM:range = 10000-80000
"КОМ" в моём примере это NetBIOS-имя домена. Разумеется Вам нужно указывать имя своего домена.
Добрый день.
Помогите пожалуйста((((
Уже который день мучаюсь, не могу создать keytab файл,
ввожу команду:
ktpass -princ HTTP/testproxe.domen.local.com@DOMEN.LOCAL.COM -mapuser LOCAL\adminproxy -pass 12345
-crypto ALL -ptype KRB5_NT_PRINCIPAL -out C:\PROXY.keytab
Что не так?????((((((
Проверьте, консоль должна быть запущена от имени Администратора, так же неплохо было бы посмотреть ошибку которую возвращает введенная Вами команда.
Блин про админа не подумал))))
Завтра с утра попробую. Спасибо за ответ.
"Михаил / 11.08.2014 15:15
Алексей у меня получилось, настроил. Проходит авторизация, пускает на сайты, но сайты открывает криво(наполовину) картинки вообще не грузит. что может быть не подскажете? и и на сайте яндекса пишет Дата на вашем компьютере %local_date не совпадает с текущей %current_date. хотя дату я сверял и там, и там стоит одинаковая!"
аналогичная ситуация у меня. подскажите куда копать
спасибо
Не знаю в чём дело. Попробуйте сопоставить дату и время на клиентском компьютере и на прокси. По логике вещей, если бы на прокси были проблемы с датой/временем, то Kerberos аутентификация попросту не работала бы.
У меня почему-то после перезагрузки сервера слетает линковка
sudo ln -s /var/lib/samba/winbindd_privileged/pipe /var/run/samba/winbindd_privileged/pipe
Добрый день.
Алексей, подскажите ответ на такой вопрос. - keytab создавался средствами samba net ads, аутентификация проходит, но лишь при отсутствующей записи fqdn в DNS (т.е. в рамках одной подсети). При добавлении записи FQDN в DNS аутентификация kerberos не происходит. В cache.log же появляется это:
ERROR: Negotiate Authentication validating user. Error returned 'BH received type 1 NTLM token'
... соответственно аутентификация NTLM проходит нормально.
По статье всё проходило хорошо но вот в домен не могу загнать. Failed to join domain: Invalid configuration ("workgroup" set to 'DC01', should be 'HOLDING') and configuration modification was not requested не знаю уже где копать.
Мало информации. Могу только предположить, что у Вас ошибки в smb.conf
После перезагрузки системы, линковка:
[b]lrwxrwxrwx 1 root root 39 Jun 6 18:41 pipe -> /var/lib/samba/winbindd_privileged/pipe[/b]
исчезает. Каким образом ее сделать постоянной?
Действительно слетает. Но как видно всё работает и без неё.
Алексей, подскажите, а можно убрать NTLM, оставив только Kerberos и сделать fallback для LDAP? Задача не использовать Samba вообще и не вводить комп в домен.
Не пробовал такую конфигурацию. А членство в группах доменных как вы будете проверять без самбы?
Группы проверять через ext_kerberos_ldap_group_acl, и в вашем варианте, группы же тоже не через NTLM проверяются, а через LDAP.
У меня так работает с такой конфигурацией squid3 (на примере конфигурации из части 5):
# Negotiate Kerberos and NTLM authentication
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -r -s HTTP/kom-ad01-squid.holding.com@HOLDING.COM
auth_param negotiate children 200 startup=50 idle=10
auth_param negotiate keep_alive off
Вопрос к вам, negotiate_kerberos_auth_test должен отдавать ответы с теми же ключами и параметрами что и negotiate_kerberos_auth или у него другой синтаксис?
У меня выдает вот такую ошибку: "negotiate_kerberos_auth_test: gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. SPNEGO cannot find mechanisms to negotiate", хотя по методу инструкции Алексея kerberos работает.
Да работает, у меня squid не введен в домен, авторизация через kerberos + basic авторизация через ldap. + rejik настроен и управлять им можно через группы в AD.
Сергей, не поделитесь конфигами?
Да там как бы и конфигов нет, в AD создаются группы согласно группам rejik -a в них добавляется пользователь которому разрешено посещать сайты той или иной группы. На сервера perl скрипт через n времени проверяет группы и сливать их участников в отдельные файлы, а в режике указывается через allow_id какому пользователю можно посещать данную группу. Единственное ограничение должна быть именно авторизаци или basic или kerberos или ntlm, что бы rejik видел в локах имя пользователя.
В общем, со всем разобрался. Сделал Kerberos+LDAP, без использования Samba и NTLM. Единственное, что в Windows, надо выключать "встроенную авторизацию" иначе IE пытается ломиться через NTLM. Да, и еще интересный момент, если использовать поиск групп через LDAP, то иногда в логах появляется ошибка что система не может связаться с LDAD-сервером, но поиск группы все-равно проходит. В варианте поиска группы через Kerberos, вроде пока все стабильно.
Здравствуйте! Настроил по статье все работает но возник такой трабл. На некоторых компах постоянно просит авторизацию. Причем именно на этих компах, на других под этими же пользователями заходит без проблем. Думаю дело в windows может сталкивались с таким, подскажите куда копать,
Возможно проблемы с Kerberos аутентификацией. Как минимум стоит проверить на проблемном клиенте время на предмет синхронизации с контроллерами домена.
Проверил mazila работает нормально. но chrome и ie гнут свое. Дайте совет где копать и как. Я навичек в этой теме. Если можно поподробней.
Коллеги, подскажите кто-нибудь сталкивался когда-нибудь с проблемой имени пользователя в AD состящую из двух слов типа "Иван Иванов". Авторизация проходит. Но в external_acl_type переменная %LOGIN ест только то что до пробела. Да и вслучае если использовать скажем в basic авторизации userPnincipalName обрезает обрезает суффикс. Ни как не пойму как заставить или обрабатывать пароль или использовать полный UPN авторизацию. Подскажите если кто сталкивался. Советовать сменить имена не надо. Домен не мой попросили помочь, а исторически там так и большие дядьки менять феншуй не хотят.
Можно использовать вместо хелпера ext_ldap_group_acl какие-то другие хелперы, например winbind, как здесь
Ещё можно попробовать использовать для external_acl_type дополнительный параметр "protocol=2.5" который, если я правильно понял, заключает все передаваемые в хелпер значения в кавычки.
Здесь пишут что подобные проблемы замечены в ветке 3.5 и при этом в версии 3.3.13 логины с пробелами обрабатываются корректно.
В общем есть над чем подумать :)
Понял, про версию протокола особенно интерсно, попробую поковырять, проверю все две теории, и на карайняк попробую вычленить хелперы с ветки 3.3 может получится. Отпишусь после праздников.
Спасибо.
Версия протокола не помогла. Подстановка старых хелперов тоже. Городить наверно другую систему с авторизацией по группам заведомо утяжеляя конструкцию сквида с разным количеством чайлд процесов как-то неправильно (IMHO), оставлю на потом, на крайний случай. Займусь мозговым штурмом местных виндовс админов (я правда сам такой, по большей степени, но таких косяков не делал), на предмет причесывания всего в нормальный вид. А именно латиница и отсутствие пробелов. А то реализация замены TMG подвисла именно на проксе. Впны поднял, релей почтовый для эксчя сделал, фаервол настроил. и пинцет вклинился на две недели. Хотят бесплатный UTM причесывайте свой домен. А то борьба с русскими именами начинает напрягать, и самое обидное, что с радиусом такая же ерунда получается, авторизация есть acl по группам не пашет.
С этого и надо было начинать :)
По любому спасибо за помощь. Вроде лед тронулся первую группу переименовали для тестов. Если все ок, а думаю ок, то значит переименюут и все о стальное.
есть второй домен в доверительных отношениях, в созданные группы доступа добавил пользователей с другого домена, прописал прокси - TCP/DENIED. зато разрешенные сайты открываются, где собака порыта? мне кажется не должно быть проблем для авторизации пользователей с другого доверительного домена?
Здесь в комментариях уже задавался подобный вопрос.
как сделать так, чтобы в логи писалось DOMAIN\\USER, а не просто USER?
А у меня обратная сторона. Хочу сделать авторизацию на одном прокси из 2х доменов с двухсторонними доверительными отношениями, но незнаю как. Прописал отдельную проверку в группе по лдап в другом домене, но я так понял по логам, юзверя он берет как DOMAIN\\USER и соответственно такого пользователя ни в какой группе найти не может. Как тогда сделать авторизацию для другого домена ?
иногда почему то пропадает соединение с доменом, после перезакидывания все работает нормально, как это можно исправить? или в крон запихать задание?
убунту 14.04 сквид3, ад 2к8, уровень леса 2к8
Обратная ссылка: Создание keytab-файла, содержащего несколько разных Kerberos Principal | Блог IT-KB /
Ребят, у меня squid 3.5, ubuntu 16.04.
вот такое дело в логе:
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. No principal in keytab matches desired name; }}
соответственно, при входе в браузер, выдается окно ввода логина/пароля с дальнейшей ошибкой авторизации.
Наткнулся на вот такую проблему
http://drels.blogspot.ru/2017/02/ubuntu-1604-squid-3512.html
Очень печально видимо все закончилось. Какие-то пакеты для kerberos изменились в 16.04, похоже, а вместе с ними и методы авторизации ???
Вопрос снят, необходимо добавить в auth_param negotiate program в конец строки вместо HTTP/...
параметр GSS_C_NO_NAME
Всем доброго дня.
keytab создан, при попытке авторизоваться по нему вот такая ошибка:
kinit: Cannot find KDC for realm "MAIN.RUSSIANPOST.RU" while getting initial credentials
пробовал по всякому. система чистая, только поставил.
подскажите куда копать.
Здравствуйте, Александр. Проверяйте настройки krb5.conf. Убедитесь в том, что там правильно прописан Ваш домен (realm) и его контроллеры.
Спасибо за ответ,
проблема была немного в другом. для свежей версии Kerberos немного другой синтаксис:
[libdefaults]
default_realm = DOMAIN.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
default_keytab_name = /etc/squid/PROXY.KEYTAB
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true
[realms]
DOMAIN.COM = {
kdc = dc
kdc = dc2
admin_server = dc
default_domain = DOMAIN.COM
}
[domain_realm]
.domain.com = DOMAIN.COM
domain.com = DOMAIN.COM
[login]
krb4_convert = false
krb4_get_tickets = false
проблема решена.
Добрый день.А можете подсказать как тогда "связать" 2 домена (леса (balalayka.loc и landish.loc) между ними настроены доверительные внешние отношения.).AD с пользователями в landish.loc, в balalayka.loc терминальный сервер и прокси(который пытаюсь настроить).Нужно что бы прокся автоматически (без запросов логина и пароля) пускала пользователей в в домене balalayka.loc
Здравствуйте, Александр. Разные домены вероятней всего имеют разные диапазоны IP. Создайте на Squid отдельный acl с типом src и укажите в нём подсеть, которую нужно пускать без аутентификации. дальше останется только сделать в самом начале правил http_access разрешающее правило для этого acl.
Алексей,тут несколько иначе.Все верно с Ip адресами + у каждого домена свой днс.Нужно проксировать этих пользователей(учитывать трафик,резать сайты,шейпить).
Доброго времени суток.
Уточните, что имеется под словосочетание "Новое содержимое файла" в контексnе для smb.conf?
Полностью затереть содержимое и вставить, то что в статье или же только заменить раздел [global]
Здравствуйте, Сергей. Насколько помню, это именно те строки, которые незакомментированы и содержат параметры. Сейчас уже нет этой конфигурации под руками поэтому более точно не скажу.
Обратная ссылка: System Center 2012 R2 Operations Manager — настраиваем базовый мониторинг ОС Linux на примере Ubuntu Server 14.04 LTS — Блог IT-KB /
Здравствуйте. Спасибо за статью.
В статье нашел интересный и нужный мне момент. Создание кейтаба для сервера с другим именем, что бы в последующем использовать одну служебную запись на нескольких серверах. Получилось ли у вас так сделать? Хочу сделать пользователя squid c именем входа HTTP/squid.domain.local, при этом сервера
squid.domain.local у меня нет и не предвидится. Этим именем будут представляться несколько других серверов. А записи в DNS для сервера squid.domain.local так же нет т.к. самого сервера не существует.
Если не трудно опишите пожалуйста подробнее этот момент. Особенно касаемо необходимости записи в днс при создании кейтаба. Обязательно ли она. Если обязательна, то куда она должна указывать и можно ли после генерации кейтаба ее (A запись в DNS) удалить?
Заранее благодарю за любую помощь!
Странный вопрос. В статье про это и написано. И статья была написана на конкретном реальном примере.
Возможность разрешения клиентами имени, указанного в keytab, обязательна. Иначе Kerberos не будет работать.
Прошу прощения если сумбурно описал вопрос. Постараюсь объяснить.
Пару лет назад по Вашей статье был сделан прокси сервер с именем proxy.domain.local. Он в домен не вводился. Для получения данных из домена для squid и squidguard использовалась служебная учетная запись squid3 с именем входа HTTP/proxy.domain.local. Все прекрасно работает. Ваша статья тогда меня очень выручила.
И вот недавно потребовалось этот сервер ввести в домен. Использовал sssd. При вводе в домен был создан свой krb5.keytab для самого хоста. Я объединил содержимое обеих файлов (keytab для службы и для хоста) в один.
Теперь у меня на этом сервере нормально авторизируются пользователи нужной группы AD, и без проблем работает связка squid/squidguard продолжая получать данные из AD как и раньше через служебную учетную запись squid3.
НО, как позже выяснилось это не очень нравится контроллеру домена. Он периодически мне шлет ошибку "Указанное значение атрибута не является уникальным в пределах леса или раздела. Атрибут: servicePrincipalName Value=host/PROXY
CN=squid3,CN=Users,DC=domain,DC=local WinError: 8647" т.к. имя proxy.domain.local задействовано и как имя хоста при введении сервера в домен, так и при создании служебной учетки для сервиса squid.
Все переделывать не хочется. Годами уже работает.
Вот я и подумал можно ли создать другую служебную учетную запись для работы через нее squid/squidguard, но что бы в ее атрибутах был указан другой сервер, НЕ proxy.domain.local? Таким образом я надеюсь избежать дублирования SPN в домене.
Можно.