Dicas de Resolução de Problemas do SPNEGO

Você pode negociar e autenticar com segurança pedidos HTTP para recursos protegidos no WebSphere Application Server usando o mecanismo Simple and Protected GSS-API Negotiation Mechanism (SPNEGO). Pode ser que encontre problemas ao usar o Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) como o serviço de autenticação da web para o WebSphere Application Server.

Problemas do SPNEGO e Possíveis Soluções

Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
Pode ser que encontre os problemas a seguir ao usar o SPNEGO como o serviço de autenticação da web para o WebSphere Application Server. Soluções possíveis são fornecidas.

Não foi possível resolver o nome principal do Kerberos.

Se você não conseguir resolver o nome principal do Kerberos, como mostrado no seguinte exemplo:

[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Iniciar handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS      u No message text associated with key Error.getting.the.Token,
.GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
	major.string:.Invalid.credentials
	minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle 
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken   E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException, 
major code: 13, minor code: 0
	major string: Invalid credentials
	minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS      u No message text associated with key SpnegoTAI.exits.due.to.an.exception. 
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI     E SpnegoTAI exits due to an exception. 

inclua o endereço IP do servidor no arquivo host. Você também deve reiniciar o servidor de aplicativos para carregar o novo arquivo host.

O WebSphere Application Server e a hora no controlador de domínio do Active Directory (AD) não estão sincronizados dentro de 5 minutos

O arquivo trace.log para este problema é semelhante ao seguinte:
[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Iniciar handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI     > Server response token as follows...
0000:  6082014f 06062b06 01050502 a1820143     `?.O..+.....¡?.C
0010:  3082013f a0030a01 01a10b06 092a8648     0?.? ....¡...*?H
0020:  82f71201 0202a282 01290482 01256082     ?÷....¢?.).?.%`?
0030:  01210609 2a864886 f7120102 0203007e     .!..*?H?÷......~
0040:  82011030 82010ca0 03020105 a1030201     ?..0?.. ....¡...
0050:  1ea41118 0f323030 33313131 31303634     .¤...20031111064
0060:  3430395a a5050203 0a3548a6 03020125     409Z¥....5H¦...%
0070:  a90b1b09 4a57434d 442e434f 4daa2630     ©.....IBM.NETª&0
0080:  24a00302 0100a11d 301b1b04 48545450     $ ....¡.0...HTTP
0090:  1b136a6f 686e7761 6e67352e 6a77636d     ..backendrc4.ibm
00a0:  642e636f 6dab81ab 1b81a86f 72672e69     .net.«?«.?¨org.i
00b0:  6574662e 6a677373 2e475353 45786365     etf.jgss.GSSExce
00c0:  7074696f 6e2c206d 616a6f72 20636f64     ption, major cod
00d0:  653a2031 302c206d 696e6f72 20636f64     e: 10, minor cod
00e0:  653a2033 370a096d 616a6f72 20737472     e: 37..major str
00f0:  696e673a 20446566 65637469 76652074     ing: Defective t
0100:  6f6b656e 0a096d69 6e6f7220 73747269     oken..minor stri
0110:  6e673a20 436c6965 6e742074 696d6520     ng: Client time 
0120:  54756573 6461792c 204e6f76 656d6265     Tuesday, Novembe
0130:  72203131 2c203230 30332061 7420313a     r 11, 2003 at 1:
0140:  33353a30 3120414d 20746f6f 20736b65     35:01 AM too ske
0150:  776564                                  wed

Você pode corrigir este problema de uma das duas formas. A melhor maneira é sincronizar a hora do sistema do WebSphere em um período de 5 minutos da hora do servidor AD. Uma prática recomendada é utilizar um servidor de tempo para manter todos os sistemas sincronizados. Ou então, você pode também incluir ou ajustar o parâmetro clockskew no arquivo de configuração Kerberos. Observe que o padrão é 300 segundos (5 minutos).

Nenhum factory está disponível para criar um nome para o mecanismo 1.3.6.1.5.5.2

Se o arquivo systemout.log contiver um erro de exceção semelhante ao seguinte:
[4/8/05 22:51:24:542 EDT] 5003e481 SystemOut     O [JGSS_DBG_PROV] Provider IBMJGSSProvider versão 1.01 
does not support mech 1.3.6.1.5.5.2
[4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent E com.ibm.issw.spnegoTAI.ServerCredential initialize() SPNEGO014: 
Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, minor code: 0
	major string: Unsupported mechanism
	minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2
	at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
	at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36)
	at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217)
	at com.ibm.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:264) 
