victor_sudakov: (Default)
Для аутентификации браузеров на прокси-сервере (проверено, работает на MSIE, Firefox, Chrome) без ввода логина и пароля (SSO, single sign-on) методом Negotiate можно использовать Kerberos. Для виндового домена и squid на FreeBSD порядок действий будет следующий...

Продолжение перенес на https://bitbucket.org/victor_sudakov/faq/src/tip/FAQ/squid_kerberos.txt
victor_sudakov: (Default)
Вот какая штука оказывается существует: http://oskt.secure-endpoints.com/knc.html

UPD Надеюсь скоро увидеть в портах FreeBSD, спасибо Denis Generalov из Рэмблера.
victor_sudakov: (Default)
Только недавно понял, что Kerberos называется Kerberos не только потому, что он страж, но и потому что трехголовый (KDC, client и server). Интересно, змея на хвосте не считается?

И вот что получается, если прочитать "Путешествия Гулливера" в детстве и потом не прочитать в оригинале. Оказывается порядок байтов big endian и little endian - это тупоконечники и остроконечники.
victor_sudakov: (Default)
В Heimdal есть очень удобная фича. Если с хоста доступен kadmind на 749/tcp, то прямо на хосте можно сказать "ktutil get host/`hostname`", и соответствующий principal будет создан на KDC, и ключ его притащен на хост и положен в /etc/krb5.keytab на хосте.

Для сервисов с non-default расположением keytab команда например: "ktutil -k ~svn/keytab get svn/`hostname`"
victor_sudakov: (Default)
Если при попытке получения билета из-за NAT возникает сабжевая ошибка, надо делать "kinit -A" (--no-addresses)
victor_sudakov: (Default)
При странных трудно диагностируемых проблемах с аутентификацией в Windows (типичный пример - юзер с XP не может зайти на расшаренный ресурс на Win 2008, а с w7 тот же самый юзер может) помогает пустить Kerberos over TCP, http://support.microsoft.com/kb/244474/en-us

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"MaxPacketSize"=dword:00000001
victor_sudakov: (Default)
Кому нужен сабж, его бесплатно раздают на http://www.centrify.com/resources/putty.asp
Я проверил, всё работает в условиях доверительных отношений между AD и UNIX realm (Heimdal).
Если у вас лес с кучей доменов, то вот полезная ссылочка: http://community.centrify.com/t5/Centrify-OpenSSH-Putty-and-Other/Putty-taking-too-long-to-obtain-a-host-ticket/td-p/838

UPD Оказывается, в снапшотах официального PuTTY тоже есть GSSAPI. http://tartarus.org/~simon/putty-snapshots/x86/
Надо проверить, будет ли работать в тех же условиях, что Centrify PuTTY.

UPD2. Из trusted realm билет взять не умеет (PuTTY-Snapshot-2011-03-06:r9120). Но если билет уже есть к моменту запуска - тогда работает. Simon Tatham-у написал об этом, ответа не получил.

UPD3. Чтобы заработало из Windows 7, пришлось разрешить алгоритм DES. http://technet.microsoft.com/en-us/library/dd560670%28WS.10%29.aspx

UPD4. Если ssh сервер находится в другом realm, то Windows хост должен знать об этом realm-е, т.е.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\YOUR.REALM.RU
(если в DNS есть информация о KDC, обслуживающих данный realm, то достаточно просто создать пустой раздел по имени realm. При отсутствии информации в DNS в него помещается информация о KDC, см. ksetup.exe).

UPD5. В свежем Heimdal/FreeBSD principals создаются с алгоритмом aes256-cts-hmac-sha1-96 в числе прочих, он вполне устраивает Windows 7, так что DES можно не включать, если нет legacy principals без AES.
victor_sudakov: (Default)
Описание настройки KDC не входит в задачи данного документа. Предполагается, что у вас уже есть работающий Kerberos (например, у вас работает CVS gserver или GSSAPIAuthentication в sshd).

1. Устанавливаем ports/devel/subversion с включенной поддержкой SASL2. Не забываем поставить security/cyrus-sasl2-gssapi.

2. В /usr/local/lib/sasl2/svn.conf пишем

