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.
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.
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
LDAP (Lightweight
Directory Access Protocol) é um registro centralizado. A maioria dos registros
do sistema operacional local não é centralizada.
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]](../images/dist.gif)
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.
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.
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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.Um registro do sistema operacional
local é um registro centralizado em um sysplex.
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.
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]](../images/dist.gif)
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.
- Um privilégio necessário não foi retido pelo cliente.
- O acesso foi negado.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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]](../images/dist.gif)
Utilizando o Registro de Usuário do Domínio e o Registro de Sistema Operacional Local
- 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.
- ExemplosA 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
- MyDomain\user1
- MyDomain\user2
- MyDomain\group1
- MyDomain\group2
Aqui estão alguns cenários que assumem o conjunto de usuários e grupos anterior:- 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.
- 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.
- 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.
- 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).
- 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.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.
- Clique em
- 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.
- Em Propriedades Adicionais, clique em Propriedades Customizadas.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Usando Registros do Usuário do Sistema
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.
Somente o registro do usuário da máquina local é usado. O NIS - Network Information Service - (Páginas Amarelas) não é suportado.
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.
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.