Interoperabilidade

Autenticar clientes Linux com Active Directory

Gil Kirkpatrick

 

Visão geral:

• Como funciona a autenticação no Windows e no Linux
• Usando Samba e Winbind
• Estratégias de implementação
• Estudando a integração do Linux com o Active Directory

Sumário

Autenticação no Windows
Autenticação no Linux
Samba e Winbind
Três estratégias de autenticação
Nosso plano de implementação
Encontrando o software certo
Compilando o Samba
Configurando o sistema de rede do Linux
Configurando a sincronização de data/hora do Linux
Configurando PAM e NSS
Instalando e configurando o Samba
O problema de mapeamento de IDs
Ingressando no domínio e fazendo logon
E se não funcionar?
Agora que está funcionando, o que você tem?
Soluções de terceiros

Republicanos e democratas. Creme dental e suco de laranja. Linux e Windows. Há coisas que simplesmente não combinam, não é verdade? Todo departamento de TI com o qual já me envolvi tem se dividido em dois grupos: a turma do Windows e a turma do Linux. Na verdade, eles não competem, mas também não colaboram uns com os outros. De fato, alguns chegam ao ponto de pintar uma linha amarela no chão apenas para deixar absolutamente claro que não existe uma fraternidade imprópria entre os dois grupos.

Sou adepto do Windows e com certeza já zombei de meus colegas que usam o Linux, mas todos temos o mesmo objetivo de oferecer serviços de TI de alta qualidade e boa relação custo/benefício para as organizações. Um jeito de fazermos isso é compartilhando a infraestrutura básica de software, como o Active Directory. Praticamente todas as organizações de TI implantaram o Active Directory para oferecer serviços de autenticação a seus desktops e servidores Windows. Em vez de manter uma infraestrutura de autenticação à parte para o ambiente Linux (e um conjunto separado de nomes de usuário e senhas), não seria melhor se os computadores com o Linux também usassem o Active Directory? Eu creio que seria. Neste artigo, vou mostrar a você como fazer isso.

Autenticação no Windows

Já faz algum tempo que o Windows vem com um sistema integrado de logon único e autenticação de rede. Antes do Windows 2000, os DCs (controladores de domínio) do Windows NT forneciam serviços de autenticação para clientes Windows usando o protocolo NTLM (NT LAN Manager). Embora o NTLM não fosse tão seguro como se pensava de início, ele era muito útil porque resolveu habilmente o problema da necessidade de manter contas de usuário duplicadas em vários servidores da rede.

A partir do Windows 2000, a Microsoft mudou do NTLM para o Active Directory e seus serviços integrados de autenticação Kerberos. O Kerberos era consideravelmente mais seguro do que o NTLM, além de ser mais bem dimensionado. O Kerberos também é um padrão do setor já usado por sistemas Linux e UNIX, o que abriu caminho para a integração dessas plataformas com o Windows.

Autenticação no Linux

Originalmente, o Linux (e as bibliotecas e ferramentas do GNU executadas nele) não foi criado com um único mecanismo de autenticação. Em consequência disso, os desenvolvedores de aplicativos Linux começaram a criar seu próprio esquema de autenticação. Eles conseguiram fazer isso pesquisando nomes e hashes de senhas em /etc/passwd (o arquivo de texto tradicional que contém as credenciais de usuário do Linux) ou oferecendo um mecanismo completamente diferente (e separado).

O excesso de mecanismos de autenticação resultante disso foi algo difícil de administrar. Em 1995, a Sun propôs um mecanismo chamado PAM (módulos de autenticação conectável). O PAM forneceu um conjunto comum de APIs de autenticação que todos os desenvolvedores de aplicativos poderiam usar, junto com um back-end configurado pelo administrador que permitia vários esquemas de autenticação "conectável". Utilizando as APIs do PAM para autenticação e as APIs NSS (Name Server Switch) para pesquisar informações de usuário, os desenvolvedores de aplicativos Linux poderiam escrever menos código e os administradores do Linux poderiam ter um único lugar para configurar e gerenciar o processo de autenticação.

A maioria das distribuições do Linux vem com diversos módulos de autenticação PAM, inclusive módulos que dão suporte à autenticação em um diretório LDAP e à autenticação usando Kerberos. Você pode usar esses módulos para fazer autenticação no Active Directory, mas existem algumas limitações consideráveis, conforme abordarei neste artigo.

Samba e Winbind

O Samba é um projeto de código-fonte aberto que visa proporcionar integração entre ambientes Windows e Linux. O Samba possui componentes que dão a máquinas Linux acesso a serviços de arquivo e impressão do Windows, além de fornecer serviços baseados em Linux que emulam DCs do Windows NT 4.0. Usando os componentes do cliente Samba, máquinas Linux podem aproveitar as vantagens dos serviços de autenticação do Windows fornecidos por DCs do Windows NT e do Active Directory.

O componente específico do Samba mais interessante para nós nesse projeto chama-se Winbind. O Winbind consiste em um daemon (serviço no linguajar do Windows) executado em clientes Samba que funciona como um proxy para a comunicação entre PAM e o NSS em execução na máquina Linux e o Active Directory em execução em um DC. Especificamente, o Winbind usa Kerberos para autenticação no Active Directory e o protocolo LDAP para recuperar informações de usuários e grupos. O Winbind também oferece serviços adicionais, como a capacidade de localizar DCs usando um algoritmo parecido com o DCLOCATOR do Active Directory e de redefinir senhas do Active Directory comunicando-se com um DC por meio de RPC.

