Gerenciamento de acesso à intranet

Artigo
03/24/2009

Capítulo 4: Design da solução

Publicado em: 11 de maio de 2004 | Atualizado em: 26 de junho de 2006

O capítulo anterior levou em consideração os problemas de segurança, de tecnologia e de negócios de dois cenários de gerenciamento de acesso à intranet e listou os requisitos da solução de cada problema. A próxima parte do processo geral é o design da solução apropriada.

As seções a seguir neste capítulo apresentam um conceito de solução e seus pré-requisitos para cada cenário de gerenciamento de acesso à intranet. Após a conclusão do design, os capítulos subseqüentes do artigo descrevem como cada solução funciona.

Nesta página

Integração de estações de trabalho UNIX com o Active Directory
Integração da autenticação do SAP R/3 Application Server usando o protocolo Kerberos

Integração de estações de trabalho UNIX com o Active Directory

A integração de estações de trabalho UNIX com a plataforma de gerenciamento de identidades e acessos da Microsoft por meio do protocolo de autenticação Kerberos versão 5 envolve a transição de um ambiente NIS+ (Serviço de Informação de Rede) para outro baseado no serviço de diretório Microsoft® Active Directory®. Um ambiente baseado no Active Directory pode fornecer serviços de autenticação e autorização para as estações de trabalho UNIX, que atendem aos requisitos da Contoso para o gerenciamento centralizado das contas de usuário no diretório da intranet.

Conceito da solução

Uma análise dos recursos comuns de segurança do Active Directory e das estações de trabalho Solaris 9 na Contoso identificou o protocolo Kerberos versão 5 como a tecnologia ideal de integração das estações de trabalho UNIX da empresa com a plataforma de gerenciamento de identidades e acessos da Microsoft.

A solução é implementada por:

Modificação do arquivo pam.conf da estação de trabalho UNIX para especificar que o Kerberos deve tentar fazer logon e autenticação que usa aplicativos UNIX padrão, como Telnet e o protocolo FTP.
Configuração do arquivo krb5.conf para que a estação de trabalho UNIX use o KDC (Centro de distribuição de chaves) do domínio baseado no Windows® da Contoso.

A Figura 4.1 mostra um diagrama do conceito da solução.

Figura 4.1. O conceito da solução da integração de estações de trabalho UNIX com o Active Directory usando o protocolo Kerberos versão 5

Figura 4.1. O conceito da solução da integração de estações de trabalho UNIX com o Active Directory usando o protocolo Kerberos versão 5

A solução será implementada por meio da configuração das estações de trabalho Solaris e o Active Directory.

Pré-requisitos da solução

A Contoso implantou o Active Directory na intranet de acordo com o artigo "Plataforma e infra-estrutura" desta série.

Essa solução é habilitada pela alteração das definições de configuração UNIX e não adiciona ou altera nenhum aspecto da arquitetura de rede existente da Contoso. Por isso, não é fornecido um diagrama de arquitetura da solução nesse cenário.

Como a solução funciona

Após a solução ser implementada e validada conforme descrito no Capítulo 5, "Implementação da solução", e no Capítulo 6, "Teste da solução", os usuários da estação de trabalho UNIX efetuam logon no shell da estação de trabalho UNIX usando o nome de usuário e as credenciais do Active Directory. A solicitação de logon passa do shell para o PAM (Pluggable Authentication Module) e, eventualmente, para a biblioteca Kerberos, que inicia uma troca de mensagens entre a estação de trabalho e o Windows KDC (etapas de 1 a 4 da Figura 4.2). O resultado final dessa troca é um tíquete de serviço Kerberos, cuja biblioteca Kerberos da estação de trabalho UNIX pode descriptografar usando suas próprias chaves. A Figura 4.2 ilustra esse processo.

Dd459062.intr4-2(pt-br,TechNet.10).gif

Figura 4.2. Uma estação de trabalho UNIX que usa o protocolo Kerberos para autenticação no Active Directory

Exibir imagem em tamanho normal

A biblioteca Kerberos do sistema UNIX descriptografa este tíquete e extrai o UPN (nome principal do usuário) do usuário autenticado. Após a autenticação, o processo de logon usa as API (interfaces de programação de aplicativo) UNIX padrão para recuperar informações de autorização. Essas APIs são roteadas pelo NSS (name service switch), que depois usa o módulo nss_ldap para se conectar ao Active Directory e recuperar as informações solicitadas [como UID (Identificação de usuário) e GID (Identificação de grupo)]. Por fim, o processo de logon usa essas informações para estabelecer o contexto de segurança do usuário e inicia o shell do logon usando tal contexto.

A biblioteca Kerberos também processará mensagens de erro e de diretiva do KDC que retransmitem requisitos de diretiva de conta, como aqueles que avisam aos usuários que eles devem alterar suas senhas. O processo de logon, pelo PAM, tomará as ações necessárias para atender as diretivas.

Como resultado da autenticação do KDC integrado ao Active Directory, a estação de trabalho (por meio do PAM e da biblioteca Kerberos) fará o cache dos tíquetes Kerberos para o usuário. O cache do tíquete é o que permite ao usuário acessar com segurança os aplicativos habilitados pelo Kerberos da rede e contar com a experiência SSO (logon único) ao mesmo tempo.

Se o usuário do Active Directory tiver usado anteriormente a estação de trabalho UNIX que usou uma conta UNIX com o mesmo nome que a conta do Active Directory, as informações da conta do usuário UNIX, inclusive a senha, ainda poderão estar presentes no arquivo /etc/shadow. O arquivo /etc/shadow pode ser editado para remover as informações de senha do usuário porque não será mais usado para fazer logon na estação de trabalho UNIX.

Para obter mais detalhes sobre a troca de tíquetes Kerberos executada durante o logon do usuário, consulte o artigo do Microsoft Systems Journal, "Exploring Kerberos, the Protocol for Distributed Security in Windows 2000” (em inglês) no MSDN.

Extensão da solução

Para satisfazer plenamente os requisitos funcionais descritos no Capítulo 3, "Questões e requisitos", os atributos da conta do usuário UNIX, como UID e GID, devem ser mantidos no Active Directory, e não na estação de trabalho UNIX. Para atender a esses requisitos, a Contoso instalará a extensão do esquema do Active Directory fornecida com o Services for UNIX.

Para a estação de trabalho UNIX recuperar esses atributos de autorização, o NSS da estação de trabalho UNIX será configurado para usar LDAP e o Active Directory.

Para obter mais informações sobre a instalação da extensão do esquema do Microsoft Services for UNIX (SFU) do Active Directory e sobre a configuração do NSS para usar LDAP, consulte Microsoft Solution Guide for Windows Directory and Security Services for UNIX (em inglês).

Integração da autenticação do SAP R/3 Application Server usando o protocolo Kerberos

A solução da Contoso para integração do sistema SAP com a plataforma de gerenciamento de identidades e acessos da Microsoft envolve a reconfiguração do SAP Application Server e da GUI do cliente SAP para usar a SNC (Secure Network Communications) e o protocolo Kerberos. Essa abordagem fornecerá autenticação forte e dados de aplicativos seguros transmitidos pela rede.

Para obter mais informações sobre os recursos da SNC do sistema SAP R/3, consulte a página SAP Partners Integration & Certification: Integration Scenarios (em inglês).

Conceito da solução

Uma análise dos recursos comuns de segurança do Active Directory e do SAP Application Server identificou o protocolo Kerberos versão 5 como a tecnologia ideal para alcançar a integração e melhorar a segurança pelos motivos a seguir.

O protocolo Kerberos é um protocolo padronizado implementado nos produtos de servidor e cliente Windows, no Active Directory e no SAP R/3 Application Server.
O protocolo Kerberos especifica que o TGT adquirido durante o logon pode ser apresentado ao Windows KDC para gerar um tíquete de serviço. Depois, esse tíquete autentica os recursos e aplicativos de rede, como o SAP R/3 Application Server. Esse processo é transparente para o usuário, permitindo uma experiência SSO.
O protocolo Kerberos inclui a criação e o compartilhamento de chaves de sessão do cliente/servidor que permite uma criptografia forte dos dados subseqüentes do aplicativo transmitidos entre o cliente e o servidor.

A configuração do SAP R/3 Application Server e da GUI do cliente SAP para usar a SNC e o protocolo de autenticação Kerberos oferece uma autenticação segura dos usuários, enquanto protege os dados do aplicativo SAP na rede.

