Gerenciamento de acesso à intranet

  • Artigo

Capítulo 2: Abordagens para o gerenciamento de acesso à intranet

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

Existem várias maneiras de melhorar o gerenciamento de acesso à intranet de uma organização que utiliza as tecnologias da Microsoft. Uma abordagem que migra plataformas e aplicativos para utilizarem serviços comuns de autenticação e autorização pode ativar o SSO para usuários, melhorar a auditoria de segurança, aproveitar as relações de confiança existentes, consolidar sua infra-estrutura, reduzir a sobrecarga de gerenciamento e melhorar a segurança da rede.

Entretanto, nem todas as abordagens são iguais em termos de eficiência, facilidade de implementação ou segurança. As abordagens, por ordem de preferência, incluem:

  • Integração de aplicativo com os serviços de segurança do Windows. Essa abordagem desenvolve e migra aplicativos para usarem os serviços de segurança da plataforma Microsoft® Windows®, que inclui autenticação e autorização. A integração com os serviços de segurança do Windows reduz os custos de desenvolvimento de aplicativo e permite a utilização das capacidades SSO, de confiabilidade e auditoria de segurança do sistema operacional Windows.

  • Integração de plataforma com os serviços de segurança e diretório do Windows. Esta abordagem configura outras plataformas para uso dos serviços de diretório e segurança suportados pelo Microsoft Active Directory®, e permite interoperabilidade entre plataformas e administração reduzida.

  • Integração de aplicativo com os serviços de diretório do Windows. O desenvolvimento e a migração de aplicativos para usarem os protocolos de diretório padrão suportados pelo Active Directory para autenticação e autorização permitem a consolidação do armazenamento de identidades.

  • Integração indireta por meio do mapeamento de credenciais. Quando a integração direta de um aplicativo ou plataforma não é possível, o mapeamento de credenciais, também conhecido como ESSO (acesso único empresarial) pode oferecer uma experiência SSO aos usuários.

  • Contas e senhas sincronizadas. Quando nenhuma das outras opções estiver disponível e os riscos de segurança forem considerados, a utilização de credenciais comuns entre diferentes aplicativos e plataformas pode reduzir a confusão do usuário.

Uma abordagem menos usada pode ser escolhida por causa das capacidades de um sistema host, da capacidade de alterar um aplicativo ou do retorno do investimento (ROI) esperado para a implementação da solução.

Nesta página

Integração de aplicativo com os serviços de segurança do Windows
Integração de plataforma com os serviços de segurança e diretórios do Windows
Integração de aplicativo com os serviços de diretório do Windows
Integração indireta por meio do mapeamento de credenciais
Contas e senhas sincronizadas

Integração de aplicativo com os serviços de segurança do Windows

A integração de aplicativos com os serviços de segurança do Windows (também chamados aplicativos integrados do Windows) oferece os seguintes benefícios:

  • SSO para clientes Windows.

  • Maior segurança para os dados de aplicativo transmitidos pela rede.

  • Gerenciamento mais eficiente das identidades digitais do Active Directory.

  • Capacidade de estabelecer grupos de segurança no nível empresarial e controle de acesso baseado em funções para vários aplicativos.

  • Uma variedade maior de serviços de autenticação e autorização por meio de relações de confiança com sobrecarga de gerenciamento limitada.

  • Log integrado de eventos de segurança.

Esta seção descreve vários benefícios dos aplicativos integrados do Windows e discute os seguintes tópicos:

  • SSO do Windows e gerenciamento de acesso.

  • Exemplos de aplicativos integrados do Windows.

Observação   Para obter mais informações sobre o desenvolvimento de aplicativos Microsoft ASP.NET que se integram aos serviços de segurança do Windows, consulte o artigo "Developing Identity-Aware ASP.NET Applications" (em inglês) desta série.

Gerenciamento de acesso e logon único do Windows

Os computadores cliente que executam sistemas operacionais Microsoft Windows, como o Microsoft® Windows® XP Professional e o Windows® 2000 Professional (bem como qualquer produto de servidor, como o Windows Server™ 2003, que funcione como cliente) incluem recursos incorporados que permitem SSO quando o cliente e o servidor estão associados a um domínio ou uma floresta do Windows. O SSO em domínios diferentes é ativado pelo estabelecimento da confiança entre domínios ou florestas, como descreve o artigo "Conceitos básicos" desta série.

Os seguintes recursos são implementados com os serviços de segurança do Windows e oferecem a capacidade de SSO:

  • Um cache de credenciais gerenciado pela autoridade de segurança local (LSA).

  • Um conjunto de pacotes de autenticação integrados ao LSA.

Para entender o modo como os serviços de segurança do Windows fornecem o SSO é preciso entender o processo de logon do Windows. As seções a seguir oferecem uma visão geral sobre como esse processo é realizado para atingir o SSO.

O processo de logon

No sistema operacional Windows, o mecanismo de logon do usuário é parte integrante do computador cliente e da rede. O usuário só precisa fazer a autenticação na rede uma vez com suas credenciais de domínio. Esse logon único permite que o usuário faça o logon na estação de trabalho e acesse quaisquer recursos locais ou remotos aos quais ele tenha permissão de acesso. O processo de logon é descrito na Figura 2.1.

Dd459060.intr2-1(pt-br,TechNet.10).gif

Figura 2.1. O processo de autenticação integrado do Windows para logon de área de trabalho

Exibir imagem em tamanho normal

Como parte do processo de logon, o usuário invoca a GINA (Graphical Identification and Authentication DLL) pressionando CTRL+ALT+DEL. Essa é a seqüência de autenticação segura (SAS), que apresenta a caixa de diálogo de logon do Windows (etapa 1) ao usuário. Em seguida, o usuário insere suas credenciais na caixa de diálogo de logon.

A LSA faz uma solicitação de TGT (permissão de concessão de permissão) ou TGT-REQ (etapa 2) a um controlador de domínio que execute o Active Directory. O KDC (Centro de distribuição de chaves) do protocolo Kerberos versão 5 que executa o serviço LSA no controlador de domínio autentica o nome de usuário e a senha, chamando o SAM (Service Accounts Manager) (etapa 3) do controlador de domínio. Se as credenciais estiverem corretas e nenhum outro elemento de diretiva (como restrições de tempo ou estação de trabalho) evitar que o usuário faça o logon, o LSA do controlador de domínio passa os tíquetes do protocolo de autenticação Kerberos versão 5 (etapa 4) ou os dados de autorização do NTLM (NT LAN Manager), que não são mostrados, de volta ao LSA do cliente.

Observação   Outros protocolos de autenticação são implementados nos pacotes de autenticação (também conhecidos como provedores de autenticação) dos clientes e servidores do Windows, mas este artigo concentra-se primariamente no protocolo de autenticação Kerberos versão 5 e menciona o NTLM apenas quando for apropriado.

Criação do contexto de autorização

O tíquete do Kerberos contém, entre outras coisas, o PAC (certificado de atributos de privilégio), que contém as informações do SID (identificador de segurança) para o usuário e os grupos dos quais o usuário faz parte. A Figura 2.2 mostra essa estrutura.

Com os dados de tíquete do Kerberos (etapa 5 da Figura 2.1) ou com os dados de autorização do NTLM, a estação de trabalho constrói o token de acesso. (Às vezes isso é chamado de contexto de segurança, mas token de acesso é mais correto quando se discute a autorização local comparada à autenticação de rede).

Um token de acesso do Windows contém:

  • O SID primário do usuário.

  • SIDs de grupo Global e Universal da conta de usuário, domínio ou floresta.

  • SIDs locais do domínio da estação de trabalho (se forem diferentes do domínio do usuário).

  • Privilégios atribuídos explicitamente ao usuário ou derivados das associações de grupo.

