This project is read-only.
Autenticação simples

Ainda que existam várias formas de se realizar autenticação no sistema, a mais apropriada e que permite melhor aproveitar as vantagens oferecidas pelo Active Directory, é a utilização do Kerberos como meio de autenticação, e as ferramentas ldap para o acesso à informação do usuário com o qual se esteja autenticando.

Para isto, é necessário que seja feita a instalação do cliente de kerberos 5 e libpam-krb 5, que podem ser encontradas em todas as distribuições atuais do Linux.

Para realizar a autenticação, é importante levar em conta vários detalhes. Daqui em diante convém ter uma série de subsistemas corretamente configurados para que, tanto as autenticações com Kerberos quanto com LDAP tenham sucesso. Uma delas é o relógio, a hora do sistema. O Kerberos é, normalmente, bastante estrito e meticuloso. Uma das características a levar em conta é o clockskew, que é a diferença de horário entre as partes negociantes, ou seja, entre o servidor e o cliente. No arquivo de configuração pode-se especificar qual diferença de horário pode existir entre os dois para que a negociação ocorra com êxito. Normalmente, como padrão, isto se trata de minutos. Por isto, é interessante fazer com que as máquinas envolvidas no processo de autenticação não permitam que sua hora local possa ser ajustada manualmente, mas sim, que seja constantemente sincronizadas com um servidor de horário NTP.

Outro tema que requer bastante atenção e que certamente ajudará a evitar muitos problemas e surpresas é a resolução de nomes. É conveniente que, no servidor DNS interno, no caso o do Windows 2003 Server (configurado, de acordo com este handbook, diretamente no processo de instalação do Active Directory), esteja preparado para as resoluções de nomes tando na forma direta como reversa das máquinas da rede local, ou, ao menos, para as máquinas usadas em exercícios de autenticação.

Primeiro, é necessário configurar o arquivo /etc/krb5.conf, onde estão definidos os realm (reinos, domínios) que são acessados para o intercâmbio de informação do kerberos.

[libdefaults]
	default_realm = NDOS.INFO
[realms]
	NDOS.INFO = {
		kdc = 192.168.0.10
		admin_server = 192.168.0.10
	default_domain = ndos.info
	}
[domain_realm]
	.ndos.info = NDOS.INFO
	ndos.info = NDOS.INFO


Feita esta configuração, já é possível testar a comunicação com o Active Directory para verificar a autenticação com um dos usuários e se ocorre a entrega do TGT por parte do mesmo.

# kinit lbosque
Password for lbosque@NDOS.INFO: 


Com o comando klist pode-se ver o ticket que foi recebido através da autenticação realizada anteriormente:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: lbosque@NDOS.INFO

Valid starting     Expires            Service principal
01/10/07 11:38:39  01/10/07 21:38:43  krbtgt/NDOS.INFO@NDOS.INFO
renew until 01/11/07 11:38:39

Kerberos 4 ticket cache: /tmp/tkt0
	klist: You have no tickets cached


Uma vez que este teste tenha se completado, pode-se eliminar este ticket para que não cause confusão mais adiante. O comando para eliminá-lo é o seguinte:

# kdestroy


Agora a seguinte questão se apresenta: com o kerberos é possível realizar a autenticação do usuário e, ainda que esta situação pareça pouco produtiva, no caso de existirem vários serviços "kerberizados" dentro da rede, isto economiza muito tempo e evita complicações. O que não é possível fazer com o kerberos é obter o resto da informação do usuário com o qual foi feita a autenticação, tais como o seu shell, o id e gid Unix do usuário entre outros dados.

Esta informação pode ser recuperada de diversas maneiras no momento do login. Duas mais conhecidas são através do nssldap ou através de winbind com o samba. Neste capítulo será usado o nssldap.

Para tal, é necessário, antes de mais nada, instalar ou compilar o pacote libnss-ldap, que se encontra disponível na maioria das distribuições atuais do Linux.

Depois disso, é necessário prestar atenção ao arquivo de configuração do nssldap, que normalmente se encontra em /etc/ldap.conf ou /etc/libnss-ldap.conf.

As opções utilizadas neste tutorial são as seguintes:

host 192.168.0.10
base dc=ndos,dc=info
uri ldap://ndos-w2k3.ndos.info/
ldap_version 3

binddn cn=Administrador,cn=Users,dc=ndos,dc=info
bindpw foobar


