Um desafio fundamental para os administradores de sistemas de qualquer datacenter é tentar coexistir em ambientes heterogêneos. Utilizando sempre a melhor solução de cada tecnologia de sistema operacional (normalmente Windows e Linux).

Gerenciamento de usuários e autenticação é de longe um dos mais dos problemas mais dificies de resolver. A maneira mais comum de resolver esse problema é usar um servidor de diretório. O Active Directory (AD) é um serviços de diretório criado pela Microsoft para rede de domínio do Windows. O computador em que o Active Directory está sendo executado são chamados de domain controller (em português, controladores de domínio).

O Active Directory é uma implementação de serviço de diretório no protocolo LDAP que armazena informações sobre objetos em rede de computadores e disponibiliza essas informações a usuários e administradores desta rede. Serve como um local centralizador para administração e segurança de rede. É responsável pela autenticação e autorização de todos os usuários e computadores dentro de uma rede de domínio do Windows, atribuindo e aplicando políticas de segurança para todos os computadores em uma rede. Por exemplo, quando um usuário faz logon em um computador que faz parte de um domínio do Windows, é o Active Directory que verifica sua senha e especifica se ele ou ela é um administrador do sistema ou usuário normal.

Este documento explica como integrar um host Linux ao um domínio existente do Windows Active Directory. Antes de continuar, você deve ter um domínio do Active Directory existente e ter um usuário com os direitos apropriados no domínio para: consultar usuários e adicionar contas de computador (domain join).

Este documento não é um guia completo do Active Directory nem das demais tecnologias aqui citadas.

Ambiente

Em meu ambiente de laboratório, o domínio usando é jonatasti.eti.br e o servidor em que o domínio esta sendo executado é WIN-VSRKDJROOAH.jonatasti.eti.br. O mesmo esta configurado como um server time.

Active Directory em Windows Server 2008 R2;

• Domain: jonatasti.eti.br
• Domain controller: WIN-VSRKDJROOAH.jonatasti.eti.br

Linux Server;

• VM Guest RedHat Entreprise 5.11;
• VM Guest RedHat Entreprise 6.7;
• VM Guest RedHat Entreprise 7.3;
• VM Guest Oracle Linux 6.5;

Comunicação com os Domain Controllers

A tabela a seguir lista os requisitos de porta para estabelecer comunicação DC a DC em todas as versões do Windows Sever começando com o Windows Server 2003.

São necessárias portas adicionais para comunicação entre um domain controlle somente leitura (RODC) e uma escrita DC .

Para maiores informações, https://technet.microsoft.com/en-us/library/8daead2d-35c1-4b58-b123-d32a26b1f1dd

Autenticando RHEL 6 e 7 SSSD com Active Directory em Windows Server 2008 R2

SSSD é um daemon de sistema. Sua principal função é fornecer acesso a identidade e autenticação de recursos remotos através de uma estrutura comum que pode fornecer cache e suporte offline para o sistema. Fornece módulos PAM e NSS e, no futuro, as interfaces baseadas em D-BUS fornecerão informações ampliadas sobre o usuário.

Ele também fornece um banco de dados para melhor armazenar usuários locais, bem como dados de usuário estendido.

Pacotes Requeridos:

Como o daemon SSSD está sendo usado, os pacotes nss-pam-ldapd e pam_ldap podem ser removidos:

yum erase nss-pam-ldapd pam_ldap

Certifique-se de que os seguintes pacotes estejam instalados:

yum install sssd oddjob oddjob-mkhomedir adcli samba-common ntpdate ntp authconfig krb5-workstation

Importante!

Para que tudo funcione corretamente, o seguinte passos devem ser configurado em ambos os servidores:

• NTP: sincronização de tempo é necessária, se a diferença de tempo é mais de 5 minutos autenticação falhará.
• DNS: A modificação do /etc/hosts para um FQDN adequado seguindo o exemplo deste documento.

Setup

É possível integrar um linux a um domínio do Active Directory facilmente com o comando realm. É fácil de usar, seguro e ao usa-lo ele configura o arquivo sssd.conf por default.

Se você ainda não ouviu falar sobre o realmd, confira a documentação. Em resumo, o realmd torna a inscrição do cliente tão fácil quanto:

# realm join domain.com