A seqüência de logon no computador cliente inicia uma instância do shell (normalmente o arquivoExplorer.exe ) e anexa o token de acesso do usuário ao shell (etapa 6 da Figura 2.1).

Figura 2.2. O tíquete do Kerberos contém o PAC, que por sua vez contém os SIDs de usuário e grupo

Figura 2.2. O tíquete do Kerberos contém o PAC , que por sua vez contém os SIDs de usuário e grupo

Acesso aos recursos locais

Todos os aplicativos que são iniciados a partir do shell na estação de trabalho herdam o token de acesso do processo do shell. Assim, após o logon do usuário, toda tentativa de acesso a um recurso local, como abrir um arquivo ou imprimir um documento do shell ou de qualquer processo iniciado pelo shell, faz com que a estação de trabalho compare o token de acesso do usuário com a ACL (lista de segurança e controle de acesso) do objeto que está sendo acessado.

Acesso a recursos remotos

Toda tentativa do usuário de realizar uma operação em um recurso remoto, como abrir um arquivo em um compartilhamento de arquivo de rede ou imprimir um documento em uma impressora de rede, faz com que o cliente e o servidor executem uma seqüência de autenticação. Como padrão, a seqüência de autenticação é executada com as mesmas credenciais que foram usadas no logon da estação de trabalho. A integração entre o Kerberos e os provedores de protocolo de autenticação NTLM com o LSA da estação é o que cria uma experiência SSO para o usuário baseado no Windows. A Figura 2.3 ilustra esse processo.

Figura 2.3. O processo de autenticação do logon de recurso remoto

Figura 2.3. O processo de autenticação do logon de recurso remoto

Neste exemplo, assume-se que o logon da estação de trabalho foi realizado usando o protocolo Kerberos, que é o mecanismo padrão de autenticação do Microsoft Windows® 2000 e do Windows Server 2003. Se o logon inicial fosse feito por meio do protocolo NTLM, a seqüência seria um pouco diferente.

O usuário tenta acessar um arquivo em um computador remoto que executa o Windows Server 2003 (etapa 1). O servidor exige autenticação e emite um "desafio" para o usuário (etapa 2). Em seguida, o LSA do cliente invoca o pacote de autenticação do Kerberos para solicitar as credenciais de autenticação necessárias (etapa 3). O pacote de autenticação do Kerberos atende à solicitação recuperando um tíquete válido emitido anteriormente do cache de tíquetes (etapa 4) no cliente, ou solicitando um novo tíquete (TKT) ao servidor (não mostrado) do KDC. Finalmente, o cliente responde ao desafio do servidor enviando o tíquete ao servidor (etapa 5).

Após a validação do tíquete (etapa 6), o provedor de autenticação do Kerberos cria um token de acesso como já foi descrito (etapa 7). Por meio desse token, o servidor pode representar (etapa 8) o usuário cliente. A representação permite ao servidor contar com o sistema operacional para implantar a autorização correta, comparando os direitos do usuário – capturados no token de acesso – com a ACL do recurso (etapa 9). Em seguida, o sistema operacional autoriza (como mostrado na Figura 2.3) ou nega a operação.

Auditoria de segurança

A auditoria de segurança pode ser configurada para a autenticação (incluindo o logon de estação de trabalho) e a autorização. A auditoria de segurança deve ser ajustada para atender à diretiva de segurança escrita da organização. É possível configurar a auditoria de autenticação para auditar o sucesso do logon, a falha do logon ou ambos.

A auditoria de autorização pode ser configurada no nível de um objeto e é detalhada até o nível em que as operações do objeto são definidas. Por exemplo, é possível auditar as operações de leitura, gravação ou edição de um arquivo realizadas com falha ou êxito.

Extensão do acesso usando as relações de confiança

É possível estender o efeito da autenticação integrada do Windows usando as relações de confiança do Windows. Uma relação de confiança entre dois domínios do Windows, ou entre florestas do Windows Server 2003, permite que as contas de usuário de um domínio confiável recebam direitos e permissões no outro domínio confiante.

As relações de confiança estendem o SSO porque o usuário não precisa fazer logon novamente para acessar os recursos do domínio confiante. Quando eles tentam se conectar a um recurso do domínio confiante, este se conecta ao domínio confiável por meio da relação de confiança e verifica as credenciais de usuário. O recurso do domínio confiante concede o acesso dependendo dos direitos do usuário no domínio confiável.

As confianças entre domínios são configuradas por padrão dentro dos domínios do Windows 2000 na mesma floresta. Nos domínios do Windows Server 2003, as confianças de diferentes florestas permitem que todos os domínios de uma floresta confiem nos domínios da outra floresta.

Quando as relações de confiança não podem ser estabelecidas, você pode usar o Windows Credential Manager para fornecer uma experiência SSO ao usuário por meio de um aplicativo que use a autenticação integrada do Windows. O Windows Credential Manager é discutido com mais detalhes mais adiante neste capítulo.

Para obter mais informações sobre os mecanismos de confiança do Windows, consulte a páginaWhat Are Domain and Forest Trusts? (em inglês).

Para obter outras informações sobre como planejar e implementar confiança entre florestas no Windows Server 2003, consulte a páginaPlanning and Implementing Federated Forests in Windows Server 2003 (em inglês).

Como melhorar o acesso usando o Windows Credential Manager

Como já foi descrito, os serviços de aplicativo e plataforma integrados aos serviços do Windows Security oferecem uma experiência SSO de usuário, utilizando as credenciais de logon do usuário para autenticar o usuário nos recursos da rede. Entretanto, essa abordagem nem sempre é suficiente ou desejável. Os exemplos dos casos nos quais os serviços de segurança do Windows não fornecem uma experiência SSO incluem:

  • Quando há necessidade de autenticação em um recurso de um domínio não confiável.

  • Quando há necessidade de autenticação em um recurso de um servidor autônomo.

  • Quando há necessidade de usar credenciais alternativas para acessar um recurso de rede.

O Microsoft Windows® XP e o Windows Server 2003 abordam esses cenários por meio de um componente integrado ao LSA conhecido como Nomes de usuário e senhas armazenados — geralmente denominado Windows Credential Manager — que oferece a funcionalidade de gerenciamento de credenciais no lado do cliente.

Você pode configurar esse componente de duas maneiras: para exigir que um usuário insira manualmente as credenciais uma vez antes de acessar o recurso ou salvando as credenciais do usuário automaticamente e as usando para acesso futuro.

O Windows Credential Manager oferece ao usuário um armazenamento móvel seguro para as credenciais. Isso é implementado no perfil móvel do usuário do domínio, permitindo que os usuários acessem seu armazenamento de credenciais em qualquer lugar onde puderem fazer logon e acessar seu perfil.

Alguns aplicativos e interfaces de desenvolvedor são escritos para usar o Windows Credential Manager quando apropriado. A experiência do usuário que ocorre neste caso é que na primeira tentativa de acesso a um recurso que exige autenticação, o aplicativo pede ao usuário para fornecer uma credencial. Se o aplicativo utilizado para acessar recurso permitir, o usuário poderá salvar a credencial. Em seguida, a credencial é associada ao recurso que a solicitou. Quando o usuário acessar o recurso no futuro, o pacote de autenticação reutilizará a credencial salva sem solicitá-la ao usuário. Entretanto, se o aplicativo não permitir que o usuário salve credenciais, este deverá configurar uma credencial manualmente para aquele recurso, indo até o componente Nomes de usuário e senhas armazenados do Windows Credential Manager. Você pode configurar o Windows Credential Manager para fornecer credenciais para os protocolos Kerberos e NTLM, SSL, TLS e autenticação Microsoft Passport e Basic.