As duas últimas linhas indicam que o nss-ldap realizará a busca de usuários tentando realizar uma autenticação simples, usando o usuário Administrador no binddn. Isto tem múltiplas implicações que devem ser levadas em conta. Se o propósito é deixar a rede segura, não é conveniente deixar uma aplicação que, no caso de uma rede grande funcione em múltiplas máquinas, tenha em seu arquivo de configuração o dn e a senha do usuário administrador do domínio.

No caso em que a busca de informação seja em uma árvore OpenLDAP, isto, por padrão, seria possível. Mas o Active Directory, por padrão, obriga a realização de um binddn válido para poder realizar qualquer tipo de consulta na árvore.

Mesmo que isto possa ser facilmente alterado, não é conveniente que o seja, já que o Active Directory foi projetado para ser bastante polivalente, de tal forma que possa centralizar uma quantidade muito grande de informações e fazer com que muitos outros serviços dependam dele. Assim, como não se conhece a fundo todas as implicações e riscos que podem ser criadas se este diretório estiver totalmente aberto, o melhor é aceitar o que é imposto como padrão.

Outra forma menos radical é criar um usuário na árvore LDAP do Active Directory que seja capaz de fazer as consultas suficientes que o libnss-ldap requer para completar uma autenticação em Linux. Desta forma, no parâmetro binddn se pode substituir o Administrador pelo usuário escolhido, assim como seu bindpw pela senha que se designou a este usuário no Active Directory.

Note que, para realizar um binddn no LDAP do Active Directory, realizando uma consulta na árvore, não é necessário inicializar os valores Unix deste usuário no Active Directory.

A seguir, são apresentados outros parâmetros importantes para esta situação:

pam_filter objectclass=user
pam_login_attribute sAMAccountName
pam_lookup_policy yes
pam_password exop

nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid msSFU30Name
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute cn sAMAccountName
nss_map_objectclass posixGroup group


Estes últimos parâmetros referem-se às equivalências entre os atributos usados pelo Active Directory e os atributos que o OpenLDAP usa em seu nis.schema para armazenar os valores das contas POSIX. Já que o LDAP é um padrão que se pode implementar de forma livre e aceita todos os tipos de modificações ou extensões aos esquemas de uma implementação ou outra, pode existir variação entre estes atributos. Desta forma, é necessário estabelecer um mapeamento entre o cliente que fará as consultas (neste caso, o libnss-ldap) e os atributos usados no diretório servidor. Mesmo que o libnss-ldap.conf venha com uma série de parâmetros padrão, indicados para um ou outro tipo de diretório, é necessário prestar atenção aos que são indicados para o Services For Unix (SFU), que podem variar entre uma versão e outra, estar desatualizados, ou conter alguma ambigüidade com outros parâmetros mapeados de maneira distinta no mesmo arquivo. Aqui, os mapeamentos mostrados acima são os necessários para conseguir realizar corretamente a autenticação no Linux com contas de usuários criadas no Active Directory, com o SFU 3.5.

Para comprovar que as informações dos usuários que foram introduzidas no arquivo de configuração estão corretas, apenas necessita-se tentar fazer uma consulta com ldapsearch da seguinte forma:

ldapsearch -x -D cn=Administrador,cn=Users,dc=ndos,dc=info -b cn=Users,dc=ndos,dc=info -wfoobar


O comando deverá retornar toda a informação existente debaixo do continente (container) "Users", como, por exemplo, os usuários e grupos que existam no Active Directory (todos, e não apenas os que tenha a informação Unix válida).

Com certeza, os parâmetros dessa consulta ldapsearch tem que ser modificados, dependendo dos valores de cada usuário, com seu nome de domínio, usuário de busca do Active Directory (que, como comentamos previamente, é recomendável que não seja o Administrador), senha e outros.

Da mesma forma que a consulta realizada com uma autenticação simples com binddn e senha, as consultas que serão feitas com libnss-ldap também serão deste tipo. Adiante veremos como uma consulta pode ser feita de um modo um pouco mais seguro.

Agora que, tanto o kerberos como o libnss-ldap estão configurados corretamente, um para autenticar e outro para recuperar a informação do usuário autenticado, respectivamente, apenas é preciso informar ao sistema Linux que isto deve ser feito automaticamente. Por padrão, um cliente Linux tentará autenticar um usuário e sua senha em sua própria base /etc/passwd e /etc/shadow, assim como tentará recuperar a informação deste usuário destes mesmos lugares.

