Autenticação de servidores CentOS/Red Hat 6 em Windows 2008

Este artigo foi criado para demonstrar o processo de autenticação de servidores CentOS e Red Hat 6 no Windows 2008, utilizando-se dos recursos de LDAP e Kerberos, e o recurso de NSLCD nos clientes (ao invés do SSSD).

[ Hits: 47.856 ]

Por: Ricardo Katz em 13/08/2012


Autenticação LDAP



Após a configuração do ambiente, devemos configurar o sistema operacional de forma a autenticar-se no AD. As seguintes configurações devem ser efetuadas:

NSLCD (Autenticação LDAP)

O NSLCD (local LDAP name service daemon) será utilizado para a autenticação ao LDAP. Antes configurado através do arquivo /etc/ldap.conf (no RHEL 5 e derivados), agora este recurso possui um daemon próprio.

Para configurá-lo, devemos alterar o arquivo /etc/nslcd.conf conforme abaixo (as explicações estão nos comentários do arquivo):

# Versao LDAP
ldap_version 3
# Usuario e grupo para executar o daemon
uid nslcd
gid ldap

# Limite de timeout de bind e de busca
bind_timelimit 30
timelimit 30

# Servidor LDAP e BaseDN
uri ldap://springfield.corp
base dc=springfield,dc=corp

# O SSL ainda não será configurado
ssl no
tls_cacertdir /etc/openldap/cacerts

# usuário e senha de serviço
binddn cn=AuthLinux,cn=Users,dc=springfield,dc=corp
bindpw 12qw!@QW

scope sub
scope   group   sub scope   hosts   sub

# Ignorar lookup de grupos para os usuários de sistema
nss_initgroups_ignoreusers root,nslcd,bin,daemon,mail,nobody,sshd,nscd,ntp

# Caso seja necessário algum filtro, para apenas algum usuário de algum grupo logar
# pam_authz_search (gidNumber=10000)


# Configuracoes de Mapping - AD
pagesize 1000
referrals off
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    passwd uid            sAMAccountName
map    passwd homeDirectory  unixHomeDirectory
map    passwd gecos          displayName
filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    shadow uid            sAMAccountName
map    shadow shadowLastChange pwdLastSet
filter group (objectClass=group)
map    group uniqueMember    member


Após isso, devemos iniciar o daemon do nslcd e colocá-lo na inicialização:

# chkconfig nslcd on
# /etc/init.d/nslcd on


Kerberos 5

A configuração do Kerberos deverá ser feita de forma a validar um usuário, e permitir, entre outras coisas, sua autenticação e posteriores operações (como query de grupos a que pertence, etc).

A configuração deverá ser feita conforme abaixo.

Alterar o arquivo /etc/krb5.conf, conforme abaixo (as explicações estão nos comentários do arquivo):

# Nao validar o hostname do servidor (senao precisa de entradas no DNS e Reverso)
[appdefaults]
  validate = false