Para obter mais informações sobre o modo como os aplicativos utilizam o componente Nomes de usuário e senhas armazenados consulteUsing Credential Management in Windows XP and Windows Server 2003 (em inglês) no Microsoft MSDN®.

Exemplos de aplicativos integrados do Windows

Os aplicativos cliente/servidor podem utilizar os mecanismos descritos anteriormente para fornecer ao usuário SSO, auditoria de segurança integrada e usar os benefícios das relações de confiança. Embora muitos aplicativos da Microsoft e de terceiros (de cliente e servidor) usem os recursos de segurança integrados do Windows para realizar o SSO, os seguintes aplicativos de cliente/servidor são particularmente interessantes:

  • Microsoft Internet Explorer e Internet Information Services (IIS).

  • Microsoft Office Outlook® e Exchange Server 5.5 ou posterior.

  • Microsoft SQL Server™ 7.0 ou posterior e SQL Server para clientes.

As seções seguintes oferecem exemplos de como a autenticação integrada do Windows funciona nesses aplicativos.

Internet Explorer e IIS

O fornecimento de Web SSO aos navegadores da intranet é uma experiência de usuário importante para os aplicativos da Web. O Internet Explorer é um aplicativo integrado do Windows, que ativa o Web SSO da intranet com o IIS 5.0 (incluído no Windows 2000 Server), IIS 6.0 (incluído no Windows Server 2003). A Figura 2.4 mostra como a autenticação integrada do Windows funciona entre o Internet Explorer e o IIS.

Figura 2.4. Autenticação IIS usando o protocolo Kerberos

Figura 2.4. Autenticação IIS usando o protocolo Kerberos

Um administrador IIS que queira permitir acesso a um aplicativo da Web para intranet apenas aos usuários autenticados pode configurar um site ou diretório virtual para utilizar a autenticação integrada do Windows. Com essa configuração de segurança ativada, o aplicativo cliente baseado no Explorer deve primeiramente autenticar o usuário no servidor Web IIS 6.0 usando os protocolos de autenticação Kerberos ou NTLM. O protocolo Kerberos versão 5 é a opção preferencial na maioria dos casos, mas existem configurações de rede e segurança no nível do controlador de domínio, do servidor que executa o IIS 6.0, e do cliente baseado no Explorer que podem ser usadas por um administrador para forçar o uso da autenticação NTLM.

Um exemplo do modo como a autenticação Kerberos funciona entre o Internet Explorer e o IIS é dado a seguir. Em primeiro lugar, o cliente que executa o Internet Explorer faz uma solicitação de página (etapa 1). O servidor que executa o IIS 6.0 força a autenticação com o protocolo HTTP enviando de volta um desafio 401 (etapa 2) para o navegador. O desafio inclui uma lista de cabeçalhos HTTPWWW-Authenticate que especifica os protocolos de autenticação que, de acordo com a configuração do servidor que executa o IIS 6.0, são aceitos para aquele URL.

Quando o Internet Explorer recebe o desafio 401, ele examina a lista de cabeçalhos e seleciona o protocolo de autenticação apropriado com base na configuração do navegador. O Internet Explorer chama o pacote de autenticação por meio do LSA (etapa 3). Com base nas credenciais de usuário presentes no cache de credenciais LSA da estação de trabalho e na capacidade de obter um tíquete do Kerberos para o recurso IIS (etapa 4), o tíquete é retornado ao Internet Explorer do LSA (etapa 5). Depois que o Internet Explorer possuir o tíquete, ele é enviado de volta ao servidor que executa o IIS em uma resposta 401, que inclui um cabeçalho HTTPWWW-Authenticate (etapa 6).

Após o cliente enviar a solicitação novamente, o servidor que executa o IIS 6.0 extrai as informações de autenticação do cabeçalho HTTP e apresenta os dados ao provedor de autenticação especificado pelo cliente (etapa 7). Se a autenticação for bem-sucedida, o provedor de autenticação cria um token de acesso que representa o usuário e o IIS 6.0 associa a representação a esse token com a solicitação do cliente (etapa 8) usando a representação. A Figura 2.4 mostra a operação desse processo.

É importante entender que o aplicativo IIS 6.0 não autentica o usuário durante esse processo. O aplicativo de servidor passa essa tarefa ao sistema operacional por meio da interface do provedor de autenticação. O aplicativo do servidor se beneficia com essa organização porque não precisa implementar sozinho o código de autenticação.

Se as seguintes condições forem atendidas, a autenticação e autorização será bem-sucedida sem que o usuário tenha que inserir credenciais adicionais:

  • O servidor que executa o IIS é membro de um domínio baseado no Windows.

  • A estação de trabalho baseada no Windows cliente é membro de um domínio com uma relação de confiança no domínio em que reside o servidor que executa o IIS.

  • O usuário faz o logon na estação de trabalho usando suas credenciais de domínio.

  • O usuário recebe o acesso ao recurso solicitado porque uma das condições a seguir é atendida.

    • O administrador do IIS 6.0 configurou as ACLs para conteúdo estático (arquivos com as extensões .htm e .asp) que permitem o acesso de usuário.

    • O aplicativo Microsoft ASP.NET define as funções do Microsoft .NET ou do Authorization Manager que permitem o acesso de usuário.

Para obter mais informações sobre esse processo de autenticação e autorização consulte:

Microsoft Office Outlook e Exchange Server

Neste exemplo, um usuário faz o logon em uma estação de trabalho baseada no Windows com sua conta de usuário. Em seguida, o usuário inicia o cliente de email do Outlook, que tenta se conectar ao aplicativo Exchange Server, executado no Windows Server 2003, usando as interfaces da chamada de procedimento remoto (RPC). O aplicativo Exchange Server exige que os clientes se autentiquem antes do estabelecimento de uma conexão, para que cliente e servidor negociem as mensagens de autenticação durante o estabelecimento da sessão RPC.

No caso do Outlook e do Exchange, a autenticação do Kerberos é tentada em primeiro lugar (o protocolo de autenticação Kerberos tem preferência em relação ao NTLM). Caso a tentativa seja bem-sucedida, um token de acesso é gerado para o aplicativo Exchange Server para representar o sistema operacional e implantar a autorização correta. O aplicativo cliente do Outlook tenta abrir a caixa de entrada do usuário, mas essa operação só será bem-sucedida se as ACLs da caixa de entrada estiverem configuradas para conceder acesso ao usuário que está tentando se conectar. Se o processo de autenticação for bem-sucedido e as regras de autorização descritas pela ACL da caixa de entrada forem cumpridas, o usuário tem acesso à caixa de entrada do Outlook sem necessidade de novo logon.

SQL Server e clientes SQL

Um processo semelhante ocorre com os bancos de dados hospedados no SQL Server que estão configurados para utilizar o Modo de Autenticação do Windows ou o Modo Misto. O Modo de Autenticação do Windows no SQL Server é equivalente à autenticação integrada do Windows descrita anteriormente para o IIS 6.0, enquanto o Modo Misto permite uma combinação entre a autenticação baseada no Windows e a autenticação do SQL Server.