.
. 
Certifique-se de que o arquivo java.security contém o provedor de segurança IBMSPNEGO e está definido corretamente. Ele deve conter uma linha semelhante à seguinte:
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

Um erro Kerberos é recebido ao decodificar e verificar o token SPNEGO

Você pode receber o seguinte erro de exceção conforme a biblioteca do Java™ Generic Security Service (JGSS) tenta processar o token SPNEGO:
Erro ao autenticar solicitação. Relatando ao cliente
Código principal = 11, Código secundário = 31
org.ietf.jgss.GSSException, código principal: 11, código secundário: 31
	cadeia principal: Falha geral, não especificada no nível GSSAPI
	cadeia secundária: erro de Kerberos ao decodificar e verificar o token: com.ibm.security.krb5.internal.KrbException, código do status: 31
	mensagem: Falha na verificação de integridade no campo decriptografado
Este erro é causado quando o ticket é codificado usando uma chave e em seguida é feita uma tentativa de decodificar o ticket usando outra chave. Existem várias explicações possíveis para isso:
  • O arquivo keytab não foi copiado para a máquina servidor depois de ele ter sido gerado novamente.
  • A configuração Kerberos aponta para o arquivo keytab incorreto.
  • O SPN foi definido para o Active Directory mais de uma vez. Isso também é causado por outro ID do usuário com um SPN definido de maneira semelhante (com o mesmo nome ou pode ser diferente ao ter uma porta definida como parte do SPN).
  • Se o tipo de criptografia for DES, a senha associada ao ID de usuário do Serviço poderá existir apenas para a criptografia RC4-HMAC. Isso ocorre quando um novo ID de usuário é criado, o SPN é definido e o arquivo keytab for gerado com a opção +DesOnly. O ticket de serviço gerado para esse SPN é criptografado com um segredo que não corresponde com o localizado nesse keytab.
  • Uma versão antiga da ferramenta ktpass Microsoft está sendo usada. Versões antigas da ferramenta criam arquivos keytab que são incorretos e podem resultar neste erro. Se você estiver usando o Windows Server 2003 como seu controlador de Domínio, use a versão do ktpass.exe que faça parte do Windows Server 2003 SP 2 (especificamente, a versão 5.2.3790.2825).

Se o problema estiver com o arquivo keytab, corrija-o. Se o problema estiver com várias definições SPN, remova o SPN extra ou em conflito, confirme se o SPN não está mais registrado no AD e, em seguida, inclua o SPN novamente. Consulte Criação de um Nome do Principal Serviço Kerberos e um Arquivo keytab para obter mais informações. O Active Directory pode precisar ser procurado para as outras entradas nos SPNs definidos que confrontam com o SPN usando um navegador LDAP.

Para confirmar se o SPN não está registrado, o comando:
setspn –l userid
deve retornar com a resposta:
Não é possível localizar o ID do usuário da conta

Se o ID do usuário e o keytab forem para DES-CBC-MD5, depois que você criar o ID do usuário, altere a senha para o ID do usuário e depois crie o arquivo keytab. Se você estiver usando o Windows Server 2003, faça upgrade para a versão mais recente do ktpass.

A Conexão Única Não Ocorre