O Winbind resolve alguns problemas que o simples uso do Kerberos com PAM não resolve. Particularmente, em vez de embutir um DC no qual se autenticar, assim como faz o módulo Kerberos PAM, o Winbind seleciona um DC procurando registros de localizador DNS de maneira semelhante à que faz o módulo DC LOCATOR da Microsoft.

Três estratégias de autenticação

Dada a disponibilidade do LDAP, do Kerberos e do Winbind em máquinas Linux, há três estratégias de implementação diferentes que podemos empregar e que permitem à nossa máquina Linux usar o Active Directory para autenticação.

Usando a autenticação LDAP A maneira mais fácil, porém menos satisfatória, de utilizar o Active Directory para autenticação é configurar o PAM para usar a autenticação LDAP, como ilustrado na Figura 1. Embora o Active Directory seja um serviço do LDAPv3, os clientes Windows usam o Kerberos (com fallback para NTLM), e não o LDAP, para fins de autenticação.

A autenticação LDAP (chamada de associação LDAP) passa o nome de usuário e a senha em texto não criptografado via rede. Isso não é seguro e, para a maioria das finalidades, é inaceitável.

Figura 1 Autenticação no Active Directory usando LDAP (Clique na imagem para ampliá-la)

A única maneira de diminuir esse risco de passar credenciais sem criptografá-las é criptografar o canal de comunicação de cliente do Active Directory usando algo como SSL. Embora isso seja certamente factível, impõe o trabalho extra de gerenciar os certificados SSL no DC e na máquina Linux. Além do mais, o uso do módulo LDAP do PAM não permite alterar senhas redefinidas ou expiradas.

Usando LDAP e Kerberos Outra estratégia para aproveitar o Active Directory na autenticação do Linux é configurar o PAM para usar a autenticação Kerberos e o NSS para usar o LDAP a fim de pesquisar informações de usuários e grupos, como ilustrado na Figura 2. Este esquema tem a vantagem de ser relativamente mais seguro e aproveita os recursos "prontos de fábrica" do Linux. No entanto, ele não aproveita os recursos SRV (localização de serviço DNS) publicados por DCs do Active Directory, por isso você é forçado a escolher um determinado conjunto de DCs nos quais deseja ser autenticado. Ele também não oferece uma maneira muito intuitiva de gerenciar senhas do Active Directory prestes a expirar ou, até pouco tempo atrás, de fazer pesquisas sobre membros de grupos.

Figura 2 Autenticação no Active Directory usando LDAP e Kerberos (Clique na imagem para ampliá-la)

Usando o Winbind A terceira forma de usar o Active Directory para autenticação no Linux é configurar o PAM e o NSS para fazer chamadas ao daemon Winbind. O Winbind converterá as diferentes solicitações de PAM e NSS nas chamadas do Active Directory correspondentes usando LDAP, Kerberos ou RPC, dependendo de qual for o mais apropriado. A Figura 3 mostra essa estratégia.

Figura 3 Autenticação no Active Directory usando Winbind (Clique na imagem para ampliá-la)

Nosso plano de implementação

Por causa da avançada integração com o Active Directory, escolhi usar o Winbind no RHEL5 (Red Hat Enterprise Linux 5) para meu projeto de integração do Linux ao Active Directory. RHEL5 é a versão atual da distribuição comercial do Red Hat Linux, sendo bastante conhecido nos data centers empresariais.

Para que o RHEL5 seja autenticado no Active Directory, basicamente são necessárias cinco etapas distintas, como segue:

1. Localize e baixe o Samba e outros componentes dependentes apropriados.
2. Compile o Samba.
3. Instale e configure o Samba.
4. Configure o Linux, especificamente o PAM e o NSS.
5. Configure o Active Directory.

As próximas seções deste artigo descrevem essas etapas mais detalhadamente.

Encontrando o software certo

Uma das maiores diferenças entre o Linux e o Windows é que o Linux consiste em um pequeno kernel de sistema operacional e em uma imensa coleção de componentes que podem ser baixados e instalados separadamente. Isso permite criar configurações muito específicas do Linux otimizadas para certas tarefas, mas também pode tornar a configuração e o gerenciamento de um servidor extremamente complicados. Distribuições diferentes lidam com isso de maneiras diferentes. O Red Hat (e sua prima não-comercial Fedora) usa o RPM (Red Hat Package Manager) para instalar e gerenciar esses componentes.

Os componentes do Linux para Red Hat vêm em dois formatos. Os arquivos RPM contêm arquivos binários que foram pré-compilados e compilados para uma combinação específica de versão de componente, distribuição do Linux e arquitetura de CPU. Por isso, você poderia baixar e instalar, por exemplo, a versão 1.3.8-5 da compilação do CUPS (Common UNIX Printing System) para Fedora versão 10 em execução em uma CPU de arquitetura Intel x86. Considerando que existem inúmeras arquiteturas de CPU diferentes, mais de 100 distribuições do Linux e milhares de pacotes e versões, você percebe que há um número incrível de RPMs binários para escolher.

