Problemas de Acesso Após Ativação da Segurança

Utilize estas informações se estiver enfrentando problemas de acesso depois de ativar a segurança.

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.

[AIX Solaris HP-UX Linux Windows][IBM i]Para obter dicas gerais sobre como diagnosticar e resolver os problemas relacionados à segurança, consulte o tópico Dicas de resolução de problemas de componentes de segurança.

[AIX Solaris HP-UX Linux Windows][IBM i]Caso não encontre um problema semelhante ao seu ou caso as informações fornecidas não resolvam seu problema, consulte a ajuda de Resolução de problemas da IBM.

Não Consigo Acessar o console administrativo Todo ou Parte Dele ou Utilizar a Ferramenta wsadmin Após Ativar a Segurança

  • [AIX Solaris HP-UX Linux Windows][IBM i]Se você não puder acessar o console administrativo ou visualizar e atualizar determinados objetos, consulte o log SystemOut do servidor de aplicativos que hospeda a página do console administrativo para obter uma mensagem de erro relacionada.
  • [z/OS]Se você não puder acessar o console administrativo ou visualizar e atualizar determinados objetos, consulte os logs do servidor de aplicativos que hospeda a página do console administrativo para obter uma mensagem de erro relacionada.
    Nota: Será necessário utilizar o console administrativo para concluir os dois itens a seguir. Se tiver problemas para acessar o console administrativo, será necessário desativar a segurança e reiniciar o console administrativo. Para desativar a segurança, digite o seguinte comando no prompt de comandos do sistema:
    wsadmin.sh -conntype NONE
    Quando o prompt de comandos do sistema for reexibido, digite:
    securityoff
    Reinicie o gerenciador de implementação depois de desativar a segurança.
  • Você pode não ter autorizado seu ID para tarefas administrativas. Esse problema é indicado por erros como:
    • [8/2/02 10:36:49:722 CDT] 4365c0d9 RoleBasedAuth A CWSCJ0305A: Falha na verificação de autorização baseada em função para o nome de segurança MyServer/myUserId, accessId MyServer/S-1-5-21-882015564-4266526380-2569651501-1005 ao chamar o método getProcessType no Servidor do recurso e Servidor do módulo.
    • Mensagem de exceção: "CWWMN0022E: Acesso negado para a operação getProcessType no Servidor MBean"
    • Ao executar o comando: wsadmin -username j2ee -password j2ee: CWWAX7246E: Não é possível estabelecer uma conexão "SOAP" com o host "BIRKT20" devido a uma falha de autenticação. Verifique se o usuário e a senha estejam corretos na linha de comandos ou em um arquivo de propriedades.
    Para conceder autoridade administrativa a um ID, a partir do console administrativo, clique em Administração do Sistema > Usuários do Console e valide se o ID é um membro. Se o ID não for um membro, inclua o ID com, pelo menos, privilégios de acesso ao monitor, para acesso de somente leitura.
  • Verifique se a funcionalidade de aplicativo confiável está ativada. A funcionalidade de aplicativo confiável está ativada se o WebSphere Application Server tiver acesso SAF de READ para a classe RACF de FACILITY, e perfil BBO.TRUSTEDAPPS.<nome abreviado da célula>.<nome abreviado do cluster>.
[z/OS]Lembre-se: Você poderia encontrar problemas de sincronização se estiver em um ambiente WebSphere Application Server, Network Deployment e salvar suas configurações de segurança e o agente do nó estiver inativo.

Não é Possível Acessar uma Página da Web após Ativar a Segurança

