LINUX.ORG.RU
Форум — Admin  

squid + ad

 , ,


0

3

Всем добрый день. Прошу помочь любителей кальмаров. Есть Squid 3.5.20, работающий на CentOS 7. Сервер является членом AD, настроена авторизация пользователей. Все было прекрасно до позавчерашнего дня. Сначала у пользователей перестали открываться некоторые сайты, потом перестали открываться почти все сайты.

Самое подозрительное, что нашел в cache.log:

negotiate_kerberos_auth.cc(180): pid=1562 :2022/04/13 15:51:52| negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. Cannot find key for HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU kvno 4 in keytab

access.log полон сообщений:

TCP_DENIED/407 4254 CONNECT api.msn.com:443 - HIER_NONE/- text/html

Никаких изменений в AD в учетной записи, связанной с keytab-файлом, не было. Я пробовал генерировать его заново, подкладывать, но результат тот же. Пробовал восстанавливать сервер из бэкапа. Тоже не помогло.

Чувствую, это как-то связано с kvno 4 и атрибутом msDS-KeyVersionNumber, равный 3.

Конечно связано. kvno в кейтабе должен совпадать с msDS-KeyVersionNumber.

Т.е. получается, что у тебя в кейтабе kvno больше, чем в AD? Значит, какой-то вумный софт на сервере перегенерил кейтаб, но не обновил пароль в AD.

Короче, генери кейтаб заново.

P.S. Если ты в процессе генерации кейтаба еще раз менял пароль, то восстанавливать сервер из бэкапа не имеет смысла, т.к. ключ в AD уже другой.

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

В том и дело, что пароль не менялся от учетной записи, и keytab тоже. Я уже удалил и создал заново учетную запись в AD, заново сгенерировал keytab, положил его на сервер, перезагрузил сервер для уверенности, на при сравнении все равно разница в 1 между msDS-KeyVersionNumber и kvno. Как так?

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

А как ты проверял, что пароль не менялся? По атрибуту PwdLastSet?

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

Или, как вариант, неправильно смотришь kvno в AD. Его кстати, можно смотреть командой 

kvno HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU

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

Да. Через PowerShell смотрел, когда менялся последний раз пароль.

Вот сейчас сменил пароль у учетной записи в AD на другой. Сгенерировал новый keytab.

ktpass /princ HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU /mapuser krb5@MAIN.DOMAIN.RU /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass <password> /out C:\krb5.keytab

ktpass отчитался об успешном создании 5 ключей с разными алгоритмами шифрования, vno = 5. Посмотрел атрибут msDS-KeyVersionNumber — также 5.

Потом закинул keytab-файл на CentOS, перезагрузился. Узнал kvno.

klist -K -e -t -k /etc/squid/krb5.keytab
Keytab name: FILE:/etc/squid/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   5 01/01/1970 03:00:00 HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU (des-cbc-crc)  (0xe9eae3e31.....cd)
   5 01/01/1970 03:00:00 HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU (des-cbc-md5)  (0xe9eae3e31.....cd)
   5 01/01/1970 03:00:00 HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU (arcfour-hmac)  (0xf843b5971988ebc3e347e50b9.....5a)
   5 01/01/1970 03:00:00 HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU (aes256-cts-hmac-sha1-96)  (0x9935cc45f3f65cc30dd6a54ee673bb5c30140fd1ab98e5f73bcaf8714.....bb)
   5 01/01/1970 03:00:00 HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU (aes128-cts-hmac-sha1-96)  (0xb42a4a035d92759e2a6e99b1e.....80)

KVNO = 5

Тестирую. На сайты через прокси по-прежнему не заходит. Ошибки из cache.log пропали. Остались только сообщения отладки. Наткнулся на одно из них.

Got user1@MAIN.DOMAIN.RU squid_full from squid
User:  -user1@MAIN.DOMAIN.RU-
Group: -squid_full-

Дело в том, что я этого пользователя вывел из группы AD squid_full еще вчера и сейчас он в другой группе доступа для squid, но cache.log показывает, будто пользователь до сих пор там.

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