No entanto, realmd depende de alguns softwares que não estão disponíveis em plataformas estáveis usadas na produção, como RHEL 6.x. Ainda assim, é possível usar alguns dos componentes que o realmd constrói separadamente e tem uma experiência razoavelmente fácil de usar. Neste post, vou mostrar como, usando um pacote chamado adcli, que normalmente é apenas um bloco de construção de realmd.

Voltando para nossa VM Linux. Devemos configurar o AD como nosso DNS, configurando o arquivo /etc/resolv.conf como o exemplo a seguir:

[root@rhel-6 ~]# cat /etc/resolv.conf 
nameserver 192.168.60.135
nameserver 192.168.60.2

E o também o arquivo /etc/hosts:

[root@rhel-6 ~]# cat /etc/hosts
... omitindo saida ...
192.168.60.131 rhel-6.jonatasti.eti.br rhel-6
192.168.60.135 WIN-VSRKDJROOAH.jonatasti.eti.br dc.jonatasti.eti.br

Obs: Certifique-se que o selinux e iptables estejam desligados.

Já possível obter informações do nosso domínio, com o comado adcli.

[root@rhel-6 ~]# adcli info jonatasti.eti.br
[domain]
domain-name = jonatasti.eti.br
domain-short = JONATASTI
domain-forest = jonatasti.eti.br
domain-controller = WIN-VSRKDJROOAH.jonatasti.eti.br
domain-controller-site = Default-First-Site-Name
domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret ads-web
domain-controller-usable = yes
domain-controllers = WIN-VSRKDJROOAH.jonatasti.eti.br
[computer]
computer-site = Default-First-Site-Name

O comando a seguir funciona no RHEL 5 e 6. Certifique-se de que o pacote authconfig esteja totalmente atualizado no RHEL 5, caso contrário o authconfig não terá os parâmetros de linha de comando sssd:

[root@rhel-6 ~]# authconfig --enablesssd --enablesssdauth --update

[root@rhel-6 ~]# grep sss.so /etc/pam.d/system-auth
auth        sufficient    pam_sss.so use_first_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

[root@rhel-6 ~]# grep sss.so /etc/pam.d/password-auth
auth        sufficient    pam_sss.so use_first_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

[root@rhel-6 ~]# grep sss /etc/nsswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss
services:   files sss
netgroup:   files sss
automount:  files sss

[root@rhel-7 ~]# realm discover jonatasti.eti.br
jonatasti.eti.br
  type: kerberos
  realm-name: JONATASTI.ETI.BR
  domain-name: jonatasti.eti.br
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U
  login-policy:

[root@rhel-7 ~]# authconfig --enablesssd --enablesssdauth --update

[root@rhel-7 ~]# grep sss /etc/pam.d/system-auth
auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

[root@rhel-7 ~]# grep sss /etc/pam.d/password-auth
auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

[root@rhel-7 ~]# realm join jonatasti.eti.br
Password for Administrator@JONATASTI.ETI.BR:

[root@rhel-7 ~]# realm permit --realm jonatasti.eti.br --all

[root@rhel-7 ~]# realm list
jonatasti.eti.br
  type: kerberos
  realm-name: JONATASTI.ETI.BR
  domain-name: jonatasti.eti.br
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U
  login-policy: allow-realm-logins

[root@rhel-7 ~]# systemctl stop sssd
[root@rhel-7 ~]# rm -f /var/lib/sss/db/*
[root@rhel-7 ~]# systemctl start sssd

[root@rhel-7 ~]# authconfig --updateall
getsebool:  SELinux is disabled
getsebool:  SELinux is disabled

Realizando join em um domain com adcli – rhel6

Este comando adcli join solicitará ao usuário sua senha e se a senha estiver correta, ela retornará ao prompt sem mais mensagens. O usuário padrão é o Administrador, mas qualquer usuário que tenha permissão para ingressar em uma nova máquina para o domínio pode ser usado. Você pode usar a opção -U para especificar o usuário.

[root@rhel-6 ~]# adcli join jonatasti.eti.br
Password for Administrator@JONATASTI.ETI.BR:

Se o comando adcli for bem-sucedido, um arquivo keytab será criado em /etc/krb5.keytab.

Verifique o kerberos ticket

