LINUX.ORG.RU
ФорумAdmin

SQUID kerberos and failback LDAP auth

 


1

1

Всем привет!

Имею конфигу:

# egrep -v '^(#|$)' /etc/squid3/squid.conf 
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth
auth_param negotiate children 10
auth_param negotiate keep_alive on
auth_param basic program /usr/lib/squid3/basic_ldap_auth -R -b "CN=Users,DC=xxxx,DC=ru" -f sAMAccountName=%s -h xxx -D "CN=reader,CN=Users,DC=xxx,DC=ru" -w xxx
auth_param basic children 5
auth_param basic realm Weclome!
auth_param basic credentialsttl 2 hours
acl auth proxy_auth REQUIRED
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT
http_access deny !auth
http_access allow auth
http_access deny all
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
http_port 3128
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .		0	20%	4320

При таком конифге, Linux работает адекватно (firefox)! Если нет kerberos билета, предлагает BASIC AUTH - c ldap. Всё ок. Windows клиенты - не важно, firefox, IE: если нет kerberos билета, выкидывают окно аутотентификации BASIC AUTH - c ldap, при вводе пароля, окно снова вылетает (и так до бесконечности). При том в логе squid такое:

TCP_DENIED/407 4702 GET http://www.google.ru/url? - HIER_NONE/- text/html

Удалось нагуглить, что Windows посылает похоже не только Kerberos, LDAP, но и NTLM запрос. От чего squid сходит с ума... http://serverfault.com/questions/544858/http-proxy-authentication-kerberos-fa... - очень походит на правду.

Что собственно делать в таком случае? Потыкал палочкой: /usr/lib/squid3/ntlm_fake_auth - но это не то, что нужно насколько я понимаю.

Как быть?

# squid3 -v
Squid Cache: Version 3.3.8
Ubuntu
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'
★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от DALDON

Ты представляешь дело так, как будто твоя ситуация какая-то уникальная, хотя это просто стандартная схема.

У меня из винды через FF или осла (все последних версий если что) без домена всё работает без проблем, вот кусок лога:

1408700722.065      0 10.1.0.255 TCP_DENIED/407 4218 GET http://yandex.ru/ - HIER_NONE/- text/html
1408700723.213    117 10.1.0.255 TCP_MISS/302 494 GET http://yandex.ru/ test HIER_DIRECT/93.158.134.11 text/html

Лезем, получаем 407, лезем еще раз с авторизацией и вуаля.

Часть конфига, ответственная за авторизацию:

auth_param basic program /opt/squid/libexec/basic_pam_auth -n squid -t 300 -o
auth_param basic children 30 startup=5 idle=5
auth_param basic credentialsttl 10800 seconds
auth_param basic realm squid.domain.ru

auth_param negotiate program /opt/squid/libexec/negotiate_kerberos_auth -r -s GSS_C_NO_NAME
auth_param negotiate children 100 startup=10 idle=10
auth_param negotiate keep_alive on

authenticate_cache_garbage_interval 1 hour
authenticate_ttl 1 hour

...

acl proxy_authorized proxy_auth REQUIRED

...

http_access deny !proxy_authorized

Сквида рукотворная:

Squid Cache: Version 3.3.12 configure options: '--prefix=/opt/squid' '--sysconfdir=/etc/squid' '--disable-loadable-modules' '--disable-wccp' '--disable-wccpv2' '--disable-eui' '--disable-htcp' '--disable-select' '--disable-poll' '--with-pthreads' '--disable-storeio' '--disable-disk-io' '--disable-removal-policies' '--enable-delay-pools' '--disable-useragent-log' '--disable-referer-log' '--enable-ssl' '--enable-ssl-crtd' '--disable-cache-digests' '--enable-icap-client' '--disable-snmp' '--disable-ident-lookups' '--enable-auth' '--enable-auth-basic=LDAP,PAM' '--enable-auth-ntlm=smb_lm' '--enable-auth-negotiate=kerberos' '--enable-auth-digest=LDAP,file' '--enable-external-acl-helpers=LDAP_group' '--enable-zph-qos' '--with-openssl' '--disable-ipv6'

3.4 не советую, очень грузит проц даже при минимальных нагрузках.

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

Да понимаю, что моя ситуация не уникальна... По этому очень и удивлён.

1408702591.610      0 192.168.11.209 TCP_DENIED/407 4179 GET http://linux.org.ru/ - HIER_NONE/- text/html
1408702591.616      0 192.168.11.209 TCP_DENIED/407 4282 GET http://linux.org.ru/ - HIER_NONE/- text/html
1408702607.750      0 192.168.11.209 TCP_DENIED/407 4282 GET http://linux.org.ru/ - HIER_NONE/- text/html
1408702607.767      0 192.168.11.209 TCP_DENIED/407 4282 GET http://linux.org.ru/ - HIER_NONE/- text/html

Вот мой лог, BASIC аутотентификаци с Windows без kerberos...

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

# squid3 -v

Squid Cache: Version 3.3.8 Ubuntu

configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Я оставлю только BASIC AUTH , и попробую зайти с Windows. О результатах отпишу. Максимально почищу конфиг. Постараюсь сделать его таким же как у тебя.

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

Ок! У меня как народ с работы убежит, посмотрю вечерком.

Слушай, а почему у тебя так мало helperов от kerberos?

# ps aux|grep negotiate_kerberos_auth -c

39

Это у меня на четверых вот... Чтобы не вылетало окно с BASIC авторизации.

При том, у меня idle 20 стоит.

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

Хз, у меня:

# ps aux | grep negotiate_kerberos_auth -c
21
Никаких окон не вылазит ни у кого, юзеров ~300 голов. Сквид сервер почти не грузит (5-10%). У меня, правда, выключено кеширование вообще ибо нафиг не надо и диск не грузит.

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

Я тоже хочу выключить его нафиг... Кеширование в современном Интернет на фиг не надо? Ты со мной согласен?

А можешь мне скинуть весь конфиг squid?

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

Погоди, погоди... Что-то тут не то... Выложи пожалуйста весь конфиг squid.

Смотри, разве такое возможно: у тебя сначало идет:

auth_param basic

А потом:

auth_param negotiate

У тебя в таком случае же вообще не смогут по идее пройти аутотентификацию пользователи с kerberos. Я точно читал, что порядок должен быть строго наоборот. Я попробовал поменять местами - и у меня теперь даже при наличии билета, выскакивает BASIC.

И как обещал: я убрал kerberos helper - у меня на Windows клиентах BASIC хелпер отрабатывать стал корректно.... Вот блин не задача то.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

У меня именно сначала бейсик, потом негошиейт.

И хотя да, в доках пишут:

The order in which authentication schemes are presented to the client is
	dependent on the order the scheme first appears in config file. IE
	has a bug (it's not RFC 2617 compliant) in that it will use the basic
	scheme if basic is the first entry presented, even if more secure
	schemes are presented.
Но у меня именно так всё работает отлично. Может баг в осле уже поправили давно и инфа устарела?

У тебя, случаем, логины-пароли не в кириллице? А то

IF HAVE_AUTH_MODULE_BASIC
	=== Basic authentication parameters ===

	"utf8" on|off
		HTTP uses iso-latin-1 as character set, while some
		authentication backends such as LDAP expects UTF-8. If this is
		set to on Squid will translate the HTTP iso-latin-1 charset to
		UTF-8 before sending the username and password to the helper.

Полный конфиг:

debug_options ALL,1 rotate=1
logfile_rotate 0

cache_mgr admin@domain.ru
visible_hostname squid.domain.ru

http_port 0.0.0.0:3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=64MB cert=/etc/squid/ssl/ca-squid.domain.ru.pem options=NO_SSLv2,NO_SSLv3 dhparams=/etc/squid/ssl/dh2048.pem cipher=ECDH+AESGCM:DH+AESGCM:ECDH+AES:DH+AES:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

server_persistent_connections on
client_persistent_connections on

cache_effective_user squid
cache_effective_group squid

# ICAP ACL
acl icap_whitelisted dstdomain "/etc/squid/lists/icap_domains_whitelisted.txt"

# ICAP scanning
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_connect_timeout 1 second
icap_preview_enable on
icap_preview_size 1024
icap_206_enable on
icap_persistent_connections on

icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_req deny icap_whitelisted
adaptation_access service_req allow all

icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_resp deny icap_whitelisted
adaptation_access service_resp allow all

forwarded_for delete
httpd_suppress_version_string on

### Error messages ###
error_directory /etc/squid/errors/ru

### Cache options ###
cache_mem 1024 MB
cache deny all

auth_param basic program /opt/squid/libexec/basic_pam_auth -n squid -t 300 -o
auth_param basic children 30 startup=5 idle=5
auth_param basic credentialsttl 10800 seconds
auth_param basic realm squid.domain.ru

auth_param negotiate program /opt/squid/libexec/negotiate_kerberos_auth -r -s GSS_C_NO_NAME
auth_param negotiate children 100 startup=10 idle=10
auth_param negotiate keep_alive on

authenticate_cache_garbage_interval 1 hour
authenticate_ttl 1 hour

external_acl_type squid_ldap ttl=30 negative_ttl=30 children-max=100 children-startup=10 children-idle=5 %LOGIN /opt/squid/libexec/ext_ldap_group_acl -b "OU=Пользователи,DC=domain,DC=ru" -s sub -D CN=service_ldap_ro,CN=Users,DC=domain,DC=ru -W /etc/squid/ldap.password -R -H ldap://10.1.16.10 -v 3 -S -K -f "(&(sAMAccountName=%u)(memberOf=%g))"
acl proxy_full_access external squid_ldap CN=proxy_full_access,OU=Proxy,OU=Groups,DC=domain,DC=ru
acl proxy_email_access external squid_ldap CN=proxy_email_access,OU=Proxy,OU=Groups,DC=domain,DC=ru
acl proxy_hr_access external squid_ldap CN=proxy_hr_access,OU=Proxy,OU=Groups,DC=domain,DC=ru
acl proxy_no_access external squid_ldap CN=proxy_no_access,OU=Proxy,OU=Groups,DC=domain,DC=ru
acl proxy_no_access_expired external squid_ldap CN=Expired_Passwords,OU=Groups,DC=domain,DC=ru

### Delay Pools ###
delay_pools 1
delay_class 1 4
delay_access 1 deny all
delay_parameters 1 -1/-1 -1/-1 -1/-1 8000/16000

### File lists ###
include "/etc/squid/lists.conf"

### File ACLs ###
## Lists ##
acl lists_block_dom dstdomain "/etc/squid/lists/domains_blocked.txt"
acl lists_fun_dom dstdomain "/etc/squid/lists/domains_fun.txt"
acl lists_job_dom dstdomain "/etc/squid/lists/domains_job.txt"

## Custom Lists ##
acl domains_whitelisted dstdomain "/etc/squid/lists/domains_whitelisted.txt"
acl domains_ssl_direct dstdomain "/etc/squid/lists/domains_ssl_direct.txt"
acl domains_mail dstdomain "/etc/squid/lists/domains_mail.txt"
acl domains_no_auth dstdomain "/etc/squid/lists/domains_no_auth.txt"
acl ip_ssl_direct dst "/etc/squid/lists/ip_ssl_direct.txt"

# SSL exceptions
acl domains_ssl_error dstdomain "/etc/squid/lists/domains_ssl_error.txt"

# SSL Proxying
ssl_bump none domains_ssl_direct
ssl_bump none ip_ssl_direct
ssl_bump client-first domains_ssl_error
ssl_bump server-first all
sslproxy_options NO_SSLv2,NO_SSLv3
sslproxy_cipher ECDH+AESGCM:DH+AESGCM:ECDH+AES:DH+AES:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
sslproxy_cert_error allow domains_ssl_error
sslproxy_cert_error deny all
sslcrtd_program /opt/squid/libexec/ssl_crtd -s /etc/squid/ssl/ssl_db -M 128MB
sslcrtd_children 50 startup=10 idle=10
always_direct allow all

### Port based ACLs ###
acl ports_allowed port 20
acl ports_allowed port 21
acl ports_allowed port 80
acl ports_allowed port 443
acl ports_allowed port 9000

acl ports_connect port 443
acl ports_connect port 9000

### Time period ACLs ###
acl time_fun time MTWHF 13:00-14:00 18:30-23:00
acl time_weekends time SA 00:00-23:59

### Other ACLs ###
acl net_internal src 10.0.0.0/8
acl net_internal src 192.168.20.0/24

acl svc_chk src 10.1.16.11
acl svc_chk src 10.1.16.12

acl method_connect method CONNECT
acl proxy_authorized proxy_auth REQUIRED

# Do not log requests to these domains
acl skip_logging dstdomain "/etc/squid/lists/skip_logging.txt"

# Statistics page
acl manager url_regex -i ^cache_object:// /squid-internal-mgr/
http_access allow manager svc_chk
http_access deny manager

follow_x_forwarded_for allow svc_chk
follow_x_forwarded_for deny all

icap_uses_indirect_client on
delay_pool_uses_indirect_client on
acl_uses_indirect_client on
log_uses_indirect_client on

### Access lists ###
http_access allow svc_chk
http_access deny !net_internal
http_access allow domains_no_auth ports_allowed
http_access deny !proxy_authorized
http_access deny proxy_no_access
http_access deny proxy_no_access_expired
http_access deny !proxy_full_access !time_fun lists_fun_dom
http_access deny !proxy_full_access lists_block_dom !domains_whitelisted
http_access deny !proxy_email_access !proxy_full_access !domains_whitelisted lists_mail_dom
http_access deny !proxy_hr_access !proxy_full_access lists_job_dom
http_access deny method_connect !ports_connect
http_access deny !ports_allowed
http_access allow all

deny_info https://support.domain.ru/pass_change proxy_no_access_expired

### Other parameters ###
access_log stdio:/var/log/squid/access.log squid !skip_logging
cache_log /var/log/squid/cache.log
cache_store_log none

logfile_rotate 90
mime_table /etc/squid/mime.conf

request_header_max_size 20 KB
request_body_max_size 0 KB

via off

shutdown_lifetime 3 seconds

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

Пока прикидываю конфигу твою.

По последовательности аутотентификаторов: смотри, если я ставлю первым аутотентификатором BASIC, вторым ставлю negotiate - то у меня АБСОЛЮТНО ВСЕ браузеры начинают настаивать на BASIC и забивают на negotiate (даже при наличии kerberos билета!). То есть: Linux: ff - упорно начинает сыпать окнами BASIC. Windows: FF, IE - аналогично. Я тоже считаю, что squid должен выдавать все методы проверки подлинности, а браузер на основе этого, должен выбирать наиболее безопасный (в моём случае - очевидно kerberos). Однако, этого не происходит.

Может где-то их надо перечислить в конфиге..? У тебя вроде ничего такого не вижу...

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

В общем поменял порядок местами. - Теперь BASIC заработал и в Windows, и можно его игнорить - то есть закрывать крестиком, что приведёт к открытию страниц, но уже по kerberos. ОЧЕВИДНО, что браузер не выбирает типы аутотентификации, а использует первый что ему предлагает squid!

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

http://wiki.squid-cache.org/Features/Authentication :

When multiple authentication schemes are offered by the server (Squid in this case), it is up to the User-Agent to choose one and authenticate using it. By RFC it should choose the safest one it can handle; in practice usually Microsoft Internet Explorer chooses the first one it's been offered that it can handle, and Mozilla browsers are bug-compatible with the Microsoft system in this field.

Конечно это wiki, тут может быть не самая свежая информация, однако это официальная wiki... Надо посмотреть на других браузерах, и понять, о каком RFC идёт собственно речь!

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

Ну что..? Посмеёмся? :)