Не, это неважно. Скорее всего это потому, что кейтаб был сгенерирован на винде, и виндовый ktpass выставляет 0 в это поле. Не критично.

С Kerberos я так понимаю проблема решена, теперь проблема в чем-то другом.

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

Разницы во времени нет, в NTP-клиенте прописаны парочка контроллеров домена, которые являются NTP-серверами. CentOS я удалял и заново добавлял в домен через winbind с помощью net ads join -U <username>. Ошибок не было. Проверка через net ads testjoin ошибок не выдала.

Демон живой.

[root@te-gw02-m ~]# service winbind status -l
Redirecting to /bin/systemctl status  -l winbind.service
● winbind.service - Samba Winbind Daemon
   Loaded: loaded (/usr/lib/systemd/system/winbind.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2022-04-13 20:26:47 MSK; 46min ago
     Docs: man:winbindd(8)
           man:samba(7)
           man:smb.conf(5)
 Main PID: 894 (winbindd)
   Status: "winbindd: ready to serve connections..."
   CGroup: /system.slice/winbind.service
           ├─ 894 /usr/sbin/winbindd --foreground --no-process-group
           ├─1037 /usr/sbin/winbindd --foreground --no-process-group
           ├─1453 /usr/sbin/winbindd --foreground --no-process-group
           ├─1454 /usr/sbin/winbindd --foreground --no-process-group
           └─1455 /usr/sbin/winbindd --foreground --no-process-group

Apr 13 20:26:47 te-gw02-m.main.domain.ru systemd[1]: Starting Samba Winbind Daemon...
Apr 13 20:26:47 te-gw02-m.main.domain.ru winbindd[894]: [2022/04/13 20:26:47.932267,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
Apr 13 20:26:47 te-gw02-m.main.domain.ru winbindd[894]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
Apr 13 20:26:47 te-gw02-m.main.domain.ru winbindd[894]: [2022/04/13 20:26:47.943851,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
Apr 13 20:26:47 te-gw02-m.main.domain.ru systemd[1]: Started Samba Winbind Daemon.
Apr 13 20:26:47 te-gw02-m.main.domain.ru winbindd[894]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections
naemeless
() автор топика
Ответ на: комментарий от bigbit

Снова полезли ошибки в cache.log. Пытается найти kvno 3 в keytab, когда он уже 5.

negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. Cannot find key for HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU kvno 3 in keytab
naemeless
() автор топика
Ответ на: комментарий от naemeless

Это странно, что он kvno=3 ищет. Клиент что-ли к нему приходит с таким тикетом…

Попробуй:

  1. На клиенте сбросить тикеты. Для винды это команда klist purge.
  2. Выполнить на сервере команду kvno
    HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU. Находит ли она SPN?
bigbit ★★★★★
()
Ответ на: комментарий от naemeless

Давай с клиентом разберемся. Зайди на клиента, и:

  1. Закрой все браузеры и дай команду klist purge
  2. Обратись к Squid’у
  3. Дай команду klist (просто klist, без purge). Появился ли тикет для сквида в выводе klist?
bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Я уже пробовал проводить всю эту процедуру на клиенте. Безрезультатно.

Текущим идентификатором входа является 0:0x11df9c

Кэшированные билеты: (0)
naemeless
() автор топика
Ответ на: комментарий от naemeless

Так у тебя клиент не получает тикет.
Надо решать проблему с клиентом.
Без этого делать что-либо на сервере не имеет смысла.

Может были какие-то изменения в DNS в последнее время? Например, A-запись заменили на CNAME, и т.п.?

Или изменения в доменных политиках (список Trusted sites)?

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

Записи прямой и обратной зоны для этого сервера в DNS не менялись. Они на месте, все прекрасно отвечает по доменным именам.

Примерно три недели назад мой коллега перенес в AD подсеть и контроллеры домена из одного удаленного сайта на наш сайт в AD.

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

А, если имеется в виду GPO, то нет, доверенные сайты не менялись.

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

Тогда боюсь остается только запуск сниффера на клиенте на 88 порт, чтобы понять, почему он тикет не может получить.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit 
Kerberos
    Record Mark: 233 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0000 1110 1001 = Record Length: 233
    krb-error
        pvno: 5
        msg-type: krb-error (30)
        stime: 2022-04-14 12:49:25 (UTC)
        susec: 103758
        error-code: eRR-PREAUTH-REQUIRED (25)
        realm: MAIN.DOMAIN.RU
        sname
            name-type: kRB5-NT-SRV-INST (2)
            sname-string: 2 items
                SNameString: krbtgt
                SNameString: MAIN.DOMAIN.RU
        e-data: 306d304aa103020113a2430441303f3027a003020112a1201b1e4d41494e2e5445504c4f…
            PA-DATA pA-ETYPE-INFO2
                padata-type: pA-ETYPE-INFO2 (19)
                    padata-value: 303f3027a003020112a1201b1e4d41494e2e5445504c4f454e4552474f2d4e4e2e525574…
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                            salt: MAIN.DOMAIN.RUtestuser
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-ARCFOUR-HMAC-OLD (-133)
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-ARCFOUR-MD4 (-128)
            PA-DATA pA-ENC-TIMESTAMP
                padata-type: pA-ENC-TIMESTAMP (2)
                    padata-value: <MISSING>
            PA-DATA pA-PK-AS-REQ
                padata-type: pA-PK-AS-REQ (16)
                    padata-value: <MISSING>
            PA-DATA pA-PK-AS-REP-19
                padata-type: pA-PK-AS-REP-19 (15)
                    padata-value: <MISSING>
naemeless
() автор топика
Ответ на: комментарий от naemeless

Что это, какой-то один пакет?
Нужно смотреть полный дамп обмена с домен-контроллером во время попытки получения тикета. Желательно в Wireshark.

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

Доброе утро. Извиняюсь, вчера забыл включить прокси в системе перед захватом трафика, поэтому и не получил тикеты.

Думаю, что не следует считать это ошибкой, а всего лишь проверкой на атрибут «Do not require Kerberos preauthentication».

error-code: eRR-PREAUTH-REQUIRED (25)

Тикеты запрашиваются рабочей станцией и отдаются ближайшим доступным контроллером домена штатно через KRB5.


Текущим идентификатором входа является 0:0x4d56b7

Кэшированные билеты: (2)

#0>     Клиент: testuser @ MAIN.DOMAIN.RU
        Сервер: krbtgt/MAIN.DOMAIN.RU @ MAIN.DOMAIN.RU
        Тип шифрования KerbTicket: AES-256-CTS-HMAC-SHA1-96
        флаги билета 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Время начала: 4/15/2022 8:46:02 (локально)
        Время окончания:   4/15/2022 18:46:02 (локально)
        Время продления: 4/22/2022 8:46:02 (локально)
        Тип ключа сеанса: AES-256-CTS-HMAC-SHA1-96
        Флаги кэша: 0x1 -> PRIMARY
        Вызванный центр распространения ключей: te-dc02-m.main.domain.ru

#1>     Клиент: testuser @ MAIN.DOMAIN.RU
        Сервер: HTTP/te-gw02-m.main.domain.ru @ MAIN.DOMAIN.RU
        Тип шифрования KerbTicket: RSADSI RC4-HMAC(NT)
        флаги билета 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Время начала: 4/15/2022 8:46:02 (локально)
        Время окончания:   4/15/2022 18:46:02 (локально)
        Время продления: 4/22/2022 8:46:02 (локально)
        Тип ключа сеанса: RSADSI RC4-HMAC(NT)
        Флаги кэша: 0
        Вызванный центр распространения ключей: te-dc02-m.main.domain.ru
naemeless
() автор топика
Ответ на: комментарий от bigbit

На сниффере вижу пакеты запросов/ответов AS-REQ и AS-REP. То же самое для TGS-тикетов.

AS-REQ:


Kerberos
    Record Mark: 329 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0001 0100 1001 = Record Length: 329
    as-req
        pvno: 5
        msg-type: krb-as-req (10)
        padata: 2 items
            PA-DATA pA-ENC-TIMESTAMP
                padata-type: pA-ENC-TIMESTAMP (2)
                    padata-value: 3041a003020112a23a0438fc435e87aec4300fd464a06abd491be1a0080bacf9760cfb85…
                        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                        cipher: fc435e87aec4300fd464a06abd491be1a0080bacf9760cfb85c374a8e9f15f5053196e53…
            PA-DATA pA-PAC-REQUEST
                padata-type: pA-PAC-REQUEST (128)
                    padata-value: 3005a0030101ff
                        include-pac: True
        req-body
            Padding: 0
            kdc-options: 40810010
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...1 .... = renewable-ok: True
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            cname
                name-type: kRB5-NT-PRINCIPAL (1)
                cname-string: 1 item
                    CNameString: testuser
            realm: MAIN.DOMAIN.RU
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: MAIN.DOMAIN.RU
            till: 2037-09-13 02:48:05 (UTC)
            rtime: 2037-09-13 02:48:05 (UTC)
            nonce: 391150565
            etype: 6 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD (-133)
                ENCTYPE: eTYPE-ARCFOUR-MD4 (-128)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
            addresses: 1 item TE-TESTWS-M<20>
                HostAddress TE-TESTWS-M<20>
                    addr-type: nETBIOS (20)
                    NetBIOS Name: TE-TESTWS-M<20> (Server service)

AS-REP:


Kerberos
    Record Mark: 1789 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0110 1111 1101 = Record Length: 1789
    as-rep
        pvno: 5
        msg-type: krb-as-rep (11)
        padata: 1 item
            PA-DATA pA-ETYPE-INFO2
                padata-type: pA-ETYPE-INFO2 (19)
                    padata-value: 30293027a003020112a1201b1e4d41494e2e5445504c4f454e4552474f2d4e4e2e525574…
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                            salt: MAIN.DOMAIN.RUtestuser
        crealm: MAIN.DOMAIN.RU
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: testuser
        ticket
            tkt-vno: 5
            realm: MAIN.DOMAIN.RU
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: MAIN.DOMAIN.RU
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 3
                cipher: e1451e52cc002693dc9b9232b0ed33764410033e089878703b0fe9f266c6fb47d6c65974…
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            kvno: 7
            cipher: b7b265af917fd8bf8a659fd3154e865c04486f97292882d3f88d56f606a54bc1154f87b2…
naemeless
() автор топика
Ответ на: комментарий от bigbit

TGS-REQ:


Kerberos
    Record Mark: 1847 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0111 0011 0111 = Record Length: 1847
    tgs-req
        pvno: 5
        msg-type: krb-tgs-req (12)
        padata: 2 items
            PA-DATA pA-TGS-REQ
                padata-type: pA-TGS-REQ (1)
                    padata-value: 6e8205c9308205c5a003020105a10302010ea20703050000000000a38205096182050530…
                        ap-req
                            pvno: 5
                            msg-type: krb-ap-req (14)
                            Padding: 0
                            ap-options: 00000000
                                0... .... = reserved: False
                                .0.. .... = use-session-key: False
                                ..0. .... = mutual-required: False
                            ticket
                                tkt-vno: 5
                                realm: MAIN.DOMAIN.RU
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: krbtgt
                                        SNameString: MAIN.DOMAIN.RU
                                enc-part
                                    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                    kvno: 3
                                    cipher: e1451e52cc002693dc9b9232b0ed33764410033e089878703b0fe9f266c6fb47d6c65974…
                            authenticator
                                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                cipher: d6bd53d5d9318ed7fd6d85455ae295a9a4e5c07b0853e55596384a0dce98dd2ba88ac9ee…
            PA-DATA pA-PAC-OPTIONS
                padata-type: pA-PAC-OPTIONS (167)
                    padata-value: 3009a00703050040000000
                        Padding: 0
                        flags: 40000000
                            0... .... = claims: False
                            .1.. .... = branch-aware: True
                            ..0. .... = forward-to-full-dc: False
                            ...0 .... = resource-based-constrained-delegation: False
        req-body
            Padding: 0
            kdc-options: 40810000
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...0 .... = renewable-ok: False
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            realm: MAIN.DOMAIN.RU
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: HTTP
                    SNameString: te-gw02-m.main.domain.ru
            till: 2037-09-13 02:48:05 (UTC)
            nonce: 391150133
            etype: 5 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
            enc-authorization-data
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                cipher: 5c5615e8c3539a82d412e3e464f5c019c385083fe383b7b5a7d9649ccd9f0be5459ee981…

TGS-REP:


Kerberos
    Record Mark: 1833 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0111 0010 1001 = Record Length: 1833
    tgs-rep
        pvno: 5
        msg-type: krb-tgs-rep (13)
        crealm: MAIN.DOMAIN.RU
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: testuser
        ticket
            tkt-vno: 5
            realm: MAIN.DOMAIN.RU
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: HTTP
                    SNameString: te-gw02-m.main.domain.ru
            enc-part
                etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                kvno: 5
                cipher: 4a372ff0dacbc7d09a99af0363162390cf137676a19a38f84189ba1c84029414fa85cc8f…
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            cipher: 6c4ab24968e1b244b20145392e46dee1dc102649900b6c0525f8bf685a7182388fd0bd55…

Актуальный kvno равен 5. Я пытаюсь понять, почему в AS-REP фигурируют ложные kvno 3 и kvno 5.

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

Плохо, что тикет RC4. Он в современных линуксах отключен.
Поставь у учетки в AD галочку «Использовать AES-256».

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

Я так подозреваю, что с kvno=3 приходят старые клиенты, у которых закэширован старый тикет.

А так все выглядит нормально.

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

Как раз тот клиент, под которым я это тестирую. Это следует из cache.log. Эту проблему должен был решить klist purge, но не решил. Я не знаю, что происходит, и куда дальше копать. Может быть есть еще какие-нибудь идеи? Вплоть до невероятных.

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

Ну все стандартно. Поднять уровень логирования, вгрызаться везде tcpdump’ом и strace’ом и смотреть, что происходит. Проверить на глупые ошибки (может там тикет не из того кейтаба берется или прав не хватает на чтение этого файла).

Идей я могу еще накидать =) Дублирующиеся SPN в AD (проверить можно с помощью setspn), сломаная репликация между домен-контроллерами, вумная сетевая железка посередине, которая пытается оптимизировать трафик, но все портит.

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

Еще можно постараться понять, что предшествовало отвалу. Да, я читал в ОП, что никаких изменений в AD не было. Но обычно так все говорят =)

Если я правильно понял, то отвал произошел в понедельник, т.е. после выходных. А в выходные часто делаются изменения в инфраструктуре.

Так что стоит сесть и хорошенько так подумать, какие изменения делались и что бы это могло быть. Поспрашивать коллег и смежные отделы, если ты не сам всей инфрой управляешь.

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

Интересно, спасибо, что отписался.

А не пробовал раскопать, в чем там дело (может AAAA-записи в DNS кривые…)?

И еще непонятно, почему оно работало до этого без этой опции, а потом вдруг перестало.

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

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

Нет, с DNS точно все в порядке было. Как были статичные записи с правильными FQDN, так они и не менялись. Я пока не знаю, почему это произошло со Сквидом. Связываю это с чем-то, про произошло за неделю до проблем, поскольку время жизни тикетов — 1 неделя. Тут либо каким-то образом сказался перенос контроллеров домена и подсетей на другой сайт домена, либо обновление прошивки маршрутизатора, через который Сквид выходит в Интернет, хотя конфиг маршрутизатора не менялся. Проблему обнаружил случайно, когда решил посмотреть, как сервер будет себя вести при запрете IPv6 через /etc/sysctl.conf.

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Хэлперы Сквида для авторизации сразу навалили сообщений, на рабочей станции начало появляться окно ввода логина и пароля, поэтому и решил уже внести изменения в конфиг Сквида.

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