O administrador do banco de dados SQL Server pode definir o acesso para os usuários ou grupos do Active Directory no nível de banco de dados ou de tabela. Quando um aplicativo cliente como o SQL Query Analyzer ou um aplicativo personalizado que utiliza a ODBC (conectividade aberta de banco de dados) conecta-se ao banco de dados, o SQL Server autentica o usuário e, em seguida, determina se os dados solicitados devem ser retornados ao cliente. A verificação de acesso compara as permissões do usuário relativas a todo o banco de dados ou mais precisamente no nível de tabela, com base nas ACLs armazenadas pelo sistema operacional SQL Server e no token de acesso do usuário. Se a autenticação e verificação de acesso forem bem-sucedidas, o acesso aos dados do SQL Server é obtido com segurança sem causar logon separado do usuário no aplicativo SQL Server.

Para obter mais informações sobre como configurar e utilizar a autenticação integrada do Windows com o SQL Server, consulte a página Administering SQL Server: Authentication Modes (em inglês).

Integração de plataforma com os serviços de segurança e diretórios do Windows

Existem vários serviços para integração do Windows com outras plataformas. Esses serviços oferecem às organizações opções para integração até um determinado nível com os serviços de segurança e diretório do Windows. A integração por meio desses serviços em geral não envolve a mudança de aplicativos ou a reconfiguração de estações de trabalho e servidores. Entretanto, elas introduzem "partes móveis" adicionais à rede e têm requisitos próprios de gerenciamento. Em geral, esses serviços não oferecem todas as capacidades e a funcionalidade que podem ser atingidas por meio da integração direta com os serviços de segurança do Windows.

Integração Linux e UNIX

A integração entre plataformas e serviços de segurança do Windows usa o protocolo Kerberos versão 5. O protocolo Kerberos é uma opção excelente para integrar o UNIX e o Linux ao sistema operacional Windows porque todos eles suportam o protocolo (às vezes usando produtos de terceiros).