Por outro lado, os arquivos RPM de origem contêm o código-fonte propriamente dito de um dado pacote. A expectativa é de que você mesmo irá baixar e instalar os códigos-fonte, configurar as opções de compilação e compilar e vincular os binários. A ideia de compilar seus próprios componentes de sistema operacional é assustadora para um adepto do Windows acostumado a instalar tudo o que a Microsoft coloca no CD de instalação do Windows, mas o gerenciador de pacotes torna o processo absolutamente tranquilo e surpreendentemente confiável. O Samba agrupa atualizações de versões e patches de segurança com uma velocidade assombrosa; somente em julho e agosto de 2008, houve quatro lançamentos do Samba 3.2, totalizando mais de 100 correções de bugs e de segurança. Para esse projeto, baixei os códigos-fonte da última versão estável do Samba, a 3.0.31.

Por que baixei os códigos-fonte do Samba em vez de um conjunto pré-compilado de binários? Com certeza, foi isso que tentei fazer primeiro. Depois de muitas horas com um depurador, descobri que os binários que baixei não foram compilados com as opções corretas que permitem a autenticação no Active Directory. Em particular, o código que dá suporte ao mapeamento de IDs do Linux no Active Directory foi desativado nas compilações padrão; por isso, tive de recompilar o Samba com as opções de compilação apropriadas. Falarei mais sobre mapeamento de IDs mais adiante neste artigo.

Apesar de nativamente o Linux ser um kernel pequeno, a distribuição do Red Hat Enterprise vem com muitos pacotes pré-instalados. Normalmente, isso facilita bastante a vida porque você começa com um sistema operacional completo em funcionamento, mas os pacotes pré-instalados às vezes entram em conflito com o software que você deseja instalar depois.

Não incluí o Samba quando instalei o Red Hat (normalmente o Samba é instalado por padrão) porque eu queria usar uma versão mais atual. Porém, a versão mais recente do Samba exige novas versões de várias outras bibliotecas e utilitários que já estavam instalados. Esses tipos de problemas de dependência são muito irritantes, mas é fácil resolvê-los usando o RPM.

Há muitos sites que hospedam pacotes RPM binários. O que usei (simplesmente porque foi o primeiro que encontrei) chama-se PBONE e está em rpm.pbone.net. Ele tem um jeito prático de procurar pacotes e tinha todos os binários de que eu precisava para minha arquitetura de CPU (i386) e a distribuição do sistema operacional (Red Hat Enterprise Linux 5/Fedora 7&8).

Tive de baixar e atualizar os pacotes listados na Figura 4 para compilar e instalar a versão mais recente do Samba, a 3.0 (há uma versão ainda mais recente, a 3.2, que ainda não experimentei). Observe que esses pacotes são para a distribuição do Fedora Core (fc). O Red Hat baseia-se nos mesmos códigos-fonte utilizados pelo Fedora e é completamente interoperável com ele. Os pacotes compilados para o Fedora Core 7 e versões posteriores serão executados no RHEL5 sem a necessidade de modificações. Coloque os arquivos RPM baixados no diretório /usr/src/redhat/RPMS.

Figura 4 Pacotes necessários para compilar e instalar o Samba 3.0.31

samba-3.031-0.fc8.src.rpm	RPM de código-fonte do Samba 3.0.31
gnutls1.6.3-3.fc7.i386	Bibliotecas do protocolo TLS do GNU
gnutils-devel-1.6.3-3.fc7.i386	Arquivos de desenvolvimento de TLS do GNU
popt-1.12-3.fc8.i386	Bibliotecas para análise de argumentos da linha de comando
popt-devel-1.12-3.fc8.i386	Arquivos de desenvolvimento para análise de argumentos da linha de comando
cups-libs-1.2.12-11.fc7.i386	Bibliotecas do Common UNIX Printer System
cups-devel-1.2.12-11.fc7.i386	Arquivos de desenvolvimento do Common UNIX Printer System
cups-1.2.12.11.fc7.i386	Binários do Common UNIX Printer System

Compilando o Samba

A primeira etapa da compilação do Samba é baixar o RPM de origem correto. Eu baixei o RPM de origem do Samba 3.0.31 do site PBONE. Em seguida, coloque o arquivo RPM de origem baixado em /usr/src/redhat/SRPMS, que é o diretório padrão para RPMs de origem durante o processo de compilação.

Abra uma sessão de terminal (a janela de linha de comando, no linguajar do Windows) e acesse a pasta SRPMS. Depois de fazer isso, instale o pacote de origem usando o comando, como mostrado na Figura 5.

Figura 5 Instalando o RPM de origem do Samba (Clique na imagem para ampliá-la)

Caso veja o aviso de erro "user mockbuild does not exist—using root", não se preocupe. Esse erro indica que os utilitários de compilação Mock não estão instalados. O processo de compilação funcionará sem eles.

Em seguida, vá para o diretório /usr/src/redhat/SPECS e edite o arquivo SAMBA.SPEC, que contém as opções de compilação do Samba. Procure a linha que começa com "CFLAGS=" e verifique se a opção "--with-shared-modules=idmap_ad,idmap_rid" está presente. Essa opção assegura que o processo de compilação incluirá o código que converte UIDs (identificadores exclusivos) do Linux corretamente para o Active Directory. A Figura 6 mostra essa opção.

Figura 6 A opção de compilação with-shared-modules (Clique na imagem para ampliá-la)

Em seguida, talvez você tenha de atualizar algumas das bibliotecas do seu computador para compilar e instalar o Samba corretamente; tudo depende de quais versões das bibliotecas estão instaladas. No meu caso, tive de instalar os pacotes listados na Figura 4 usando o comando rpm --install; em alguns casos, precisei usar a opção --force para ignorar alguns dos problemas de dependência.

