Registros do Sistema Operacional Local

Com a implementação do registro para o sistema operacional local, o mecanismo de autenticação do WebSphere Application Server pode utilizar o banco de dados de contas do usuário do sistema operacional local.

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.

[IBM i]Se você quiser utilizar o registro do sistema operacional local para representar os proprietários que acessam os recursos do WebSphere Application Server, não precisará concluir nenhuma etapa especial de configuração de registro do usuário. O registro do sistema operacional local é utilizado para autenticação e autorização de usuários que acessam os recursos do WebSphere Application Server, mas não para usuários do WebSphere Application Server que acessam recursos do sistema operacional. O WebSphere Application Server não é executado sob o perfil de usuários do sistema operacional do Servidor de Aplicativos. Em vez disso, o WebSphere Application Server é executado sob o perfil do sistema operacional configurado pelo administrador do Servidor de Aplicativos.

[IBM i]Se você quiser autorizar um usuário para qualquer recurso do WebSphere Application Server, um perfil para esse usuário deverá existir no sistema operacional. Utilize o comando Criar Perfil do Usuário (CRTUSRPRF) para criar novos IDs de usuário que possam ser utilizados pelo WebSphere Application Server

[AIX Solaris HP-UX Linux Windows]LDAP (Lightweight Directory Access Protocol) é um registro centralizado. A maioria dos registros do sistema operacional local não é centralizada.

[AIX Solaris HP-UX Linux Windows]O WebSphere Application Server fornece implementações para o registro de domínio e de contas locais do Windows, além de implementações para os registros de contas do usuário do Linux, Solaris e AIX. O Windows Active Directory é suportado por meio da implementação do registro do usuário LDAP, abordada posteriormente.

[AIX Solaris HP-UX Linux Windows]
Nota: Para um Active Directory (controlador de domínio), os três escopos de grupo são Domain Local Group, Global Group e Universal Group. Para um Active Directory (Controlador de Domínio), os dois tipos de grupos são Segurança e Distribuição.
Quando um grupo é criado, o valor padrão é Global e o tipo padrão é Segurança. Com o suporte ao registro de domínio do Windows NT para controladores de domínio do Windows 2003, o WebSphere Application Server suporta apenas grupos globais que são o tipo de segurança. É recomendado usar o suporte ao registro do Active Directory em vez de um registro de domínio do Windows NT se você usar controladores de domínio do Windows 2003, pois o Active Directory suporta todos os escopos e tipos de grupos. O Active Directory suporta também um grupo aninhado que não é suportado pelo registro de domínio do Windows NT. O Active Directory é um registro de controle centralizado.
Nota: O WebSphere Application Server não precisa instalar o membro do domínio porque ele pode ser instalado em qualquer máquina de qualquer plataforma. Observe que a chamada nativa do domínio do Windows NT retorna o grupo de suporte somente sem um erro.

[AIX Solaris HP-UX Linux Windows][IBM i]Não utilize um registro do sistema operacional local em um ambiente do WebSphere Application Server no qual os servidores de aplicativos estejam dispersos em mais de uma máquina, visto que cada máquina tem seu próprio registro do usuário.

[AIX Solaris HP-UX Linux Windows]O registro de domínio do Windows e o NIS (Network Information Services) são exceções. O registro de domínio do Windows e o NIS (Network Information Services) são registros centralizados. O registro de domínio do Windows é suportado pelo WebSphere Application Server; entretanto, o NIS não é suportado.

[AIX Solaris HP-UX Linux Windows][IBM i]Como mencionado anteriormente, os IDs de acesso tirados do registro do usuário são utilizados durante as verificações de autorização. Como esses IDs em geral são identificadores exclusivos, eles variam de máquina a máquina mesmo que os usuários e senhas exatos existam em cada máquina.

[AIX Solaris HP-UX Linux Windows][IBM i]A autenticação por certificado de Web client não é suportada atualmente quando se utiliza o registro de usuários do sistema operacional local. Entretanto, a autenticação do certificado do cliente Java™ funciona com um registro do usuário operacional local. A autenticação do certificado do cliente Java mapeia o primeiro atributo do nome de domínio do certificado para o ID do usuário no registro do usuário.

[AIX Solaris HP-UX Linux Windows][IBM i]Mesmo que os certificados do cliente Java funcionem corretamente, o seguinte erro será exibido no arquivo SystemOut.log:

CWSCJ0337E: O método mapCertificate não é suportado

O erro é planejado para certificados de Web client; entretanto, também é exibido para certificados do cliente Java. Ignore esse erro para certificados do cliente Java.

[z/OS]Um registro do sistema operacional local é um registro centralizado em um sysplex.

[z/OS]O WebSphere Application Server utiliza as interfaces SAF (System Authorization Facility). As interfaces SAF são definidas pelo MVS para permitir que os aplicativos utilizem serviços de autorização do sistema ou registros para controlar o acesso a recursos, como conjuntos de dados e comandos do MVS. O SAF permite que pedidos de autorização de segurança sejam processados diretamente pelo RACF (Resource Access Control Facility) ou por um provedor de segurança do z/OS de terceiros. É necessário fornecer um mapeamento de uma identidade de registro do usuário para um ID do usuário do SAF, a menos que você selecione sistema operacional local como o registro do usuário. Para obter mais informações, consulte Módulos de Mapeamento Customizado do System Authorization Facility.

[z/OS]A autenticação por certificado de Web client é suportada quando se utiliza o registro de usuários do sistema operacional local. Certificados digitais podem ser mapeados para as identidades do MVS pelos Web clients e clientes Java quando selecionado o S.O. Local. Um filtro de nome de certificado pode ser utilizado para simplificar o mapeamento. Se você estiver utilizando o RACF como servidor de segurança, o comando RACDCERT MAP criará um perfil de recurso que mapeia várias identidades do usuário para um certificado digital a fim de simplificar a administração de certificados, preservar o espaço de armazenamento no banco de dados RACF, manter a prestação de contas ou a granularidade do controle de acesso.

[AIX Solaris HP-UX Linux Windows]

Privilégios Requeridos

O usuário que está executando o processo do WebSphere Application Server precisa de privilégio de sistema operacional suficiente para chamar a API (interface de programação de aplicativos) dos sistemas Windows para autenticar e obter informações de usuários e grupos do sistema operacional Windows. Esse usuário efetua login na máquina ou, se estiver em execução como um serviço, será o usuário Efetuar Logon Como. Dependendo da máquina e se a máquina é uma máquina independente ou uma máquina que é parte de um domínio ou é o controlador de domínio, os requisitos de acesso variam.

  • Para uma máquina independente, o usuário:
    • É um membro do grupo administrativo.
    • Possui o privilégio Agir como parte do sistema operacional.
    • Possui privilégio Logon como um serviço, se o servidor for executado como um serviço.
  • Para uma máquina que é um membro de um domínio, somente um usuário do domínio pode iniciar o processo de servidor e:
    • Possui o privilégio Agir como parte do sistema operacional na política de segurança do Domínio no controlador de domínio.
    • Possui o privilégio Agir como parte do sistema operacional na política de segurança Local na máquina local.
    • Possui o privilégio Logon como um serviço na máquina local, se o servidor for executado como um serviço.

      O usuário é um usuário do domínio e não um usuário local, o que implica que quando uma máquina faz parte de um domínio, somente um usuário do domínio pode iniciar o servidor.

  • Para uma máquina do controlador do domínio, o usuário:
    • É um membro dos grupos administrativos do domínio no controlador do domínio.
    • Possui o privilégio Agir como parte do sistema operacional na política de segurança do Domínio no controlador de domínio.
    • Possui o privilégio Logon como um serviço no controlador de domínio, se o servidor for executado como um serviço.
Se o usuário que está executando o servidor não tiver o privilégio necessário você poderá ver uma das seguintes mensagens de exceção nos arquivos de log:
  • Um privilégio necessário não foi retido pelo cliente.
  • O acesso foi negado.
Evitar Problemas Evitar Problemas: O servidor de aplicativos deve ser iniciado com privilégios de Administrador se você estiver usando um prompt de comandos. Inicie o servidor de aplicativos a partir de uma janela de prompt de comandos que for ativada, executando as seguintes ações:
  • Clique com o botão direito do mouse em um atalho de prompt de comandos.
  • Clique em Executar como administrador.

    Ao abrir a janela de prompt de comandos como Administrador, aparece um diálogo do sistema operacional perguntando se você deseja continuar. Clique em Continuar para prosseguir.

gotcha
[AIX Solaris HP-UX Linux Windows]

Registros do Usuário de Domínio e Local

Quando o WebSphere Application Server é iniciado, o processo de inicialização do tempo de execução de segurança tenta dinamicamente determinar se a máquina local é membro de um domínio do Windows. Se a máquina for parte de um domínio, por padrão, tanto os usuários ou grupos do registro local quanto os usuários ou grupos do registro do domínio podem ser utilizados para fins de autenticação e autorização com o registro do domínio tendo prioridade. A lista de usuários e grupos apresentada durante o mapeamento da função de segurança inclui os usuários e grupos do registro do usuário local e do registro do usuário do domínio. Os usuários e grupos podem ser distintos pelos nomes de host associados.

O WebSphere Application Server não suporta domínios confiáveis.

Se a máquina não for membro de um domínio do sistema Windows, o registro do usuário local para essa máquina será utilizado.

[AIX Solaris HP-UX Linux Windows]

Utilizando o Registro de Usuário do Domínio e o Registro de Sistema Operacional Local

Quando a máquina que hospeda o processo do WebSphere Application Server for membro de um domínio, os registros do usuário local e do domínio serão utilizados por padrão. A seção a seguir descreve mais sobre esse tópico e recomenda algumas boas práticas para evitar consequências desfavoráveis.
Nota: Embora esta seção não descreva diretamente as considerações do z/OS, esteja ciente de que as operações de segurança geral são afetadas pelo modo como você configura esses registros.
  • Práticas Recomendáveis
    • Em geral, se os registros locais e de domínio não contiverem usuários ou grupos comuns, é mais simples administrá-los e são eliminados os efeitos colaterais desfavoráveis. Se possível, conceda a usuários e a grupos acesso a funções de segurança exclusivas, incluindo o ID do servidor e funções administrativas. Neste caso, selecione os usuários e grupos do registro do usuário local ou do registro do usuário de domínio para serem mapeados para as funções.
    • Em casos em que existem os mesmos usuários ou grupos no registro do usuário local e no registro do usuário de domínio, é recomendável que pelo menos o ID do servidor e os usuários e grupos mapeados para as funções administrativas sejam exclusivos nos registros e existam apenas no domínio.
    • Se existir um conjunto de usuários comum, defina uma senha diferente para certificar-se de que o usuário apropriado seja autenticado.
  • Como funciona
    • Quando uma máquina faz parte de um domínio, o registro de usuários do domínio tem precedência sobre o registro de usuários local. Por exemplo, quando um usuário efetua login no sistema, o registro do usuário de domínio tenta autenticar o usuário primeiro. Se a autenticação falhar, o registro do usuário local será utilizado. Quando um usuário ou grupo é mapeado para uma função, as informações sobre o usuário ou grupo são obtidas primeiro do registro do usuário de domínio. Em caso de defeito, é tentado o registro do usuário local.
    • No entanto, quando um nome completo de usuário ou grupo, um com um nome de domínio ou de host anexado, é mapeado para uma função, apenas esse registro do usuário é utilizado para obter as informações. Utilize o console administrativo ou os scripts para obter os nomes de usuário e de grupo completos, que é a maneira recomendada para mapear usuários e grupos para as funções.
      Dica: Um usuário, Bob, em uma máquina no registro do usuário do O.S. local, por exemplo, não é igual ao usuário Bob em outra máquina no registro do usuário do domínio, por exemplo, porque o ID exclusivo de Bob, que é o id de segurança [SID] neste caso, é diferente em registros do usuário diferentes.
  • Exemplos
    A máquina MyMachine faz parte do domínio MyDomain. A máquina MyMachine contém os seguintes usuários e grupos:
    • MyMachine\user2
    • MyMachine\user3
    • MyMachine\group2
    O domínio MyDomain contém os seguintes usuários e grupos:
    • MyDomain\user1
    • MyDomain\user2
    • MyDomain\group1
    • MyDomain\group2
    Aqui estão alguns cenários que assumem o conjunto de usuários e grupos anterior:
    1. Quando user2 efetua login no sistema, o registro do usuário de domínio é utilizado para autenticação. Por exemplo, se a autenticação falhar porque a senha é diferente, será utilizado o registro do usuário local.
    2. Se o usuário MyMachine\user2 for mapeado para uma função, apenas o usuário user2 na máquina MyMachine terá acesso. Portanto, se a senha de user2 for igual nos registros do usuário local e de domínio, o usuário user2 não poderá acessar o recurso, porque esse usuário user2 sempre é autenticado utilizando o registro do usuário de domínio. Se os dois registros do usuário tiverem usuários comuns, será recomendável ter senhas diferentes.
    3. Se o grupo group2 for mapeado para uma função, apenas os usuários que são membros do grupo MyDomain\group2 poderão acessar o recurso, porque as informações sobre o group2 são obtidas primeiro do registro do usuário de domínio.
    4. Se o grupo MyMachine\group2 for mapeado para uma função, apenas os usuários que são membros do grupo MyMachine\group2 poderão acessar o recurso. Um grupo específico é mapeado para a função (MyMachine\group2 em vez de apenas group2).
    5. Utilize o usuário user3 ou o usuário MyMachine\user3 para fazer o mapeamento para uma função, porque o usuário user3 é exclusivo, já que existe apenas em um registro do usuário.

    Fazer a autorização com o registro de usuário do domínio primeiro pode causar problemas se um usuário existir nos registros de usuário do domínio e local com a mesma senha. A autorização baseada em função pode falhar nessa situação, porque o usuário é primeiramente autenticado no registro de usuário do domínio. Essa autenticação produz um ID de segurança de domínio exclusivo que é utilizado no WebSphere Application Server durante a verificação de autorização. No entanto, o registro de usuário local é utilizado para atribuição de função. O ID de segurança do domínio não corresponde ao ID de segurança exclusivo associado com a função. Para evitar esse problema, mapeie as funções de segurança para usuários do domínio ao invés de para usuários locais.

    Somente um repositório centralizado poderá ser utilizado se mais de um nó estiver envolvido. Este uso implica que apenas o registro do usuário de domínio pode ser utilizado, porque os IDs do usuário e do grupo (SIDs) exclusivos diferem em vários nós, conforme mencionado anteriormente.