Quando recursos protegidos não estão acessíveis, as causas prováveis incluem:
  • Erros de autenticação - a segurança do WebSphere Application Server não pode identificar o ID da pessoa ou do processo. Sintomas de erros de autenticação incluem:
    Em um navegador Netscape:
    • A mensagem Falha na autorização. Tentar novamente? é exibida depois de uma tentativa para efetuar login.
    • Aceita qualquer número de novas tentativas de efetuar login e exibe a mensagem Erro 401 quando se clica em Cancelar para parar as novas tentativas.
    • Uma mensagem típica de navegador é exibida: Error 401: Basic realm='Default Realm'.
    Em um navegador Internet Explorer:
    • O prompt de login é exibido novamente após uma tentativa de efetuar login.
    • Permite três tentativas de repetir o login.
    • Exibe a mensagem Erro 401 após três novas tentativas malsucedidas.
  • Erros de autorização - A função de segurança identificou a pessoa ou o processo solicitante como não autorizado para acessar o recurso protegido. Sintomas de erros de autorização incluem:
    • Navegador Netscape: A mensagem de erro "Error 403: AuthorizationFailed" é exibida.
    • Internet Explorer:
      • A mensagem "Você não está autorizado a visualizar esta página" é exibida.
      • O erro "HTTP 403 Forbidden" também é exibido.
  • Erros SSL - a segurança do WebSphere Application Server utiliza a tecnologia Secure Sockets Layer (SSL) internamente para garantir e criptografar sua própria comunicação, e a configuração incorreta das configurações SSL internas pode causar problemas. Além disso, você pode ter ativado a criptografia SSL para seu próprio aplicativo da Web ou tráfego do cliente do enterprise bean que, se corretamente configurado, pode causar problemas independentemente da segurança do WebSphere Application Server estar ativada.
    • Os problemas relacionados com SSL são em geral indicados pela mensagem de erro que contém uma instrução como: ERRO: Não foi possível obter o contexto inicial ou pesquisar o contexto inicial. Saindo. seguido por javax.net.ssl.SSLHandshakeException

O Cliente Não Pode Acessar um Bean Corporativo Depois de Ativar a Segurança

Se o acesso do cliente a um enterprise bean falhar depois da segurança ser ativada:
  • Reveja as etapas para fazer a segurança e conceder acesso aos recursos.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Navegue nos logs da JVM do servidor para obter erros relacionados ao acesso e à segurança do bean corporativo. Consulte os erros na tabela de mensagens.

    [z/OS]Navegue nos registros do servidor para obter erros relacionados ao acesso e segurança do bean corporativo. Consulte os erros na tabela de mensagens.

    Erros semelhantes a Falha na autorização para /UNAUTHENTICATED ao chamar resource securityName:/UNAUTHENTICATED;accessId:UNAUTHENTICATED não concedida a nenhuma das funções requeridas roles indicam que:
    • Um servlet ou uma JSP (JavaServer Pages) desprotegida acessou um enterprise bean protegido. Quando um servlet não protegido é acessado, não é solicitado que o usuário efetue login e o servlet é executado como UNAUTHENTICATED. Quando o servlet realiza uma chamada para um enterprise bean protegido, o servlet falha.

      Para resolver esse problema, proteja o servlet que acessa o bean corporativo protegido. Verifique se a propriedade runAs do servlet está configurada para um ID que possa acessar o enterprise bean.

    • Um programa cliente Java não autenticado está acessando um recurso enterprise bean que está protegido. Essa situação poderá acontecer se o sinalizador securityEnabled do arquivo lido pelo arquivo de propriedades sas.client.props, utilizado pelo programa cliente, não estiver configurado como true.

      Para resolver esse problema, certifique-se de que o arquivo sas.client.props no lado do cliente tenha seu sinalizador securityEnabled definido para true.

    Erros semelhantes a Falha na autorização para valid_user ao chamar o recurso securityName:/username;accessId:xxxxxx não concedido a nenhuma das funções requeridas indicam que um cliente tentou acessar um recurso de enterprise bean protegido e o ID do usuário fornecido não possui as funções necessárias designadas para esse enterprise bean.
    • Verifique se as funções necessárias do recurso do enterprise bean são acessadas. Visualize as funções obrigatórias para o recurso do enterprise bean no descritor de implementação do recurso da Web.
    • Verifique a tabela de autorização e certifique-se de que o usuário, ou o grupo ao qual o usuário pertence, tenha uma das funções requeridas atribuída. Você pode visualizar a tabela de autorização do aplicativo que contém o recurso do enterprise bean utilizando o console administrativo.
  • [z/OS]Se estiver utilizando a Autorização SAF (System Authorization Facility) e S.O Local, verifique a configuração das EJBROLEs do SAF. Mais especificamente, verifique se
    • a classe EJBROLE é ativada.
    • A função é definida como SAF.
    • O userid é permitido para a função.
    • A classe é atualizada depois da operação de permissão.