Поставил google chrome - всё заработало как нужно! Прям с ходу! Очевидно, что оно перебирает схемы! Вошёл тупо в домен под учёткой которой ещё не входили ни раза. Запустил chrome - всё сразу побежало по kerberos! Хотя первым аутотентификатором стоял BASIC

Каким это таким чудным образом это корректно работает у тебя? - Лично для меня очень большой вопрос... Да и тебе я думаю станет интересно...

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Вот даж не знаю, у меня все компы на обычной Win7 с IE11, месяца два назад был IE9 - без разницы, всё работало и тогда отлично. С XP были какие-то косяки редко, помню, но мы его везде в конторе убрали уже давно. Такая схема работает еще со времен сквида 2.6 - 2.7 (или даже раньше) без принципиальных изменений.

Вот счас подключился по впн к офису, запустил у себя файрфокс на ноуте, прописал офисную проксю, лезу в инет - бейсик авторизация - вбил логин пасс, вуаля всё работает.

IE11 вообще провалился сразу без авторизации, хотя ноут не в домене ни разу, похоже как-то авторизация на VPN сработала (klist кажет тикет), хотя VPN-сервер цыска, авторизующаяся в домене через радиус. Чудеса да и только :)

Доменный Firefox/Chrome пока проверить не могу, но вроде у нас они где-то в офисе встречаются и работают без проблем.

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

Даже не знаю чего сказать... Не уж-то как то samba в качестве DC может на это влиять? Ну я прям не поверю в это и в жизнь... Сейчас посмотрел версию IE с которой я пробую - 9. Chrome прям с ходу как надо заработал. Всё бы простил, если бы не сей факт. Ещё остаётся конечно момент, на косячную сборку squid в репозитариях последней ubuntu... Блин, проверить чтоль на другом дистрибутиве?

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

Ну вот кагбе ты про дц на самбе то не упоминал, может как раз и в нем дело, хрен знает насколько оно винде соответствует. Керберос то как бы вроде достаточно универсальная вещь, конечно, но мало ли. Я таким секасом как дц на самбе не занимался и не собираюсь пока :) так что не в курсе как оно дружит.

Косячная сборка вряд-ли, но попробуй скомпилить последнюю с моими параметрами, там правда кеш уже на этапе сборки выпилен, так что имей в виду. Но я сумневаюсь что в этом дело, а то бы в багтрекерах бубунты был бы уже хай на эту тему.

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

Ну я упоминал про самбу тут раньше (в этом треде). В общем рано я обрадовался... - Chrome тоже не проглатывает аутотентификацию. Но способен выбрать аутотентификатор при неправильном их порядке.

Мы пока мест смотрим на самбу, чтобы не покупать серверные винды. Нам по сути от неё нужен SSO (потому как Microsoft отказалась хранить basic пароли в своём password storage начиная с Vista (не очень правда понятно зачем тогда вообще он нужен?)). В целом всё что нам нужно вроде как работает (а именно: делегирование тикетов, SSO на нужные нам сервисы)... Но есть нюансы, есть... В частности как раз вот этот, и нюанс с автообновлением билетов. - Билеты не продлеваются в linux (автоматом имею ввиду). В Windows вроде как получше с продлением, но тоже на мой взгляд есть странности. Вот думаю, не уж-то может co squid быть такой косяк косячный из-за криворукой samba.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Конкретно, эта проблема со squid она в общем то не страшная. Это третьестепенный сервис. И насколько я понял, все те приложения, которые хотят ходить в Интернет, минуя настройки винды - могут авторизоваться. Ну и вообще, в целом давать Интернет только по тикетам - не самая ужасная проблема. Да и в linux вроде как работает squid по паролю. Надо попробовать правда копнуть поточнее.

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

Мы пока мест смотрим на самбу, чтобы не покупать серверные винды.

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

потому как Microsoft отказалась хранить basic пароли в своём password storage начиная с Vista (не очень правда понятно зачем тогда вообще он нужен?

Не понял о чем ты - об обратимом шифровании чтоль? Чтобы пароли можно было прочитать из лдапа? Вроде там можно галку поставить «хранить в обратимом виде», но не пробовал. Я пароли храню в отдельной бд куда они заносятся автоматом после создания юзеров.

Вот думаю, не уж-то может co squid быть такой косяк косячный из-за криворукой samba.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

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

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

Две версии Windows Server 2012 R2 Std - 60 тысяч.

Лицензии клиентского доступа на наш парк (Windows CAL license): 138 тысяч.

Железо где всё это крутить (облака не рассматриваю, так-как это всё же AD, а оно в облаках как-то не очень): пусть даже по 30к на тазики- 60 тысяч. Ну или виртуализация, что также не отменяет расходов.

Итого: 60+138+60 = 258 тысяч.

Шеф сказал: давай попробуем samba. Мы сейчас вообще без домена живём, и в целом успешно живём. У нас крайне большой круг задач, хоть и мало народу. Так что всё равно очень много чего приходится делать руками. Так же у нас очень много легаси ПО и сервисов.

Не понял о чем ты - об обратимом шифровании чтоль?

Нет, нет... Что ты. Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint. Так вот они там отключили хранение пароля. И таким образом, если у тебя нету kerberos, при каждом открытии документа через протокол sharepoint у тебя будет вылезать окно - введи логин+пароль.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

Да, ты прав. Просто я удивлён вот чему: формально, я могу сделать сервер kerberos, не только на samba. Могу его сделать на: Windows/samba/MIT kerberos server/389 Directory Server (хоть это тот же MIT но всё же). И т.п. Исходя из моего представления: SQUID вообще не должен ходить на kerberos сервер. Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере. Затем он ожидает билетов от клиентов. Клиент ему предъявил билет - билет валидный. - Всё, он пропустил. Тут я правда не до конца всё же понял, на счёт сессионых ключей kerberos. Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.

Более того: формально, мне домен тоже не нужен. Можно поставить на Windows HOME - клиент MIT Kerberos, получить билет, положить его в хранилище MSLSA: , и иметь SSO. Другое дело, что для конечного пользователя это не очень удобно, и есть там моменты с продлением билета. Но всё же. Удобнее конечно залогиниться в ОС, и сразу иметь SSO. Но формально - и такая схема работает.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Итого: 60+138+60 = 258 тысяч.

Да, про клиентские лицензии я подзабыл, давно это добро не покупал.

Насчёт серверов - у меня лично всё давно и прочно виртуализовано, физических серверов почти нет. Так что пару виртуалок поднять обычно не проблема :)