Você pode usar o seguinte comando para verificar o keytab arquivo, funcional em ambos rhel 6 e 7.

[root@rhel-6 ~]# klist -k |head
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 192-168-60-131$@JONATASTI.ETI.BR
   2 host/192-168-60-131@JONATASTI.ETI.BR

Em RHEL7:
[root@rhel-7 ~]# klist -k |head 
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 SERVERA$@JONATASTI.ETI.BR
   2 SERVERA$@JONATASTI.ETI.BR
   2 SERVERA$@JONATASTI.ETI.BR
   2 SERVERA$@JONATASTI.ETI.BR
   2 SERVERA$@JONATASTI.ETI.BR
   2 SERVERA$@JONATASTI.ETI.BR
   2 host/SERVERA@JONATASTI.ETI.BR
[root@rhel-7 ~]#

Kerberos Configuração

Recomenda-se também configurar o arquivo de configuração do kerberos em /etc/krb5.conf para usar o domínio AD.

Configuração a seguir usado em ambos rhel version 6 e 7.

[root@rhel-6 ~]# cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = JONATASTI.ETI.BR
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 JONATASTI.ETI.BR = {
  kdc = ad.jonatasti.eti.br
  admin_server = ad.jonatasti.eti.br
 }

[domain_realm]
 .jonatasti.eti.br = JONATASTI.ETI.BR
 jonatasti.eti.br = JONATASTI.ETI.BR

IMPORTANTE!

Observe que o realm foi especificado com caracteres em maiúsculo. Este é um requisito do krb5. Caso você se esqueça e coloque em minúsculo ocorrerá um erro.

SSSD Configuração

A etapa final é configurar o SSSD (ou Winbind se você quiser) para realmente fazer uso do keytab para resolver os usuários. Vou mostrar como usar o AD backend do SSSD com o exemplo. Certifique-se de que sssd e authconfig estão instalados:

Configuração usado para ambas versões, rhel 6 e 7.

[root@rhel-6 ~]# cat /etc/sssd/sssd.conf 
[sssd]
services = nss, pam, ssh, autofs
config_file_version = 2
domains = jonatasti.eti.br
[nss]
 filter_groups = root <grouplocal>
 filter_users = root <userlocal>
[domain/JONATASTI.ETI.BR]
 id_provider = ad
 override_homedir = /home/%d/%u
 default_shell = /bin/bash
 timeout = 120
 auth_provider = ad
 chpass_provider = ad
 access_provider = ad
 cache_credentials = true
 ad_gpo_access_control = permissive
# Uncomment if service discovery is not working
# ad_server = server.win.example.com

Defina a permissão do arquivo para 600, inicie o serviço sssd e habilite para iniciar no boot e inicie o serviço SSSD.

[root@rhel-6 ~]# chmod 600 /etc/sssd/sssd.conf
[root@rhel-6 ~]# service sssd start
Starting sssd:                                             [  OK  ]
[root@rhel-6 ~]# chkconfig sssd on

Acompanhado os logs, ao iniciar o serviço sssd você terá algo parecido como o que se segue:

[root@rhel-6 ~]# tail /var/log/messages 
Nov 11 15:30:39 rhel-6 sssd: Starting up
Nov 11 15:30:39 rhel-6 sssd[be[JONATASTI.ETI.BR]]: Starting up
Nov 11 15:30:39 rhel-6 sssd[nss]: Starting up
Nov 11 15:30:39 rhel-6 sssd[pam]: Starting up
Nov 11 15:30:39 rhel-6 sssd[ssh]: Starting up
Nov 11 15:30:39 rhel-6 sssd[autofs]: Starting up

Agora você já deve ser capaz de realizar um login através de um usuário do AD.

Definir shell e um diretório home para usuários AD.

O diretório home não existirá no sistema quando um novo usuário fizer logon, execute o comando abaixo para que o homedir seja criado automaticamente no primeiro login.

Habilita o serviço oddjobd para iniciar no boot

Passos a seguir usado em ambos rhel version 6 e 7.

[root@rhel-6 ~]# authconfig --enablemkhomedir --update
Starting oddjobd                                           [  OK  ]
[root@rhel-6 ~]# chkconfig oddjobd on

Certifique que a seguinte linha foram adicionadas com o modulo pam_oddjob_mkhomedir.so no arquivo  no arquivo /etc/pam.d/system-auth e /etc/pam.d/password-auth como explicado anteriormente pelo comando authconfig. Caso contrario adicione conforme exemplo abaixo.

[root@rhel-6 ~]# grep pam_oddjob_mkhomedir.so /etc/pam.d/system-auth
session     required      pam_oddjob_mkhomedir.so skel=/etc/skel umask=022

[root@rhel-6 ~]# grep pam_oddjob_mkhomedir.so /etc/pam.d/password-auth
session     required      pam_oddjob_mkhomedir.so skel=/etc/skel umask=022

Esta parametrização dever esta na sessão [domain/jonatasti.eti.br]. Perceba que em nossa configuração SSSD.conf estas linhas já foram incluídas.

override_homedir = /home/%u
default_shell = /bin/bash

Você pode substituir configurações como o diretório inicial do usuário, o shell, etc., que são definidas no AD, adicionando diretrizes apropriadas no sssd.conf. Por exemplo, para substituir o diretório inicial predefinido de um usuário, adicione a diretriz override_homedir na seção de domínio como mencionado acima.

override_homedir = /home/%d/%u

Neste caso, o diretório home do usuário será /home/jonatasti.eti.br/<user>

As sequencias disponíveis são:

%u
    login name
%U
    UID number
%d
    domain name
%f
    fully qualified user name (user@domain)
%o
    The original home directory retrieved from the identity provider.
%%
a literal ´%´

Essas sequencias são expandidas automaticamente. Você pode usar a diretiva override_home juntamente com as sequencias acima para obter o resultado desejado.

Teste Configuração

Se você não receber nenhuma saída para um nome de usuário conhecido, algo está errado.

[root@rhel-6 ~]# id Administrator
uid=1996600500(administrator) gid=1996600513(domain users) grupos=1996600513(domain users),1996600572(denied rodc password replication group),1996600518(schema admins),1996600519(enterprise admins),1996600520(group policy creator owners),1996600512(domain admins)

Logando com um usuário conhecido em um domínio AD.

Percerba que neste momento não temos quaisquer informações sobre o usuário “btest” localmente, apenas sabemos que o mesmo pertence ao AD.

[root@rhel-6 ~]# ls -lh /home
total 4,0K
drwx------. 2 jslopes domain users 4,0K Nov 11 19:22 jslopes

Quando um usuário é inserido no Linux a partir de algum sistema de autenticação, ele fica disponível para o PAM. Podemos listar todos os usuários com o comando getent passwd, neste caso queremos apenas lista o usuário btest.

[root@rhel-6 ~]# getent passwd btest
btest:*:1996601112:1996600513:Ben Test:/home/btest:/bin/bash

Com o comando id retorna os identificadores do usuário, login e os grupos a que ele pertence.

[root@rhel-6 ~]# id btest
uid=1996601112(btest) gid=1996600513(domain users) grupos=1996600513(domain users),1996601107(ad-admins)

Acompanho o login pelo log em /var/log/secure perceba que no primeiro momento errei a senha “proporcionalmente, para fins académicos, rsrs”.

[root@rhel-6 ~]# tail -f /var/log/secure
Nov 13 13:41:17 rhel-6 sshd[2439]: Accepted password for root from 192.168.60.1 port 43058 ssh2
Nov 13 13:41:17 rhel-6 sshd[2439]: pam_unix(sshd:session): session opened for user root by (uid=0)
 
Nov 13 13:56:15 rhel-6 sshd[2551]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.1  user=btest
Nov 13 13:56:15 rhel-6 sshd[2551]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.1 user=btest
Nov 13 13:56:15 rhel-6 sshd[2551]: pam_sss(sshd:auth): received for user btest: 17 (Failure setting user credentials)
Nov 13 13:56:18 rhel-6 sshd[2551]: Failed password for btest from 192.168.60.1 port 43082 ssh2
Nov 13 13:56:24 rhel-6 sshd[2551]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.1 user=btest
Nov 13 13:56:24 rhel-6 sshd[2551]: Accepted password for btest from 192.168.60.1 port 43082 ssh2
Nov 13 13:56:25 rhel-6 sshd[2551]: pam_unix(sshd:session): session opened for user btest by (uid=0)

Segundo momento, agora sim o acesso foi concluído com sucesso para o usuário conhecido.

@scrpnx [~] $ ssh -l btest 192.168.60.131
btest@192.168.60.131's password: 
Permission denied, please try again.
btest@192.168.60.131's password: 
Creating home directory for btest.        <------------------- "Criou o diretório no primeiro login"
Last login: Fri Nov 11 19:05:10 2016 from 192.168.60.1
[btest@rhel-6 ~]$ pwd
/home/btest
[btest@rhel-6 ~]$ umask 
0022
[btest@rhel-6 ~]$ whoami
btest

Conforme evidenciado, perceba que ao logar, o diretório home do usuário foi criado automaticamente.

[root@rhel-6 ~]# ls -lhtr /home/
total 8,0K
drwx------. 2 jslopes domain users 4,0K Nov 11 19:22 jslopes
drwx------  2 btest   domain users 4,0K Nov 13 13:56 btest

É possível realizar a troca da senha definida no AD para qual o usuário deseja. Neste caso, apôs o login será solicitado a troca da senha.

Acompanhado pelo log;

[root@rhel-6 ~]# tail -f /var/log/secure 
Nov 13 14:18:32 rhel-6 sshd[3313]: pam_sss(sshd:auth): received for user btest: 12 (Authentication token is no longer valid; new one required)
Nov 13 14:18:32 rhel-6 sshd[3313]: pam_sss(sshd:account): User info message: Password expired. Change your password now.
Nov 13 14:18:32 rhel-6 sshd[3313]: Accepted password for btest from 192.168.60.1 port 43296 ssh2
Nov 13 14:18:32 rhel-6 sshd[3313]: pam_unix(sshd:session): session opened for user btest by (uid=0)
Nov 13 14:18:32 rhel-6 passwd: pam_unix(passwd:chauthtok): user "btest" does not exist in /etc/passwd
Nov 13 14:18:58 rhel-6 passwd: pam_unix(passwd:chauthtok): user "btest" does not exist in /etc/passwd
Nov 13 14:19:06 rhel-6 passwd: pam_unix(passwd:chauthtok): user "btest" does not exist in /etc/passwd
Nov 13 14:21:35 rhel-6 sshd[3313]: pam_unix(sshd:session): session closed for user btest

Nov 13 14:21:55 rhel-6 sshd[3332]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.1 user=btest
Nov 13 14:21:55 rhel-6 sshd[3332]: Accepted password for btest from 192.168.60.1 port 43300 ssh2
Nov 13 14:21:55 rhel-6 sshd[3332]: pam_unix(sshd:session): session opened for user btest by (uid=0)

@scrpnx [~] $ ssh -l btest 192.168.60.131
btest@192.168.60.131's password: 
Password expired. Change your password now.
Last login: Sun Nov 13 13:56:25 2016 from 192.168.60.1
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user btest.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Shared connection to 192.168.60.131 closed

Definir sudoers ao usuario AD.

Winbind e sssd importar os grupos de AD de uma maneira equivalente aos NIS netgroups. Portanto, suas definições de grupo no arquivo /etc/sudoers precisam começar com + e ou %. Em meu laboratório criei o grupo no AD chamando “ad-admins”.

Conforme mencionado anteriormente, o comando getent pode lista todo informações de entradas de bancos de dados. Para mais informações man getent.

[root@rhel-6 ~]# getent group ad-admins
ad-admins:*:1996601107:jslopes,btest,mluiza

Perceba que não temos definição de sudoers para o usuário btest, ou o grupo no qual pertence.

[root@rhel-6 ~]# sudo -l -U btest
User btest is not allowed to run sudo on rhel-6.

Com as informações do comando getent, irei definir que o grupo do AD “ad-admins” terá permissão sudo para tudo e quaisquer comandos.

[root@rhel-6 ~]# grep ad-admins /etc/sudoers
%ad-admins ALL=(ALL) ALL

Agora o usuário btest e qualquer outro pertencente ao gupor AD “ad-admins” é capaz de elevar seus privilegias no server linux.

[root@rhel-6 ~]# sudo -l -U btest
Matching Defaults entries for btest on this host:
    !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
    LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
    LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER
    LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
 
User btest may run the following commands on this host:
    (ALL) ALL

Autenticando RHEL 5 Winbind usando Keberos com Active Directory em Windows Server 2008 R2

O Winbind usa uma implementação do Microsoft RPC (Remote Procedure Calls), PAM

(Pluggable Authentication Modules) e Nsswitch (Interruptor de Serviço de Nome) para permitir que os usuários do Windows Active Directory apareçam e operem como usuários locais em uma máquina Red Hat Enterprise Linux. O Winbind minimiza a necessidade de administradores de sistema gerenciarem contas de usuário separadas nos ambientes Red Hat Enterprise Linux e Windows Server 2008 R2.

O Winbind é um componente do pacote de programas Samba que permite o logon de usuário unificado. E fornece três funções separadas:

• Autenticação de credenciais de usuário (via PAM). Isso torna possível fazer logon em um RedHat Enterprise Linux usando contas de usuário do Active Directory. A autenticação é Responsável por identificar “who” um usuário alega ser.
• ID Tracking/Name Resolution via nsswitch (NSS). O serviço nsswitch permite que informações de sistema a serem obtidas de diferentes serviços de banco de dados como LDAP ou NIS. O ID Tracking/Name Resolution é responsável pela determinação de identidades de usuários “where”.
• ID Mapping representa o mapeamento entre IDs de segurança (SID) do usuário, do grupo (GID) e do Windows Server 2008 R2 do Red Hat Enterprise Linux (UID). Os mapeamentos de ID são manipulados através de um “backend” idmap que é responsável pelo rastreamento dos usuários do ID de “what” são conhecidos por ambos os ambientes do sistema operacional.

Pacotes Requeridos:

Certifique-se que os seguintes pacotes estejam instalados e atualizados:

yum install samba-common ntpdate ntp authconfig pam_krb5 krb5-workstation krb5-libs

Este pacote é opcionais mas altamente recomendável para troubleshooting em autenticação com kerberos.

yum install krb5-server

Setup

Após as instalações, iremos editar os arquivos de configuração do Kerberos e do Samba Winbind. Para se aprofundar mais, sugiro que você visite o site do samba: http://samba.org.

Kerberos Configuração

Altere o arquivo de configuração Kerberos em /etc/krb5.conf adicionando, como se segue.

[root@rhel-5 ~]# cat /etc/krb5.conf 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = JONATASTI.ETI.BR
 dns_lookup_realm = true
 dns_lookup_kdc = true
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true
  allow_weak_crypto = true

[realms]
  JONATASTI.ETI.BR = {
   kdc = dc.jonatasti.eti.br:88
   admin_server = WIN-VSRKDJROOAH.jonatasti.eti.br
  }

[domain_realm]
  .jonatasti.eti.br = JONATASTI.ETI.BR
  jonatasti.eti.br = JONATASTI.ETI.BR

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

Certifique-se que o modulo pam_krb5.so esteja adicionado no arquivo /etc/pam.d/system-auth.

[root@rhel-5 ~]# grep pam_krb5.so /etc/pam.d/system-auth
auth        sufficient    pam_krb5.so use_first_pass
...
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
...
password    sufficient    pam_krb5.so use_authtok
...
session     optional      pam_krb5.so

Nota:

A partir deste ponto já possível autenticar no host Linux com quaisquer usuários conhecidos no Active Directory. Desde que, você criar este usuario local com o comando useradd. Por exemplo, o user1 é um usuário conhecido ao AD, é necessário que o mesmo esteje criado localmente mas sem definir quaisquer informação ou senha para o mesmo. Seguindo o comando abaixo.

# useradd user1
# passwd -l user1

Possivelmente se deparar com trecho de logs desse tipos. Perceba que após criarmos o usuário conseguimos autenticar.

Nov 15 12:16:45 rhel-5 useradd[3807]: new group: name=user1, GID=500
Nov 15 12:16:45 rhel-5 useradd[3807]: new user: name=user1, UID=500, GID=500, home=/home/user1, shell=/bin/bash

Nov 15 12:17:04 rhel-5 sshd[3813]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.1  user=user1
Nov 15 12:17:04 rhel-5 sshd[3813]: pam_krb5[3813]: error reading keytab 'FILE:/etc/krb5.keytab'
Nov 15 12:17:04 rhel-5 sshd[3813]: pam_krb5[3813]: TGT verified
Nov 15 12:17:04 rhel-5 sshd[3813]: pam_krb5[3813]: authentication succeeds for 'user1' (user1@JONATASTI.ETI.BR)

A desvantagem de apenas usarmos o autenticação com somente o kerberos são:

• Não há compartilhamento de arquivos (mas pode ser ativado, configurando o Samba)
• Sem cache off-line de credenciais de usuário
• Má gestão de colisões de ID

O tempo de vida do ticket é um outro ponto que pode ser considerado como problemático. Um tempo de vida muito longo pode dar mais tempo a um invasor caso um ticket seja capturado ou uma estação comprometida. Um tempo muito pequeno impõe ao usuário a necessidade de redigitar a senha após a expiração.

Voltando. Verifique a configuração do Kerberos. Primeiro, limpe todos os tickets existentes:

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

Obtêm um novo kerberos ticket

[root@rhel-5 ~]# kinit Administrator
Password for Administrator@JONATASTI.ETI.BR: 
[root@rhel-5 ~]#

Verifique o novo kerberos ticket

Verifique se um novo kerberos ticket o mesmo foi gerado

[root@rhel-5 ~]# klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@JONATASTI.ETI.BR

Valid starting     Expires            Service principal
11/15/16 12:32:03  11/15/16 22:32:10  krbtgt/JONATASTI.ETI.BR@JONATASTI.ETI.BR
renew until 11/22/16 12:32:03


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

Configurando o Samba

O Samba é uma reimplementação de software livre do protocolo de rede SMB/CIFS. Também inclui ferramentas para que máquinas Linux funcionem como servidores e clientes de rede Windows.

Nota: 

A configuração pode variar muito dependendo de como o ambiente do Windows foi implantado.

Esteja preparado para troubleshooting e pesquisas !!!

Vamos nos concentrar em fazer com que a autenticação funcione primeiro editando a sessão “global”. Em meu ambiente de teste as seguintes parametrizações a principio atenderam o propósito.

[root@rhel-5 ~]# cat /etc/samba/smb.conf
[global]
workgroup = JONATASTI
server string =  %h Host
netbios name = rhel-5
realm = JONATASTI.ETI.BR
log file = /var/log/samba/samba.log
os level = 2
preferred master = no
max log size = 50
debug level = 1
security = ads
encrypt passwords = yes
socket options = SO_KEEPALIVE TCP_NODELAY
password server = 192.168.60.130
allow trusted domains = yes
idmap uid = 1000-20000
idmap gid = 1000-20000
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
#winbind refresh tickets = yes
template shell = /bin/bash
template homedir = /home/%U
client use spnego = yes
domain master = no
restrict anonymous = 2

Se você receber erros informando que /etc/security/pam_winbind.conf não foi encontrado, crie o arquivo e adicione o seguinte:

[root@rhel-5 ~]# cat /etc/security/pam_winbind.conf 
[global]
  debug = no
  debug_state = no
  try_first_pass = yes
  krb5_auth = yes
  krb5_cache_type = FILE
  cached_login = yes
  silent = no
  mkhomedir = yes

Conforme mencionado anteriormente, você precisa de uma conta de administrador do AD para fazer join em um domino existente. No meu caso é Administrador.

Join Domain

[root@rhel-5 ~]# net ads join -U Administrator
Administrator's password: 
Using short domain name -- JONATASTI
Joined 'RHEL-5' to realm 'JONATASTI.ETI.BR'

Habilite e inicia os samba deamons individualmente:

[root@rhel-5 ~]# /etc/init.d/winbind start
Iniciando serviços Winbind:                                [  OK  ]

Em seguida, precisamos modificar a configuração NSSwitch.

[root@rhel-5 ~]# grep winbind /etc/nsswitch.conf 
passwd:     files winbind
shadow:     files winbind
group:      files winbind
services:   files winbind

Certifique-se que o modulo pam_mkhomedir.so esteja adicionado no arquivo /etc/pam.d/system-auth. Esta configuração irar garantir que crie automaticamente o diretório home do usuário assim que o mesmo logar pela primeira vez.

[root@rhel-5 ~]# grep pam_mkhomedir.so /etc/pam.d/system-auth
session     optional      pam_mkhomedir.so skel=/etc/skel umask=0022

Teste Configuração

Se você não receber nenhuma saída para um nome de usuário conhecido, algo está errado.

[root@rhel-5 ~]# id Administrator
uid=1001(administrator) gid=1000(domain users) grupos=1000(domain users),1003(denied rodc password replication group),1004(enterprise admins),1005(schema admins),1006(group policy creator owners),1007(domain admins)

Teste Winbind

Vamos verificar se winbind é capaz de realizar consulta no AD.

O comando a seguir deve retornar uma lista de usuários do Active Directory.

[root@rhel-5 ~]# wbinfo -u
administrator
guest
krbtgt
jslopes
btest
mluiza

Podemos fazer o mesmo para os grupos do AD.

[root@rhel-5 ~]# wbinfo -g
domain computers
domain controllers
schema admins
enterprise admins
cert publishers
domain admins
domain users
domain guests
group policy creator owners
ras and ias servers
allowed rodc password replication group
denied rodc password replication group
read-only domain controllers
enterprise read-only domain controllers
dnsadmins
dnsupdateproxy
ad-admins

Quando um usuário é inserido no Linux a partir de algum sistema de autenticação, ele fica disponível para o PAM. Podemos listar todos os usuários com o comando getent passwd, neste caso estaremos testando a configuração do arquivo nsswitch. Queremos apenas lista o usuário btest

[root@rhel-5 ~]# getent passwd btest
btest:*:1000:1000:Ben Test:/home/btest:/bin/bash

Podemos fazer o mesmo para os grupo AD.

[root@rhel-5 ~]# getent group ad-admins
ad-admins:*:1001:mluiza,btest,jslopes

Definir sudoers ao usuário AD.

Winbind e sssd importar os grupos de AD de uma maneira equivalente aos NIS netgroups. Portanto, suas definições de grupo no arquivo /etc/sudoers precisam começar com + e ou %(indica ser um grupo e não um usuário). Em meu laboratório criei o grupo no AD chamando “ad-admins”.

Conforme mencionado anteriormente, o comando getent pode lista todo informações de entradas de bancos de dados. Para mais informações man getent.

Com a informações do comando getent irei definir que o grupo do AD “ad-admins” terar permissão sudo para todo e quaisquer comandos.

[root@rhel-5 ~]# grep ad-admins /etc/sudoers 
%ad-admins ALL=(ALL) ALL

Agora o usuário btest e qualquer outro pertencente ao grupo AD “ad-admins” é capaz de elevar seus privilegias no server linux.

[root@rhel-5 ~]# sudo -l -U btest
Matching Defaults entries for btest on this host:
    requiretty, !visiblepw, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS MAIL
    PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES
    LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

Runas and Command-specific defaults for btest:

User btest may run the following commands on this host:
    (ALL) ALL

Alta utilização de CPU pelo processo sssd_be

Quanto maior o número de objetos no servidor Active Directory, maior a probabilidade de que isso ocorra. Se a enumeração estiver ativada, o processo sssd_be solicitará ao servidor de diretório tudo sob o local ldap_search_base na árvore de diretórios. Sites com mais de 10.000 objetos podem enfrentar esse problema.

Workarround

Fonte: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

Uma das razões para a alta utilização da CPU pelo processo sssd_be é devido ao fato de que o cache é mantido com total conformidade com o ACID.
À medida que cada entrada é gravada no disco, o processo força o file system um flush do cache para o disco, isso retarda o filesystem I/O por um pouco mais. O tmpfs pode ser usado para armazenar o cache com o custo de perder a persistência do cache através de reinicializações.

Para armazenar as informações de diretório em tmpfs, faça o seguinte:

Edite o /etc/fstab, adicionando a seguinte linha:

tmpfs /var/lib/sss/db/ tmpfs size=300M,mode=0700,noauto  0 0

Pare o daemon sssd e monte o tmpfs

mount /var/log/sss/db

Isso deve reduzir o tempo de espera de I/O pleo processo sssd_be.
O parâmetro size do filesystem tmpfs depende do tamanho do seu diretório. Como regra geral, use 100 MB por 10.000 entradas de diretório.