Quando o rastreio é ativado, a seguinte mensagem de erro pode ser exibida:
O cliente retornou um cabeçalho de autenticação não SPNEGO, SpnegoTAI existe
Uma possível razão para este erro é que o cliente está retornando uma resposta do gerenciador NT LAN (NTLM) para o desafio de autorização, não um token SPNEGO. Isso pode ocorrer devido a um ou mais dos seguintes problemas:
  • O cliente não foi configurado corretamente.
  • O cliente não está utilizando um navegador suportado. Por exemplo, os usuários do Internet Explorer 5.5 SP1 respondem com um cabeçalho de autenticação não-SPNEGO.
  • O usuário não efetuou login no domínio do AD ou em um domínio confiável, ou o cliente utilizado não suporta Autenticação Integrada com o Windows. Neste caso, o TAI está funcionando corretamente.
  • O usuário acessa um serviço definido na mesma máquina sobre a qual o cliente está sendo executado (o host local). O Internet Explorer resolve o nome do host da URL para http://localhost<someURL> ao invés do nome completo que é fornecido.
  • O SPN não está localizado no Active Directory. O SPN deve ser no formato HTTP/server.realm.com. O comando para incluir o SPN é:
    setspn –a HTTP/server.realm.com userid

    Se o SPN for definido incorretamente como HTTP/server.realm.com@REALM.COM com a adição de @REALM.COM, então exclua o usuário, redefina-o e, em seguida, redefina o SPN.

  • O nome do host é resolvido como um Alias DNS e não como um registro de HOST. Altere o nome do host para um registro HOST.
  • A conta no AD que mantém o ServicePrincipalName está um um domínio do AD que é remoto a partir do domínio do AD com o qual o usuário efetuou login e esses domínios não são do Windows 2003. Migre os domínios para o Windows 2003 ou limite o SSO para os usuários no mesmo domínio que o ID de usuário do ServicePrincipalName.

Não é possível usa a conexão (SSO) com a criptografia RC4-HMAC

Quando o rastreio é ativado, a seguinte mensagem de erro pode ser exibida:
com.ibm.security.krb5.internal.crypto.KrbCryptoException, código de status: 0
mensagem: Erro de soma de verificação; a soma de verificação recebida não corresponde à soma de verificação calculada
Algumas das possíveis causas para esse erro são:
  • A criptografia RC4-HMAC não é suportada com uma versão Windows anterior ao KDC 2003. Para confirmar que isto é um problema, examine o rastreio anterior em que a exceção é lançada. O conteúdo do ticket de entrada deve ser visível no rastreio. Enquanto ele estiver criptografado, o nome SPN para o serviço estará legível. Se um Windows versão anterior a 2003 KDC é usado, e o sistema estiver configurado para usar o RC4-HMAC, a sequência representando o chamado para userid@REALMinstead do HTTP/hostname.realm@REALM esperado é mostrado. Por exemplo, isso inicia o chamado recebido de uma versão do Windows anterior ao KDC 2003:
    0000: 01 00 6e 82 04 7f 30 82  04 7b a0 03 02 01 05 a1  ..n...0.........
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: a5 61 82 03 a1 30 82 03  9d a0 03 02 01 05 a1 0a  .a...0..........
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 18 30 16 a0 03  ...REALM.COM.0..
    0040: 02 01 01 a1 0f 30 0d 1b  0b 65 70 66 64 77 61 73  .....0...userid
    0050: 75 6e 69 74 a3 82 03 6e  30 82 03 6a a0 03 02 01  .a.f...n0..j....
    A região é REALM.COM. O nome do serviço é o ID do usuário. Um ticket corretamente formado para o mesmo SPN é:
    0000: 01 00 6e 82 04 56 30 82  04 52 a0 03 02 01 05 a1  ..n..V0..R......
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: 82 61 82 03 7e 30 82 03  7a a0 03 02 01 05 a1 0a  .a...0..z.......
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 2a 30 28 a0 03  ..REALM.COM.0...
    0040: 02 01 02 a1 21 30 1f 1b  04 48 54 54 50 1b 17 75  .....0...HTTP..u
    0050: 73 31 30 6b 65 70 66 77  61 73 73 30 31 2e 65 70  serid.realm.com.
    0060: 66 64 2e 6e 65 74 a3 82  03 39 30 82 03 35 a0 03  ...n.....90..5..

    Para corrigir o problema, utilize a criptografia DES exclusiva ou utilize um Windows Server 2003 para um KDC. Lembre-se de gerar novamente o SPN e o arquivo keytab.

  • A criptografia RC-HMAC não funciona quando o recurso de delegação de credencial for usado. Para saber se você está com esse problema, ative o rastreio JGSS e Krb5. Se o nome do SPN estiver correto, os seguintes tipos de mensagens poderão ser exibidos:
    [JGSS_DBG_CTX] Ticket decriptografado com sucesso
    [JGSS_DBG_CTX] Coloque as informações authz no cache
    [JGSS_DBG_CTX] Tipo de chave de sessão = rc4-hmac
    …
    [JGSS_DBG_CTX] Autenticador decriptografado com sucesso
    [JGSS_DBG_CTX] Erro na autenticação do pedido. Relatando ao cliente
    …
    Código principal = 11, Código secundário = 0
    org.ietf.jgss.GSSException, código principal: 11, código secundário: 0
    	cadeia principal: Falha geral, não especificada no nível GSSAPI
    	cadeia secundária: erro de Kerberos ao converter KRBCred: com.ibm.security.krb5.internal.crypto.KrbCryptoException, código do status: 0
    	mensagem: Erro de soma de verificação; a soma de verificação recebida não corresponde à soma de verificação calculada

    Isso indica que a credencial delegada contida no token SPNEGO não foi criptografada com a chave correta.

    Obtenha o APAR IY76826. Isso substitui ibmjgssprovider.jar pela versão que pode aceitar a credencial delegada criptografada RC4 definida pela Microsoft.

  • A senha usada ao gerar o arquivo keytab com ktpass não corresponde com a senha designada para a conta de serviço. Quando a senha for alterada, você deverá gerar novamente e redistribuir as chaves, mesmo se ela for redefinida para a mesma senha.
    Além disso, a ferramenta ktpass pode gerar um arquivo keytab com uma senha não correspondente nos seguintes casos:
    • Se a senha digitada no ktpass corresponder à senha para a conta de serviço, o arquivo keytab gerado funcionará.
    • Se a senha inserida no ktpass não corresponder à senha para a conta do serviço, e for menor do que 7 caracteres de comprimento, o ktpass parará e não produzirá um arquivo keytab.
    • Se a senha inserida no ktpass não corresponder à senha para a conta do serviço, e ela for maior do que 6 caracteres de comprimento, o ktpass não parará. Em vez disso, ele gerará um arquivo keytab contendo uma chave inválida. O uso desta chave para decriptografar um token de SPNEGO produz o erro de soma de verificação listado anteriormente.

    Use uma senha não nula para a conta de serviço e depois use essa senha ao chamar o ktpass.

  • O ktpass versão 1830 (nas Ferramentas de Suporte SP1) pode causar o erro em alguns ambientes do Windows 2003 Server. Use a versão da ferramenta SP2 para evitar o erro.

    Use a versão do ktpass Ferramentas de Suporte SP2 para gerar o arquivo keytab.