sasldb_path: /home/svn/svn.sasldb
keytab: /home/svn/svn.keytab
mech_list: gssapi digest-md5 anonymous

Если предполагается Kerberos only окружение (аутентификация в svn с запросом логина и пароля не нужна), можно исключить упоминание о sasldb и убрать digest-md5 из списка механизмов.

Тут есть одна засада, но о ней позже, чтобы сохранялась интрига.

3. Создаем пользователя svn. Удобнее создать его с полноценным шеллом, потом пригодится для работы с svnadmin.

pw useradd svn -g svn -m -s /bin/tcsh -c 'Subversion server'

4. Создаем kerberos principal для svnserve.

su -l svn
ktutil -k /home/svn/svn.keytab get -p root/admin svn/`hostname`
ktutil -k /home/svn/svn.keytab list

5. Создаем репозиторий
su -l svn
mkdir /home/svn/repos
svnadmin create /home/svn/repos/myproject

6. В /home/svn/repos/myproject/conf/svnserve.conf раскомментируем следующие строки

[general]
anon-access = read
auth-access = write
realm = YOUR.DOMAIN.RU # тут должен быть ваш Kerberos realm

[sasl]
use-sasl = true

7. Вносим в /etc/rc.conf.local
svnserve_enable="YES"
svnserve_data="/home/svn/repos"

и запускаем сервер
/usr/local/etc/rc.d/svnserve start

8. Пробуем с клиентской машины
svn mkdir -m 'test dir ' svn://server.your.domain.ru/myproject/test44
и получаем ошибку:

svn: Authentication error from server: SASL(-1): generic failure:
GSSAPI Error: No credentials were supplied, or the credentials were
unavailable or inaccessible. (unknown mech-code 0 for mech unknown)

Очень информативно, правда?

9. Начинаем материться, читать рассылки, смотреть ktrace и приходим к выводу, что опция keytab: в /usr/local/lib/sasl2/svn.conf не работает (not implemented), и svnserve пытается искать свои ключи в системном /etc/krb5.keytab, естественно юзеру svn не хватает прав прочитать этот файл, и возникает ошибка GSSAPI. Зато есть переменная среды KRB5_KTNAME и libkrb5 в неё смотрит.

10. Начинаем думать, как задать эту переменную среды при старте svnserve. Обнаруживаем, что через login class задать не получается. Зато можно например задать ее в /etc/rc.local и потом оттуда же стартовать

su -l svn -c '/usr/local/bin/svnserve -d --listen-port=3690 --listen-host 0.0.0.0 -r /home/svn/repos'

11. Можно также положить скрипт /etc/rc.conf.d/svnserve вот с таким содержимым
KRB5_KTNAME=/home/svn/svn.keytab ; export KRB5_KTNAME

12. Вот теперь всё хорошо:
svn mkdir -m 'test dir ' svn://server.your.domain.ru/myproject/test44
Committed revision 1.

(с) 2010 Виктор Судаков
victor_sudakov: (Default)
CLI: "C:\Program Files\Windows Resource Kits\Tools\klist.exe" tickets
GUI: "C:\Program Files\Windows Resource Kits\Tools\kerbtray.exe"
victor_sudakov: (Default)
Поставил сервер под FreeBSD 8.0-RELEASE и обнаружил, что не работает GSSAPIAuthentication в sshd, если ходить на этот сервер с более старых версий FreeBSD. Неработа проявляется в том, что не пускает (метод gssapi-with-mic не проходит) и "sshd -d" пишет в дебаге "GSSAPI MIC check failed". За подробностями отсылаю в архив freebsd-stable, а вкратце и по-русски, чтобы работало, надо в /etc/krb5.conf на машине с более старой версией FreeBSD и ssh клиентом дописать:
[gssapi]
        correct_des3_mic = host/your.server.ru@YOUR.KERBEROS.REALM

Где your.server.ru - машина с sshd под 8.0-RELEASE.

Говорят, что можно даже использовать wildcards, типа
[gssapi]
        correct_des3_mic = host/*

если все сервера под новой версией фри.

Profile

victor_sudakov: (Default)
Виктор Судаков

May 2017

S M T W T F S
  123456
7 8 9101112 13
14151617 181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 24th, 2017 07:30 pm
Powered by Dreamwidth Studios