Miranda GSSAPI не работает с Prosody 0.9

[Oneiron]

Настроили GSSAPI, сервер - Debian 9, на нем prosody 0.9.12, с настроенным GSSAPI. Pidgin поверх GSSAPI подключается нормально.
Запускаем Miranda NG 0.9.95 x32, чистую, единственная настройка - указание сервера и "Доменный логин". Вываливается с ошибкой "аутентификация не прошла".
Нетлог прилагаю.
На сервере в логе следующее:

Spoiler

Code: [Select]

Aug 16 14:49:22 socket  debug   accepted incoming client connection from: 192.168.7.7 49525 to 5222
Aug 16 14:49:22 c2s56e47978     info    Client connected
Aug 16 14:49:22 c2s56e47978     debug   Client sent opening <stream:stream> to etpk.local
Aug 16 14:49:22 c2s56e47978     debug   Sent reply <stream:stream> to client
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Aug 16 14:49:22 socket  debug   try to start ssl at client id: 56cc06b0
Aug 16 14:49:22 socket  debug   ssl session delayed until writebuffer is empty...
Aug 16 14:49:22 c2s56e47978     debug   TLS negotiation started for c2s_unauthed...
Aug 16 14:49:22 socket  debug   starting ssl handshake after writing
Aug 16 14:49:22 socket  debug   starting handshake...
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:1
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:2
Aug 16 14:49:22 socket  debug   ssl handshake of client with id:table: 0x56cc06b0, attempt:3
Aug 16 14:49:22 socket  debug   ssl handshake done
Aug 16 14:49:22 c2s56e47978     debug   Client sent opening <stream:stream> to etpk.local
Aug 16 14:49:22 c2s56e47978     debug   Sent reply <stream:stream> to client
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <auth mechanism='GSS-SPNEGO' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>oYG1MIGyoAMKAQChCwYJKoZIgvcSAQICooGdBIGaY
IGXBgkqhkiG9xIBAgICAG+BhzCBhKADAgEFoQMCAQ+ieDB2oAMCARKibwRttFDq1Px+V3tQ/psGtl+h5RyTxfmLupJDroZeD7NxD1m9SK2pdlilEH22ME1L+3xb2HjDwLRmPhSGZ+lcFUXShAKt2QL1b9
g3ZcZnEdtZ4dJM4XHMUnki6TB07yYEDxkYFdfGuEk0kqE22h00dA==</challenge>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>BQQF/wAMAAAAAAAAAjKJaAEAAACzTjBB47RIgkhEf
ig=</challenge>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 sasl_cyrus      debug   Got SASL error condition -1: generic failure
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><undefined-condition/><text>generic failure
</text></failure>
Aug 16 14:49:22 c2s56e47978     debug   Received[c2s_unauthed]: <auth mechanism='GSSAPI' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Aug 16 14:49:22 sasl_cyrus      debug   Got SASL error condition -1: generic failure
Aug 16 14:49:22 etpk.local:saslauth       debug   sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><undefined-condition/><text>generic failure
</text></failure>
Aug 16 14:49:24 c2s56e47978     debug   Received </stream:stream>
Aug 16 14:49:24 c2s56e47978     info    c2s stream for <192.168.7.7> closed: session closed

[close]

Без SSL картина примерно та же самая. Сбой идет при проверке SASL. В чем может быть дело?

[ghazan]

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

в том смысле, что надо перейти на ночник (0.9.96)

[Oneiron]

Перешел на ночник. Лог приложен

[ghazan]

Перешел на ночник. Лог приложен

Печаль. Винда почему-то отвергает механизм GSS-SPNEGO на твоей машине.
Вопрос: если, к примеру, вообще вырубить его в капсах сервера и оставить только GSSAPI, оно будет работать или нет?
Сервер в данном случае конкретно неправ, что отвергает полностью попытку клиента сменить механизм на лету

[Oneiron]

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

Spoiler

VirtualHost "sn.local"
   enabled = true
   ssl = {
      key = "/etc/prosody/certs/sn.key";
      certificate = "/etc/prosody/certs/sn.crt";
      }
   authentication = "cyrus"
   cyrus_application_name = "xmpp"
   cyrus_server_fqdn = "apache.sn.local"
   cyrus_service_realm = "SN.LOCAL"
   c2s_require_encryption = true

[close]

А все колдунство с выбором конкретного механизма совершается уже внутри сервера.

[Magic]

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

Spoiler

VirtualHost "sn.local"
   enabled = true
   ssl = {
      key = "/etc/prosody/certs/sn.key";
      certificate = "/etc/prosody/certs/sn.crt";
      }
   authentication = "cyrus"
   cyrus_application_name = "xmpp"
   cyrus_server_fqdn = "apache.sn.local"
   cyrus_service_realm = "SN.LOCAL"
   c2s_require_encryption = true

[close]

А все колдунство с выбором конкретного механизма совершается уже внутри сервера.

В 0.10 можно выключать ненужные механизмы в этом конфиге.

[Oneiron]

Щас проверим

[Oneiron]

Если на сервере явно запретить GSS-SPNEGO, то все работает нормально
Спасибо за помощь

[ghazan]

Oneiron,

поставил себе убунту в виртуалку с prosody 0.12.
объяснишь, как туда вдуплить GSSAPI, чтобы проверить Negotiaion?

[ghazan]

всё, починилось. вопрос закрыт