A forma de dizer ao Linux que tente autenticar de outra fonte é através da modificação do sistema pam (Pluggable Authentication Modules). Este sistema é composto de vários arquivos, mas no momento serão modificados apenas três deles, conforme abaixo:

/etc/pam.d/common-auth

# /etc/pam.d/common-auth - authentication settings common to all services
auth    sufficient      pam_unix.so nullok_secure
auth    sufficient      pam_krb5.so ccache=/tmp/krb5cc_%u use_first_pass
auth    required        pam_deny.so


Isto quer dizer o seguinte: o sistema irá tentar autenticar, inicialmente, na base de usuários Unix local e, caso consiga, passará à fase seguinte do processo de login. Caso contrário, tentar-se-á autenticar com o módulo do kerberos 5, usando a configuração anteriormente definida em /etc/krb5.conf, com o mesmo usuário e senha usando o servidor kerberos indicado. Como antes, em caso de sucesso, passa-se a fase seguinte do processo de login. Não conseguindo, o pam negará o login e retornará ao princípio para que uma nova autenticação seja tentada.

/etc/pam.d/common-account

account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so


/etc/pam.d/common-session

session required pam_unix.so
session optional pam_krb5.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022


É necessário prestar também atenção a este último módulo incluído nesta parte da sessão. Ele se encarrega de criar as pastas de usuário no sistema no caso em que, se o processo de autenticação que passou pelas sessões auth e account, seja o de um usuário que está fazendo o login no sistema pela primeira vez, estando, neste caso, em um diretório remoto e não como um usuário local.

Chegando a este ponto, o pam já é capaz de realizar uma autenticação com o módulo do kerberos em um servidor kerberos remoto (o que é, realmente, o caso do Active Directory). Mas isto não é suficiente, já que, para que a autenticação tenha sucesso, o Linux necessita de mais informações do usuário para completar o processo de login. Para isto, anteriormente, já foi configurado o libnss-ldap. Agora, só resta indicar ao encarregado da resolução de nomes do Linux, o nsswitch, que não se limite a consultar usuários, grupos e senhas em seus arquivos locais, mas que também os consulte em uma fonte LDAP configurada no libnss-ldap.conf. Para isto, é necessário apenas modificar o seguinte arquivo:

/etc/nsswitch.conf

passwd: compat ldap
group: compat ldap
shadow: compat ldap


É realmente importante avaliar esta situação com tranqüilidade. Muitos podem pensar que isto não é necessário, que afeta a velocidade da resolução de nomes ao ter-se duas fontes de informação. É altamente desaconselhável deixar unicamente a fonte de dados LDAP e eliminar compat, ou no caso de outros "files" Linux, já que, uma falha de comunicação ou de autenticação com o diretório LDAP resultaria na impossibilidade de se fazer login no sistema, mesmo com o usuário root. Neste caso, a única solução seria iniciar uma sessão monousuário (single user), implicando na presença física do administrador, tipicamente traduzida em grande perda de tempo e dinheiro em um sistema crítico.

Algo bastante interessante e que irá livrar o administrador de rede de muitos imprevistos é a instalação do nscd, um serviço (daemon) de cache (armazenamento temporário de informações). Este serviço se encarrega de armazenar operações de consulta de usuários, grupos, senhas e máquinas de maneira que as mesmas estejam disponíveis para a consulta seguinte. Isto provoca dois efeitos: 1) agiliza muito as consultas, o que pode ser bastante crítico, por exemplo, em uma grande rede, como uma formada por Active Directory, servidores de arquivos com ACLs e múltiplas máquinas em um domínio; 2). permite melhorar a segurança do libnss-ldap. Por padrão, o libnss-ldap.conf não é legível por todos os usuários, o que exige a troca das permissões de leitura para que o nsswitch possa lê-lo e usar o LDAP no momento do login do usuário. Ao usar o nscd permite-se que o nsswitch consulte este serviço, sem a necessidade de leitura direta da informação do libnss-ldap.conf.

Se tudo saiu bem, os usuários devem poder agora autenticar-se corretamente no sistema Linux.

Seguindo o mesmo padrão de autenticação, mas com rápidas mudanças, pode-se, como comentado anteriormente, alterar um pouco o funcionamento do libnss-ldap de forma que a comunicação ocorra de forma um pouco mais segura. Isto se dá fazendo com que o ldap faça a consulta na árvore do LDAP do Active Directory com um método de autenticação com SASL, ao invés de um binddn simples. A forma de se conseguir isto é fazer com que o LDAP use como elemento autenticador a informação de um cache de usuários do kerberos.