A delegação de credencial pode não funcionar devido a uma opção inválida no pedido de ticket.

Quando o rastreio é ativado, se a seguinte mensagem de erro for exibida:
com.ibm.security.krb5.KrbException, status code: 101 message: Opção inválida em solicitação de chamado

, o arquivo de configuração Kerberos não está configurado corretamente. Certifique-se de que nem renovável e nem passível de proxy estejam definidos como true.

Problemas ao acessar uma URL protegida por meio da conexão única (SSO) SPNEGO

Você pode receber a seguinte mensagem de erro ao acessar uma URL protegida por meio da SSO SPNEGO:
Solicitação Inválida

Seu navegador enviou um pedido que esse servidor não pôde entender.
O tamanho do cabeçalho do pedido excede o limite do servidor.

Autorização: Negociar YII……

Essa mensagem é gerada pelo Apache/IBM HTTP Server e indica que o cabeçalho de autorização que seu navegador retornou é muito grande. A cadeia longa que segue a palavra Negotiate é o token SPNEGO. Esse token SPNEGO é um wrapper do token Windows Kerberos. O Windows inclui as informações do PAC do usuário no token de Kerberos. Quanto mais grupos de segurança o usuário pertencer, mais informações PAC serão inseridas no token Kerberos e maior será o SPNEGO. O IBM HTTP Server 2.0 (além do Apache 2.0 e do IBM HTTP Server 6.0) limita o tamanho de qualquer cabeçalho HTTP aceitável para 8 K. Em domínios do Windows com muitos grupos e com participação do usuário em muitos grupos, o tamanho do token SPNEGO do usuário pode exceder o limite de 8 K.

Se possível, reduza o número de grupos de segurança do qual o usuário é membro. O IBM HTTP Server 2.0.47, correção acumulativa PK01070, permite tamanhos de cabeçalhos HTTP até e além do limite de 12 K da Microsoft.