Para compilar o Samba, vá para o diretório /usr/src/redhat e execute o comando rpmbuild –bb SPECS/samba.spec, como ilustrado na Figura 7. O processo deixará um novo arquivo RPM samba-3.0.31-0.i386 no diretório /usr/src/redhat/RPMS. Instalaremos esse arquivo RPM mais adiante no projeto.

Figura 7 Criando o arquivo RPM binário do Samba (Clique na imagem para ampliá-la)

Configurando o sistema de rede do Linux

Para ser autenticada no Active Directory, sua máquina Linux deve ser capaz de se comunicar com um DC. Você precisa definir três configurações de rede para que isso aconteça.

Primeiro, é importante certificar-se de que a interface de rede da sua máquina Linux está configurada corretamente, seja usando o protocolo DHCP (Dynamic Host Configuration Protocol) ou atribuindo a ela um endereço IP e uma máscara de rede apropriados através do comando ifconfig. No RHEL5, para configurar a rede você deve selecionar Network no menu System | Administration, como mostrado na Figura 8.

Figura 8 Configurando a rede (Clique na imagem para ampliá-la)

Em seguida, verifique se o resolvedor de DNS da máquina Linux está configurado para usar o mesmo servidor de nomes DNS utilizado por seus DCs; na maioria dos casos, é um DC do domínio ao qual você deseja incluir a máquina Linux, supondo que esteja usando o DNS integrado ao Active Directory. Configure o resolvedor de DNS na guia DNS do mesmo utilitário de configuração Network usado para configurar a rede, como mostrado na Figura 9.

Figura 9 Configurando o resolvedor de DNS primário (Clique na imagem para ampliá-la)

Por fim, depois de concluir essas etapas, você deve definir o nome de host do computador Linux para que reflita o respectivo nome no domínio. Embora você possa definir o nome de host usando o aplicativo de configuração Network, não parece que isso sempre funciona corretamente.

Em vez disso, edite o arquivo /etc/hosts diretamente e adicione uma entrada abaixo da entrada localhost.localdomain com o formato <endereço ip> <FQDN> <nome de host>. (Um exemplo seria "10.7.5.2 rhel5.linuxauth.local linuxauth".) Devo ressaltar que, se isso não for feito, será criado um objeto de computador errado no diretório depois que você adicionar o computador Linux ao domínio.

Configurando a sincronização de data/hora do Linux

O protocolo Kerberos é dependente do fato de os sistemas de autenticação terem relógios sincronizados dentro de um valor relativamente pequeno. Por padrão, o Active Directory permite uma defasagem máxima de cinco minutos. Para assegurar que os relógios dos sistemas Linux e do sistema dos DCs permaneçam dentro desse valor, você deve configurar os sistemas Linux para usar o serviço NTP (Network Time Protocol) de um DC.

Em seguida, no servidor Linux, execute o utilitário Date & Time disponível no menu System | Administration e clique na guia Network Time Protocol. Marque a caixa Enable Network Time Protocol e adicione o endereço IP do DC que deseja usar como fonte de tempo da rede. Observe que isso deveria tipicamente ser o DC no domínio que retém a função FSMO (operação flutuante de mestre único) do emulador de PDC (controlador de domínio primário). A Figura 10 é um exemplo de como definir a fonte de tempo da rede Linux.

Figura 10 Configurando o protocolo de tempo da rede (Clique na imagem para ampliá-la)

Configurando PAM e NSS

O PAM e o NSS são a cola entre um aplicativo Linux, como o desktop, e o Winbind. Como muitos serviços do Linux, você configura o PAM e o NSS por arquivos de texto. Examinaremos primeiro a configuração do PAM.

O PAM fornece quatro recursos relacionados à autenticação aos aplicativos que o usam. O recurso de autenticação permite que um aplicativo determine quem o está usando. O recurso de conta fornece funções de gerenciamento de conta não especificamente relacionadas à autenticação, como a restrição de tempo de login. O recurso de senha fornece mecanismos para solicitar e gerenciar senhas. O recurso de sessão executa tarefas de configuração relacionadas ao usuário e de desmontagem para o aplicativo, como registro ou criação de arquivos em um diretório específico do usuário.

O PAM no Red Hat armazena seus arquivos de configuração no diretório /etc/pam.d, que conterá um arquivo de texto para cada aplicativo que usa o PAM para autenticação. Por exemplo, o arquivo /etc/pam.d/gdm contém as informações de configuração do PAM para o GDM (Gnome Desktop Manager), o ambiente de janelas padrão para Red Hat. Cada arquivo de configuração de PAM contém várias linhas, com cada linha definindo algum aspecto do processo de autenticação de PAM. A Figura 11 mostra o conteúdo do arquivo de configuração do PAM para GDM.

Figura 11 Arquivo de configuração de PAM para Gnome Desktop Manager (Clique na imagem para ampliá-la)

Cada entrada em um arquivo de configuração de PAM possui o formulário <grupo de gerenciamento> <controle> <módulo> <parâmetros>, onde <grupo de gerenciamento> corresponde ao recurso ao qual a entrada de configuração pertence: auth, account, password ou session. As palavras-chave de controle, descritas na Figura 12, dizem ao PAM como processar a entrada de configuração. A terceira coluna do arquivo contém o nome de uma biblioteca compartilhada do PAM no diretório /lib/security. Bibliotecas compartilhadas contêm código executável dinamicamente carregável, similar a DLLs no Windows. Termos adicionais após o nome do módulo são parâmetros que o PAM transmite à biblioteca compartilhada.