# Locais de Logging
[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

# Configuracoes Padrao
[libdefaults]
  # Dominio Padrao - SPRINGFIELD.CORP - Deve ser o mesmo do AD
  default_realm = SPRINGFIELD.CORP
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true

[realms]
  # Configuracao do servidor de KERBEROS
  # Utilizando o nome do DOMINIO, ele vai para o DC

  SPRINGFIELD.CORP = {
    kdc = SPRINGFIELD.CORP
    admin_server = SPRINGFIELD.CORP
}

# Configuracoes de DOMINIO - Qual REALM deve ser usado para qual dominio
[domain_realm]
  springfield.corp = springfield.corp
  .springfield.corp = springfield.corp


Testar a geração de um ticket de autenticação para um usuário qualquer do domínio, como o Administrador:

# kinit -V Administrator@SPRINGFIELD.CORP

A saída seria:
Using default cache: /tmp/krb5cc_0
Using principal: Administrator@SPRINGFIELD.CORP
Password for Administrator@SPRINGFIELD.CORP: [DIGITAR A SENHA]
Authenticated to Kerberos v5


Caso o retorno seja diferente de:
Authenticated to Kerberos v5

A configuração deve ser verificada novamente, pois alguma configuração foi efetuada incorretamente.

Configuração do NSCD e NSSWITCH

Devemos agora, configurar o daemon de cache de logins, e o NSSWITCH, que irá direcionar a autenticação de usuários e grupos para o NSLCD (LDAP), caso não seja encontrado um usuário local.

Por padrão, o arquivo /etc/nscd.conf já vem configurado com parâmetros aceitáveis, sendo necessário apenas descomentar a linha "logfile /var/log/nscd.log", para que o daemon efetue log, caso algo dê errado.

Devemos então, alterar o arquivo /etc/nsswitch.conf, deixando as linhas: passwd, shadow e group, conforme abaixo:

  passwd:    files ldap
  shadow:    files ldap
  group:     files ldap


Por fim, o daemon do NSCD deve ser colocado na inicialização do S.O., e ser iniciado:

# chkconfig nscd on
# /etc/init.d/nscd start


Para verificar o funcionamento correto da configuração, utilizar o comando getent no usuário e grupo criado na etapa de "Pré requisitos":

# getent passwd rkatz

A saída seria:
rkatz:*:10002:10000:Ricardo P. Katz:/home/rkatz:/bin/bash


E:

# getent group Linux
Linux:*:10000:rkatz


Configuração do PAM

A etapa final da configuração é a alteração do PAM (Plugable Authentication Modules), de forma que as autenticações do Sistema Operacional sejam enviadas ao servidor LDAP (Domain Controller).

Adicionalmente, quando um usuário não possuir diretório 'home' no ambiente, o esperado é que o PAM crie esse diretório.

O arquivo /etc/pam.d/system-auth deverá ser alterado para ficar conforme abaixo. O arquivo aqui é um exemplo, sugiro que verifique se não há nenhum mecanismo de autenticação já em uso no ambiente, e adeque as configurações às suas necessidades:

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so


Após as alterações, logar-se em um novo terminal com o usuário criado no AD (no exemplo, o usuário: rkatz), e verificar se o login é autorizado, bem como o diretório home criado.

Verificar também com o comando id, se os grupos a que o usuário pertence são carregados. Caso não funcione, os arquivos /var/log/messages e /var/log/secure podem ser verificados em busca de erros.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução - Pré-requisitos
   2. Configuração do S.O.
   3. Autenticação LDAP
   4. Habilitação de SSL (LDAPs)
Outros artigos deste autor

Criação de um repositório (mrepo) - Red Hat e CentOS 5 (com atualização na RHN para RedHat)

Leitura recomendada

Bloqueio de repetidas tentativas de login ao seu Linux

Configurando uma VPN IPSec Openswan no SUSE Linux 9.3

Servidor de DNS com DNS reverso, DHCP3 e wpad.dat

Mudança de hábito: autenticando usuários em base de dados MySQL

Elastic SIEM - Instalação e Configuração do LAB (Parte I)

  
Comentários
[1] Comentário enviado por removido em 13/08/2012 - 19:17h

Muito bom o artigo !

[2] Comentário enviado por Tiago_Rc2 em 13/08/2012 - 20:29h

rikatz, boa noite.

Primeiramente parabéns pelo excelente artigo. Sou um iniciante do mundo Linux, e estou tentando enteder como funciona de fato uma estrutura Linux dentro de um dominio AD.

Me tire só umas dúvidas:

Caso eu queria colocar um Centos como servidor de arquivos, você acha isso uma boa prática?

E outra, as permissões a usuários ou grupos, posse fazer isso pelo Centos? é possível?


Grato!

[3] Comentário enviado por Leosousa84 em 14/08/2012 - 08:54h


Tiago,

Seria uma boa prática sim, mais esse servidor terá que ter o samba e o winbind configurado e as permissões serão dadas por acl.


[2] Comentário enviado por Tiago_Rc2 em 13/08/2012 - 20:29h:

rikatz, boa noite.

Primeiramente parabéns pelo excelente artigo. Sou um iniciante do mundo Linux, e estou tentando enteder como funciona de fato uma estrutura Linux dentro de um dominio AD.

Me tire só umas dúvidas:


Caso eu queria colocar um Centos como servidor de arquivos, você acha isso uma boa prática?

E outra, as permissões a usuários ou grupos, posse fazer isso pelo Centos? é possível?


Grato!



[4] Comentário enviado por amandahla em 14/08/2012 - 10:24h

Excelente artigo!

[5] Comentário enviado por rikatz em 14/08/2012 - 21:45h

Thiago,

Primeiramente, bem vindo ao mundo Linux ;)

Colocar um CentOS como servidor de arquivos é relativo. Servidor de arquivos para clientes Windows? Para clientes Linux? Servidor FTP? :)

As permissões de usuários e grupos funcionam sim, mesmo com a autenticação via AD / LDAP. O que acontece na prática é que o Windows 2008 + atributos extendidos do AD acabam dando um 'UID / GID' para os usuários e grupos unico, e uma vez que esses identificadores são dados aos usuários, podem ser utilizados internamente no servidor para permissionamento :)

Espero ter mais tirado dúvidas que gerado elas ;)




[3] Comentário enviado por Leosousa84 em 14/08/2012 - 08:54h:


Tiago,

Seria uma boa prática sim, mais esse servidor terá que ter o samba e o winbind configurado e as permissões serão dadas por acl.


[2] Comentário enviado por Tiago_Rc2 em 13/08/2012 - 20:29h:

rikatz, boa noite.