Depois de aplicar a correção, você deve especificar o parâmetro LimitRequestFieldSize no arquivo httpd.conf para aumentar o tamanho de cabeçalhos permitidos a partir do padrão 8192.

Mesmo com o rastreio JGSS desativado, algumas mensagens KRB_DBG_KDC aparecem no SystemOut.log.

Embora a maior parte do rastreio JGSS seja controlada pela propriedade com.ibm.security.jgss.debug, um pequeno conjunto de mensagens é controlado pela propriedade com.ibm.security.krb5.Krb5Debug. O valor padrão da propriedade krb5 é emitir algumas mensagens para o SystemOut.log.

Para remover todas as mensagens de KRB_DBG_KDC messages do SystemOut.log, configure a propriedade JVM para -Dcom.ibm.security.krb5.Krb5Debug=none.

O ktpass não consegue localizar o ID do usuário

Ao usar o ktpass, você pode receber uma mensagem de erro semelhante à seguinte:
DsCrackNames retornou 0x2 na entrada do nome para server3
Falha ao obter o domínio de destino para um usuário especificado.

Em uma "floresta" do Active Directory, a consulta do ID do usuário pelo ktpass.exe não possui um nome de domínio padrão a ser usado. Isso não ocorre quando o controlador de domínio não estiver em uma floresta.

Para corrigir o problema, em vez de especificar a opção -mapUser userid, use -mapUser userid@domain no lugar. Por exemplo, especifique –mapUser server3@WIBM.NET.

A delegação da credencial não funciona para nenhum ID de usuário

Se no arquivo trace.log uma exceção de erro semelhante à seguinte for exibida:
> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() não é possível obter a Credencial Delegada
< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: Nenhuma credencial delegada foi localizada para o usuário: nauser@NA.IBM.NET

a conta de domínio em que o SPN está anexado não tem a propriedade "A conta é confiável para delegação" definida.

Para endereçar este problema, certifique-se de que a conta de domínio define a propriedade "A conta é confiável para delegação".

Um usuário é solicitado pelas credenciais mesmo se o navegador estiver configurado corretamente

Um usuário pode ter que fornecer as credenciais mesmo se o navegador estiver configurado corretamente. O TAI pode ter obtido as credenciais do usuário a partir do token SPNEGO e o usuário pode ter falhado ao efetuar login. No arquivo trace.log, um erro de exceção semelhante ao seguinte pode ser exibido:
< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Saída
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Handshake finished, enviando 200 :SC_OK
< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: Ocorreu uma exceção inesperada ao tentar criar um LoginContext. O alias LoginModule é system.WEB_INBOUND 
e a exceção é...
O ID do usuário (que é lansche no exemplo anterior) não existe no registro em uso pelo WebSphere. Esse problema pode ocorrer quando:
  • O registro usado pelo WebSphere não é o LDAP de domínio do Active Directory ou um Catálogo Global, mas é algum outro registro virtual (por exemplo, um registro de usuário customizado baseado em arquivo).
  • Uma implementação IClientToServerUseridMapper customizada que modifica o nome de usuário para o nome para o qual ele é mapeado não existe no registro.
  • O atributo para o qual é mapeado pela propriedade Filtro do Usuário LDAP do WebSphere está incorreto.

Para corrigir este problema, certifique-se de que o usuário que está sendo assertado para o WebSphere Application Server pelo TAI seja o registro WebSphere configurado.

Um usuário do cliente Novell não pode autenticar usando o SPNEGO

Se um usuário que está usando o cliente Novell não puder se autenticar usando SPNEGO, talvez ele receba uma mensagem "É recebido um token NTLM." .

O usuário pode ter efetuado login no Novell Client mas não efetuou um login no Kerberos Windows (o que pode ser confirmado usando o utilitário Kerbtray). Se um usuário tiver efetuado logon no domínio do Windows e tiver um ticket Kerberos, o usuário não poderá utilizar a autenticação SPNEGO.

Para corrigir este problema, remova o cliente Novell e use o login de domínio padrão do Windows.

Acessar sites SPNEGO por meio de alguns servidores de proxy de armazenamento em cache pode causar problemas de autenticação SPNEGO

Se você acessar sites SPNEGO por meio de alguns servidores de proxy de armazenamento em cache poderá impedir a autenticação usando o SPNEGO. A mensagem "Autenticação de SPNEGO não suportada neste cliente" pode ser exibida.

É possível que o proxy de armazenamento em cache esteja alterando o nome do host que retorna na resposta HTTP 401 Negociação de Autenticação.

Se você tiver este problema, entre em contato com o fornecedor do proxy para obter uma possível solução.

O software e os firewalls da Rede Privada Virtual (VPN) podem interferir com as operações SPNEGO

Você pode ter problemas com o software e os firewalls da VPN que podem interferir com as operações SPNEGO.

Para resolver esses problemas, entre em contato com os fornecedores da VPN ou do firewall para obter quais quer alterações que possam ser necessárias.

Possível problema de navegador ao acessar um aplicativo protegido pelo SPNEGO

Poderá ocorrer um problema de navegador se você efetuar logon na máquina de domínio usando uma senha (por exemplo, passwordA) e, em seguida, efetuar logon em uma segunda máquina de domínio alterando a senha original (por exemplo, você poderá alterar a senha na segunda máquina de domínio para passwordB).

Ao retornar para a máquina de domínio original, você poderá não obter uma resposta SPNEGO/Kerberos ou NTLM na solicitação de Negociação. Após duas tentativas, o navegador exibe uma mensagem de erro HTTP 404.

Para resolver esse problema, efetue logoff na máquina de domínio original e logon novamente com a nova senha (passwordB).

Possível Problema de Navegador com o Internet Explorer 6.0

Quando o WebSphere Application Server estiver configurado com o SPNEGO e o fallback estiver ativado para uma solicitação, o Internet Explorer 6.0 poderá falhar ao efetuar login nas páginas de login de formulário.

Para evitar esta situação, conclua uma das seguintes ações:
  • No painel Segurança Global > Autenticação da Web SPNEGO, cancele a seleção da opção Permitir fallback para o mecanismo de autenticação do aplicativo, se estiver selecionada.
  • Faça upgrade para o Internet Explorer Versão 7.0
  • Configure o Internet Explorer Versão 6.0 para usar uma página de autenticação diferente. O problema é com a autenticação básica versus a preferência de autenticação de login do formulário.

As páginas de erro definidas para as propriedades NTLMTokenReceivedPage ou SpnegoNotSupportedPage efetuam são carregadas a partir de uma URL http://

As páginas de erro definidas para as propriedades NTLMTokenReceivedPage ou SpnegoNotSupportedPage efetuam são carregadas a partir de uma URL http://. A seguinte mensagem de rastreio pode ser exibida:
Não foi possível carregar o conteúdo SPNEGO não suportado, indo para o conteúdo padrão. 
Exceção recebida: java.net.ProtocolException: Servidor redirecionado muitas vezes (20)

Este problema ocorre quando o arquivo carregado executa um redirecionamento automático. Não é possível para ambos carregar o arquivo a partir de um servidor da Web e também usar um redirecionamento automático.

Para resolver esse problema, carregue o conteúdo a partir de um arquivo:/// URL e não http:// URL.

Uma Tentativa de Conexão Única (SSO) do Navegador Cliente Falha ao Ser Autenticada

Pode ocorrer um erro quando uma tentativa de conexão única (SSO) do navegador cliente falha ao ser autenticada no WebSphere Application Server ao usar um token SPNEGO com o Microsoft Internet Security Acceleration Server

Quando o rastreio é ativado, existem as seguintes mensagens:
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
ENTRY Negotiate                                                  
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
Client sent back a non-SPNEGO authentication header

Quando existe um Microsoft Internet Security Acceleration Server (ISA) entre um navegador do cliente e o WebSphere Application Server, o ISA pode interceptar o cabeçalho de autenticação SPNEGO a partir do pedido do navegador do cliente. O ISA converte o identificador de objeto (OID) SPNEGO em um OID do Kerberos. A tentativa de autenticação no WebSphere Application Server falha porque o OID SPNEGO foi convertido e agora está ausente.

Para obter informações sobre como corrigir este problema, consulte o tópico "Os usuários não podem acessar um site da web que é publicado no ISA Server 2006 se o website aceitar apenas o pacote de autenticação do SPNEGO" no site de Suporte da Microsoft Corporation.