У нас крайне большой круг задач, хоть и мало народу.

Такая же фигня, поэтому я стараюсь везде где можно всё автоматизировать, и виндовое АД в этом плане очень сильно помогает. Плюс стопицот скриптов) Руками почти ничего не делается, в итоге. Щас вот на VDI перейдём и будет вообще лафа :)

Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint.

А, это. А почему у вас нет сквозной авторизации в домене? Потому что домена по-сути нет? :) Так сделайте его и проблема сама уйдёт. У меня даже апач юзеров на странице создания тикетов авторизует керберосом абсолютно прозрачно (всё точно также как в сквиде), юзер вводит пароль только при входе в винду.

Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.

Так и есть. Это принцип кербероса - служба никогда напрямую не обращается к авторизационному серверу. Когда клиент хочет получить доступ к службе HTTP/squid.domain.ru, то сервер авторизации после проверки прав клиента генерирует ему тикет с сессионным ключом, который зашифрован ключом службы, т.е. тем, который в кейтабе. Поэтому если сквид смог расшифровать своим кейтабом твой запрос (там симметричная криптография, ключ на шифровку и дешифровку один и тот же), то он автоматически считает тебя авторизовавшимся.

Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере.

Хуже того, он там вообще не авторизуется :)

# klist -l
Principal name                 Cache name
--------------                 ----------

Можно получить тикет службы, но на авторизацию это никак не влияет:
# kinit -k -t /etc/squid/keytabs/squid.domain.ru.keytab HTTP/squid.domain.ru@DOMAIN.RU

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/squid.domain.ru@DOMAIN.RU

Valid starting    Expires           Service principal
24/08/2014 23:19  25/08/2014 09:19  krbtgt/DOMAIN.RU@DOMAIN.RU
        renew until 25/08/2014 09:19

Ну а резюмируя про домены - я так считаю, что раз у тебя клиенты виндовые, то домен нужен виндовый. Самба таки отстает прилично от паровоза мелкомягких и гемора с ней прилично. А виндовый дц просто работает и хрен бы ему будет. Если б клиенты были линух или макось какой, то можно что-то другое городить, а так - непонятно, ну пусть 200 тыщ на это, для почти любой конторы это небольшие деньги. А тем, для кого большие есть Windows Essentials (<=25 юзеров).

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

Насчёт серверов - у меня лично всё давно и прочно виртуализовано, физических серверов почти нет. Так что пару виртуалок поднять обычно не проблема :)

У нас нету соответствующей инфраструктуры. :(

Такая же фигня, поэтому я стараюсь везде где можно всё автоматизировать, и виндовое АД в этом плане очень сильно помогает. Плюс стопицот скриптов) Руками почти ничего не делается, в итоге. Щас вот на VDI перейдём и будет вообще лафа :)

У нас недавно праздник был, мы убрали последнюю WinNT. Теперь убираем Win2k. VDI это хорошо. Но есть там много моментов. Кладя все яйца в одну корзину встаёт ряд вопросов: начиная от профессиональности системного администратора, до увеличения пропускной способности сети. VDI это можно сказать домен для железяк. Всё это ОЧЕНЬ круто, но у нас VDI на все места не сгодится. К сожалению полностью гомогенную инфраструктуру не получится сделать. И бизнес не совсем понимает: зачем нам VDI, когда и так всё работает... - К слову, нам VDI насчитали на 12 млн. руб.

А, это. А почему у вас нет сквозной авторизации в домене? Потому что домена по-сути нет? :) Так сделайте его и проблема сама уйдёт.

Ну да... Но тут возникает ряд моментов, начиная с того, что часть Windows HOME версий. Есть часть ноутбуков, есть удалёнщики со своим хомячковым оборудованием...

Это принцип кербероса - служба никогда напрямую не обращается к авторизационному серверу. Когда клиент хочет получить доступ к службе HTTP/squid.domain.ru, то сервер авторизации после проверки прав клиента генерирует ему тикет с сессионным ключом, который зашифрован ключом службы, т.е. тем, который в кейтабе. Поэтому если сквид смог расшифровать своим кейтабом твой запрос (там симметричная криптография, ключ на шифровку и дешифровку один и тот же), то он автоматически считает тебя авторизовавшимся.

Спасибо за более подробное пояснение, в целом я так себе всё это и представлял.

Хуже того, он там вообще не авторизуется :)

Вооот. Это я как раз и отметил. И по сему не до конца понимаю роль keytab на сервере squid.

Можно получить тикет службы, но на авторизацию это никак не влияет:

Да, это я тоже подметил.

Ну а резюмируя про домены - я так считаю, что раз у тебя клиенты виндовые, то домен нужен виндовый.

В целом согласен. У меня 90 процентов это Win клиенты. Другое дело, что они несколько разных версий все и разных поколений... HOME/PRO. 2000/Vista/7/XP.

А тем, для кого большие есть Windows Essentials (<=25 юзеров).

Ага, в курсе про эту штуку. Не дорогая совсем.

В общем резюмируя наш разговор: я так и не понимаю, почему SQUID может себя так странно вести... Или не SQUID а его клиенты... Вот в чём дело. Что может такого делать косячного samba, что вот ТАК ВОТ это сбоит..? Прям не понимаю.

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

И по сему не до конца понимаю роль keytab на сервере squid.

Ну дык как раз для дешифровки сессионного ключа, который клиент передает. Если он дешифровался - клиент авторизован, все довольны.

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

Спасибо! Понял. Пока мест поковыряю это добро ещё малость. :) Может чего и выйдет ещё толкового.

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

Слушай, у меня пока мест нету времени на поднятие виндового DC, мне вот чего подумалось то...

Если у меня нет kerberos тикета, то squid вообще должен не обращать внимания ни на что и сувать мне BASIC AUTH... - И уж тем более не должен обращать внимания на ДЦ. Так-как я хочу BASIC AUTH. То есть домен не при делах. Однако, остаётся один момент: keytab. Быть может, squid его читает, и там что-то не так сгенерированно... - Вот в это я охотно поверую, ибо по сути только keytab меня и связывает с доменом. Больше то ничего. Я ведь прихожу без kerberos...

Пожалуйста, покажи мне:

root@gateway:~# klist -kt /etc/squid3/squid.keytab 
Keytab name: FILE:/etc/squid3/squid.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 01.01.1970 03:00:00 HTTP/proxy.company.ru@COMPANY.RU

Есть мнение, что я олух просто, и не правильно подготовил keytab. В частности, меня смущает kvno 1 (кстати, я до конца так и не понял, на что влияет этот kvno, это вроде как формат/версия билета?).

Keytab генерировал так (Win 2008 SP2):

ktpass /princ HTTP/proxy.company.ru@COMPANY.RU /mapuser squid@COMPANY.RU /pass xxxxxxxxxx /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL -out c:\squid.keytab
DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Если у меня нет kerberos тикета, то squid вообще должен не обращать внимания ни на что и сувать мне BASIC AUTH... -

Нет, не так. Алгоритм авторизации следующий:

1. Твой браузер отправляет проксе запрос GET что-то там

2. Прокся настроена на авторизацию методами BASIC и NEGOTIATE и отвечает на запрос ответом «407 Proxy authentication required», где в заголовке перечислены методы авторизации, которые прокси умеет

3. Браузер выбирает подходящий ему метод (по RFC - самый надежный, см. посты раньше о баге в IE, который ломился в первый попавшийся) и отправляет GET запрос еще раз, но уже с заголовком с авторизационными данными (тикетом кербероса с сессионным ключом и т.п.)

Пожалуйста, покажи мне:

Всё аналогично:

Keytab name: FILE:/etc/squid/keytabs/squid.domain.ru.keytab
KVNO Timestamp        Principal
---- ---------------- ---------------------------------------------------------
   1 01/01/1970 03:00 HTTP/squid.domain.ru@DOMAIN.RU
Кейтаб это таблица (что ясно из названия) и в ней может быть несколько ключей, так что KVNO это просто индекс ключа в файле.

Keytab генерировал так (Win 2008 SP2):

А зачем яго в винде генерить, если у тебя домен на самбе?.. Генерируй через mskutil

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

mskutil - то ещё поделие... Я так понимаю проект не развивается. Ему правда может и развиваться особо некуда, но я так поглядел на него, и покамест не стал связываться. Его поставить - то ещё дело... Я ставил. Генерил ключи, но мне что-то не понравилось... А вот чего: не понравилось: kvno оно там ставило странные, и TimeStamp реальный. - Почему кстати он от 1970 года? :)

Так... Ну ты описал процедуру аутотентификации ровно так, как я себе её представлял. Раз ключи у нас с тобой одинаковые, то может быть krb5.conf отличается..? Зачем кстати хэлперу kerberos нужен krb5.conf, если его уже keytab накормили..?

SQUID kerberos and failback LDAP auth (комментарий) - сейчас погляжу внимательнее на твой пост, и твой krb5.conf. Они у нас отличаются. Ну это единственное в таком случае, что ещё может связывать SQUID и samba домен. Не очень понимаю зачем нужен правда этот файл в случае keytab.

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

В общем содрал твой keytab - не помогло. :( Остаётся... Зимовать. Или понять зачем нужен таки krb5.conf при наличии keytab.

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

mskutil - то ещё поделие... Я так понимаю проект не развивается. Ему правда может и развиваться особо некуда, но я так поглядел на него

Ну оно 13 года обновилось последний раз, нормуль. Может дошло до идеала, да :)

Зачем кстати хэлперу kerberos нужен krb5.conf, если его уже keytab накормили..?

Может разве что для описания имеющихся реалмов\доменов и ограничения типов шифрования ключей, мол принимать только aes, остальное в баню. А для basic/pam авторизации еще как нужен. У меня через него же еще и сокс прокси авторизуется.

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

Может разве что для описания имеющихся реалмов\доменов и ограничения типов шифрования ключей, мол принимать только aes, остальное в баню.

Ну блин, если ты прав, то как может влиять samba на процесс выбора способа аутотентификации... Искренне не понимаю! Прям уже есть желание накатить squid постарше куда-нибудь, запихать ему в глотку keytab и попробовать.

А для basic/pam авторизации еще как нужен. У меня через него же еще и сокс прокси авторизуется.

Ну для модуля PAM - всё понятно, тут нет вопросов, очевидно оно нужно чтобы он за тебя получал билеты.

Кстати, какой у тебя сокс? Ты его через kerberos не научил? :( Чего через него гоняешь?

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

Сокс данте, гоняю через него скайп и еще чёто вроде, не помню уже. Скайп вроде не умеет через керберос, хотя могу ошибаться, разбираться лень.

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

Вот тоже хочу dante. Руками прописываешь его в скайпе? Кстати, а что будет у тебя если пользователь пропишет себе вместо http proxy в браузере, твой SOCKS, увидит мультики минуя SQUID или ты как то это предусмотрел? Почему кстати не рискнул прописывать SQUID в skype? Там всё совсем плохо с оверхедом в виде HTTP?

Как учитываешь трафик на dante?

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Да, руками эникеи прописывают пока, но вроде там групповые политики на это есть, хотя логин-пасс пока всё равно надо руками.

В браузере юзеры ничего прописывать не имеют права, им политиками там всё заблокировано нафиг :) Ну и скайп стоит только у узкого круга ограниченных людей, так что люлей раздать, если что вдруг, будет нетрудно.

Сквид почему нет, уже не помню - толи он не работал толком, толи только чаты работали, а голосовые звонки - нет, давно это было. Можно будет попробовать ради интереса еще разок, авось запашет.

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

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

Всё так, всё так барин.

В браузере юзеры ничего прописывать не имеют права

Так portable firefox таскаютЪ... Или ты настолько суров, что сумел запретить запуск всех exe кроме доверенных?

Если дойдут руки, сегодня сделаю apt-get install squid на ubuntu 12.04. Благо машинка есть уже под рукой. Посмотрю на старый squid.

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

Так portable firefox таскаютЪ... Или ты настолько суров, что сумел запретить запуск всех exe кроме доверенных?

Уже почти до этого дошли - софт только из program files, куда доступа на запись у юзверей нет. USB уже у всех заблокирован на запись, только чтение разрешено. Параноя она такая :)

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

То же самое с W2012 в качестве КД

Настраиваю прокси, хочу, чтобы браузер не спрашивал у пользователя, кто он такой, а чтобы брал данные,
введенные пользователем при входе в систему. Пришел к тому, что требуется аутентикация по керберос.
Делаю на OpenSUSE 12,3 присоединенной к домену ALG.LAN; Прокси - squid 3.2.11 ; хост alg-gw7
контроллер домена сделан на W2012

Для хоста на контроллере домена создал кейтаб-файл.
Создавал так:

ktpass /princ HTTP/alg-gw7.alg.lan@ALG.LAN /mapuser alg-gw7$@alg.lan /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass пароль /out путь 

Созданный файл проверяю на Проксе:

kinit -V -k -a HTTP/alg-gw7.alg.lan 
Using default cache: /tmp/krb5cc_0 
Using principal: HTTP/alg-gw7.alg.lan@ALG.LAN 
Authenticated to Kerberos v5 

klist 
Ticket cache: FILE:/tmp/krb5cc_0 
Default principal: HTTP/alg-gw7.alg.lan@ALG.LAN 

Valid starting     Expires            Service principal 
09/05/14 10:01:26  09/05/14 20:01:36  krbtgt/ALG.LAN@ALG.LAN 
        renew until 09/06/14 10:01:26 

Конфиг сквида в части, которая касается пользователей, прошедших аутентикацию или авторизацию

auth_param basic program /usr/sbin/basic_ldap_auth -d -b "dc=alg,dc=lan" -R -D wwwrun@alg.lan -W /etc/squid/pass -f "sAMAccountName=%s" -h alg-dc1.alg.lan
auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -i -d -r -s HTTP/alg-gw7.alg.lan@ALG.LAN
acl allowinett proxy_auth REQUIRED
external_acl_type ldapgroup %LOGIN /usr/sbin/ext_ldap_group_acl -d -R -b "dc=alg,dc=lan" -f "(&(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%a,OU=Internet-Access,OU=ANYWHERE,dc=alg,dc=lan))" -D wwwrun@alg.lan -W /etc/squid/pass alg-dc1.alg.lan
acl inet_access_0 external ldapgroup IA-ALG-IT
acl inet_access_1 external ldapgroup IA-ALG-Acc
http_access allow allowinett
http_access allow inet_access_0
http_access allow inet_access_1
http_access deny !allowinett

То есть LDAP читаю пользователем wwwrun, созданном в AD с паролем, прописанным в файл pass
Если закомментировать negotiate, то basic прекрасно работает, спрашивает аккаунт, определяет группу и соответственно дает или не дает доступ к инет
Если раскомментровать negotiate то... спрашивает аккаунт, в зависимости от браузера два раза хром или шесть раз осел, но хоть убей в инет не пускает,а логе (заранее простите, не смог понять как сделать спойлер) cache.log в это время вот что...

negotiate_kerberos_auth.cc(316): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: DEBUG: Got 'YR YIIG4gYGKwYBBQUCoIIG1jCCB......eOLg8fJZlJGLk=' from squid (length: 2359).
negotiate_kerberos_auth.cc(379): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: DEBUG: Decode 'YIIG4gYGKwYBBQUCoIIG1jCCB.......eOLg8fJZlJGLk=' (decoded length:1766).                                                   negotiate_kerberos_auth.cc(199): pid=8984 :2014/09/05 11:19:25| negotiate_kerberos_auth: ERROR: gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information.                                    
2014/09/05 11:19:25| negotiate_kerberos_auth: INFO: User not authenticated                                                   
2014/09/05 11:19:25.677 kid1| helper.cc(969) helperStatefulHandleRead: helperStatefulHandleRead: 98 bytes from negotiateauthenticator 
#1
2014/09/05 11:19:25.677 kid1| helper.cc(993) helperStatefulHandleRead: helperStatefulHandleRead: end of reply found                                                                                                              
2014/09/05 11:19:25.677 kid1| UserRequest.cc(122) releaseAuthServer: releasing Negotiate auth server '0x7f33b15d41f8'
2014/09/05 11:19:25.677 kid1| helper.cc(463) helperStatefulReleaseServer: srv-0 flags.reserved = 1
2014/09/05 11:19:25.677 kid1| helper.cc(1202) StatefulGetFirstAvailable: StatefulGetFirstAvailable: Running servers 2
2014/09/05 11:19:25.677 kid1| helper.cc(1222) StatefulGetFirstAvailable: StatefulGetFirstAvailable: returning srv-0
2014/09/05 11:19:25.677 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| UserRequest.cc(97) valid: Validated. Auth::UserRequest '0x7f33b12e4fc0'.
2014/09/05 11:19:25.677 kid1| client_side_request.cc(768) clientAccessCheckDone: The request CONNECT alt1-safebrowsing.google.com:443 is 3, because it matched 'allowinett'
2014/09/05 11:19:25.677 kid1| client_side_request.cc(781) clientAccessCheckDone: Access Denied: alt1-safebrowsing.google.com:443
2014/09/05 11:19:25.677 kid1| client_side_request.cc(782) clientAccessCheckDone: AclMatchedName = allowinett
2014/09/05 11:19:25.677 kid1| helper.cc(1202) StatefulGetFirstAvailable: StatefulGetFirstAvailable: Running servers 2
2014/09/05 11:19:25.677 kid1| helper.cc(1222) StatefulGetFirstAvailable: StatefulGetFirstAvailable: returning srv-0
2014/09/05 11:19:25.677 kid1| client_side_request.cc(138) ~ClientRequestContext: 0x7f33b1600008 ClientRequestContext destructed
2014/09/05 11:19:25.679 kid1| UserRequest.cc(126) releaseAuthServer: No Negotiate auth server to release.
2014/09/05 11:19:25.679 kid1| UserRequest.cc(126) releaseAuthServer: No Negotiate auth server to release.
2014/09/05 11:19:25.679 kid1| UserRequest.cc(125) ~UserRequest: freeing request 0x7f33b12e4fc0
2014/09/05 11:19:25.679 kid1| User.cc(14) ~User: doing nothing to clear Negotiate scheme data for '0x7f33b15d3f70'
2014/09/05 11:19:25.679 kid1| User.cc(154) ~User: Freeing auth_user '0x7f33b15d3f70'.
Логи такие, потому что уже голову сломал, не могу понять, включил сообщения отладки
Есть жуткое подозрение, что кейтаб-файл как-то неправильно создан, в сети еще есть описания,
что можно примапить к учетке пользователя, кто-нибудь может подсказать какая разница?

savranskiy73
()
Ответ на: То же самое с W2012 в качестве КД от savranskiy73

Я мапил на учётку пользователя, так-как у меня squid не в домене.

А поменяй ка местами:

auth_param basic program ... auth_param negotiate program ...

То есть так: auth_param negotiate program ... auth_param basic program ...

После этого скорее всего у тебя заработает kerberos. Но вот вполне может быть такое, что отвалится BASIC.

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

Значит, я логично поступил при изготовлении кейтаба...

В таком положении, как сейчас, basic тоже не работает, если после negotiate то тоже не работает basic...

Начинает работать basic, если закомментировать negotiate, тогда он даже умеет отличить в правильной группе пользователь или нет

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

Ага. Примерно аналогичная фигня и у меня...

Вот что можешь попробовать: http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory - ходят слухи, что нужно NTLM обязательно настраивать. - У меня впрочем не получилось ничего. Ну я так понимаю, чтобы использовать NTLM в домене нужно уже обязательно быть. Я собственно в домен зашёл. Но толку нет. :(

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Это может показаться странным, но не могу понять, какой хелпер в моей системе за это отвечает...
Есть в системе ntlm_fake_auth и ntlm_smb_lm_auth, basic_msnt_auth и basic_msnt_multi_domain_auth
Не могу понять, как их проверить, манов на них в системе нет, два последних ругаются чуть ли не матом, что надо указать DC
Первый не ругается, но понять какие ему данные дать не могу, и что он мне должен отвечать непонятно..

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

А вот просто единственный negotiate_kerberos_auth разве не может работать, без всяких других?
Чтобы, например, основную толпу, которые просто каким-то образом проникли в систему, пропускать в инет, ну тоже какой-то усредненный
А вот уже потом, если пользователь принадлежит группе ИТ или вообще ТОП, то тогда ему можно больше..

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

Эту статью тоже видел, кстати, как и в других есть указание создать переменную KRB5_KTNAME и экспортировать ее
Так вот, у меня в SUSE есть каталог /etc/default и в нем лежат файлы, но ни в одном из них export не применяется
Может здесь и ошибка, что сам сквид не понимает, где кейтабфайл? Может это в SUSE не так делается?

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

Kerberos работает, корректно отрабатывает kinit. С хоста самого прокси получает билет на любого пользователя, если угадал пароль. )
Если пароль не угадал - kinit ругается, что, мол провалено получение креденшлов.

kinit wwwrun
Password for wwwrun@ALG.LAN: правильный
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: wwwrun@ALG.LAN

Valid starting     Expires            Service principal
09/06/14 18:57:09  09/07/14 04:57:28  krbtgt/ALG.LAN@ALG.LAN
        renew until 09/07/14 18:57:09
kdestroy
kinit wwwrun
Password for wwwrun@ALG.LAN: неправильный 
kinit: Preauthentication failed while getting initial credentials
Я выше выкладывал получение билета без запроса пароля с кейтаб-ключом. Причем путь к ключу я не указываю, он понимает как-бы сам...
Я правильно понимаю, при изготовлении кейтаб-ключа на учетную запись компьютера в AD устанавливается пароль,
и созданный утилитой ключ содержит: компьютер такой-то, пароль такой-то, адрес такой-то, и т.д., а аутентикатор просто читает билет и сверяет с запросом?
Я в данный момент в конфиге поменял-таки местами, как советовали, не работает, однако...
В логе вот...
2014/09/06 19:30:04 kid1| Starting new negotiateauthenticator helpers...
2014/09/06 19:30:04 kid1| helperOpenServers: Starting 1/5 'negotiate_kerberos_auth' processes
negotiate_kerberos_auth.cc(271): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
negotiate_kerberos_auth.cc(316): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: DEBUG: Got 'здесь длиинный ключ' from squid (length: 2359).
negotiate_kerberos_auth.cc(379): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: DEBUG: Decode 'здесь длиинный ключ' (decoded length: 1766).
negotiate_kerberos_auth.cc(199): pid=840 :2014/09/06 19:30:04| negotiate_kerberos_auth: ERROR: gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. 
2014/09/06 19:30:04 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '
2014/09/06 19:30:04| negotiate_kerberos_auth: INFO: User not authenticated
в соседней теме парень пишет, что тупил squidGuard, он у меня тоже установлен, но я его не трогал вообще... и следов присутствия нет и логов его нет и процесса такого нет

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

Вот последняя редакция моего конфига:

# Squid 3.2.11
# debug_options ALL,1 84,9 85,5 82,3 29,6
auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -i -d -r -s HTTP/alg-gw7.alg.lan@ALG.LAN
auth_param negotiate children 5
auth_param negotiate keep_alive on
auth_param basic program /usr/sbin/basic_ldap_auth -d -b "dc=alg,dc=lan" -R -D wwwrun@alg.lan -W /etc/squid/pass -f "sAMAccountName=%s" -h alg-dc1.alg.lan
auth_param basic children 10
acl allowinett proxy_auth REQUIRED
external_acl_type ldapgroup %LOGIN /usr/sbin/ext_ldap_group_acl -d -R -b "dc=alg,dc=lan" -f "(&(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%a,OU=Internet-Access,OU=ANYWHERE,dc=alg,dc=lan))" -D wwwrun@alg.lan -W /etc/squid/pass alg-dc1.alg.lan

# Эти строки были по умолчанию в конфиге
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
# acl localnet src 172.16.0.0/12        # RFC1918 possible internal network
# acl localnet src 192.168.0.0/16       # RFC1918 possible internal network
# acl localnet src fc00::/7       # RFC 4193 local private network range
# acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80          # http
# acl Safe_ports port 21                # ftp
acl Safe_ports port 443         # https
# acl Safe_ports port 70                # gopher
# acl Safe_ports port 210               # wais
# acl Safe_ports port 1025-65535        # unregistered ports
# acl Safe_ports port 280               # http-mgmt
# acl Safe_ports port 488               # gss-http
# acl Safe_ports port 591               # filemaker
# acl Safe_ports port 777               # multiling http
acl CONNECT method CONNECT
http_access allow localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
#http_access deny to_localhost
# Этот кусок конфига я почти не трогал, все по умолчанию 

# А вот здесь я не уверен, что все правильно сделал
acl inet_access_0 external ldapgroup IA-ALG-IT
acl inet_access_1 external ldapgroup IA-ALG-Acc
http_access allow allowinett
http_access allow inet_access_0
http_access allow inet_access_1
http_access deny !allowinett

# http_access allow localnet
# http_access allow localhost
http_access deny all
http_port 10.0.20.1:3128
cache_mem 1024 MB
cache_dir aufs /var/cache/squid 2048 32 256
coredump_dir /var/cache/squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320
По моим расчетам это должно было работать так: Клиенты имеют возможность аутентикации сначала по керберос потом авторизации по basic
Правило allowinet дальше пропускает тех, у кого с auth все в порядке. Далее «пробиваются» в AD данные на пользователя...
Дальше кусок конфига, так было по умолчанию, я не торгал.
А вот правила inet_access_0 и inet_access_1 может неправильно сделал?
Изначально я хотел, чтобы из тех, кто аутентицировался или авторизовался на проксе получал доступ,
если он принадлежит или IT или Acc группам, остальным нельзя.
Eсли закомментировать negotiate аутентикацию тогда пользователя, угадавшего пароль и входящего в эти группы - пропускает
Если раскомментировать - то запрашивает логин\пароль бесконечно, пароль хоть какой вводи.. Я проверял, раз 20 вводил...Думал, мало ли....

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

И, тогда уж еще вопрос к гуру:
Как проверить работу negotiate_kerberos_auth - Squid kerberos based authentication helper. Version 3.0.4sq?
Не могу понять, какие ему данные надо и что он мне ответить должен, ибо не добился ни разу от него ответа.
Вот я так запускал:

negotiate_kerberos_auth -d -i -s HTTP/alg-gw7.alg.lan@ALG.LAN

negotiate_kerberos_auth.cc(271): pid=2430 :2014/09/06 22:02:27| negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
tester%Alg12345
negotiate_kerberos_auth.cc(316): pid=2430 :2014/09/06 22:02:58| negotiate_kerberos_auth: DEBUG: Got 'tester%Alg12345' from squid (length: 15).
negotiate_kerberos_auth.cc(363): pid=2430 :2014/09/06 22:02:58| negotiate_kerberos_auth: ERROR: Invalid request [tester%Alg12345]
BH Invalid request
^C
И на все один ответ. Хоть что ему вводи... Как я ни извращался, так и не понял, как с ним разговаривать.

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

KRB5_KTNAME=/etc/squid/HTTP.keytab export KRB5_KTNAME

У себя в системе нашел /etc/default, но файла squid там не было. Создал, внес строку, в ней указал путь к своему кейтабу.
Перезагружался. Понимания не добавило. Пытался в скрипт /etc/init.d/squid вставить такую строку, тоже где-то читал на форумах.
Научите, кто знает..

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

Стоп... Стоп. Стоп.... Всё слишком сложно. Ты мне кажется запутался чуть более чем полностью. Куда спешишь? У тебя стоит сейчас задача номер1: это сделать прозрачную аутотентификацию в kerberos. Вот ты сперва реши её, а потом уже иди дальше. Для аутотентификации по kerberos тебе достаточно весьма простого конфига squid: описать просто аутотентификатор, и задать одно правило для http_access и один acl. Всё. Уже всё должно заработать. Иди от простого к сложному. Ты навключал кучу дебага, и сам же не понимаешь о чём у тебя в логах ругань идёт. Но насколько я могу понять твои логи - у тебя в kerberos присутствует очень серьёзная ошибка. И скорее всего у тебя не подгружается keytab. Так же я не очень понимаю, почему ты keytab создавал на компьютер, а не на пользователя? - Везде создают на пользователя... Я не знаю какая точно в этом разница, и чем принципиально отличаются объекты в kerberos - пользователь, компьютер... Но я бы всё же сделал как делают все. HTTP/alg-gw7.alg.lan@ALG.LAN - это у тебя о чём? У тебя имеется А запись на хост: alg-gw7.alg.lan ? И PTR на него же? PTR должна быть единственной. В браузере должен быть прописан fqdn. - В общем на ubuntu я поднял squid c kerberos вообще не напрягась можно сказать. Тут главное не суетиться. :)

К примеру, я поднял kerberos на squid буквально с первого запуска. В ubuntu мне потребовалось править /etc/init/squid (не путать с /etc/init.d , может конечно /etc/init это фишка upstart, не вникал...) или как-то так. То есть в последней ubuntu насколько я понял /etc/default для squid не отрабатывает. По сему я там прописал просто экспорт keytab файла. Сейчас мне лениво лезть на сервер за конфигами. Выходной же... :) Но в общем суть я думаю тебе понятна.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от savranskiy73

И на все один ответ. Хоть что ему вводи... Как я ни извращался, так и не понял, как с ним разговаривать.

Я не гуру... Был бы гуру, сам тут не спрашивал бы. :) Но в целом, у меня есть ощущение, что данный хелпер не ожидает никакого простого текста с клавиатуры. А ожидает полноценный билет. Следовательно - тем способом, что ты его хочешь дебажить - может и не возможно это делать.

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

Но в целом, у меня есть ощущение, что данный хелпер не ожидает никакого простого текста с клавиатуры. А ожидает полноценный билет.

Так и есть, это же negotiate авторизация, а не basic, которую можно проверить тупым логин-пароль.

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

Угу. Я как-то help глянул по этому хэлперу (простите за тавтологию), кроме опций дебага ничего не нашёл.

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

Привет, ты решил эту задачу?

У себя столкнулся с точно таким же поведением(вечно выскакивающее окно авторизации на машинах не входящих в домен), решил установлением директивы keep-alive в состояние off, т.е. строки авторизации выглядят так:

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive off

auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid
auth_param basic children 10
auth_param basic realm ProxyAuthentication

После этого на WIN машине, не входящей в домен, вводим в выскакивающее basic окно логин-пароль и попадаем в интернет.
P.S. домен у меня тоже на samba4
P.S.S. В IE и chrome логин нужно вводить в формате DOMAIN.LOCAL\username, в firefox достаточно указать username.

menzoberronzan
()
Последнее исправление: menzoberronzan (всего исправлений: 3)
Ответ на: комментарий от menzoberronzan

ТВОЮ-жеж ты мать!!! Проблему я не решил, и уже отчаился... Пока ты вот не написал... Спасибо тебе, что не поленился! А я что-то даже и не подумал, что всё так просто.

Значится так, у меня сейчас настройки такие:

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -r
auth_param negotiate children  99 startup=20 idle=20
auth_param negotiate keep_alive off


auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid -t 300 -o
auth_param basic children 5 startup=5 idle=1
auth_param basic credentialsttl 10800 seconds

blind_oracle Имя пользователя можно вводить и в формате: user@domain.local.

Вопрос, как бы избавиться от: «@domain.local» или «DOMAIN.LOCAL\» в имени пользователя? При basic AUTH?

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Интересно, сейчас посмотрел - в логах ни слова о basic_pam_auth.
Закомментировал строчки с basic авторизацией, перезапустил squid и поведение на машине не-в-домене сохранилось. Т.е. выскочило окошко, ввел логин DOMAIN.LOCAL\username и получил доступ в интернет. Получается, что окошко авторизации выводит negotiate_kerberos_auth, до basic_pam_auth дело даже не доходит.

menzoberronzan
()
Последнее исправление: menzoberronzan (всего исправлений: 1)
Ответ на: комментарий от menzoberronzan

Ааа... Похоже на правду. А причина такому поведению скорее всего является:

auth_param negotiate keep_alive off

По идее, чтобы перескочило на следующий хэлпер, оно должно быть on. Но на практике - мне это не помогало.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Вопрос, как бы избавиться от: «@domain.local» или «DOMAIN.LOCAL\» в имени пользователя? При basic AUTH?

Проще пареной репы:

# cat /etc/pam.d/squid 
auth sufficient pam_krb5.so alt_auth_map=%s@DOMAIN.LOCAL
account required pam_krb5.so

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

Ага, это то у меня вестимо есть. :) Я ж забыл, что и сам выяснил, но тов. menzoberronzan - напомнил. Что дело то до BASIC и вовсе не доходит... Так что мой basic хэлпер вообще не используется...

DALDON ★★★★★
() автор топика
8 апреля 2015 г.
Ответ на: комментарий от blind_oracle

Вчера стали неожиданно днём сыпаться ошибки в браузерах: Прокси сервер отказывается принимать соединения... Страницы открывались через раз... Часть css, js не загружалась.

Первое что пришло в голову - увеличить кол-во kerberos хелперов. - Стал увеличивать, особо не помогало. Увеличил в три раза - помогло. Оказалось ужасное.

Стал выяснять по логам, и по коннектам, чего происходит, вычислил top ip адресов, которые ломятся в squid:

netstat -nat |grep :3128 | grep -v 0.0.0.0:3128 | grep -v 127.0.0.1:3128 | awk '{print $5}' | awk -F\: '{print $1}' | sort |uniq -c

Потом посмотрел в отчёты и ужаснулся... : http://pix.toile-libre.org/upload/original/1428481614.png у одного из пользователей, windows решила так обновиться (про WSUS знаю)... При этом создав 43,000 запросов на squid, от чего всем kerberos хелперам стало плохо.

Ну я так... Малоли тебе интересно будет. :)

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Нифига себе... винда, я смотрю, всё ещё может удивить весёлыми глюками)))

У меня хоть и WSUS, но с ним тоже весело - когда всякие удалённые офисы начинают дружно качать обновления с него через 5-10Мбит каналы. А апдейты нынче (с офисом вместе) бывают по 1.5Гбайт за раз... После этого начинает глючить ip-телефония даже несмотря на шейпинг и прочий QoS :)

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