KERBEROS. Замена Heimdal на MIT

Приветствую Вас, дорогие пользователи.

Вообще тема данного топика неоднозначная, и немножко шире может оказаться, нежели то, что было написано в заголовке. В очередной раз пытаюсь перейти с NTLM на Negotiate (KERBEROS) аутентификацию пользователей, с целью последующего разграничения уровня (прав) доступа к ресурсам в сети Интернет. В очередной же раз у меня это не выходит.

Балуюсь в песочнице. Поднял на гипервизоре машиночку FreeBSD 9.1 x86.
Поставил squid 3.3 с поддержкой всего необходимого. Автоматом самба 3.6 притянулась.
Собственно читал и пытался делать вот по этому мануалу:
http://www.k-max.name/linux/avtorizaciy … iya-squid/
В процессе курения данной статьи (и не только) и пытаясь реализовать у себя то, что изложено в ней у меня ничего не получилось. А именно: после создания keytab-файла на контроллере домена W2k8R2 все заткнулось на этапе:
(сейчас будет короткая цитата из статьи ссылка на которую выше указана)

(собственно это пункт 2.5.)

У меня эта штука не работает.
Во-первых, ключа -V в манах нет.
Я думаю, что это не великая беда и данный ключ не критичен, надеюсь. Скорее всего автор реализовывал это не на FreeBSD, а на чем то другом и там данный ключ есть и что то значит. (вот только почему на момент написания топика у меня появилась мысль проверить что это за ключ?)) ).
Двигаемся дальше. Команда эта у меня не отрабатывает так как надо. Пишет следующее:

root@testbsd:/etc # kinit -k -t /etc/krb5.keytab HTTP/testbsd.domain
kinit: krb5_get_init_creds: KDC has no support for encryption type

При этом в билете вот что:

root@testbsd:/etc # ktutil -k /etc/krb5.keytab list
/etc/krb5.keytab:
Vno  Type                     Principal
  5  des-cbc-crc              HTTP/testbsd.domain@DOMAIN
  5  des-cbc-md5              HTTP/testbsd.domain@DOMAIN
  5  arcfour-hmac-md5         HTTP/testbsd.domain@DOMAIN
  5  aes256-cts-hmac-sha1-96  HTTP/testbsd.domain@DOMAIN
  5  aes128-cts-hmac-sha1-96  HTTP/testbsd.domain@DOMAIN

Я английский понимаю. Из сообщения видно, что кодировку KDC не понимает, но в списке есть же MD5. Какого, извините, тогда черта?
В итоге, пробуя различные варианты (уже не помню какие) я обошел проблему кодировки, но на данную команду уже был другой вывод

krb5_get_init_creds: Additional pre-authentication required

Погуглив, наткнулся на совет поставить галочку в учетке AD "Без предварительной проверки подлинности Kerberos".
НО, данная галочка как и вкладка существует для учетных записей пользователей, а не для учетных записей компьютеров.
Обратил внимание на то, что автор статьи пишет об используемой версии KERBEROS от MIT.
Проверил у себя - heimdal. Ставил порты krb5 и после этого проверял версию. Heimdal.
Ставил порт krb5-maint. Все равно Heimdal.
Проверял так: kinit --version.
Как правильно заменить Heimdal на MIT?
Возможно я где то чушь написал, извините )

Добавлено: 01-04-2014 12:36:04

Ну вот, что за напасть. Пока ковырялся "сам" не мог ничего сделать. Стоило только создать топик на форуме как спустя пару часов нашел решение)

Действительно, учетной записи компьютера в AD не нужно.
Нашел другую похожую статью, но более дельную:
http://kaktusenok.blogspot.ru/2012/08/c … ndows.html

Извините за беспокойство.

Хотя еще остается вопрос авторизации.

В статье говорится о squid_ldap_auth.
А у меня:

root@testbsd:/usr/local/etc/squid # ls /usr/local/libexec/squid/
basic_db_auth                    basic_pop3_auth            ext_ldap_group_acl        ntlm_fake_auth
basic_fake_auth            basic_radius_auth                ext_time_quota_acl        ntlm_smb_lm_auth
basic_getpwnam_auth        basic_smb_auth            ext_unix_group_acl        unlinkd
basic_ldap_auth            basic_smb_auth.sh                ext_wbinfo_group_acl    url_fake_rewrite
basic_msnt_auth            cachemgr.cgi                    helper-mux.pl            url_fake_rewrite.sh
basic_msnt_multi_domain_auth    digest_file_auth        log_file_daemon            wbinfo_group.pl
basic_ncsa_auth            diskd                        negotiate_kerberos_auth
basic_nis_auth                    dnsserver                            negotiate_kerberos_auth_test
basic_pam_auth            ext_file_userip_acl                negotiate_wrapper_auth

В статье говорилось, что надо использовать squid_kerb_auth.
Методом тыка случайно определил, что это одно и то же что и negotiate_kerberos_auth.
Почему?
Потому что при вводе неполных данных или некорректных ключей... или же запроса хелпа, вылезает вот это:

root@testbsd:/usr/local/etc/squid # /usr/local/libexec/squid/negotiate_kerberos_auth --help
negotiate_kerberos_auth: illegal option -- -
2014/04/01 11:35:01| negotiate_kerberos_auth: WARNING: unknown option: -?.
Usage: [b]
squid_kerb_auth[/b] [-d] [-i] [-s SPN] [-h]
-d full debug
-i informational messages
-r remove realm from username
-s service principal name
-h help
The SPN can be set to GSS_C_NO_NAME to allow any entry from keytab
default SPN is HTTP/fqdn@DEFAULT_REALM

Вот я и смекнул, что вместо того надо подставить это...
Но вот что будет аналогом squid_ldap_auth?