O Microsoft Windows Versão 7 e o Internet Explorer Versão 8 Desativam o Tipo de Criptografia DES Por Padrão

Se estiver usando o Microsoft Windows Versão 7 com o Internet Explorer Versão 8, e não conseguir obter a Conexão Única (SSO) SPNEGO para funcionar,isso pode ter ocorrido porque o Windows Versão 7 desativa o tipo de criptografia DES para o Kerberos, por padrão. Quando o rastreio é ativado, a seguinte mensagem é exibida:
O cliente retornou um cabeçalho de autenticação não-SPNEGO...

É recomendado alterar o tipo de criptografia para o RC4-HMAC ou para o AES. Se você ainda escolher usar o tipo de criptografia DES, entretanto, deverá consultar a documentação do Windows 7 para obter ajuda sobre como ativar o tipo de criptografia DES.

A seguir há um exemplo de como alterar seu tipo de criptografia a partir do DES para RC4:

  1. Certifique-se de que a conta do Microsoft Active Directory usada para mapear para o SPN não tenha a caixa de seleção Usar tipo de criptografia DES para essa conta marcada. Na máquina do Microsoft Active Directory:
    1. Clique em Iniciar- > Programas->Ferramentas Administrativas > Usuários e Computadores do Active Directory > Usuários.
    2. Clique na conta do Microsoft Active Directory usada para mapear para o SPN.
    3. Selecione a conta e, em seguida, certifique-se de que a caixa de seleção Usar tipo de criptografia DES para essa conta não esteja marcada.
  2. Reconfigure a senha para a conta do Microsoft Active Directory usada para mapear para o SPN. É possível reconfigurá-la para a mesma senha.
  3. Gere novamente o keytab com o tipo de criptografia RC4.
  4. Copie o novo arquivo keytab para os servidores WebSphere Application Server.
  5. Atualize os arquivos de configuração do Kerberos (krb5.ini/krb5.conf) para listar o RC4 primeiro para o atributos default_tkt_enctypes e default_tgs_enctypes.
    Exemplo
    default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    .
  6. Pare e reinicie todos os servidores WebSphere Application Server.
Nota: Se tiver mais de uma conta no Microsoft Active Directory que usa para mapear SPNs diferentes, então você deve repetir as etapas de 1 a 3 para cada SPN e para a mesclagem de todos os arquivos keytab.

Estabelecendo uma política irrestrita e, então, usando a criptografia de AES256

É possível usar a criptografia de AES256 depois de estabelecer uma política irrestrita. Execute as seguintes etapas:
  1. Pare o servidor de aplicativos.
  2. Faça download e instale os novos arquivos de política.
    Importante: O país de origem pode restringir a importação, posse, uso ou a reexportação para outro país de software de criptografia. Antes de fazer o download ou usar os arquivos de política irrestrita, você deve verificar as leis de seu país, os regulamentos e as políticas referentes à importação, à posse, ao e à nova exportação do software de criptografia para garantir a conformidade.
    1. Clique no nível apropriado do SDK.
    2. Role a página para baixo e, então, clique em Arquivos de políticas do IBM SDK. Os arquivos de políticas do JCE para o website do SDK serão exibidos.
    3. Clique em Efetuar Sign in e forneça o ID e a senha do IBM.com.
    4. Selecione Arquivos irrestritos de políticas do JCE para o SDK e clique em Continuar.
    5. Visualize a licença e clique em Concordo para continuar.
    6. Extraia os arquivos de políticas de jurisdição ilimitadas que estão empacotados no arquivo ZIP. O arquivo ZIP contém um arquivo US_export_policy.jar e um arquivo local_policy.jar.
    7. Na instalação do WebSphere Application Server, acesse o diretório $JAVA_HOME/lib/security e faça o backup dos arquivos US_export_policy.jar e local_policy.jar existentes.
    8. Substitua o arquivos US_export_policy.jar e local_policy.jar pelos dois arquivos transferidos por download do website IBM.com.
    Nota: Faça um backup antes de substituir esses arquivos. Um exemplo de um caminho que seria usado é WAS_Install/java/jre/lib/security .
  3. Inicie o servidor de aplicativos.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_SPNEGO_troubles
Nome do arquivo: rsec_SPNEGO_troubles.html