Figura 12 Palavras-chave de controle do PAM

Palavra-chave	Descrição
Obrigatório	Se o módulo for bem-sucedido, o PAM continuará avaliando as entradas restantes para o grupo de gerenciamento e os resultados serão determinados pelos resultados dos módulos restantes. Se o módulo falhar, o PAM continuará a avaliação, mas retornará falhas no aplicativo de chamada.
Requisito	Se o módulo for bem-sucedido, o PAM continuará avaliando as entradas do grupo de gerenciamento. Se o módulo falhar, o PAM retornará ao aplicativo de chamada sem processamento adicional.
Suficiente	Se o módulo for bem-sucedido, o PAM retornará êxito ao aplicativo de chamada. Se o módulo falhar, o PAM continuará a avaliação, mas os resultados serão determinados por módulos subsequentes.
Opcional	O PAM ignora os resultados do módulo, a menos que seja o único módulo especificado para o grupo de gerenciamento.
Incluir	O PAM inclui o conteúdo do arquivo de configuração do PAM mencionado e processa as entradas contidas nele.

Você pode ver que cada grupo de gerenciamento possui várias entradas. O PAM processa as entradas em ordem chamando o módulo nomeado. O módulo retorna então êxito ou falha e o PAM continua de acordo com a palavra-chave de controle.

Você observará que o arquivo de configuração do PAM para GDM inclui system-auth em todos os seus grupos de gerenciamento. É assim que o PAM estabelece comportamento de autenticação padrão para o GDM. Modificando system-auth, é possível modificar o comportamento de autenticação para todos os aplicativos que incluem o arquivo system-auth em suas configurações de PAM. O arquivo padrão system-auth é mostrado na Figura 13.

Figura 13 Arquivo system-auth do PAM (Clique na imagem para ampliá-la)

O módulo NSS (Name Service Switch) oculta as especificações de armazenamento de dados do sistema do desenvolvedor do aplicativo, da mesma forma que o PAM oculta os detalhes de autenticação. O NSS permite que o administrador especifique a maneira com que os bancos de dados do sistema são armazenados. Em particular, o administrador pode especificar como as informações de nome de usuário e senha são armazenadas. Como queremos que os aplicativos pesquisem informações do usuário no Active Directory usando o Winbind, precisamos modificar o arquivo de configuração do NSS para mostrar isso.

O Red Hat inclui um miniaplicativo gráfico para configurar PAM e NSS chamado de system-config-authentication. Ele cuida da maior parte (mas não todas) das alterações que você precisa fazer nos arquivos system-auth e nss.conf.

Execute o aplicativo system-config-authentication e você verá uma caixa de diálogo como a exibida na Figura 14. Marque a opção do Winbind nas guias User Information (Informações do Usuário) (que configura o arquivo nss.conf) e Authentication (Autenticação) (que modifica o arquivo system-auth).

Figura 14 A caixa de diálogo do system-config-authentication

Clique no botão Configure Winbind (Configurar Winbind) e você verá a caixa de diálogo da Figura 15. Digite o nome do domínio em que deseja que os usuários sejam autenticados no campo Winbind Domain (Domínio do Winbind) e selecione "ads" como o modelo de segurança. Digite um nome de domínio DNS do domínio do Active Directory no campo Winbind ADS Realm (Realm ADS do Winbind). No campo Winbind Domain Controllers (Controladores de Domínio do Winbind), digite o nome de um DC com que deseja que esse sistema Linux se autentique ou um asterisco, indicando que o Winbind deve selecionar um DC consultando registros SRV do DNS.

Figura 15 Configurar caixa de diálogo do Winbind

Selecione o shell de comando padrão apropriado que seus usuários do Active Directory devem possuir; nesse caso, selecionei o shell Bourne-again ou BASH. Não experimente o botão "Join Domain" (Ingressar em Domínio) nesse momento. Você ingressará a máquina no domínio posteriormente.

Há uma alteração adicional a ser feita no arquivo /etc/pam.d/system-auth após tê-lo modificado para suportar o Winbind. Quando um usuário do Linux efetua login, o sistema requer que o usuário possua um diretório base. O diretório base contém várias preferências específicas do usuário e itens de configuração, muito parecido com o Registro do Windows. O problema é que, como você está criando seus usuários no Active Directory, o Linux não criará automaticamente o diretório base do usuário. Felizmente, você pode configurar o PAM para fazer isso como parte de sua configuração de sessão.

Abra o arquivo /etc/pam.d/system-auth, vá para baixo e insira uma linha antes da última linha da sessão chamada "session optional pam_mkhomedir.so skel=/etc/skel umask=0644" (consulte a Figura 16). Essa linha configura o PAM para criar um diretório base a um usuário se um não existir. Ela usará o diretório /etc/skel como um "esqueleto" ou modelo e atribuirá a máscara de permissões 0644 (leitura e gravação para o proprietário, leitura para o grupo primário e leitura para todas as outras pessoas) à nova pasta.

Figura 16 Criando um diretório base para usuários (Clique na imagem para ampliá-la)

Instalando e configurando o Samba