[AIX Solaris HP-UX Linux Windows][IBM i]Se exceções org.omg.CORBA.NO_PERMISSION ocorrerem ao efetuar logon programaticamente para acessar um bean corporativo protegido, uma exceção de autenticação ocorreu no servidor. Geralmente, a exceção de CORBA é acionada por uma com.ibm.WebSphereSecurity.AuthenticationFailedException subjacente. Para determinar a causa real da exceção de autenticação, examine toda a pilha de rastreio:
  1. Inicie visualizando o texto a seguir WSSecurityContext.acceptSecContext(), reason: na exceção. Geralmente, esse texto descreve a falha sem analises adicionais.
  2. Se essa ação não descrever o problema, procure o código secundário CORBA (Common Object Request Broker Architecture). Os código estão listados no artigo denominado Resolução de Problemas da Referência dos Componentes de Segurança.
    Por exemplo, a exceção a seguir indica um código secundário CORBA de 49424300. A explicação desse erro na tabela de códigos secundários CORBA é a seguinte:
    authentication failed error
    Nesse caso, é provável que o ID de usuário ou a senha fornecida pelo programa cliente não seja válida:
    org.omg.CORBA.NO_PERMISSION: Capturada WSSecurityContextException em 
    WSSecurityContext.acceptSecContext(), razão: Código Principal[0] Código Secundário[0] 
    Mensagem[ Exceção capturada ao chamar authenticateBasicAuthData a partir de SecurityServer 
    para usuário jdoe. Razão: com.ibm.WebSphereSecurity.AuthenticationFailedException] 
    código secundário: 49424300 concluído: 
    No at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code 
    (PrincipalAuthFailReason.java:83)

[AIX Solaris HP-UX Linux Windows][IBM i]Uma exceção CORBA INITIALIZE com o erro CWWSA1477W: SECURITY CLIENT/SERVER CONFIGURATION MISMATCH incorporado, é recebida pelo programa cliente a partir do servidor.

[AIX Solaris HP-UX Linux Windows][IBM i]Esse erro indica que a configuração de segurança do servidor difere do cliente de alguma forma importante. A mensagens de exceção completa lista as incompatibilidades específicas. Por exemplo, a exceção a seguir lista três erros:
Exceção recebida: org.omg.CORBA.INITIALIZE: 
CWWSA1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: 
A configuração de segurança do cliente (sas.client.props ou configurações de saída no 
console administrativo) não suporta a configuração de segurança do servidor pelos 
seguintes motivos: 
ERRO 1: CWWSA0607E: O cliente requer Confidencialidade SSL, mas o servidor não a 
         suporta. 
ERRO 2: CWWSA0610E: O servidor requer Integridade SSL, mas o cliente não a 
         suporta. 
ERRO 3: CWWSA0612E: O cliente requer cliente (por exemplo, ID do usuário/senha ou token), 
         mas o servidor não suporta. 
     código secundário: 0 
     concluído: No at 
com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey
(SecurityConnectionInterceptor.java:1770)

[AIX Solaris HP-UX Linux Windows][IBM i]Em geral, a resolução para o problema requer uma alteração na configuração da segurança do cliente ou do servidor. Para determinar qual definição de configuração está envolvida, consulte o texto que segue a mensagem de erro CWWSA. Para obter explicações e instruções mais detalhadas, consulte a referência da mensagem, selecionando a visualização Referência da navegação do centro de informações e expandindo Mensagens na árvore de navegação.

[AIX Solaris HP-UX Linux Windows][IBM i]Nesses casos específicos:
  • No ERRO 1, o cliente exige confidencialidade SSL mas o servidor não suporta confidencialidade SSL. Resolva essa incompatibilidade de uma das seguintes formas. Atualize o servidor para suportar confidencialidade SSL ou atualize o cliente para não exigir mais confidencialidade.
  • No ERRO 2, o servidor exige integridade SSL mas o cliente não suporta integridade SSL. Resolva essa incompatibilidade de uma das seguintes formas. Atualize o servidor para suportar integridade SSL ou atualize o cliente para não exigir mais integridade.
  • No ERRO 3, o cliente exige autenticação do cliente através de um id de usuário e senha, mas o servidor não suporta esse tipo de autenticação de cliente. É necessário alterar a configuração do cliente ou do servidor. Para alterar a configuração cliente, modifique o arquivo SAS.CLIENT.PROPS para um cliente puro ou altere a configuração de saída do servidor no console administrativo de Segurança. Para alterar a configuração do servidor de destino, modifique a configuração de entrada no console administrativo de Segurança.

