From: "Dmitry Akindinov" Received: by mx.demos.su (CommuniGate Pro PIPE 5.0.14) with PIPE id 548948814; Wed, 23 Oct 2013 17:49:27 +0400 X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2-st1.demos X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 3.3.2-st1.demos (2011-06-06) X-Spam-Report: -0.9 points, 5.0 required; * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.0 SPF_PASS SPF: sender matches SPF record * -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain * -0.5 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 AWL AWL: From: address is in the auto white-list Received: from mail.moscow.stalker.com ([89.175.185.228] verified) by mx.demos.su (CommuniGate Pro SMTP 5.0.14) with ESMTP id 548948812 for CGatePro@mx.ru; Wed, 23 Oct 2013 17:49:24 +0400 Received: from [10.1.1.104] (account dimak@mail.moscow.stalker.com [10.1.1.104] verified) by mail.moscow.stalker.com (CommuniGate Pro SMTP 6.0.8i) with ESMTPSA id 38697477 for CGatePro@mx.ru; Wed, 23 Oct 2013 17:49:19 +0400 Message-ID: <5267D3DD.6050305@stalker.com> Date: Wed, 23 Oct 2013 17:49:17 +0400 Organization: Stalker Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: CommuniGate Pro Russian Discussions Subject: Re: Re: [CGP] Kerberos debug? References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Здравствуйте, On 23:59, Victor Sudakov wrote: > Dmitry Akindinov wrote: >>>>>> Скажите просто, как дебаг GSSAPI включить в сервере. Это был основной >>>>>> вопрос, и даже в тему вынесен. >>>>> >>>>> Там нет отдельного лога, максимум что можно увидеть - низкоуровневый >>>>> обмен в логах протокола, в котором происходит аутентификация (IMAP, HTTP >>>>> и так далее). Там же будет ошибка о неверном ключе или о проблеме с >>>>> декодированием тикета. Но вряд ли этосильно поможет... >>> >>> А вот таки посмотрел wireshark-ом, запретив SSL. Ответ сервера: >>> >>> a0001 NO Kerberos: incorrect request format >>> >>> Дамп пакетов тут: http://zalil.ru/34788611 >>> Как проанализировать то, что идет после "AUTHENTICATE GSSAPI", и >>> почему оно incorrect. я не знаю. Не поможете? >> >> Ну там много нгде оно может сломаться... Сам запрос декодируется без >> ошибок, версия тикета правильная, имя домена и реалма в правильных >> местах. > > А не покажете dump в текстовом виде того, что удалось декодировать? > Есть у меня одно подозрение насчет principal-а. Строка, которой клиент отвечает на + сервера кодирует в base64 некоторые данные, упакованные с помощью BER. Собственно, в дампе echo -n строчка | base64 -d | hexdump -C видно и реалм и принципал. Для разбора ASN/BER структуры на данные можно натравить http://lapo.it/asn1js/ > Или подскажите, чем декодировать можно. Чтобы понять, на каком этапе ломается разбор данных сервером - только в отладчике. >> Дальше нужен кейтаб для расшифровки тикета и ошибка с форматом >> происходит скорее всего уже прирасшифровке тикета. > > Я бы предоставил кейтаб, если кто-то согласится взглянуть. Взглянуть можно. >> Но даже если мы найдём - где, вряд ли получится починить, если баг - >> плавающий. >> >> Проверьте, что на сервере, клиенте и Керберос контроллере часы >> синхронизованы. > > Везде ntpd работает. Сколько у CGP-шного кербероса предельный > clockskew, не милисекунды же? У клиента тоже? Просто подумалось, что если "то работает, то не работает", то дело может быть во времени, к кторому Керберос чуствителен. Но там, насколько помню, допускается расхождение часов до пяти минут. А какой керберос сервер используется? -- Best regards, Dmitry Akindinov