Como vimos anteriormente, quando é feita uma autenticação em um servidor kerberos com êxito, o cliente recebe um "ticket" ou TGT, o qual tem uma validade limitada, definida pelo servidor Kerberos. Esta informação do "ticket" fica normalmente armazenada no sistema, de forma que outro serviço possa usá-la para ter acesso a um serviço remoto "kerberizado". Este é exatamente o propósito agora. A intenção é que o libnss-ldap utilize a informação armazenada de um usuário do Active Directory para realizar sua consulta por meio do SASL, sem a necessidade de fazer um binddn no Active Directory.

Com a configuração previamente estabelecida do kerberos, faz-se uma autenticação com kinit, da mesma forma que foi feita no começo desta seção:

# kinit lbosque
Password for lbosque@NDOS.INFO:


Com o klist pode-se ver o "ticket" recebido através do processo de autenticação anterior:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: lbosque@NDOS.INFO

Valid starting 		Expires 			Service principal
01/10/07 11:38:39 	01/10/07 21:38:43	krbtgt/NDOS.INFO@NDOS.INFO
renew until 01/11/07 11:38:39

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached


Agora, simplesmente executando o comando ldapsearch, será suficiente para se ter sucesso na busca. Isto ocorre pois, por padrão, o ldapsearch, não especificado com o parâmetro -x que se deseja utilizar uma autenticação simples, tenta utilizar o SASL. Deve se levar em conta que, para realizar uma operação, não só com ldapsearch, como com qualquer outra ferramenta ou serviço que precise do SASL, o sistema deve possuir as bibliotecas correspondentes instaladas. Neste caso seriam necessárias as bibliotecas para a autenticação SASL com GSSAPI e kerberos.

#ldapsearch
SASL/GSSAPI authentication started
SASL username: lbosque@NDOS.INFO
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# ndos.info
dn: DC=ndos,DC=info
objectClass: top
objectClass: domain
objectClass: domainDNS
.
.
.


Logo no início pode-se comprovar que o ldapsearch está utilizando SASL/GSSAPI para a autenticação no Active Directory, já que, como comentado previamente, este não permite, por padrão, consultas anônimas. Também vale destacar que, automaticamente, está sendo usado para esta autenticação o usuário que estava armazenado, proveniente da autenticação com kerberos, que é lbosque@NDOS.INFO.

Agora apenas falta ajustar alguns parâmetros para que o libnss-ldap utilize este método de autenticação.

A situação ideal seria que, durante o processo de login, o libnss-ldap utilizasse o "ticket" recebido do usuário que está se autenticando, de forma que, cada usuário, fosse autosuficiente na obtenção de sua própria informação Unix em cada processo de login. O problema é que, atualmente, isto não é possível. A solução mais próxima disto é criar um usuário no Active Directory de forma que, ao receber seu "ticket" no sistema Linux, o libnss-ldap o use sempre para as consultas por meio do SASL. Qualquer leitor que tenha chegado até este ponto pensará que isto supõe um problema, já que para que o cliente do kerberos (no caso, a máquina Linux) receba este "ticket", já há a necessidade de uma autenticação, por exemplo, com kinit, implicando que o usuário digite sua senha de forma interativa. Para evitar isto existem os keytab, arquivos que irão conter basicamente usuários e senhas, mas de forma não excessivamente legível. Para gerar o keytab deve-se seguir os passos a seguir.

Primeiro é necessário ter no Windows 2003 Server uma ferramenta capaz de fazer isto. Por padrão, nenhuma está disponível, mas pode-se obter uma no site da Microsoft. O pacote a ser obtido chama-se Windows Server 2003 Support Tools, que contém muitas ferramentas úteis para a administração do servidor. A que nos interessa agora é a chamada ktpass.

Depois de instalado, o pacote terá que criar, no Active Directory, um usuário que o libnss-ldap irá utilizar posteriormente. Para evitar confusão, pode-se dar o nome da máquina a partir da qual ele será utilizado. Em nosso exemplo: ndos-cliente1.

Agora, para gerar o keytab, a partir do Windows 2003 Server, com os dados deste usuário, deve-se executar o seguinte o comando:

ktpass -ptype KRB5_NT_PRINCIPAL /princ nssldap/ndos-cliente1@NDOS.INFO /mapuser 
ndos-cliente1@NDOS.INFO /pass <senha_usuario> /out <caminho_do_arquivo>ndos-cliente1.keytab