[AIX Solaris HP-UX Linux Windows][IBM i]De forma semelhante, uma exceção como org.omg.CORBA.INITIALIZE: JSAS0477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: aparecendo em um servidor tentando efetuar uma solicitação do cliente indica uma incompatibilidade da configuração de segurança entre cliente e servidor. As etapas para resolver o problema são as mesmas das exceções JSAS1477W descritas anteriormente.

O programa cliente nunca é avisado ao acessar um bean corporativo seguro

Embora pareça que a segurança está ativada e um bean corporativo está protegido, pode haver ocasiões nas quais o cliente executa o método remoto sem gerar aviso para o usuário. Se o método remoto estiver protegido, o resultado é uma falha de autorização. Caso o contrário, execute o método como um usuário não autenticado.

As possíveis razões para esse problema incluem:
  • O servidor com o qual você está se comunicando pode não ter segurança ativada. Verifique com o administrador do WebSphere Application Server para assegurar que a segurança do servidor esteja ativada. Acesse as configurações de segurança na seção Segurança do console administrativo.
  • A segurança do cliente não está ativada no arquivo sas.client.props. Edite o arquivo sas.client.props para garantir que a propriedade com.ibm.CORBA.securityEnabled esteja configurada como true.
  • O cliente não possui um ConfigURL especificado. Verifique se a propriedade com.ibm.CORBA.ConfigURL está especificada na linha de comandos do cliente Java, utilizando o parâmetro -D.
  • A ConfigURL especificada não possui uma sintaxe de URL válida, ou não foi possível encontrar o sas.client.props para o qual ela aponta. Verifique se a propriedade com.ibm.CORBA.ConfigURL é válida. Verifique a documentação Java para obter uma descrição de regras de formatação URL. Além disso, valide se o arquivo existe no caminho especificado.

    [AIX Solaris HP-UX Linux Windows][Windows]Um exemplo de uma propriedade válida é C:/WebSphere/AppServer/properties/sas.client.props.

  • [AIX Solaris HP-UX Linux Windows][IBM i]A configuração do cliente não suporta autenticação de cliente em camada de mensagens (ID de usuário e senha). Verifique se o arquivo sas.client.props possui uma das seguintes propriedades definidas para true:
    • com.ibm.CSI.performClientAuthenticationSupported=true
    • com.ibm.CSI.performClientAuthenticationRequired=true
  • [AIX Solaris HP-UX Linux Windows][IBM i]A configuração do servidor não suporta autenticação de cliente em camada de mensagens, composta de um ID de usuário e senha. Verifique com o administrador do WebSphere Application Server para verificar se a autenticação de ID do usuário e senha está especificada para a configuração de entrada do servidor dentro da seção de Administração do Sistema da ferramenta de administração do console.

Não é possível parar um servidor de aplicativos, um gerenciador de nós ou um nó depois de ativar a segurança

Se você utilizar os utilitários de linha de comandos para parar os processos do WebSphere Application Server, aplique os parâmetros adicionais após ativar a segurança para fornecer informações de autenticação e autorização.

[AIX Solaris HP-UX Linux Windows][IBM i]Utilize o comando ./stopServer -help para exibir os parâmetros a serem utilizados.

[AIX Solaris HP-UX Linux Windows][IBM i]Utilize as opções de comando a seguir após ativar a segurança:
  • ./stopServer serverName -username name -password password
  • ./stopNode -username name -password password
  • ./stopManager -username name -password password