As vantagens do uso do protocolo Kerberos versão 5 para a integração incluem:

  • O protocolo Kerberos é um protocolo baseado em padrões (RFC 1510 Internet Engineering Task Force (IETF), implementado nos produtos de cliente e servidor baseados no Microsoft Windows, Active Directory e em quase todas as versões do UNIX e Linux.

  • O protocolo Kerberos oferece suporte a logon seguro.

  • O logon com o protocolo Kerberos pode oferecer contexto de autorização (contendo os grupos) e informações de perfil por meio dos seguintes mecanismos.

    • Processamento das informações do Windows PAC nos tíquetes Kerberos emitidos pelos controladores de domínio do Windows: Nem todos os fornecedores modificaram suas implementações do protocolo Kerberos versão 5 para solicitar o Windows PAC ao fazer solicitações de tíquetes. Essa restrição inclui a versão atual das bibliotecas do protocolo Kerberos fornecidas com o sistema operacional Solaris 9 da SUN.

      Para obter mais informações sobre o Windows PAC, consulte o documento " Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources" (em inglês) no MSDN.

    • Configuração do NSS (name service switch) de estação de trabalho UNIX para utilização do LDAP com o módulo nss_ldap: O módulo nss_ldap oferece o meio pelo qual as estações de trabalho UNIX recuperam as informações de autorização de um diretório LDAP baseado no nome principal dos tíquetes Kerberos emitidos pelo KDC. Esta abordagem para autorização em geral exige uma extensão de esquema para o Active Directory que adiciona dados de grupo e autorização no estilo UNIX. O Microsoft Services for UNIX (SFU) oferece uma extensão de esquema que atende a esse requisito.

    • Configuração do NSS de estação de trabalho UNIX para usar o NIS com o módulo nss_nis: Você pode instalar o SFU para fornecer um "cabeçalho" NIS para o Active Directory. Com o SFU, o Active Directory aparecerá como um servidor NIS, bem como implementará uma extensão de esquema no Active Directory para fornecer informações comuns de perfil UNIX e autorização, UID (identificação de usuário), GID (identificação de grupo) e informações de shell.

  • O protocolo Kerberos do Active Directory é totalmente integrado a uma forte diretiva de segurança que é implantada pelos controladores de domínio que executam o Windows Server 2003. Antes de processar uma solicitação de logon do Kerberos, o controlador de domínio compara todas as configurações de diretiva pertinentes com o status de conta atual. Se algum requisito da diretiva não for atendido, o controlador de domínio negará a solicitação.

  • O protocolo Kerberos especifica que o TGT adquirido durante o logon pode ser apresentado ao KDC para gerar um tíquete de serviço. Em seguida, o tíquete de serviço é usado para autenticação de recursos da rede e aplicativos, como o SAP R/3 Application Server. Esse processo é transparente para o usuário, permitindo uma experiência SSO.

  • O protocolo de autenticação 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.

Os usuários do UNIX e Linux convencional fazem logon em seus computadores fornecendo um nome de usuário e senha exclusivos. O nome de usuário e a senha são comparados àqueles que estão armazenados nos arquivos /etc/password e**/etc/shadow** . O serviço PAM (Pluggable Authentication Module) estende as capacidades de autenticação e autorização do UNIX e Linux permitindo que as credenciais sejam armazenadas em locais diferentes. O PAM também permite que mecanismos diferentes sejam usados para verificar as credenciais de usuário.

Em sistemas que utilizam o PAM, o processo de logon e todos os utilitários que exigem autenticação de usuário devem ser compilados para usar o PAM para autenticação e autorização.

A maioria das versões do UNIX e muitas distribuições do Linux incluem suporte ao protocolo Kerberos versão 5 por meio do arquivo de configuração do PAM chamado pam.conf. Muitas dessas versões de sistema operacional também oferecem bibliotecas que implementam partes de cliente/servidor do protocolo Kerberos. O suporte ao protocolo Kerberos do UNIX e Linux permite integração transparente entre aplicativos com os serviços de segurança do Windows em computadores que executam o UNIX e o Linux.

Os capítulos de 3 a 7 deste artigo incluem um cenário detalhado que configura a autenticação Kerberos em uma estação de trabalho do Sun Solaris UNIX, para integração de autenticação e autorização com o Active Directory.

Serviços para UNIX 3.5

O SFU ativa os clientes e servidores Windows e UNIX para compartilhamento de recursos de rede, integra o gerenciamento de contas, simplifica o gerenciamento de diferentes plataformas e oferece um ambiente completo de scripting de UNIX e execução de aplicativo, que é executado de forma nativa no sistema operacional Windows. Para obter mais informações sobre o SFU, consulte o site Windows Services for UNIX .

Interoperabilidade do Windows Server 2003 R2 UNIX

O Windows Server 2003 R2 inclui os componentes de interoperabilidade do UNIX como parte do sistema operacional. Esses componentes de interoperabilidade consistem em:

  • Subsistema para aplicativos baseados no UNIX, que ativa os aplicativos baseados no UNIX para compilação e execução no Windows Server 2003 R2.

  • IDMU (Identity Management for UNIX), que fornece a capacidade de integrar os serviços de segurança e diretório do UNIX. O IDMU inclui uma atualização de esquema opcional do Active Directory que importa as extensões de esquema do NIS e Kerberos.

  • Serviços de NFS (Network File System) da Microsoft, que incluem vários componentes para compartilhar arquivos, implantar segurança de arquivos e gerenciar o compartilhamento de arquivos e impressão entre os sistemas UNIX e Windows.

Para obter mais informações, consulte o documento "UNIX Interoperability in Microsoft Windows Server 2003 R2".

Serviços de autenticação Vintela

A Vintela Inc. (agora parte da Quest Software) é um parceiro da Microsoft e fornecedor independente de software que se concentra na integração do UNIX à plataforma Microsoft. O VAS (Vintela Authentication Services) integra versões dos sistemas operacionais UNIX Linux ao Active Directory, integrando as interfaces UNIX nativas ao Active Directory utilizando o protocolo Kerberos e o LDAP.

Para obter mais informações sobre o VAS, consulte o site Vintela .

Integração do Novell NetWare

O Microsoft Windows Services for NetWare (SFN) 5.02 oferece um conjunto de utilitários de interoperabilidade que ajudam a simplificar a introdução do Windows Server 2003 e do Active Directory em um ambiente de rede Novell NetWare com o Novell Directory Service (NDS).

Para obter mais informações sobre o SFN, consulte o site Microsoft Windows Services for Netware 5.03.

Integração do Apple Macintosh

O Microsoft Windows Server 2003 Services For Macintosh (SFM) é um componente totalmente integrado do Windows Server 2003, que possibilita a computadores com os sistemas operacionais Windows e Macintosh compartilharem arquivos e impressoras. Após a configuração do SFM, esses computadores podem executar as funções de um servidor de arquivos, um servidor de acesso remoto e um servidor de impressão para computadores que executam o sistema operacional Macintosh. Além disso, o Windows Server 2003 com o SFM pode executar as funções de um roteador AppleTalk.

Para obter mais informações sobre o SFM, consulte a páginaWindows 2000 SFM no Mactopia Web.

Integração de Mainframe

A integração entre sistemas operacionais de maiframe, como o OS/390 e o z/OS da IBM, e os serviços de diretório e segurança do Windows pode ser feita de várias maneiras, incluindo:

  • Mapeamento de credenciais por meio do Microsoft Host Integration Server.

  • Integração de plataforma por meio do protocolo Kerberos.

  • Abordagens de integração de aplicativo que utilizam o LDAP e a GSS-API.

O HIS oferece uma abordagem de mapeamento de credenciais (ou ESSO) para integrar indiretamente o Active Directory aos armazenamentos de diretórios do mainframe. Para obter outras informações sobre esse assunto, consulte a seção "Integração indireta por meio do mapeamento de credenciais" mais adiante neste artigo.

Os mainframes da IBM com versões atualizadas do IBM SecureWay Security Server (que inclui o RACF (Resource Access Control Facility)) suportam o protocolo Kerberos, LDAP, SSL, GSS-API e outros padrões relacionados a gerenciamento de acesso descritos no artigo "Fundamental Concepts" desta série. Em teoria, o uso de padrões como o protocolo Kerberos possibilita a configuração do RACF em um mainframe, para cooperação com a implementação da Microsoft para um KDC do Kerberos.

Teoricamente você também pode configurar ou migrar aplicativos em mainframes que usam padrões como o LDAP e a GSS-API para utilização dos serviços de diretórios e segurança do Windows.

Para obter mais informações sobre como usar os padrões RACF que oferecem suporte a integração com os serviços de diretório e segurança do Windows, consulte os recursos a seguir.

Integração com o J2EE

O J2EE é uma opção de plataforma de desenvolvimento de aplicativos considerada por muitos clientes em vez, ou além, do Microsoft .NET Framework para o desenvolvimento de aplicativos. A integração entre os aplicativos J2EE e os serviços de diretório e segurança do Windows é possível com o uso de uma ou mais das tecnologias a seguir:

  • Navegador para servidor da Web. Os servidores de aplicativo J2EE, como o Apache e o BEA WebLogic, oferecem suporte ao protocolo Kerberos por meio de módulos de autenticação conectáveis disponíveis no fornecedor, como código aberto, ou de ISVs (distribuidores de software independentes).

  • LDAP. Todo aplicativo J2EE que execute a autenticação BASIC ou baseada em formulários pode validar as credenciais de usuário no Active Directory usando o vínculo LDAP.

  • Serviços da Web – Segurança. O WS-Segurança define vários tipos de tokens, incluindo aqueles para o protocolo Kerberos e o X.509, que permitem integração entre os aplicativos J2EE e os serviços de segurança do Windows.

Vintela

A Vintela (agora parte da Quest Software) integrou o JCSI Kerberos da Wedgetail ao Vintela Single Sign-on for Java (VSJ). O VSJ é uma solução no lado do servidor que permite autenticação integrada do Windows aos servidores de aplicativos Java. Para obter mais informações sobre os produtos da Vintela, consulte o site Vintela .

Integração de aplicativo com os serviços de diretório do Windows

Quando a integração nativa entre aplicativos e os serviços de segurança do Windows não é possível, os aplicativos podem ser integrados ao ambiente Windows por meio dos serviços de diretório do Windows, ou por meio de um produto que estenda a funcionalidade do Active Directory. Essa solução pode não ser tão elegante quanto a abordagem totalmente integrada descrita anteriormente, mas ela pode ser necessária para diferentes plataformas e aplicativos que não ofereçam suporte à integração direta com o Windows.

A integração dos serviços de diretório pode simplesmente exigir a configuração de aplicativos, servidores ou estações de trabalho para utilizar um serviço do Active Directory como o LDAP. Em alguns casos, pode ser necessário modificar os aplicativos para integração completa com os serviços de diretório do Windows ou um diretório de aplicativo como o ADAM (Modo de Aplicativo do Active Directory) pode ser usado.

As seções a seguir fornecem exemplos de como integrar os aplicativos aos serviços de diretório do Windows usando o LDAP e o ADAM.

Integração com o LDAP

O Active Directory é compatível com o LDAP 3.0, que é definido pelo RFC 3377 e outros RFCs. Como muitos outros serviços de diretório disponíveis comercialmente oferecem suporte ao LDAP e como muitos aplicativos utilizam o LDAP para acessar esses serviços de diretório, um protocolo padronizado como o LDAP pode fornecer interoperabilidade de gerenciamento de acesso entre os aplicativos de terceiros existentes e aplicativos desenvolvidos internamente e o Active Directory.

Para obter mais informações sobre o suporte do Active Directory ao LDAP consulte o artigoCompatibilidade entre o Active Directory e o LDAP .

O LDAP pode ativar a integração de autenticação e autorização entre o Active Directory e os aplicativos hospedados em qualquer sistema operacional de cliente ou servidor que ofereça suporte ao LDAP. Nessa função, o Active Directory torna-se o armazenamento de identidade do aplicativo. Em geral, os aplicativos podem usar o LDAP diretamente, por meio das APIs compatíveis fornecidas pelo sistema operacional que hospeda o aplicativo, ou por complementos como o Open LDAP, que é uma biblioteca LDAP de código aberto para os sistemas operacionais UNIX e Linux.

Desenvolvimento para o LDAP

O desenvolvimento de aplicativos não é o foco deste artigo, mas é importante destacar que a integração com o Active Directory por meio do LDAP pode exigir algumas modificações nos aplicativos existentes. Algumas dessas modificações podem ser necessárias, devido a:

  • Diferenças sutis nas implementações LDAP.

  • Uma estrutura de diretórios mais complexa com base em domínios e florestas do Active Directory.

  • Requisitos para o aproveitamento dos recursos de segurança do LDAP na plataforma Windows.

Para os aplicativos nos clientes e servidores baseados no Windows que não se integram aos serviços de segurança do Windows há uma variedade de APIs que podem ser usadas para a integração com os serviços de diretório do Windows. O Active Directory oferece suporte às seguintes interfaces.

  • Conjunto de APIs LDAP Win32 compatíveis com o RFC 1823 para os aplicativos C e C++.

  • Active Directory Service Interfaces (ADSI) para aplicativos Microsoft Visual Basic® e scripts VB.

  • System.DirectoryServices para aplicativos de código gerenciado criados com o Microsoft Visual Studio .NET.  

Para obter mais informações sobre como usar essas interfaces de programação no Active Directory, consulte a página Using Active Directory (em inglês) de Platform SDK: Active Directory no MSDN.

Autenticação por meio do LDAP

Em geral, as sessões LDAP iniciam com uma operação de "vinculação". A operação de vinculação pode ser anônima ou incluir credenciais do usuário que deseja se conectar ao serviços de diretório. Como o foco desta seção é a autenticação de usuários, nos concentraremos no vínculo autenticado.

Existem dois tipos de operações vinculadas autenticadas, vínculos "simples" e vínculos não simples que usam um protocolo de autenticação suportado pelo serviço de diretório. Os vínculos simples usam credenciais de texto sem formatação para autenticar o vínculo e, por esse motivo, devem ser usados com cuidado. O LDAP suporta o SSL que deve se considerado obrigatório para aplicativos que usam vínculos simples. A função LDAP que ativa o SSL éldap_set_option() com o sinalizador LDAP_OPT_SSL.

Para obter mais informações sobre como usar o SSL para proteger as sessões LDAP, consulte a página Example Code for Establishing a Session over SSL (em inglês) de Platform SDK: LDAP do MSDN.

Existem determinados casos em que os vínculos simples do LDAP são a melhor opção. Os exemplos disso incluem os aplicativos de servidor que pedem o nome de usuário e a senha para a autenticação, como um aplicativo da Web que use a autenticação baseada em formulários, e que precise validar a senha de texto sem formatação do usuário. Se o aplicativo exigir que ele seja o mais neutro possível em termos de plataforma e diretório, os vínculos simples LDAP são a melhor abordagem.

Para os aplicativos de servidor que precisem vincular-se ao Active Directory usando suas próprias credenciais para recuperar algumas informações do serviço de diretório, a Microsoft recomenda a configuração do servidor para usar uma das opções de mecanismo de autenticação listadas na documentação da APIldap_bind_s() .

Observação   As APIs LDAP que terminam em 's', como ldap_bind_s, são APIs síncronas. O 's' não implica nenhum tipo de segurança para a sessão. Isso pode causar confusão, pois apenas o vínculo síncrono, ou ldap_bind_s, oferece suporte a outros mecanismos de autenticação além do vínculo simples.

Os vínculos LDAP não simples são realizados por meio de um mecanismo conhecido como SASL (Simple Authentication and Security Layer). Os mecanismos SASL suportados pelo Active Directory incluem os mesmos protocolos de autenticação documentados em outra parte desta série, os protocolos Kerberos versão 5 e NTLM (por meio do pacote de segurança Negotiate), e a autenticação Digest. Os vínculos LDAP que utilizam esses mecanismos usam as credenciais padrão dos aplicativos de servidor e eliminam a necessidade de manter na memória uma versão em texto sem formatação da senha dos aplicativos. Para utilizar esses mecanismos o aplicativo deve chamar **ldap_bind_s()**com o sinalizador LDAP_AUTH_NEGOTIATE ou LDAP_AUTH_DIGEST.

Quando um aplicativo utiliza um dos mecanismos SASL para estabelecer uma sessão com o Active Directory, ele também pode especificar que todos os dados trocados entre o cliente e o servidor LDAP sejam assinados digitalmente ou criptografados. O aplicativo usa a API ldap_set_option() com a opção LDAP_OPT_SIGN ouLDAP_OPT_ENCRYPT . A Microsoft recomenda que todas as sessões com dados de diretório confidenciais ou quaisquer dados que serão usados para autorização sejam protegidas por criptografia de sessão.

Autorização através do LDAP

Além da autenticação, os aplicativos também consultam os serviços de diretório para recuperar dados sobre usuários que serão usados para autorização. Os atributos e as informações de diretório que normalmente são usados para autorização incluem:

  • Grupos de segurança.

  • Atributos de usuário como local, cargo ou gerente.

  • Informações hierárquicas como unidade organizacional (UO) ou departamento.

  • Atributos personalizados armazenados no diretório, que podem ser específicos do aplicativo como Cliente Platinum.

Os aplicativos que usam os serviços de diretório para autorização têm muitas opções quanto ao modo como eles acessam as informações de diretório e, às vezes, os desenvolvedores podem tomar decisões ruins de implementação. Um problema comum é quando os aplicativos não fazem o cache dos resultados da consulta. O resultado é que um único aplicativo pode gerar uma quantidade considerável de carga para um diretório. Os desenvolvedores devem tomar o cuidado de fazer o cache dos resultados da consulta de diretório para o caso dessas informações virem a ser utilizadas novamente.

Observação   Uma das maiores vantagens da integração de aplicativos aos serviços de segurança do Windows é que os mecanismos de autenticação do Windows recuperam e fazem o cache das informações de autorização, como os grupos de segurança, durante a seqüência de autenticação. O Windows Authorization Manager também faz o cache de outras informações de autorização baseadas na função quando o contexto de autorização é criado. Após o cache, as informações de autorização estão disponíveis localmente durante a sessão autenticada. Os mecanismos de cache internos facilitam muito o desenvolvimento de aplicativos eficientes.

Outro problema comum é que os desenvolvedores podem não entender o modo como devem implementar pesquisas efetivas. Pesquisas ruins que são repetidas com freqüência podem ter impacto desnecessário sobre o desempenho e a disponibilidade de diretórios. Para obter mais informações consulte a página >Creating More Efficient Microsoft Active Directory-Enabled Applications (em inglês) do MSDN.

Integração com o Windows Directory Services usando o ADAM

O ADAM oferece oportunidade adicional de integração com os serviços de diretório do Windows. O ADAM é uma versão autônoma do Active Directory executada como serviço de usuário em computadores com o Windows XP ou o Windows Server 2003.

Para atender aos requisitos de redução do número de armazenamentos de identidade de um ambiente, a Microsoft recomenda o uso do Active Directory sempre que possível. Algumas das vantagens do Active Directory com o ADAM incluem:

  • Recursos de autenticação melhores, inclusive a integração com o protocolo Kerberos versão 5 (incluindo a delegação restrita do protocolo Kerberos para servidores n camadas), PKI (infra-estrutura de chave pública) e Microsoft Passport.

  • Um lugar para todas as contas, facilitando o gerenciamento de identidades.

  • Conectividade com muitos aplicativos Microsoft, como o Microsoft SharePoint™ Portal Server e o Microsoft Exchange Server, que exigem que os usuários tenham conta no Active Directory.

Entretanto, existem várias razões válidas para optar pelo ADAM, incluindo as considerações discutidas a seguir:

  • Migração de aplicativo. A migração dos aplicativos existentes que utilizam a nomeação X.500.

  • Configuração e gerenciamento. O ADAM tem gerenciamento e configuração fáceis para os desenvolvedores.

  • Segurança e isolamento de identidade. Os objetos do ADAM não podem fazer logon em uma estação de trabalho, servidor, nem podem ser usados para acessar um recurso de rede diferente de um aplicativo específico que usa uma instância do ADAM.

  • Dados de personalização e desempenho. O ADAM é adequado para dados de personalização de baixo valor que não são globalmente interessantes. Os dados e atributos que mudam com freqüência podem afetar negativamente o desempenho do Active Directory.

Para obter mais informações sobre o ADAM, consulte a páginaWindows Server 2003 Active Directory Application Mode (em inglês).

Migração de aplicativo

Uma abordagem em que a autenticação LDAP para o Active Directory é particularmente útil é durante a migração do aplicativo de outro serviço de diretório que suporte os contextos de nomeação no estilo X.500. Como o Active Directory não oferece suporte a nomeação no estilo X.500, o ADAM pode ser bastante útil para migração de aplicativo sem código para os serviços de diretório da Microsoft.

O ADAM tem um recurso chamado redirecionamento de vínculo LDAP (também chamado proxy de vínculo) que é muito interessante para esse tipo de cenário. O redirecionamento de vínculo permite que o ADAM faça uma cópia "sombra" da conta para que um usuário do Active Directory contenha todos os atributos de usuário necessários ao aplicativo, mas não contenha a senha do usuário. O aplicativo tentará autenticar-se no ADAM usando o vínculo LDAP, mas o ADAM faz o proxy da solicitação de autenticação para o Active Directory. Em seguida, o Active Directory autentica o usuário e passa o resultado de volta ao ADAM. Esse recurso permite a migração de um aspecto importante do usuário — as credenciais de conta — para um armazenamento de identidade centralizado do Active Directory, deixando as informações de diretório específicas do aplicativo no ADAM.

Configuração e gerenciamento

Durante o desenvolvimento dos aplicativos ativados para diretório, os programadores talvez tenham que fazer modificações no esquema do diretório. Os desenvolvedores podem não ser integrantes do grupo de administradores do esquema do Active Directory e, portanto, não podem modificar o esquema. O ADAM pode ser útil como ferramenta de desenvolvedor para fazer o protótipo das modificações de esquema propostas sem precisar alterar o Active Directory da organização.

Segurança e isolamento de identidade

O ADAM também pode ser selecionado como armazenamento de identidade para determinados tipos de usuários por questões de segurança. Para aplicativos de extranet que expõem serviços aos clientes, bem como funcionários e parceiros, a organização pode exigir que as contas concedidas aos clientes não devam ser usadas para acessar nenhum outro aplicativo ou recurso da extranet. Se as contas fossem criadas no Active Directory, essa exigência poderia ser difícil de atender porque as contas do Active Directory, em geral, não poderiam ser usadas para conexão com serviços e recursos de um domínio externo. As contas de cliente poderiam ser controladas rigidamente por meio de um GPO (objeto de diretiva de grupo) e por outras configurações de diretivas, mas algumas organizações preferem ter uma separação de contas explícita. As organizações com esse requisito podem optar pelo ADAM como o armazenamento de identidade para o cliente.

Dados de personalização e desempenho

Em determinados cenários, uma organização pode se preocupar com o fato de que a migração de um aplicativo para o Active Directory pode ter um impacto negativo sobre seu serviço de diretório central. Isso pode dever-se à necessidade de armazenamento de grandes quantidades de dados de "personalização" específicos de aplicativo que não são importantes para nenhum outro aplicativo, porque os dados específicos de aplicativo mudam com muita freqüência, ou mesmo porque o aplicativo utiliza os serviços de diretório de modo pouco eficiente. Nesses casos, o uso do ADAM para os dados de diretório específicos de aplicativo é apropriado.

Integração indireta por meio do mapeamento de credenciais

Quando a integração direta de plataformas e aplicativos com os serviços de diretório e segurança do Windows não é possível, o ESSO pode atingir a integração indireta entre o Active Directory e outros armazenamentos de identidade e fornecer autenticação e SSO por meio dos serviços de mapeamento de credenciais.

Muitos aplicativos de portal e aplicativos middleware LOB (linha de negócios) recuperam dados de sistemas back-end por parte dos usuários do aplicativo. Em geral, os sistemas back-end implementam sua própria segurança e têm seus próprios armazenamentos de identidade. Normalmente, os mecanismos de segurança dos sistemas back-end não foram totalmente integrados aos serviços de segurança do Windows e, portanto, não é possível delegar autenticação do aplicativo de portal ou middleware para o sistema back-end.

Em um cenário típico, o portal pede ao usuário uma credencial que possa ser usada para autenticação no sistema back-end. Outros pedidos de credenciais de usuário no acesso a um portal em geral produz uma experiência de usuário ruim, levando as organizações a optarem por tecnologia que oferece o SSO. A tecnologia mais comum utilizada para atingir o SSO é alguma forma de mapeamento de credenciais.

Para ter um exemplo de como funciona o mapeamento de credenciais, assuma que haja um aplicativo típico de camada média que recupera os dados de um sistema back-end. O sistema back-end não está integrado aos serviços de segurança do Windows nem mantém seu próprio armazenamento de identidade. Para acessar esse sistema back-end sem pedir credenciais, o aplicativo de camada intermediária solicita credenciais específicas ao sistema back-end do serviço ESSO. Neste exemplo, as credenciais do usuário local, Maria, são mapeadas para um usuário chamado M2231 no sistema back-end. Em seguida, Maria recebe permissão de acesso ao recurso em particular, como mostra a Figura 2.5.

Uma variação do mapeamento direto ocorre quando as credenciais são usadas para formar um mapeamento muitos para um. Essa organização mapeia vários usuários para uma única credencial que é reconhecida pelo recurso do back-end. Na Figura 2.5, Nuno é mapeado para um usuário de aplicativo genérico no sistema back-end.

Figura 2.5. Um exemplo de mapeamento de credenciais

Figura 2.5. Um exemplo de mapeamento de credenciais

Vantagens e desvantagens do mapeamento de credenciais

O modelo de mapeamento de credenciais funciona bem quando você precisa lidar com uma das situações a seguir em sua organização.

  • Modelos de segurança heterogêneos. Seu aplicativo é executado no sistema operacional Windows e o IIS 6.0 no aplicativo de camada intermediária, e os sistemas back-end atuais utilizam o SQL Server 2000 ou posterior e o Exchange 5.5 ou posterior. O protocolo Kerberos versão 5 funciona bem até você resolver implementar um terceiro sistema back-end, como o DB2 no OS/390. Neste caso, você precisa mapear as credenciais do Windows para o RACF para acessar o recurso no back-end.

  • Uso adiado de credencial. É preciso adiar o uso da credencial de autenticação após passar assincronamente sobre filas de mensagens, corretores de serviço ou mecanismos de integração.

Entretanto, você deve comparar essas vantagens em relação às seguintes desvantagens.

  • O risco de armazenar nomes de usuário e senhas. Para que tais sistemas de mapeamento de credenciais funcionem, você precisa de um banco de dados que contenha os nomes de usuários e as senhas que podem ser descriptografadas depois de serem usados. Você pode dar segurança a tais bancos de dados de várias maneiras, mas o armazenamento de senhas, mesmo aquelas criptografadas, representa um risco. Por exemplo, com o uso de configurações padrão, o Active Directory nunca armazena a senha real. Esse risco deve ser avaliado e levado em conta.

  • Sincronização de senhas. Um banco de dados de mapeamento de credenciais significa que algumas credenciais de usuário devem ser mantidas em dois lugares ou sincronizadas por meio de algum tipo de processo automatizado. Esse fator pode levar ao aumento de complexidade em sua arquitetura de sistemas ou sobrecarga de processo. Consulte o artigo "Password Management" (em inglês) desta série para obter mais informações.

O modelo de mapeamento de credenciais em produtos Microsoft

Os produtos de integração comercial da Microsoft incluem um serviço ESSO que oferece armazenamento e mapeamento de credenciais para que os aplicativos possam recuperar as informações de sistemas ERP, sistemas CRM e de aplicativos baseados em mainframe.

Todos esses aplicativos usam um banco de dados seguro para conter as credenciais de usuário e as informações de mapeamento de contas que vinculam as contas do Active Directory a contas utilizadas para os aplicativos empresariais back-end. O serviço ESSO também implementa um serviço seguro para emissão e troca de tíquetes que é usado sempre que o aplicativo de integração empresarial precisa recuperar dados do aplicativo back-end. Como o usuário acessa os diversos aplicativos utilizando apenas suas credenciais do Active Directory, uma experiência SSO é fornecida aos usuários.

Os aplicativos que usam o serviço Microsoft ESSO incluem:

  • SharePoint Portal Server (SPS 2003)

  • Microsoft BizTalk® Server 2004

  • Host Integration Server 2004

Uso do SharePoint Portal Server ESSO

O SharePoint Portal Server (SPS 2003) permite que as organizações desenvolvam um portal inteligente que conecte usuários, equipes e conhecimento para permitir que as pessoas aproveitem as informações relevantes em diferentes processos empresariais e trabalhem com maior eficiência.

O SPS 2003 oferece uma solução de negócios corporativa que integra as informações de diversos sistemas em uma solução de portal baseada na Web. Ele faz isso por meio do SSO e das capacidades de integração de aplicativos empresariais, juntamente com opções flexíveis de implantação e ferramentas de gerenciamento. O SPS 2003 também ajuda a dar segurança a aplicativos empresariais, armazenando e mapeando credenciais atribuídas, o que permite aos clientes interagirem com os aplicativos da empresa diretamente do portal, utilizando apenas suas credenciais do Active Directory.

Uso do BizTalk Server ESSO

O BizTalk Server 2004 conecta sistemas, pessoas e parceiros comerciais por meio de processos empresariais gerenciáveis. Ele fornece integração entre os produtos ERP, permitindo que as organizações integrem suas operações de negócios e reúnam fornecedores e consumidores. Ele também fornece uma variedade de mecanismos de interoperabilidade, particularmente os serviços da Web em XML.

O BizTalk Server utiliza um banco de dados similar de mapeamento de credenciais ESSO para o SPS 2003. Neste caso, o BizTalk 2004 pode oferecer detalhes de autenticação a qualquer conexão definida pelo mecanismo de orquestração do BizTalk Server.

Um cenário de SSO do BizTalk Server 2004 é semelhante àquele com o SPS, embora ele possa não ser baseado em portal. O usuário autentica-se no sistema operacional Windows e, em seguida, o BizTalk Server 2004 vincula essa autenticação a seu banco de dados interno de credenciais. Quando o usuário precisa acessar as informações mantidas por um parceiro de negócios, como níveis de ações, o BizTalk Server 2004 recupera as credenciais armazenadas e as apresenta ao sistema externo.

Em relação à integração entre o SPS 2003, o BizTalk Server e o SSO, a abordagem recomendada é usar a versão SSO do BizTalk Server em vez daquela do SPS. Isso significa que as partes da Web SPS chamam o adaptador de serviços da Web do BizTalk Server, e que essas partes da Web precisam garantir que quando o adaptador de serviços da Web do BizTalk receber a solicitação, ela estará dentro do contexto do usuário final que a iniciou. Por esse motivo, o adaptador do serviço da Web precisa residir no mesmo computador da parte da Web ou você pode configurar a delegação restrita para os cenários do computador remoto. O adaptador do serviço da Web utiliza a chamada IssueTicket com o SSO empresarial e o adaptador do back-end utiliza a chamada ValidateAndRedeemTicket.

Uso do Hosting Integration Server para o ESSO

Em ambientes clientes, o mainframe e outros sistemas baseados no host nunca interoperam com as credenciais do Active Directory do usuário. Embora muitas organizações tenham uma visão de longo prazo para a integração de sistemas baseados no host com o Active Directory usando protocolos padrão como o protocolo Kerberos versão 5, leva algum tempo para que isso se realize. Uma solução mais imediata é o Host Integration Server 2004, que fornece a capacidade de gerenciamento de credenciais, oferecendo ao usuário algo parecido com o SSO.

O Host Integration Server 2004 fornece a próxima versão do banco de dados de mapeamento de credenciais ESSO oferecida pelo BizTalk Server 2004. Esse banco de dados de mapeamento de credenciais fornece o SSO no Host Integration Server usando os emuladores 3270 e 5250, permitindo que os usuários autenticados do Windows façam logon automaticamente em um mainframe ou sistema AS/400, sem precisar fornecer outras credenciais de logon. Além disso, os recursos de aplicativo e integração de dados do Host Integration Server permitem que os usuários autenticados do Windows acessem os subsistemas CICS (Customer Information Control System) e o IMS (Sistemas de Gerenciamento de Informações) ou o DB2, também sem precisar que o usuário forneça outras credenciais de logon.

Um cenário que utilize o Host Integration Server envolveria um corretor de um banco comercial. O corretor faz o logon, autentica-se no sistema operacional Windows, e inicia um aplicativo de transações baseado no .NET Framework. Para processar uma transação, ele precisa saber o saldo atual de transações do cliente, o qual é armazenado pelo banco em um mainframe antigo. O Host Integration Server 2004 encaminha os detalhes da autenticação ao mainframe, usando seu banco de dados de mapeamento de credenciais, permitindo que o corretor execute consultas sobre esse cliente.

Produtos ISV ESSO

O ESSO é outra área da tecnologia que tem experimentado um forte desenvolvimento do mercado de ISV. Ao contrário da tecnologia Microsoft ESSO, esses produtos ISV em geral fornecem um mecanismo centralizado de armazenamento baseado no Active Directory para credenciais e mapeamento, e também fornece um conjunto de APIs que podem ser usadas pelos aplicativos para atingir a funcionalidade ESSO. Os fornecedores de ESSO incluem (em ordem alfabética):

Contas e senhas sincronizadas

A integração direta de plataformas e aplicativos aos serviços comuns de diretório e segurança por meio de uma estratégia de interoperabilidade de plataformas, migração de aplicativos e consolidação de infra-estruturas pode resultar em benefícios significativos. Se a integração direta ou indireta já discutida anteriormente não for possível, a integração dos armazenamentos de identidade básicos poderá atingir um subconjunto de benefícios.

A sincronização de conta e senha é uma técnica de reserva para atingir acesso reduzido, ou para quando todas as outras abordagens falharem, forem difíceis ou de implementação muito cara. Essa abordagem não fornece o verdadeiro SSO, mas reduz o número de nomes de usuário e senhas que os usuários devem lembrar.

A sincronização de senha em geral implica vários armazenamentos de identidade que incluem contas e senhas de usuário idênticas. Cada usuário faz logon no cliente, em outras plataformas, aplicativos e sites da Web de intranet usando a mesma combinação de nome de usuário e senha.

Observação   A sincronização de senha deve ser tentada apenas após a completa consideração das características de segurança e dos riscos incorridos pelo armazenamento e uso das mesmas senhas em vários sistemas.

O artigo "Identity Aggregation and Synchronization" desta série oferece mais informações sobre como sincronizar as identidades digitais em vários armazenamentos de identidade.

O artigo "Password Management" desta série detalha as abordagens e questões associadas ao uso da sincronização de senhas para fornecer gerenciamento do acesso à intranet, bem como demonstra como implementar a propagação de senhas de uma floresta do Active Directory para outras florestas do Active Directory, armazenamentos de identidade de aplicativo e serviços de diretório para outras plataformas.

Neste artigo

Download

Obtenha a Série de Gerenciamento de Identidades e Acessos da Microsoft

Avisos de atualização

Inscreva-se para receber informações sobre atualizações e novas versões

Comentários

Envie seus comentários ou sugestões

 Dd459060.pageLeft(pt-br,TechNet.10).gif 2 de 9 Dd459060.pageRight(pt-br,TechNet.10).gif