Por que recebo uma GSSException ao usar o Active Directory SSO da Microsoft IE para um servidor Java?

Question

Eu estava construindo um sistema de autenticação de sinal único do Active Directory para aplicativos da Web Java (usando Spnego/Kerberos), e tudo funciona bem com o Firefox ou (supostamente) Safari, mas o Internet Explorer causa uma exceção:

GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)

Na verdade, eu pensei que o IE trabalhava antes que um patch do Windows fosse instalado.

Answer 1

Aparentemente, o Microsoft IE Patch KB974455 ativou a "proteção estendida" para autenticação integrada do Windows. Normalmente, com a autenticação Spnego/Kerberos, a máquina cliente adquire um ticket Kerberos/Active Directory para o servidor e apresenta esse ticket durante a negociação de autenticação HTTP. Até pelo menos Java 1.6, a biblioteca Java JGSS-API é capaz de interpretar a negociação Spnego/Kerberos e autenticar o bilhete.

Com o Proteção estendida (Veja também Proteção estendida para autenticação), Ou seja, adiciona um canal vinculado à negociação do Spnego; Em que dados em que a ligação do canal se baseia é atualmente desconhecida para mim, além do que o identificador de sessão SSL parece fazer parte dela. A biblioteca Java JGSS-API tenta validar a ligação do canal e o Canno sem os dados em que a ligação é baseada. Em seguida, ele lança a exceção de incompatibilidade de ligação do canal.

A questão resultou em algum Internet tráfego, Incluindo Sun Bug ID 6851973.

De acordo com comentários associados ao 6851973, RFC 4121, diz,

Se o chamador para gss_accept_sec_context [rfc2743] passar em GSS_C_NO_CHANNEL_BINDINGS [RFC2744] Como as ligações do canal, então o aceitador poderá ignorar as ligações de canal fornecidas pelo iniciador, o sucesso do iniciador, mesmo que o iniciador passasse no canal.

e "Todos os principais implementadores do KRB5 implementam esse 'May'". O JGSS parece estar exigindo que o aceitador forneça a ligação do canal se o iniciador estiver apresentando. Além disso, a correção está disponível no Java 7, construir 64 e estará de volta portada para Java 5 e 6, embora o Java 6U18 não parece tê -lo como relatado em 6851973.

Uma subida como visto em Proteção estendida para autenticação é definir o

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\SuppressExtendedProtection

Configuração do registro para 0x02. Isso desativa a proteção estendida.