[AIX Solaris HP-UX Linux Windows]Se você utilizar o painel de serviço do Windows ou o comando net stop para parar os processos do WebSphere Application Server e o serviço não puder ser interrompido, atualize o serviço Servidor de Aplicativos existente utilizando argumentos adicionais de parada. Pode ser necessário encerrar o processo do servidor do Gerenciador de Tarefas antes de atualizar o serviço. Use os parâmetros -stopArgs e -encodeParams para atualizar o serviço, como descrito no exemplo "Atualizando um serviço de servidor de aplicativos existente" no artigo Comando WASService.

Após Ativar a Conexão Única, Não É Possível Efetuar Logon no Console Administrativo

Este problema ocorre quando SSO (conexão única) está ativada e você tenta acessar o console administrativo usando o nome abreviado do servidor, por exemplo, http://myserver:port_number/ibm/console. O servidor aceita o seu ID de usuário e senha, mas o retorna para a página de logon em vez de para o console administrativo.

Para corrigir esse problema, use o nome completo do host do servidor, por exemplo, http://myserver.mynetwork.mycompany.com:9060/ibm/console.

SECJ0306E: nenhuma credencial existente ou recebida no encadeamento.

A mensagem a seguir é exibida quando um ou mais nós dentro da célula não foram sincronizados durante a configuração:
SECJ0306E: Não existe nenhuma credencial recebida ou de chamada no encadeamento A verificação de autorização baseada na 
função não terá um accessId do responsável pela chamada a ser verificado. Os parâmetros 
são:
método de verificação de acesso getServerConfig no recurso
FileTransferServer e módulo 
FileTransferServer. O rastreio de pilha é
java.lang.Exception: a chamada e as credenciais 
recebidas são nulas. 

Verifique se cada um dos nós está sincronizado e reinicialize o gerenciador de implementação.

O erro de nome NotFoundException ocorre ao se conectar inicialmente aos repositórios federados

[AIX Solaris HP-UX Linux Windows][IBM i]Quando o servidor tenta uma consulta indireta no nome java:comp/env/ds/wimDS e faz sua conexão EJB inicial com os repositórios federados, a mensagem de erro a seguir é exibida no arquivo SystemOut.log:

[z/OS]Quando o servidor tenta uma consulta indireta no nome java:comp/env/ds/wimDS e faz sua conexão EJB inicial com os repositórios federados, a seguinte mensagem de erro é exibida na saída do log de tarefas apropriado:

NMSV0612W: Uma Exceção NameNotFound
[z/OS]Nota: Como o arquivo SystemOut.log não existe no sistema operacional z/OS, verifique a saída do log de tarefa apropriado no sistema operacional z/OS.

O erro NameNotFoundException é causado pela definição de ligação de referência para o nome JNDI (Java Naming and Directory interface) de jdbc/wimDS no nome ibm-ejb-jar-bnd.xmi. Você pode ignorar essa mensagem de aviso. A mensagem não é exibida quando o repositório do banco de dados wimDS é configurado.

Configurações suportadas Configurações suportadas: Para arquivos de extensão e de ligação IBM, a extensão do nome do arquivo .xmi ou .xml é diferente dependendo de você estar utilizando um aplicativo pré-Java EE 5 ou um módulo ou um aplicativo ou módulo Java EE 5 ou posterior. Um arquivo de extensão ou de ligação IBM é denominado ibm-*-ext.xmi ou ibm-*-bnd.xmi em que * é o tipo de arquivo de extensão ou de ligação como app, aplicativo, ejb-jar ou web. As seguintes condições se aplicam:
  • Para um aplicativo ou módulo que usa um Java EE versão anterior à versão 5, a extensão do arquivo deverá ser .xmi.
  • Para um aplicativo ou módulo que usa Java EE 5 ou posterior, a extensão do arquivo deve ser .xml. Se os arquivos .xmi forem incluídos no aplicativo ou módulo, o produto ignorará os arquivos .xmi.

No entanto, um módulo Java EE 5 ou posterior pode existir dentro de um aplicativo que inclui arquivos pré-Java EE 5 e usa a extensão do nome do arquivo .xmi.

Os arquivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, e ibm-portlet-ext.xmi continuam a usar as extensões de arquivo .xmi.

sptcfg

Í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=rtrb_secprobs
Nome do arquivo: rtrb_secprobs.html