Para instalar os binários do Samba recém-criado, mude para o diretório /usr/src/redhat/RPMS. Todos os arquivos do RPM criados pelo comando rpmbuild aparecerão nesse diretório. Lembre-se que o Samba inclui binários que permitem a um cliente Linux acessar um compartilhamento de arquivo do Windows (ou Samba), bem como código que permite a um sistema Linux agir como um servidor de arquivos do Windows, um servidor de impressoras do Windows e um DC de estilo Windows NT 4.0.

Não precisamos disso tudo para permitir que o Linux se autentique no Active Directory; tudo o que realmente precisamos são os arquivos comuns do Samba e os binários do cliente Samba. Esses arquivos são convenientemente divididos em dois arquivos RPM: samba-client-3.0.31-0.i386.rpm e samba-common-3.0.31-0.i386.rpm. Instale os arquivos RPM usando o comando rpm --install. Veja um exemplo: rpm --install samba-common-3.0.31-0.i386.rpm. (Observe que você precisará instalar o arquivo RPM –common primeiro.)

Depois de instalar os binários do cliente Samba, você deverá modificar a configuração do Samba padrão para certificar-se de que o Winbind trate da autenticação adequadamente com o Active Directory. Todas as informações de configuração do Samba (tanto de cliente como de servidor) podem ser encontradas no arquivo de texto smb.conf, que, por padrão, está no diretório /etc/samba. O Smb.conf pode conter um número enorme de opções de configuração e uma discussão completa sobre o seu conteúdo está além do escopo deste artigo. O site samba.org e as páginas principais do Linux discutem o smb.conf em detalhes.

A primeira etapa é configurar o Winbind para que ele use o Active Directory para autenticação. Você deve definir o modelo de segurança em smb.conf como "ads". O utilitário system-config-authentication já deve ter definido isso para você, mas é sempre bom verificar. Edite o arquivo smb.conf e procure a seção chamada Domain Member Options (Opções do Membro do Domínio). Encontre a linha que começa com "security" e verifique se está escrito "security = ads". A próxima etapa de configuração determina como o Winbind mapeará as entidades de segurança do Windows como usuários e grupos para identificadores do Linux. Isso requer um pouco mais de explicação.

O problema de mapeamento de IDs

Há um grande problema que eu ainda não mencionei com a autenticação de usuários do Linux com o Active Directory e é o problema de UIDs para usuários e grupos. Internamente, nem o Linux nem o Windows se referem a usuários pelo nome de usuário; em vez disso, eles usam um identificador interno único. O Windows usa o SID (identificador de segurança), que é uma estrutura de comprimento variável que identifica unicamente cada usuário dentro de um domínio do Windows. O SID também contém um identificador de domínio único para que o Windows possa distinguir entre usuários em domínios diferentes.

O Linux possui um esquema muito mais simples. Cada usuário em uma máquina Linux possui um UID que é simplesmente um inteiro de 32 bits. Mas o escopo do UID é limitado à máquina em si. Não há garantias de que o usuário com UID 436 em uma máquina Linux é o mesmo usuário com UID 436 em outra máquina Linux. Consequentemente, um usuário terá que efetuar login em cada máquina que ele precise acessar, o que claramente não é uma situação desejável.

Administradores de redes Linux normalmente resolvem esse problema fornecendo autenticação de rede por NIS (Network Information System) ou por um diretório LDAP compartilhado. O sistema de autenticação de rede fornece o UID para o usuário e todas as máquinas Linux que usam esse sistema de autenticação irão compartilhar os mesmos identificadores de grupos e usuários. Nessa situação, usarei o Active Directory para fornecer os identificadores de grupos e usuários únicos.

Existem duas estratégias que posso usar para resolver esse problema. A primeira estratégia (e também mais óbvia) é criar um UID para cada usuário e grupo e armazenar esse identificador com o respectivo objeto no Active Directory. Desse modo, quando o Winbind autenticar um usuário, ele poderá pesquisar o UID para o usuário e fornecê-lo ao Linux como o identificador interno do usuário. O Winbind se refere a esse esquema como mapeamento de ID do Active Directory ou idmap_ad. A Figura 17 mostra o processo de mapeamento de ID do Active Directory.

Figura 17 Mapeamento de ID do Active Directory (Clique na imagem para ampliá-la)

A única desvantagem do mapeamento de ID do Active Directory é que precisamos fornecer um mecanismo para garantir que cada usuário e grupo possua um identificador e que esses identificadores sejam todos únicos na floresta. Consulte o quadro "Configurando o Active Directory para mapeamento de ID do Active Directory", para obter mais informações.

Felizmente, existe outra estratégia de mapeamento de ID que possui muito menos sobrecarga administrativa. Lembre-se de que o SID do Windows identifica unicamente o usuário em um domínio, bem como o domínio em si. A parte do SID que identifica unicamente o usuário no domínio é chamada de RID (identificador relativo) e é, na verdade, um inteiro de 32 bits. Então, o Winbind pode simplesmente extrair o RID do SID quando o usuário efetua login e, em seguida, usa o RID como o UID interno único. O Winbind se refere a essa estratégia como mapeamento de RID ou idmap_rid. A Figura 18 ilustra como o mapeamento de RID realmente funciona.

Figura 18 Mapeamento de RID (Clique na imagem para ampliá-la)

O mapeamento de RID possui o benefício de sobrecarga administrativa zero, mas você não pode usá-lo em um ambiente de vários domínios devido à probabilidade de usuários em diferentes domínios possuírem o mesmo valor de RID. Mas se você possui um único domínio do Active Directory, o mapeamento de RID é a melhor maneira.

Para configurar a estratégia de mapeamento de ID do Winbind, edite o arquivo /etc/samba/smb.conf novamente e adicione a linha "idmap backend = ad" para usar a estratégia de mapeamento do Active Directory ou "idmap backend = rid", se desejar usar a estratégia de mapeamento de RID. Verifique se não existem outras linhas especificando a estratégia de mapeamento no arquivo.

Existem algumas outras opções de configuração que precisamos adicionar ao arquivo smb.conf para o Winbind. Embora tenhamos configurado o PAM para fazer o diretório base para cada usuário quando eles efetuarem login, precisamos dizer ao Winbind qual é o nome desse diretório base. Fazemos isso adicionando a linha "template homedir = /home/%U" ao smb.conf (consulte a Figura 19). Isso informa ao Winbind que o diretório base para cada usuário autenticado usando o Active Directory será /home/<nome de usuário>. Crie o diretório /home com antecedência.

Figura 19 Especificando o nome do diretório base (Clique na imagem para ampliá-la)

Ingressando no domínio e fazendo logon

Agora que a rede, o PAM, o NSS e o Winbind do Samba estão todos configurados adequadamente, é hora de ingressar a máquina Linux no domínio. Você faz isso usando o comando NET do Samba. No prompt do shell, execute "net ads join –U <nome do administrador>". Substitua <nome do administrador> pelo nome de uma conta com privilégios suficientes para ingressar uma máquina ao domínio.

O comando net solicitará a você a senha do usuário. Se tudo funcionar adequadamente, o comando net irá ingressar sua máquina ao domínio. É possível usar Usuários e Computadores do Active Directory para localizar a conta recém-criada do computador.

Você pode testar o estado do ingresso usando uma ferramenta de teste do Winbind chamada wbinfo. Executar a wbinfo –t testará a relação de confiança entre a máquina e o domínio. Executar wbinfo –u lista todos os usuários do domínio e wbinfo –g lista todos os grupos.

Se você ingressar com êxito a máquina Linux ao domínio, a próxima etapa é tentar efetuar login usando uma conta de usuário e uma senha do Active Directory. Faça logoff na máquina Linux e faça logon usando um nome de usuário do Active Directory. Se tudo funcionar adequadamente, você deve poder efetuar logon.

Configurando o Active Directory para mapeamento de ID do Active Directory

Essas informações se aplicam apenas se você estiver usando o mapeamento de ID do Active Directory. Se você decidiu usar o mapeamento de RID, fique à vontade para ignorar esse quadro.

Antes que você possa começar a efetuar logon no seu servidor Red Hat usando uma conta do Active Directory, você precisa fazer algumas alterações no Active Directory em si. Primeiro, o esquema do Active Directory precisa acomodar os atributos usados pelo Winbind para armazenar informações do usuário. Se estiver executando o Windows Server 2003 R2, o esquema está pronto para o uso. Se possuir uma versão anterior do esquema do Active Directory, precisará estendê-la usando o pacote Microsoft Services for UNIX (SFU).

Você pode encontrar mais detalhes sobre o Services for UNIX no TechNet. O SFU também inclui uma página de propriedades adicional para o snap-in MMC (Console de Gerenciamento Microsoft) Usuários e Computadores do Active Directory que permite gerenciar as informações de ID do usuário e ID do grupo que o Linux requer.

Depois que o esquema estiver configurado adequadamente, você terá que fornecer identificadores do Linux a todos os usuários (e os grupos dos quais eles são membros) que possam fazer logon na sua máquina Linux. Isso significa que você precisa definir valores aos atributos uidNumber e gidNumber aos usuários e aos grupos que possam fazer logon nas suas máquinas Linux. Mas você deve estar ciente sobre alguns requisitos desses atributos:

1. O Linux requer um UID para cada usuário autenticado. Como você deseja gerenciar informações do usuário no Active Directory, toda conta de usuário que fará logon em uma máquina Linux deve ter um atributo uidNumber único. O valor específico usado para um uidNumber não é importante, mas ele deve ser único para todos os usuários que possam fazer logon na máquina Linux.
2. Todo usuário do Linux também deve possuir um identificador de grupo padrão, então cada usuário do Active Directory que fará logon em uma máquina Linux também requer um valor para o atributo gidNumber. Esse valor não precisa ser único entre usuários, mas deve identificar unicamente o grupo.
3. Todo grupo no Active Directory deve possuir um valor único para seu atributo gidNumber. A rigor, tudo bem se os grupos não possuem um valor para o atributo gidNumber, mas o Winbind espera, quando autentica um usuário, que cada grupo do qual esse usuário é membro, tenha um valor único de gidNumber. Provavelmente é mais fácil verificar se todos os grupos possuem um valor único de gidNumber.
4. O Winbind espera que cada usuário que ele pesquise no Active Directory seja um membro do grupo de Usuário do Domínio, então ele também espera que o grupo Usuários do Domínio possua um valor para seu atributo gidNumber.

E se não funcionar?

Configurar uma máquina Linux para que ela autentique com o Active Directory usando o Winbind não é um projeto trivial. Existem muitas partes a configurar e muitas coisas que podem dar errado. O fato de que cada versão do Linux e cada versão do Samba é um pouco diferente não ajuda. Mas existem vários lugares que você pode examinar para ajudar a determinar o que está acontecendo.

Primeiro, existe o arquivo de log do sistema Linux, mantido em /var/log/messages. O Samba colocará mensagens nesse arquivo para eventos significativos, como arquivos não encontrados ou configuração incorreta. Além do arquivo de log do sistema, existem também os arquivos de log do Samba e do Winbind. Você pode encontrá-los em /var/log/samba e eles fornecerão algumas informações adicionais.

Você pode aumentar os detalhes (e o volume) das mensagens de log emitidas pelo Winbind modificando seu script de inicialização para definir o nível de depuração. Edite o script do shell /etc/init.d/winbind e adicione "-d 5" ao comando winbindd. Isso aumentará o nível de depuração para 5 (os valores permitidos estão entre 1 a 10), o que fará com que o winbind gere mensagens de erros mais detalhadas.

Se o Winbind estiver avançando até se comunicar com um DC, você pode executar um utilitário de captura de pacote de rede como o Netmon 3.1. Isso permite que você analise exatamente o que o Winbind está tentando fazer. E você também pode inspecionar o log de segurança do Windows no DC, o que mostrará tentativas de autenticação.

Agora que está funcionando, o que você tem?

Se você conseguiu fazer tudo funcionar, agora tem a habilidade de fazer logon no seu sistema Linux usando credenciais mantidas no Active Directory. Essa é uma grande melhoria em relação a gerenciar identidades localmente na máquina Linux ou usar um sistema não seguro como o NIS. Ela permite que você centralize seu gerenciamento do usuário em um armazenamento de identidades: o Active Directory.

Mas existem várias coisas faltando para tornar essa solução realmente útil. Primeiro, obter suporte técnico é uma operação um tanto inexata. A maioria das organizações Linux está um pouco às escuras quando se trata do Active Directory e o suporte obtido da comunidade do Linux depende inteiramente de quem lê sua postagem e como essa pessoa se sente naquele dia.

Também não existem ferramentas de migração ou implantação com o Samba. Se você possui contas existentes do Linux com suas IDs e permissões associadas, terá que garantir manualmente que elas mantenham seus UIDs quando você migrá-las para o Active Directory.

Finalmente, um dos aplicativos mais importantes do Active Directory, a Diretiva de Grupo, ainda não está disponível com o Samba, embora esteja em processo de elaboração. Embora você possa ingressar um sistema Linux no Active Directory com o Samba, não é possível gerenciá-lo usando a Diretiva de Grupo.

Soluções de terceiros

Autenticar máquinas Linux com o Active Directory é claramente uma coisa boa, mas implantar sua própria solução usando o Winbind do Samba é tedioso, se não muito doloroso. Você achava que algum fornecedor de software inovador sairia na frente com uma solução mais fácil de usar e você estava certo.

Existem quatro fornecedores de software comercial que desenvolveram versões fáceis de instalar e usar do que eu demonstrei neste artigo. Eles fornecem o código e as ferramentas de migração para quase todas as versões populares do Linux, UNIX e Apple Macintosh, bem como suporte para gerenciar máquinas Linux usando a Diretiva de Grupo.

As quatro empresas são Centrify, Likewise Software, Quest Software e Symark. Todas as quatro fornecem funcionalidades similares, incluindo gerenciamento de Diretiva de Grupo, por uma ampla variedade de distribuições do Linux. A Likewise Software recentemente abriu o código-fonte de sua implementação, chamada de Likewise Open, embora seu componente de Diretiva de Grupo continue sendo um produto comercial. O Likewise Open estará disponível com várias distribuições principais do Linux. (Divulgação total: enquanto este artigo estava sendo escrito, minha empresa, a NetPro, foi adquirida pela Quest Software.)

Faz sentido compilar seu próprio sistema de autenticação usando o Samba e o Winbind quando existem opções comerciais disponíveis? Se gastar dinheiro com software de integração não estiver no orçamento, fazer a rota de código-aberto com o Samba tem a vantagem de ser algo gratuito. Você também obtém todo o código-fonte, o que pode ser um benefício relevante. Mas migrar máquinas Linux e seus UIDs existentes é um problema muito espinhoso.

Por outro lado, se deseja economizar tempo de instalação e implementação, você possui máquinas Linux existentes que precisa migrar ou preferiria ter alguém para exigir uma resposta autoritativa para a sua pergunta. Então, conhecer uma das soluções comerciais faz sentido. E se você precisar do gerenciamento da Diretiva de Grupo, a alternativa comercial é sua única escolha.

Mas, qualquer que seja o caminho escolhido, integrar a autenticação do Linux com o Active Directory reduz o esforço gasto no gerenciamento de várias contas de usuários, melhora a segurança do sistema e fornece a você um único armazenamento de identidade a gerenciar e no qual fazer auditoria. E essas são todas razões bastante convincentes pelas quais vale a pena tentar.

Gil Kirkpatrick projetou ou desenvolveu dezenas de produtos de software comercial bem-sucedido em sua carreira de 30 anos e é fundador da Directory Experts Conference (agora chamada The Experts Conference). Gil é autor de Active Directory Programming (Programação no Active Directory) e é colaborador assíduo das revistas Windows IT Pro e TechNet Magazine. Em sua função atual como Especialista em residência na NetPro (agora parte da Quest Software), Gil fornece consultoria sobre vários projetos de segurança, identidade e marketing e dá palestras em seminários de tecnologia e em conferências no mundo todo.