Claro que, uma vez mais, cada administrador deverá tomar cuidado com esta informação e ajustar os dados deste comando ao seu ambiente. Se tudo correr bem, esta operação irá gerar o keytab e uma saída, na tela, similar a esta:

Targeting domain controller: ndos-w2k3.ndos-info
Using legacy password setting method
Successfully mapped nssldap/ndos-cliente1 to ndos-cliente1.
Key created.
Output keytab to c:\ndos-cliente1.keytab:
Keytab version: 0x502
keysize 64 nssldap/ndos-cliente1@NDOS.INFO ptype 1 (KRB5_NT_PRNCIPAL) vno 
15 etype 0x17 (RC4-HMAC) keylength 16 (0xd0fc81746c2bed1da5d505b491634ce5)


Nota: Pode existir o caso em que, apesar de parecer que o mapeamento do usuário tenha sido feito corretamente, isto não seja verdade. Para corrigir isto, uma outra ferramenta dos Support Tools permite que o mapeamento seja feito manualmente, da seguinte forma:

ksetup /MapUser nssldap/ndos-cliente1@NDOS.INFO ndos-cliente1


Agora é necessário enviar este keytab, de maneira segura, já que se trata da informação de um usuário e senha do Active Directory, ao cliente Linux a partir do qual o libnss-ldap o utilizará.

Uma vez transferido, a ferramenta ktutil pode ser usada para acrescentar esta nova informação a um keytab que possa já existir nesta máquina:

# ktutil
ktutil: rkt /root/ndos-cliente1.keytab
ktutil: list
slot KVNO Principal

-------------------------------------------------------------------------------

1 5 nssldap/ndos-cliente1@NDOS.INFO
ktutil: wkt /etc/krb5.keytab
ktutil: quit

# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal

-------------------------------------------------------------------------------

5 nssldap/ndos-cliente1@NDOS.INFO

# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

# kinit -k nssldap/ndos-cliente1
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nssldap/ndos-cliente1@NDOS.INFO

Valid starting Expires Service principal
01/12/07 01:02:21 01/12/07 11:02:27 krbtgt/NDOS.INFO@NDOS.INFO
renew until 01/13/07 01:02:21

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached


Após todo este processo, pode-se comprovar, efetivamente, que ao possuir o keytab gerado a partir do servidor, não é mais necessário fazer com que o usuário digite interativamente sua senha no momento de fazer a autenticação, por exemplo, com o kinit.

O problema que aparece nesta situação é que o ldap não pode usar um keytab para fazer a autenticação com SASL, já que tem que usar o cache de um "ticket" do kerberos de um usuário autenticado. Então, já que os "tickets" resultantes de uma autenticação com kerberos, por exemplo, com kinit, tem duração limitada, para assegurar-se que o ldap tenha sempre armazenado este "ticket", pode-se introduzir uma linha no cron do Linux para que a cada tempo pré-determinado seja feito um kinit com o keytab gerado, renovando, assim, a validade do "ticket".

Por exemplo:

* */2 * * * /usr/bin/kinit -k -c /etc/.ldapcache nssldap/ndos-cliente1 && chmod a+r /etc/.ldapcache


Desta maneira, o cache do "ticket" resultante da autenticação deste usuário sempre estará presente, pois o libnss-ldap sempre poderá utilizá-lo para fazer consultas de informação de usuários através da conexão SASL/GSSAPI com este cache.

Agora que tudo está pronto, simplesmente é necessário modificar as seguintes linhas do arquivo libnss-ldap.conf para que, ao invés de fazer um binddn no LDAP do Active Directory, utilize o cache do "ticket" do usuário do qual falou-se até agora.

Em primeiro lugar, estas duas linhas devem ser comentadas ou eliminadas:

binddn cn=Administrador,cn=Users,dc=ndos,dc=info
bindpw foobar


E as linhas a seguir acrescentadas:

use_sasl on
sasl_authid nssldap/ndos-cliente1
SASL_MECH GSSAPI
sasl_secprops maxssf=0
krb5_ccname FILE:/etc/.ldapcache


Pronto, agora você já pode se autenticar a partir do Linux no Active Directory de forma segura.


Capítulo anterior | Índice | Próximo capítulo

Last edited Sep 14, 2007 at 8:11 PM by joicekafer, version 21

Comments

No comments yet.