Além disso, a habilitação do sistema SAP para usar a autenticação Kerberos faz com que os usuários do SAP tenham uma experiência SSO no sistema SAP usando seu logon de rede do Active Directory. Como a solução elimina a necessidade do usuário apresentar uma senha SAP separada, a sobrecarga de gerenciamento de senhas (inclusive os custos de assistência técnica) é reduzida significativamente. A Figura 4.3 mostra o conceito da solução para esse cenário.

Figura 4.3. Integração do SAP R/3 Application Server com o Active Directory usando o protocolo Kerberos versão 5

Figura 4.3. Integração do SAP R/3 Application Server com o Active Directory usando o protocolo Kerberos versão 5

Pré-requisitos da solução

A Contoso implantou o Active Directory na intranet de acordo com o artigo "Plataforma e infra-estrutura" desta série.

Essa solução é habilitada pela alteração das definições de configuração UNIX e não adiciona ou altera nenhum aspecto da arquitetura de rede existente Contoso. Por isso, não é fornecido um diagrama de arquitetura da solução nesse cenário.

Como a solução funciona

Após a implementação e validação da solução, conforme descrito no Capítulo 5, "Implementação da solução", e no Capítulo 6, "Teste da solução", o usuário do SAP R/3 Application Server faz logon em sua estação de trabalho do Windows usando as credenciais do Active Directory. Depois, o usuário inicia a GUI SAP da área de trabalho e seleciona a opção de logon do protocolo Kerberos. A GUI SAP, por meio do invólucro do GSS-API (Generic Security Service API) do pacote de autenticação Kerberos, solicita um tíquete de serviço Kerberos (etapa 1) para o SAP R/3 Application Server usando as informações de configurações armazenadas no perfil GUI SAP. O pacote de autenticação Kerberos solicita um novo tíquete do controlador de domínio, se necessário, ou recupera um existente no cache do tíquete (etapa 2). A GUI SAP inicia uma conexão com o SAP R/3 Application Server e apresenta o tíquete, quando solicitado (etapa 3). A Figura 4.4 mostra essa seqüência de etapas em funcionamento.

Dd459062.intr4-4(pt-br,TechNet.10).gif

Figura 4.4. Cliente Windows autenticando o SAP Application Server

Exibir imagem em tamanho normal

O SAP R/3 Application Server recebe o tíquete de serviço e o valida invocando o pacote de autenticação Kerberos no servidor por meio do invólucro do GSS-API (etapa 4). Se o tíquete for validado, o SAP R/3 Application Server extrairá o UPN do usuário e mapeará suas informações em uma conta mantida pelo SAP R/3 Application Server (etapa 5). O usuário faz logon no SAP Application Server usando a conta mantida pelo sistema SAP e é estabelecida uma sessão criptografada entre o cliente e o servidor dos dados do aplicativo (etapa 6).

Como o usuário autenticou o SAP R/3 Application Server usando suas credenciais Kerberos padrão, uma experiência SSO foi alcançada pelo usuário.

Extensão da solução

Essa solução descreve como configurar manualmente cada conta SAP para usar uma conta do Active Directory para autenticação usando o protocolo Kerberos. Essa é uma solução suficiente para organizações que têm um número limitado de usuários SAP diretos, como um departamento de recursos humanos de médio porte.

Para ambientes com grande número de usuários SAP, é preferível uma abordagem de configuração e sincronização mais automatizada para o gerenciamento de contas SAP (incluindo mapeamentos de contas do Active Directory). Tal solução poderia ser criada usando o Microsoft Identity Integration Server 2003 e o Enterprise Edition com Service Pack 1 (MIIS 2003 com SP1).

Observação O design também poderia ser estendido para incluir estações de trabalho UNIX que usem o protocolo Kerberos versão 5 para autenticar o SAP R/3 Application Server, mas há alguns problemas que bloqueiam a adoção imediata de tal solução na Contoso. O principal motivo pelo qual a Contoso não está implementando essa solução atualmente é que o sistema SAP endossa somente algumas implementações de biblioteca GSS-API para a plataforma UNIX. A Contoso iniciará essa fase do projeto quando a lista de bibliotecas GSS-API endossadas pelo sistema SAP for expandida para incluir uma versão já implantada na Contoso, ou quando a empresa implantar uma versão aprovada diferente.