Evitar Problemas Evitar Problemas: Antes deste fix pack, o registro do usuário do sistema operacional local em sistemas UNIX pode não localizar nomes de grupos se o registro contiver um grande número de grupos. Este problema surge a partir de uma limitação de memória e geralmente ocorre quando o registro contém várias centenas de grupos. Iniciando com este fix pack, o tamanho do buffer pode acomodar um grande número de grupos.gotcha
[AIX Solaris HP-UX Linux Windows][IBM i]

Utilizando o Registro do Usuário Local ou de Domínio

Se desejar acessar usuários e grupos a partir do registro do usuário local ou de domínio, em vez de ambos, defina a propriedade com.ibm.websphere.registry.UseRegistry. Essa propriedade pode ser definida como local ou domain. Quando esta propriedade estiver definida como local (sem distinção entre maiúsculas e minúsculas), apenas o registro do usuário local será utilizado. Quando esta propriedade estiver definida como domínio, (sem distinção entre maiúsculas e minúsculas), apenas o registro do usuário de domínio será utilizado.

Defina essa propriedade concluindo as etapas a seguir para acessar o painel Propriedades Customizadas no console administrativo:
  1. Clique em Segurança > Segurança Global
  2. No repositório Conta do Usuário, clique na lista drop-down Definições da Região Disponível, selecione Sistema Operacional Local e clique em Configurar.
  3. Em Propriedades Adicionais, clique em Propriedades Customizadas.
Também é possível utilizar wsadmin para configurar essa propriedade. Quando a propriedade é definida, o requisito de privilégio para o usuário que está executando o processo do produto não é alterado. Por exemplo, se essa propriedade for definida como local, o usuário que está executando o processo irá requerer o mesmo privilégio, como se a propriedade não estivesse definida.
[AIX Solaris HP-UX Linux Windows]

Usando Registros do Usuário do Sistema

As seguintes observações se aplicam quando você usa os registros do usuário do sistema:
  • [AIX][HP-UX][Linux][Solaris]Ao utilizar registros do usuário do sistema, o ID do processo que executa o processo do WebSphere Application Server precisará da autoridade raiz para chamar as APIs do sistema operacional local para autenticação e para obter informações sobre o usuário ou grupo.
  • [AIX][HP-UX][Linux][Solaris]Somente o registro do usuário da máquina local é usado. O NIS - Network Information Service - (Páginas Amarelas) não é suportado.
  • [HP-UX]Se você estiver usando o registro do usuário do sistema operacional local, o HP-UX deve ser configurado em modo não confiável. O modo confiável não será suportado se o registro de usuário do sistema operacional local estiver sendo utilizado.
  • [Linux][Solaris]

    Para que o registro do sistema operacional local do WebSphere Application Server funcione nas plataformas Linux e Solaris, um arquivo de senha shadow deve existir. O arquivo de senha sombra é denominado shadow e está localizado no diretório /etc. Se o arquivo shadow de senhas não existir, ocorrerá um erro depois de ativar a segurança administrativa e configurar o registro como sistema operacional local.

    Para criar o arquivo shadow, execute o comando pwconv (sem parâmetros). Esse comando cria um arquivo /etc/shadow a partir do arquivo /etc/passwd. Depois de criar o arquivo shadow, é possível ativar com êxito a segurança do sistema operacional local.


Ícone que indica o tipo de tópico Tópico de Conceito



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