Primeiramente parabéns pelo excelente artigo. Sou um iniciante do mundo Linux, e estou tentando enteder como funciona de fato uma estrutura Linux dentro de um dominio AD.

Me tire só umas dúvidas:


Caso eu queria colocar um Centos como servidor de arquivos, você acha isso uma boa prática?

E outra, as permissões a usuários ou grupos, posse fazer isso pelo Centos? é possível?


Grato!




[6] Comentário enviado por rikatz em 14/08/2012 - 21:45h

Obrigado! :)


[4] Comentário enviado por amandahla em 14/08/2012 - 10:24h:

Excelente artigo!



[7] Comentário enviado por rikatz em 14/08/2012 - 21:46h

Obrigado!


[1] Comentário enviado por Thalysson S em 13/08/2012 - 19:17h:

Muito bom o artigo !



[8] Comentário enviado por andrefreire em 15/08/2012 - 13:32h

Boa tarde !

Parabéns pelo artigo.

Nesse tipo de solução o host Linux não ingressa no domínio Windows em vez disso usa uma conta de serviço para fazer as consultas.

Essa solução poderia ser utilizada para autenticação do squid por exemplo ?

[9] Comentário enviado por rikatz em 15/08/2012 - 14:44h

Boa tarde:

Obrigado!

Então, exatamente, eu não queria que a máquina ingressasse no domínio, isso depende da abertura de muitas portas, etc.

Como as contas do AD ficam dentro do servidor LDAP do Windows 2008, você simplesmente autenticando o seu squid no LDAP (nem precisa do kerberos) já funciona normalmente.

Veja um exemplo:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Ldap

Se você fosse utilizar esse artigo como referência, a linha de autenticação ficaria como: 'auth_param basic program /usr/lib/squid/squid_ldap_auth -v 3 -b "dc=springfield,dc=corp" -D cn=AuthLinux,cn=Users,dc=springfield,dc=corp -w 12qw!@QW -f uid=%s springfield.corp'

Ats

[8] Comentário enviado por andrefreire em 15/08/2012 - 13:32h:

Boa tarde !

Parabéns pelo artigo.

Nesse tipo de solução o host Linux não ingressa no domínio Windows em vez disso usa uma conta de serviço para fazer as consultas.

Essa solução poderia ser utilizada para autenticação do squid por exemplo ?


[10] Comentário enviado por fabiocruz27 em 28/09/2012 - 11:44h

Prezado, rikatz


Primeiro parabéns pelo artigo ficou otimo.

Só me tira uma duvida para eu utilizar os usuarios e grupos do ad, eu preciso sempre configurar o NIS Domain , para o linux entender que os usuarios e os grupos fazem parte dele.

Obrigado

[11] Comentário enviado por removido em 15/10/2012 - 13:37h

Amigo gostei do artigo...

Tenho uma pergunta: Usando o método explicado aqui pode ingressar uma máquina com o GNU/Linux instalado no domínio do active directory ?

será necessário algo mais ?

[12] Comentário enviado por digaovaa em 05/09/2013 - 15:45h

Boa tarde, excelente artigo, funcionou perfeitamente. Única coisa que não está funcionando é quando entro a primeira vez com o usuário, ele não cria o diretório /home/usuario.. se eu entrar pelo shell, ele cria e assim quando logar no gnome, ele vai criar as outras pastas (Documents, Downloads,etc). sabe dizer o que pode ser?

obrigado e um abraço

[13] Comentário enviado por ddias em 10/09/2013 - 15:02h

Parabens, excelente artigo! Apenas estou com uma dúvida, onde posso realizar o download do Unix Integration Tools?

Obg.!

[14] Comentário enviado por ddias em 10/09/2013 - 16:48h

Parabens, excelente artigo! Apenas estou com uma dúvida, onde posso realizar o download do Unix Integration Tools para Windows Server R2 x64

Obg.!

[15] Comentário enviado por rikatz em 10/09/2013 - 16:53h

Olá,

Na verdade o Integration Tools você instala como 'Role' (ou Feature, não lembro) do Windows direto no servidor que vai ser o AD




[13] Comentário enviado por ddias em 10/09/2013 - 15:02h:

Parabens, excelente artigo! Apenas estou com uma dúvida, onde posso realizar o download do Unix Integration Tools?

Obg.!



[16] Comentário enviado por marcelo.cheveau em 28/11/2013 - 09:49h

Gostaria de saber como faço para configurar no Linux um meio em que alguns usuários acessam a internet e todas as pastas e outros não acessam a internet e acessam algumas pastas e os que não estão cadastrados não acessam nada?

[17] Comentário enviado por Virgil_Dantas em 27/07/2015 - 10:11h

bom dia, porque utilizar NSLCD nos clientes ao invés do SSSD??


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts