News:

Автоматизация бардака приводит к автоматизированному бардаку

Main Menu

Active Directory и Squid

Started by abdullasharapov, 04 April 2017, 17:24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

abdullasharapov

Добрый день. По статье пытаюсь подружить сквид и авторизацию посредством AD. Что касается прокси, то по статье все получилось. Проблема на стороне домена. Структура следующая.
Первый КД DC1 имеет один сетевой виртульный интерфейс с адресом 192.168.85.1
Второй КД DC2 имеет два интерфейса: физический с адресом 10.1.220.20 и виртуальный 192.168.85.2
Оба этих КД находятся в сайте Office1  с подсетью 192.168.85.0/24
Третий КД DC3 имеет два интерфейса: физический 192.168.11.1 и виртуальный 192.168.85.3. Он находится в своем сайте Office2 с подсетью 192.168.11.0/24
Все КД являются GC. В ДНС имеются 3 обратные зоны (т.к. 3 подсети).
Хелпер тянет инфу из DC1 и DC2, но вот с DC3 тупик.

kerberos_ldap_group.cc(371): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: INFO: Got User: user1 set default domain: TEST.RU
kerberos_ldap_group.cc(376): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: INFO: Got User: user1 Domain: TEST.RU
support_member.cc(63): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: User domain loop: group@domain inet_full@NULL
support_member.cc(91): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Default domain loop: group@domain inet_full@NULL
support_member.cc(119): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Default group loop: group@domain inet_full@NULL
support_member.cc(121): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Found group@domain inet_full@NULL
support_ldap.cc(898): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Setup Kerberos credential cache
support_krb5.cc(127): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Set credential cache to MEMORY:squid_ldap_2676
support_krb5.cc(138): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Get default keytab file name
support_krb5.cc(144): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Got default keytab file name /etc/squid/squid3.keytab
support_krb5.cc(158): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Get principal name from keytab /etc/squid/squid3.keytab
support_krb5.cc(169): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Keytab entry has realm name: TEST.RU
support_krb5.cc(181): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Found principal name: HTTP/gate-office.test.ru@TEST.RU
support_krb5.cc(196): pid=2676 :2017/04/04 17:16:57| kerberos_ldap_group: DEBUG: Got principal name HTTP/gate-office.test.ru@TEST.RU
support_krb5.cc(260): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Stored credentials
support_ldap.cc(927): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Initialise ldap connection
support_ldap.cc(933): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Canonicalise ldap server name for domain TEST.RU
support_resolv.cc(379): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.RU record to dc1.test.ru
support_resolv.cc(379): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.RU record to dc3.test.ru
support_resolv.cc(379): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.TEST.RU record to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 1 of TEST.RU to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 2 of TEST.RU to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 3 of TEST.RU to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 4 of TEST.RU to dc1.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 5 of TEST.RU to dc1.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 6 of TEST.RU to dc1.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 7 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 8 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 9 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 10 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 11 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 12 of TEST.RU to dc3.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 13 of TEST.RU to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 14 of TEST.RU to dc2.test.ru
support_resolv.cc(207): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Resolved address 15 of TEST.RU to dc2.test.ru
support_resolv.cc(407): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Adding TEST.RU to list
support_resolv.cc(443): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Sorted ldap server names for domain TEST.RU:
support_resolv.cc(445): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Host: dc3.test.ru Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Host: dc2.test.ru Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Host: dc1.test.ru Port: 389 Priority: 0 Weight: 100
support_resolv.cc(445): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Host: TEST.RU Port: -1 Priority: -2 Weight: -2
support_ldap.cc(942): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc3.test.ru:389
support_ldap.cc(953): pid=2676 :2017/04/04 17:16:59| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_sasl.cc(276): pid=2676 :2017/04/04 17:19:36| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=2676 :2017/04/04 17:19:36| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact LDAP server
support_ldap.cc(942): pid=2676 :2017/04/04 17:19:36| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc2.test.ru:389
support_ldap.cc(953): pid=2676 :2017/04/04 17:19:36| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI
support_ldap.cc(967): pid=2676 :2017/04/04 17:19:46| kerberos_ldap_group: DEBUG: Successfully initialised connection to ldap server dc2.test.ru:389
support_ldap.cc(333): pid=2676 :2017/04/04 17:19:46| kerberos_ldap_group: DEBUG: Search ldap server with bind path "" and filter: (objectclass=*)
support_ldap.cc(602): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : schemaNamingContext
support_ldap.cc(645): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: 1 ldap entry found with attribute : schemaNamingContext
support_ldap.cc(342): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Search ldap server with bind path CN=Schema,CN=Configuration,DC=test,DC=ru and filter: (ldapdisplayname=samaccountname)
support_ldap.cc(345): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Found 1 ldap entry
support_ldap.cc(350): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Determined ldap server as an Active Directory server
support_ldap.cc(1080): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Search ldap server with bind path dc=TEST,dc=RU and filter : (samaccountname=user1)
support_ldap.cc(1093): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Found 1 ldap entry
support_ldap.cc(602): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : memberof
support_ldap.cc(645): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: 2 ldap entries found with attribute : memberof
support_ldap.cc(1120): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Entry 1 "RDP" in hex UTF-8 is 524450
support_ldap.cc(1132): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Entry 1 "RDP" does not match group name "inet_full"
support_ldap.cc(1120): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Entry 2 "inet_full" in hex UTF-8 is 696e65745f66756c6c
support_ldap.cc(1128): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Entry 2 "inet_full" matches group name "inet_full"
support_ldap.cc(1390): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: DEBUG: Unbind ldap server
support_member.cc(125): pid=2676 :2017/04/04 17:19:48| kerberos_ldap_group: INFO: User user1 is member of group@domain inet_full@NULL
OK
Это я с ДНС запорол?

Уваров А.С.

Я уже отписал в комментах.

Делаем:

nslookup test.ru
затем для каждого адреса, по очереди

nslookup -type=ptr xxx.xxx.xxx.xxx
Думаем и идем настраивать обратную зону.

abdullasharapov

nslookup test.ru
Server:         192.168.11.1
Address:        192.168.11.1#53

Name:   test.ru
Address: 192.168.11.1
Name:   test.ru
Address: 192.168.85.3
Name:   test.ru
Address: 10.1.220.20
Name:   test.ru
Address: 192.168.85.2
Name:   test.ru
Address: 192.168.85.1
admin@gate-office:~$ nslookup -type=ptr 192.168.11.1
Server:         192.168.11.1
Address:        192.168.11.1#53

1.11.168.192.in-addr.arpa       name = dc3.test.ru.

admin@gate-office:~$ nslookup -type=ptr 192.168.85.1
Server:         192.168.11.1
Address:        192.168.11.1#53

1.85.168.192.in-addr.arpa       name = dc1.test.ru.

admin@gate-office:~$ nslookup -type=ptr 192.168.85.2
Server:         192.168.11.1
Address:        192.168.11.1#53

2.85.168.192.in-addr.arpa       name = dc2.test.ru.

admin@gate-office:~$ nslookup -type=ptr 10.1.220.20
Server:         192.168.11.1
Address:        192.168.11.1#53

20.220.1.10.in-addr.arpa        name = dc2.test.ru.
Обратная зона вроде правильно настроена.

abdullasharapov

Кстати, нет ведь разницы на каком из КД создавать файл keytab?
krb5 выглядит так:
[libdefaults]
        default_realm = TEST.RU
        default_keytab_name = /etc/squid/squid3.keytab

[realms]
        TEST.RU = {
                kdc = dc3.test.ru
                kdc = dc2.test.ru
                kdc = dc1.test.ru
                admin_server = dc1.test.ru
                default_domain = test.ru
        }

[domain_realm]
        .test.ru = TEST.RU
        test.ru = TEST.RU

Уваров А.С.

Без разницы, только уберите оттуда  dc3.test.ru, он, насколько я понял, в другом сайте и обращаться к нему нежелательно.

Также не очень хорошо, что он идет первым в выдаче адресов DNS, попробуйте "поиграть" с опцией расстановки в свойствах DNS-сервера.

abdullasharapov

Так DC3 мне в первую очередь и нужен. 1 и 2 находятся физически в другом здании, а 3й у меня в офисе. Соответственно он в своем сайте с подсетью 192.168.11.0/24. Не знаю где косяк, но этот косяк мне спать не дает((

Уваров А.С.

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

abdullasharapov

Если вас не затруднит, подскажите как найти этот косяк, работа просто парализована, хорошо параллельно старая сетка работает...

Уваров А.С.

Вот документация http://www.squid-cache.org/mail-archive/squid-users/201302/0083.html

Там есть ключ  [-S ldap server list] - попробовать явно указать контроллер и посмотреть выхлоп.

abdullasharapov

Подскажите как правильно прописать ДНС интерфейсов КД в моем случае.
1-й КД с адресом 192.168.85.1
2-1 КД с двумя интерфейсами: 192.168.85.2 и 10.1.220.20
3-й КД также с двумя интерфейсами: 192.168.85.7 и 192.168.11.1
Как выше писал, 1 и 2 КД в своем сайте с подсетью 192.168.85.0/24, 3й в своем 192.168.11.0/24. Клиентские ПК находятся в подсети 192.168.11.0/24 и должны стучаться к третьему КД.
Может я тут накосячил, хелпер к 1 и 2 КД подключается без проблем. Третий КД поднял также как второй, считай под копирку сделал. А хелпер упорно до него достучаться не может. У шлюза со сквидом прописан в качестве ДНС 192.168.11.1

Уваров А.С.

Вы имеете в виду сами контроллеры? Для них правильно будет первым DNS указывать 127.0.0.1, а вторым - любой иной контроллер. Несмотря на то, что в сети бытуют страшилки про DNS island, подобное явление последний раз мы наблюдали на Server 2003.