Conteúdo


A integração de autenticação de SO com Microsoft Active Directory no IBM PureApplication System

Comments

Ao implementar o IBM PureApplication System, a IBM recomenda a integração com um subsistema LDAP externo. Isso permite a transferência da autenticação bem como associação ao grupo a um diretório corporativo existente na paisagem de TI. Isso se aplica a usuários e grupos para interfaces administrativas do IBM PureApplication System, como o console do sistema, console de carga de trabalho, Pure CLI e interface REST.

Com a integração LDAP descrita em vigor, é importante apontar que o sistema operacional que é implementado com cada máquina virtual no sistema não se integra automaticamente com esse LDAP. Vários clientes possuem um requisito para o SO integrar com um LDAP externo, porque simplifica muito o gerenciamento da segurança para grandes conjuntos de VMs no PureApplication System.

Esse artigo descreve como integrar a segurança do SO no IBM PureApplication System com o Microsoft Active Directory, uma implementação LDAP usada por vários clientes. Aqui está descrito em detalhes como essa integração pode ser automatizada usando os pacotes de script para VMs que fazem parte de um padrão do sistema virtual. A configuração necessária no Active Directory para essa integração funcionar também é destacada.

A solução descrita aqui é aplicável somente a modelos Intel® IBM PureApplication System (8283/W1500 e 8283/W2500) que executam Red Hat Enterprise Linux®.

O problema

Ao implementar um padrão do sistema virtual, o administrador deve especificar a senha para uma ou mais contas do SO no momento da implementação que serão definidas no SO Red Hat Enterprise Linux (RHEL). As contas sempre incluem root e virtuser, mas dependendo do padrão de sistema virtual, também podem existir outras (como db2inst1 para IBM DB2®).

A implementação de um padrão de sistema virtual no PureApplication System conduz a implementação de uma ou mais máquinas virtuais. Como resultado, gerenciar um grande número de VMs se torna desafiador. Os administradores precisam receber as senhas dessas contas do SO. Gerenciar o ciclo de vida dessas contas pode ser complicado; por exemplo, como você força uma política de senha que requer que as senhas sejam alteradas a cada três meses? Outros desafios incluem novas pessoas se associando à equipe de administradores e outras pessoas saindo.

Com essas dificuldades em mente, a integração do SO RHEL com um serviço existente do Microsoft Active Directory traria muitos benefícios. O gerenciamento de ciclo de vida de senhas não estaria mais no escopo da VM no PureApplication System em si. Você precisaria de um mecanismo para um usuário existente no Active Directory para efetuar logon em uma VM implementada. O SO RHEL precisaria estar configurado para acessar o Active Directory para validar as credenciais do usuário e associações ao grupo quando o usuário tentar efetuar logon sobre SSH. A associação ao grupo pode ser usada para restringir o acesso a uma VM para um subconjunto de usuários presente no Active Directory.

Implementação

Essa solução de amostra usa Samba para executar a autenticação no Active Directory. Pluggable Authentication Module (PAM) e winbind são configurados e realmente se associam ao host RHEL no domínio do Active Directory. A associação ao domínio requer que um contêiner no Active Directory bem como o usuário de ligação com permissões suficientes para criar objetos de computador no domínio.

Depois de pronto, o SO pode executar a autenticação no Active Directory usando challenge/response. As associações ao grupo para o usuário também são obtidas do Active Directory e um mapeamento consistente nos uids e gids pode ser configurado. Como o host RHEL se associou ao domínio, ele também pode obter Kerberos. Isso permite Conexão Única (SSO) em um domínio, que é um recurso poderoso. Depois de ter efetuado logon na VM, um usuário pode executar SSH em outra VM no mesmo domínio sem ter que inserir novamente sua senha.

Como as VMs no Pure Application System podem ser excluídas, também é necessário remover o objeto do computador correspondente no Active Directory. Consequentemente, isso requer que o usuário de ligação tenha permissões suficientes para excluir os objetos de computador no Active Directory (Figura 1).

Figura 1. Visão geral da solução
Overview of the solution
Overview of the solution

A intenção é distribuir as permissões com base na associação ao grupo do usuário no Active Directory. Para cada carga de trabalho no sistema, é possível usar a associação ao grupo para determinar se um usuário tem permissão para efetuar logon no SSH, ou se o usuário pode executar um switch user (su) em um usuário técnico ou raiz:

  • GRP_IPAS_<workload>_login
    Os membros deste grupo possuem permissão para efetuar login no SO usando SSH.
  • GRP_IPAS_<workload>_middleware
    Os membros deste grupo possuem permissão para o switch user (su) para um ou mais usuários técnicos diferentes no SO; por exemplo, virtuser ou db2inst1.
  • GRP_IPAS_<workload>_root
    Os membros deste grupo possuem permissão para switch user (su) para raiz.

Configuração Active Directory

As seções abaixo descrevem qual configuração é necessária no domínio do Active Directory. Isso precisa estar em vigor antes de tentar configurar a segurança do SO em RHEL e associar o domínio.

  • Contêineres

    Para simplificar a estrutura do Active Directory para este exemplo, coloque todos os componentes relacionados em um único contêiner na raiz do domínio do Active Directory:

    OU=IPAS,DC=dw,DC=ibm,DC=com

    Neste contêiner, crie três contêineres adicionais para as contas de serviço, grupos e hosts reais que associam o domínio:

    OU=Service Accounts,OU=Users,OU=IPAS, DC=dw,DC=ibm,DC=com
    OU=Management,OU=Groups,OU=IPAS, DC=dw,DC=ibm,DC=com
    OU=Servers,OU=IPAS, DC=dw,DC=ibm,DC=com

    A Figura 2 ilustra a estrutura que você precisa ter em vigor.

    Figura 2. Configuração em árvore Active Directory
    Active Directory tree setup
  • Conta do serviço

    Você precisa de uma conta do serviço no Active Directory que possa criar novos objetos de computador ao associar o domínio. A conta precisaria de permissões para criar novos objetos de computador no contêiner OU=Servers,OU=IPAS,DC=dw,DC=ibm,DC=com. Depois de sair do domínio, o objeto do computador teria que ser removido do contêiner. Portanto, a conta também precisaria ter permissões para excluir os objetos do computador do contêiner:

    CN=IPASAD,OU=Service Accounts,OU=Users,OU=IPAS,DC=dw, DC=ibm, DC=com

  • Grupos e usuários

    Depois de associado no domínio, você usará a associação do grupo para determinar quais permissões um usuário possui nesse SO. Portanto, precisa criar inúmeros grupos que possam ser usados para esse propósito; certamente, mais grupos podem ser incluídos com o tempo:

    • GRP_IPAS_myWorkload_login
      Os membros deste grupo possuem permissão para efetuar login no SO usando SSH.
    • GRP_IPAS_myWorkload_middleware
      Os membros deste grupo possuem permissão para switch user (su) para um ou mais usuários técnicos diferentes no SO; por exemplo, virtuser ou db2inst1.
    • GRP_IPAS_myWorkload_root
      Os membros deste grupo possuem permissão para switch user (su) para raiz.

    Naturalmente, inúmeros usuários teriam que ser definidos também. Para propósitos de teste, você deve ter usuários em vigor com diferentes associações ao grupo.

  • RPMs necessários

    Os arquivos RPM a seguir são necessários para que a integração com o Active Directory funcione. Esteja ciente de que a versão pode ser importante; encontramos comportamento inconsistente para a associação ao grupo com uma versão mais antiga dos binários Samba/winbind. As versões RPM listadas aqui foram testadas e devem ser consideradas como número de versão mínima.

    Esses RPMs precisam ser instalados antes de configurar o SO RHEL. Dependendo da imagem virtual usada por seu padrão de sistema virtual, alguns desses RPMs já podem estar instalados:

    • libsmbclient-3.6.9-151.el6.x86_64.rpm
    • libtalloc-2.0.7-2.el6.x86_64.rpm
    • libtdb-1.2.10-1.el6.x86_64.rpm
    • openldap-clients-2.4.23-20.el6.x86_64.rpm *
    • openldap-clients-2.4.23-26.el6_3.2.x86_64.rpm *
    • openldap-clients-2.4.23-32.el6_4.1.x86_64.rpm *
    • openldap-clients-2.4.23-34.el6_5.1.x86_64.rpm *
    • samba-3.6.9-151.el6.x86_64.rpm *
    • samba-3.6.9-151.el6_4.1.x86_64.rpm *
    • samba-3.6.9-169.el6_5.x86_64.rpm *
    • samba-client-3.6.9-151.el6.x86_64.rpm
    • samba-common-3.6.9-151.el6.x86_64.rpm
    • samba-winbind-3.6.9-151.el6.x86_64.rpm
    • samba-winbind-clients-3.6.9-151.el6.x86_64.rpm

    Para pacotes nesta lista marcados com *, a versão exata a ser usada depende da imagem virtual.

  • Dados necessários

    Esses são os dados que você precisa como variáveis para executar seus scripts (definidos abaixo):

    $ADS_username
    $ADS_password
    $ADS_container_shortname
    $ADS_domain
    $ADS_workgroup
    $ADS_realm
    $ADS_login_group
    $ADS_middleware_group
    $ADS_root_group

    • Nome de usuário e senha da conta do serviço: O nome de usuário e a senha da conta do serviço definida anteriormente no Active Directory são necessários para o objeto do computador a ser criado (e excluído).
    • Nome do contêiner: O nome do contêiner (OU) para armazenar o objeto do computador é necessário pelo comando net ads join. A sequência OU lê de cima para baixo sem nomes distintos relativos (RDNs) e é delimitada por “/.” Nesse exemplo, seu contêiner OU=Servers,OU=IPAS, DC=dw,DC=ibm,DC=com deve ser fornecido como “IPAS/Servers.”
    • Domínio: O domínio da máquina virtual é necessário, especialmente para o comando net ads join. Conforme o nome do host qualificado é fornecido no tempo de implementação pelo Pure Application System, você usará o comando hostname –domain para obter o nome de domínio, de modo que não é necessário expor isso como uma variável de pacote de script.
    • Grupo de trabalho: O nome do grupo de trabalho a se associar será usado pelo Samba. Nas amostras de código abaixo, esses dados são armazenados na variável $ADS_workgroup.
    • Domínio: O nome do domínio é usado pelas configurações Samba e Kerberos. Ele também é usado para criar UPN (User Principal Name) enquanto se associa ao Active Directory. Nas amostras de código abaixo, esses dados são armazenados na variável $ADS_realm.
    • Nome do grupo: Os nomes dos três grupos são necessários para configurar as permissões corretas:
      • GRP_IPAS_myWorkload_login
      • GRP_IPAS_myWorkload_middleware
      • GRP_IPAS_myWorkload_root.

Configurando o SO RHEL 6

As seções abaixo descrevem as etapas necessárias para configurar a segurança no RHEL 6 a fim de integrar com o Active Directory.

1. Identifique os caminhos do arquivo de configuração

Aqui você usará os caminhos de arquivo padrão para os arquivos de configuração. Os arquivos nos quais trabalhar são:

  • /etc/samba/smb.conf
  • /etc/security/pam_winbind.conf
  • /etc/security/access.conf
  • /etc/krb5.conf
  • /etc/sudoers.

2. Inicie os serviços

Depois que todos os RPMs necessários são instalados, a primeira etapa é assegurar que os serviços messagebus, oddjobd, smb e winbind estão todos iniciados.

3. Defina a configuração samba inicial

Substitua o conteúdo do arquivo/etc/samba/smb.conf pelo código mostrado em Listando 1. Mantenha uma cópia de backup do arquivo antes de substituir seu conteúdo.

Lista 1.
     [global]
     idmap config ${HomeDirDomain} : backend=rid
     idmap config ${HomeDirDomain} : range=100000-2000000000
     winbind enum users = false
     winbind enum groups = false
     # http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#KERBEROSMETHOD
     kerberos method = secrets and keytab
     client ldap sasl wrapping = sign
     username level = 3
     server string = Samba Server Version %v
     log file = /var/log/samba/log.%m
     max log size = 50
     passdb backend = tdbsam

Esteja ciente de que ${HomeDirDomain} sequência deve ser substituída pelo nome abreviado do domínio, que pode ser recuperado com este comando:

HomeDirDomain=$(echo $ADS_domain | awk -F'.' '{print $1}' | tr '[:lower:]' '[:upper:]')

Além disso, certifique-se de que o diretório /var/log/samba exista; caso contrário, nada será registrado.

4. Modifique os arquivos de configuração

Execute o utilitário authconfig para modificar os arquivos de configuração (Listagem 2).

Lista 2.
     authconfig \
     --disablecache \
     --enablewinbind \
     --enablewinbindauth \
     --smbsecurity=ads \	
     --smbworkgroup=$ADS_workgroup \
     --smbrealm=$ADS_realm \
     --enablewinbindusedefaultdomain \
     --winbindtemplateshell=/bin/bash \
     --winbindtemplatehomedir=/home/${HomeDirDomain}/%U \
     --krb5realm=$ADS_realm \
     --enablekrb5kdcdns \
     --enablekrb5realmdns \
     --smbidmapuid=100000-2000000000 \
     --smbidmapgid=100000-2000000000 \
     --enablelocauthorize \
     --enablepamaccess \
     --enablemkhomedir \
     --disablefingerprint \
     --disablesmartcard \
     --updateall

A opção--winbindtemplatehomedir=/home/${HomeDirDomain}/%U é incluída para quando um usuário efetuar login pela primeira vez no sistema, um diretório inicial /home/<domain>/<user> seja criado.

Depois de executar esse comando, a configuração samba gerada deve aparecer coma a Listagem 3. (Lembre-se, os valores do grupo de trabalho e de domínio são valores de amostra mostrados como exemplos.)

Lista 3.
     [global]
     #--authconfig--start-line--
     
     # Generated by authconfig on 2014/01/15 18:15:56
     # DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--)
     # Any modification may be deleted or altered by authconfig in future
     
     workgroup = DW
     realm = DW.IBM.COM
     security = ads
     idmap uid = 100000-2000000000
     idmap gid = 100000-2000000000
     template shell = /bin/bash
     winbind use default domain = true
     winbind offline logon = false
     
     #--authconfig--end-line--
     idmap config DW : backend=rid
     idmap config DW : range=100000-2000000000
     winbind enum users = false
     winbind enum groups = false
     # http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#KERBEROSMETHOD
     kerberos method = secrets and keytab
     client ldap sasl wrapping = sign
     username level = 3
     server string = Samba Server Version %v
     log file = /var/log/samba/log.%m
     max log size = 50
     passdb backend = tdbsam

A configuração PAM também é gerada, produzindo arquivos /etc/pam.d/system-auth-ac e /etc/pam.d/password-auth-ac (Listagem 4).

Lista 4.
     #%PAM-1.0
     # This file is auto-generated.
     # User changes will be destroyed the next time authconfig is run.
     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_winbind.so use_first_pass
     auth        required      pam_deny.so
     
     account     required      pam_access.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_winbind.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_winbind.so use_authtok
     password    required      pam_deny.so
     
     session     optional      pam_keyinit.so revoke
     session     required      pam_limits.so
     session     optional      pam_oddjob_mkhomedir.so
     session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
     session     required      pam_unix.so

5. Modifique a configuração Kerberos

O arquivo /etc/krb5.conf deve ser modificado para:

  • Remova as referências para EXAMPLE.COM.
  • Inclua os tipos de criptografia padrão.
  • Inclua as entradas default_realm na seção libdefaults.
  • Inclua as entradas de domínio na seção de domínio.
  • Inclua as entradas para a seção domain_realm.

Isso pode ser feito com o código mostrado na Listagem 5.

Lista 5.
     # creating backup of original config file 
     cp $ADS_kerberos_config_file $ADS_kerberos_config_file.bk
     
     # remove "EXAMPLE.COM" samples entries from config file
     #cat $ADS_kerberos_config_file.bk | sed '/EXAMPLE.COM.*{.*}/d'| 
     sed '/EXAMPLE.COM.*{/,/}/d' | grep -v EXAMPLE.COM > $ADS_kerberos_config_file
     cat $ADS_kerberos_config_file.bk |grep -vi EXAMPLE |grep -v } > 
     $ADS_kerberos_config_file
     
     # configure use of arcfour-hmac-md5 and aes256-cts-hmac-sha1-96 as defaults for 
     kerberos tickets in kerberos configuration file (this is required when ADS is running 
     on Windows 2008R2 server!)
     sed -i "s/^\[libdefaults\]/\[libdefaults\]\n default_tkt_enctypes = arcfour-hmac-md5 
     aes256-cts-hmac-sha1-96\n default_tgs_enctypes = arcfour-hmac-md5 aes256-cts-hmac-sha1-96/" 
     $ADS_kerberos_config_file
     
     # add default_realm entries to libdefaults section
     sed -i "s/^\[libdefaults\]/\[libdefaults\]\n default_realm = $ADS_realm/" 
     $ADS_kerberos_config_file
     
     # add realm entries to realm section
     sed -i "s/^\[realms\]/\[realms\]\n $ADS_realm = {\n  } /" $ADS_kerberos_config_file
     
     # add entries for the domain of the actual host to kerberos configuration file to ensure 
     that they are part of the realm 
     sed -i "s/^\[domain_realm\]/\[domain_realm\]\n `hostname -d` = $ADS_realm\n .`hostname -d` 
     = $ADS_realm/" $ADS_kerberos_config_file

O arquivo modificado /etc/krb5.conf deve agora aparecer como a Listagem 6.

Lista 6.
     [logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
     
     [libdefaults]
     default_tkt_enctypes = arcfour-hmac-md5 aes256-cts-hmac-sha1-96
     default_tgs_enctypes = arcfour-hmac-md5 aes256-cts-hmac-sha1-96
     default_realm = DW.IBM.COM
     dns_lookup_realm = true
     dns_lookup_kdc = true
     ticket_lifetime = 24h
     renew_lifetime = 7d
     forwardable = true
     
     [realms]
     
     DW.IBM.COM = {
     }
     
     [domain_realm]
     dw.ibm.com = DW.IBM.COM
     .dw.ibm.com = DW.IBM.COM

6. Associe o domínio do Active Directory

Em seguida, você fará a máquina associar o domínio Active Directory. Isso é alcançado usando o comando net ads join . Mais precisamente, você executar os comandos mostrados na Listagem 7.

Lista 7.
     net ads join -w $ADS_workgroup -U $ADS_username%$ADS_password 
     createupn=host/`hostname -f`@$ADS_realm createComputer=$ADS_container_shortname 
     2> /dev/null | grep -v "DNS Update"
     
     if [[ `net ads testjoin` == "Join is OK" ]]; then
     logger_info "join_ads_domain: Successfully joined domain!"
     else
     logger_error "join_ads_domain: Failed to join domain!"
     fi

As variáveis passadas neste comando são:

  • $ADS_workgroup
    Nome do grupo de trabalho no domínio.
  • $ADS_username
    Nome de usuário da Conta do Serviço Active Directory.
  • $ADS_password
    Senha da Conta do Serviço Active Directory.
  • $ADS_realm
    Região para o domínio (por exemplo, DW.IBM.COM).
  • $ADS_container_shortname
    Nome abreviado do contêiner no qual o host será registrado como Objeto do Computador (por exemplo, “IPAS/Servers”, se seu nome distinto for OU=Servers,OU=IPAS, DC=dw,DC=ibm,DC=com).

Observe que o nome do host do Active Directory Server real nunca é usado aqui. Em vez disso, as duas linhas a seguir em /etc/krb5.conf asseguram que os controladores de domínio Active Directory são consultados através do DNS:

dns_lookup_realm = true
dns_lookup_kdc = true

Após a associação do domínio (ou seja, ao executar o comandonet ads join ), o Kerberos irá obter os controladores de domínio Active Directory dos registros DNS. Os controladores de domínio aqui agirão como Kerberos Authentication Servers bem como Key Distribution Centers (KDCs). Saiba que os registros DNS são type=SRV e o nome precisa ser do formato _kerberos._tcp.<domain>. Aqui, <domain> é o domínio do host (conforme relatado pelo comando hostname –d). Ao usar múltiplos controladores de domínio para um único domínio, deve haver um registro em DNS para cada um deles.

A solução que descrevemos aqui requer que esses registros para os controladores de domínio estejam presentes em DNS.

A Listagem 8 mostra um exemplo de como consultar esses registros usando DNS. Nesse caso, você possui um total de sete controladores de domínio para o domínio test.dw.ibm.com.

Lista 8.
     nslookup -type=SRV _kerberos._tcp.test.dw.ibm.com 
     
     ;; Truncated, retrying in TCP mode.
     Server:         10.16.81.21
     Address:        10.16.81.21#53
     
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw238vdcw9re.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw244vdcw9rb.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw243vdcw9rb.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw242vdcw9re.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw376vdcw9rb.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw239vdcw9rb.test.dw.ibm.com.
     _kerberos._tcp.test.dw.ibm.com   service = 0 100 88 dw286vdcw9re.test.dw.ibm.com.

Depois que o servidor estiver associado com êxito o domínio, é possível obter mais detalhes usando o comando mostrado na Listagem 9. Isso mostra o objeto do computador que foi criado no contêiner IPAS no Active Directory.

Lista 9.
     -bash-4.1# net ads status -U $ADS_username%********
     objectClass: top
     objectClass: person
     objectClass: organizationalPerson
     objectClass: user
     objectClass: computer
     cn: HOSTNAME
     distinguishedName: CN=HOSTNAME,OU=Servers,OU=IPAS,DC=dw,DC=ibm,DC=com
     instanceType: 4
     whenCreated: 20140122165553.0Z
     whenChanged: 20140122165553.0Z
     uSNCreated: 1876615
     uSNChanged: 1876622
     name: ON01P015
     objectGUID: 35ab4986-1775-4214-86ef-47efa308ba2a
     userAccountControl: 69632
     badPwdCount: 0
     codePage: 0
     countryCode: 0
     badPasswordTime: 0
     lastLogoff: 0
     lastLogon: 130348833536553755
     localPolicyFlags: 0
     pwdLastSet: 130348833532803611
     primaryGroupID: 515
     objectSid: S-1-5-21-1679220263-2264458565-1637611664-27733
     accountExpires: 9223372036854775807
     logonCount: 2
     sAMAccountName: DW01P015
     sAMAccountType: 805306369
     dNSHostName: hostname.dw.ibm.com
     userPrincipalName: host/hostname.dw.ibm.com@DW.IBM.COM
     servicePrincipalName: HOST/hostname.dw.ibm.com
     servicePrincipalName: HOST/HOSTNAME
     objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=dw,DC=ibm,DC=com
     isCriticalSystemObject: FALSE
     dSCorePropagationData: 16010101000000.0Z
     lastLogonTimestamp: 130348833536084987

Assumindo que o Kerberos foi configurado corretamente, você também deve conseguir ver as chaves (KVNOs) a partir do arquivo local keytab (/etc/krb5.keytab). A sinalização -e assegura que os tipos de criptografia usados também são mostrados (Listagem 10).

Lista 10.
     -bash-4.1# klist -ke
     Keytab name: WRFILE:/etc/krb5.keytab
     KVNO Principal
     ---- --------------------------------------------------------------------------
     2 host/hostname.dw.ibm.com@DW.IBM.COM (des-cbc-crc)
     2 host/hostname.dw.ibm.com@DW.IBM.COM (des-cbc-md5)
     2 host/hostname.dw.ibm.com@DW.IBM.COM (arcfour-hmac)
     2 host/hostname.dw.ibm.com@DW.IBM.COM (aes128-cts-hmac-sha1-96)
     2 host/hostname.dw.ibm.com@DW.IBM.COM (aes256-cts-hmac-sha1-96)
     2 host/hostname @DW.IBM.COM (des-cbc-crc)
     2 host/hostname @DW.IBM.COM (des-cbc-md5)
     2 host/hostname @DW.IBM.COM (arcfour-hmac)
     2 host/hostname @DW.IBM.COM (aes128-cts-hmac-sha1-96)
     2 host/hostname @DW.IBM.COM (aes256-cts-hmac-sha1-96)
     2 HOSTNAME$@DW.IBM.COM (des-cbc-crc)
     2 HOSTNAME$@DW.IBM.COM (des-cbc-md5)
     2 HOSTNAME$@DW.IBM.COM (arcfour-hmac)
     2 HOSTNAME$@DW.IBM.COM (aes128-cts-hmac-sha1-96)
     2 HOSTNAME$@DW.IBM.COM (aes256-cts-hmac-sha1-96)

7. Modifique a configuração winbind PAM gerada para Kerberos SSO

Em seguida, você modificará a configuração winbind PAM editando o arquivo gerado /etc/security/pam_winbind.conf. Configure os parâmetros a seguir:

  • krb5_auth = yes
  • krb5_ccache_type = FILE
  • winbind refresh tickets = yes.

Essas opções ativam a conexão única (SSO) Kerberos. Mais precisamente, elas indicam que o winbind PAM usará Kerberos para autenticar quando falar com o controlador de domínio do Active Directory e um arquivo for usado para armazenar em cache o Ticket Granting Ticket (TGT) recuperado. O parâmetro winbind refresh tickets = yes , em conjunto com krb5_auth = yes, faz com que winbind TGT seja atualizado sempre que necessário.

Isso pode ser feito usando comandos na Listagem 11.

Lista 11.
     sed -i "s/.krb5_auth.*/krb5_auth = yes/g" /etc/security/pam_winbind.conf
     sed -i "s/.krb5_ccache_type.*/krb5_ccache_type = FILE/g" /etc/security/pam_winbind.conf
     echo "winbind refresh tickets = yes" >> /etc/security/pam_winbind.conf

O arquivo /etc/security/pam_winbind.conf agora deve aparecer com a Listagem 12.

Lista 12.
     #
     # pam_winbind configuration file
     #
     # /etc/security/pam_winbind.conf
     #
     
     [global]
     
     # turn on debugging
     ;debug = no
     
     # turn on extended PAM state debugging
     ;debug_state = no
     
     # request a cached login if possible
     # (needs "winbind offline logon = yes" in smb.conf)
     ;cached_login = no
     
     # authenticate using kerberos
     krb5_auth = yes
     
     # when using kerberos, request a "FILE" krb5 credential cache type
     # (leave empty to just do krb5 authentication but not have a ticket
     # afterwards)
     krb5_ccache_type = FILE
     
     # make successful authentication dependend on membership of one SID
     # (can also take a name)
     ;require_membership_of =
     
     # password expiry warning period in days
     ;warn_pwd_expire = 14
     
     # omit pam conversations
     ;silent = no
     
     # create homedirectory on the fly
     ;mkhomedir = no
     winbind refresh tickets = yes

Configurando permissões de usuário do SO RHEL 6

Com a integração de usuários e grupos do Active Directory no SO RHEL 6, é possível agora começar a aplicar permissões. Uma configuração relativamente simples é mostrada aqui, mas as permissões mais complexas poderiam ser configuradas conforme necessário.

8. Configure o acesso PAM

O arquivo /etc/security/access.conf é usado para controlar o acesso ao SO RHEL 6. Com este arquivo:

  1. Limpe o arquivo de configuração existente.
  2. Configure todos os usuários com acesso a cronjobs.
  3. Negue acesso a todos os usuários, exceto raiz e membros dos grupos definidos anteriormente no Active Directory.

O shell script na Listagem 13 mostra como essas etapas podem ser automatizadas.

Lista 13.
     # creating backup of original config file 
     cp /etc/security/access.conf /etc/security/access.conf.bk
     
     # clear existing pam access configuration file
     >/etc/security/access.conf
     
     # configure all users access for cron jobs
     printf "+:ALL:cron\n" >> /etc/security/access.conf
     
     # configure access for root and the user(s) and groups \"${ADS_login_group}\", 
     \"${ADS_middleware_group}\" and \"${ADS_root_group}\"
     if [[ -n ${Local_users} ]];
     then
     for usr in $(echo ${Local_users}|tr "," " ")
     do
     if [[ $usr == "root" ]];
     then
     echo "root found in variable Local_users. This value is not processed. By default 
     root will be added to access.conf."
     continue
     else
     Usrs=$(printf "%s %s" "${Usrs}" "${usr}" )
     fi
     done
     fi
     
     if [[ -n ${Local_groups} ]];
     then
     for gp in $(echo ${Local_groups} |tr "," " ")
     do
     Grps=$(printf "%s %s" ${Grps} "(${gp})" )
     done
     fi
     
     printf "%sALL EXCEPT root%s %s %s %s %s:ALL\n" "-:" "${Usrs}" "${Grps}" "(${ADS_login_group})" 
     "(${ADS_middleware_group})" "(${ADS_root_group})" >> /etc/security/access.conf

O arquivo /etc/security/access.conf agora deve aparecer como a Listagem 14:

Lista 14.
     +:ALL:cron
     -:ALL EXCEPT root GRP_IPAS_myWorkload_login GRP_IPAS_myWorkload_middleware 
     GRP_IPAS_myWorkload_root :ALL

9. Configure sudo

Modifique o arquivo /etc/sudoers a fim de configurar a capacidade de alternar o usuário definido na seção Permissões (Listagem 15). Uma lista de usuários locais de middleware é passada usando a variável ${ADS_middleware_users} . Por padrão, Pure Application System usa virtuser como administrador de middleware (ou seja, o administrador IBM WebSphere Application Server), porém mais usuários podem ser incluídos nessa lista.

Lista 15.
     # creating backup of original config file 
     cp /etc/sudoers /etc/sudoers.bk
     
     # clear existing sudo configuration file
     >/etc/sudoers
     
     # configure default settings for sudo configuration file
     printf 'Defaults   !visiblepw\nDefaults    always_set_home\nDefaults    env_reset\nDefaults    
     env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"\nDefaults    
     env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"\nDefaults    
     env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"\nDefaults    
     env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"\nDefaults    
     env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"\nDefaults    
     secure_path = /sbin:/bin:/usr/sbin:/usr/bin\n' > /etc/sudoers
     
     # configure root with all permissions in sudo configuration file
     printf "root            ALL=(ALL)       ALL\n" >> /etc/sudoers
     
     # configure members of group ${ADS_middleware_group} to switch to the users 
     \"${ADS_middleware_users}\" in sudo configuration file
     local sudostring=""
     IFS=","
     for username in ${ADS_middleware_users}; do
     sudostring="${sudostring} /bin/su ${username}, /bin/su - ${username}, /bin/su - ${username} 
     -c whoami,"
     done
     unset IFS
     # remove last character from sudostring as it is a ','
     sudostring=`echo ${sudostring} | rev | cut -c 2- | rev`
     printf "%%${ADS_middleware_group} ALL=NOPASSWD:${sudostring}\n" >> /etc/sudoers
     
     # configure members of group ${ADS_root_group} to switch to root in sudo configuration file
     printf "%%${ADS_root_group} ALL=NOPASSWD:ALL\n" >> /etc/sudoers

O arquivo agora deve aparecer como Listagem 16.

Lista 16.
     Defaults   !visiblepw
     Defaults    always_set_home
     Defaults    env_reset
     Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
     Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
     Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
     Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
     Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
     Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
     root            ALL=(ALL)       ALL	
     %GRP_IPAS_myWorkload_middleware ALL=NOPASSWD:/bin/su virtuser, /bin/su - virtuser, 
     /bin/su - virtuser -c whoami
     %GRP_IPAS_myWorkload_root ALL=NOPASSWD:ALL

Finalizando a configuração

Agora que a configuração inteira está completa, a última etapa é reiniciar o messagebus, oddjobd, smb e winbind serviços depois de ter configurado corretamente seus níveis de execução.

10. Configure os níveis de execução para os serviços

Você precisa ativar esses serviços para os níveis de execução 2, 3, 4 e 5:

  • Messagebus
  • Oddjobd
  • Smb
  • winbind

Isso também pode ser feito com o código mostrado na Listagem 17.

Lista 17.
     chkconfig messagebus on --level 2345
     chkconfig oddjobd on --level 2345
     chkconfig smb on --level 2345	
     chkconfig winbind on --level 2345

11. Inicie os serviços

Sua etapa final é assegurar que esses serviços são todos iniciados. O script na Listagem 18 mostra como isso pode ser feito de uma maneira automatizada.

Lista 18.
     printf "start_services: ensure services \"messagebus\", \"oddjobd\", \"smb\" 
     and \"winbind\" are all started"
     
     # Verify status of service "messagebus" and start if not running yet.
     status=`service messagebus status`
     printf $status
     if [[ $status == "messagebus is stopped" ]]; then
     printf "start_services: messagebus not running, starting..."
     printf "start_services: `service messagebus start`"
     printf "start_services: messagebus started"
     fi
     
     # Verify status of service "oddjobd" and start if not running yet.
     status=`service oddjobd status`
     printf $status
     if [[ $status == "oddjobd is stopped" ]]; then
     printf "start_services: oddjobd not running, starting..."
     printf "start_services: `service oddjobd start`"
     printf "start_services: oddjobd started"
     fi
     
     # Verify status of service "smb" and start if not running yet.
     local status=`service smb status`
     printf $status
     if [[ $status == "smbd is stopped" ]]; then
     printf "start_services: smb not running, starting..."
     printf "start_services: `service smb start`"
     printf "start_services: smb started"
     fi
     
     #Verify status of service "winbindd" and start if not running yet.
     status=`service winbind status`
     printf $status
     if [[ $status == "winbindd is stopped" ]] || [[ $status == "winbindd dead but 
     pid file exists" ]]; then
     printf "start_services: winbind not running, starting..."
     printf "start_services: `service winbind start`"
     printf "start_services: winbind started"
     fi
     
     printf "start_services: all services started"
     return 0

Forçando autenticação do SO RHEL 6 com Active Directory

Por padrão, o SO RHEL 6 está forçando sua política de senha local. Agora que a máquina virtual está usando o Active Directory para autenticação, é possível desativar a política local RHEL e usar a política de senha do Active Directory.

Para desativar a política de senha local do RHEL 6, faça as mudanças mostradas na Listagem 19 para /etc/security/system-auth-ac.

Lista 19.
     #%PAM-1.0
     # This file is auto-generated.
     # User changes will be destroyed the next time authconfig is run.
     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_winbind.so use_first_pass
     auth        required      pam_deny.so
     
     account     required      pam_access.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_winbind.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_winbind.so use_authtok
     password    sufficient    pam_winbind.so
     password    required      pam_deny.so
     
     session     optional      pam_keyinit.so revoke
     session     required      pam_limits.so
     session     optional      pam_oddjob_mkhomedir.so
     session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
     session     required      pam_unix.so

A Listagem 20 mostra um exemplo do Active Directory forçando sua política de senha.

Lista 20.
     -bash-4.1$ passwd
     Changing password for user dwuser01.
     Changing password for dwuser01
     (current) NT password:
     New password:
     Retype new password:
     Password does not meet complexity requirements
     Your password must be at least 8 characters; cannot repeat any of your previous 
     10 passwords; must contain capitals, numerals or punctuation; and cannot contain your 
     account or full name; Please type a different password. Type a password which meets these 
     requirements in both text boxes.
     passwd: Authentication token manipulation error

Removendo a máquina virtual do Active Directory

Quando a máquina virtual é excluída (geralmente como resultado da exclusão da instância do sistema virtual à qual pertence), o host associado a essa máquina virtual deve deixar o domínio Active Directory. Isso também removerá o objeto do computador correspondente no Active Directory. O comando a seguir pode ser emitido para sair do domínio:

net ads leave -U $ADS_username%$ADS_password

As variáveis$ADS_username e $ADS_password são o nome de usuário e a senha da Conta do Serviço do Active Directory.

Colocando tudo junto

Agora que viu como automatizar a configuração da integração do Active Directory, você está pronto para construir pacotes de script. Eles podem ser incluídos em padrões de sistema virtual, como você verá um pouco mais tarde.

Pacotes de scripts

Para o propósito deste artigo, dois pacotes de script foram incluídos como exemplos:

  • add_ad_os_authentication deve ser executado na criação da VM e basicamente configura e integra a VM ao domínio do Active Directory.
  • remove_ad_os_authentication deve ser executado na exclusão da VM e remove esta VM do domínio do Active Directory.

Pacote de scripts: incluir autenticação do SO AD

Esse pacote de script executa as etapas de 1 a 11 descritas neste artigo para integrar a autenticação RHEL 6 com o Active Directory:

  1. Identifique os caminhos do arquivo de configuração
  2. Inicie os serviços
  3. Defina a configuração samba inicial
  4. Modifique os arquivos de configuração
  5. Modifique a configuração Kerberos
  6. Associe o domínio do Active Directory
  7. Modifique a configuração winbind PAM gerada para Kerberos SSO
  8. Configure o acesso PAM
  9. Configure o Sudo
  10. Configure os níveis de execução para os serviços
  11. Inicie os serviços

Neste pacote de script, a instalação de RPMs é feita usando arquivos locais incluídos no arquivo zip do pacote de script. Uma solução melhor seria usar o RedHat OS Update Shared Service fornecido pelo PureApplication System em substituição.

Como esse pacote de scripts de amostra usa os arquivos RPM locais, um parâmetro adicional denominado OS_IMAGE é apresentado para assegurar que os RPMs corretos para a imagem devem ser instalados. Isso se refere à imagem virtual obtida do catálogo que é usada pelo padrão de sistema virtual para cada parte do padrão. Esse tipo de imagem virtual poderia ser, por exemplo "Core OS 2.0.0.4", "DB2 Enterprise 9.7.0.8" ou "WAS 8.5.5.1."

nome: incluir autenticação do SO AD
execmode: 0 (na criação do sistema virtual)
descrição: Instale RPMs e configure para autenticação do SO Active Directory
envonly: TRUE
savevars: 0

Tablela 1. Parâmetros para incluir autenticação do SO AD
ParâmetroTipoObrigatórioValor de exemploDescrição
OS_IMAGE(padrão)TrueOs valores válidos são:
BPM 8.0.1.0
BPM 8.5.0.1
Core OS 2.0.0.1
Core OS 2.0.0.3
Core OS 2.0.0.4
Core OS 2.1.0.0
IIS 9.1.0.0 CN
IIS 9.1.0.0 EN
WAS 8.0.0.4
WAS 8.0.0.5
WAS 8.0.0.7
WAS 8.5.0.0
Denota a imagem do sistema virtual usada para implementação da VM. Essa lista é usada para instalar os RPMs corretos. Essa lista precisa ser adaptada.
ADS_username(padrão)TrueipasadO nome de usuário para ligar ao Active Directory e possui permissões para incluir o objeto do computador
ADS_passwordpasswordTrue********Senha para nome de usuário acima
ADS_container_shortname(padrão)TrueIPAS/ServersO nome do contêiner (OU) para armazenar o objeto do computador é necessário pelo comando net ads join. A sequência OU lê de cima para baixo sem nomes distintos relativos (RDNs) e é delimitada por “/.”
ADS_workgroup(padrão)TrueDWNome do grupo de trabalho no domínio
ADS_realm(padrão)TrueDW.IBM.COMO nome do domínio é usado pelas configurações Samba e Kerberos.
ADS_login_group(padrão)TrueGRP_IPAS_<workload>_loginOs membros deste grupo no Active Directory possuem permissão para efetuar login no SO usando SSH
ADS_middleware_group(padrão)TrueGRP_IPAS_<workload>_middlewareOs membros deste grupo no Active Directory possuem permissão para switch user (su) um ou mais usuários técnicos diferentes no SO, conforme especificado pelo ADS_middleware_users.
ADS_root_group(padrão)TrueGRP_IPAS_<workload>_rootOs membros deste grupo no Active Directory possuem permissão para switch user (su) para “root”.
ADS_middleware_users(padrão)Truevirtuser,db2inst1A lista separada por vírgula contendo usuários técnicos para middleware no SO definido no Active Directory (por exemplo, virtuser, db2inst1 e assim por diante).

Pacote de scripts: remover autenticação do SO AD

O propósito deste pacote de script é assegurar que o host deixe o domínio após a exclusão da máquina virtual. Portanto, este pacote de scripts está configurado para ser executado na exclusão do sistema virtual. Como esse pacote de scripts será executado no momento da exclusão, tenha em mente que a máquina virtual precisa estar em execução ao excluir a instância do sistema virtual. Se a máquina virtual for parada, o pacote de scripts não será executado.

nome: remover a autenticação do SO AD
execmode: 1 (na exclusão do sistema virtual)
descrição: Remova a máquina virtual do Active Directory
envonly: TRUE
savevars: 0

Tablela 2. Parâmetros para remover a autenticação do SO AD
ParâmetroTipoObrigatórioValor de exemploDescrição
Remove_AD_ADS_container(padrão)TrueOU=IPAS,DC=dw,DC=ibm,DC=comNome distinto do contêiner no qual o objeto do computador é armazenado no Active Directory.
Remove_AD_ADS_user(padrão)TrueipasadO nome de usuário para ligar ao Active Directory e possui permissões para remover o objeto do computador
Remove_AD_ADS_passwordpasswordTrue********Senha para nome de usuário acima

Padrão de sistema virtual

Com os dois pacotes de scripts acima, agora é possível construir um padrão do sistema virtual simples que se associará automaticamente a um domínio do Active Directory no momento da implementação. Você apenas tem que incluir dois pacotes de scripts a cada VM no qual deseja a autenticação Active Directory (Figura 3). Tenha cuidado ao selecionar o valor correto para o parâmetro OS_IMAGE, dependendo da VM na qual está incluindo os pacotes de scripts.

Figura 3. Padrão de sistema virtual de amostra (firmware do Pure Application System v2.0)
Sample virtual system pattern (Pure Application System v2.0 firmware)
Sample virtual system pattern (Pure Application System v2.0 firmware)

Efetuando logon usando as credenciais do Active Directory

A Listagem 21 mostra um exemplo de um usuário criando log com credenciais do Active Directory, mostrando a associação ao grupo. Essa associação ao grupo permite que o usuário execute sudo su – virtuser e sudo –i (root).

Lista 21.
     login as: dwuser01
     dwuser01@pas01-grp063.dw.ibm.com's password:
     -bash-4.1$ id
     uid=138373(dwuser01) gid=100513(domain users) groups=100513(domain users),
     138530(GRP_IPAS_myWorkload_login),138531(GRP_IPAS_myWorkload_middleware),
     138532(GRP_IPAS_myWorkload_root)
     -bash-4.1$ sudo -i
     -bash-4.1$ id
     uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
     -bash-4.1$ logout
     -bash-4.1$ sudo su - virtuser
     [virtuser@pas01-grp063 ~]$ id
     uid=1000(virtuser gid=501(virtuser) groups=501(virtuser)
     [virtuser@pas01-grp063 ~]$

Efetuando logon usando SSO

A Listagem 22 mostra um exemplo de um usuário efetuando login de uma VM (pas01-grp063.dw.ibm.com) para outra (pas01-grp064.dw.ibm.com) usando a Conexão Única. Como ambas fazem parte do mesmo domínio do Active Directory, nenhuma senha é necessária porque o Kerberos manipula isso através da Conexão Única.

Lista 22.
     login as: dwuser01
     dwuser01@pas01-grp063.dw.ibm.com's password:
     -bash-4.1$ id
     uid=138373(dwuser01) gid=100513(domain users) groups=100513(domain users),
     138530(GRP_IPAS_myWorkload_login),138531(GRP_IPAS_myWorkload_middleware),
     138532(GRP_IPAS_myWorkload_root)
     -bash-4.1$ ssh pas01-grp064.dw.ibm.com
     -bash-4.1$ id
     uid=138373(dwuser01) gid=100513(domain users) groups=100513(domain users),
     138530(GRP_IPAS_myWorkload_login),138531(GRP_IPAS_myWorkload_middleware),
     138532(GRP_IPAS_myWorkload_root)
     -bash-4.1$

Padrão de sistema virtual (clássico)

A solução é exatamente a mesma com o padrão de sistema virtual clássico e os mesmos pacotes de scripts podem ser usados. Você tem que incluir ambos os pacotes de scripts em cada parte na qual deseja a autenticação do Active Directory (Figura 4). Tenha cuidado ao selecionar o valor correto para o parâmetro OS_IMAGE, dependendo da parte na qual está incluindo os pacotes de scripts.

Figura 4. Padrão de sistema virtual de amostra (clássico)
Sample virtual system pattern (Classic)
Sample virtual system pattern (Classic)

Conclusão

Integrar as máquinas virtuais executando no IBM PureApplication System com um Active Directory corporativo é útil, porque isso traz consistência na infraestrutura de TI. Os usuários e grupos podem ser gerenciados centralmente no Active Directory e as políticas de senha existente podem ser alavancadas, reduzindo muito o esforço para manter um grande número de máquinas virtuais no PureApplication System. Esse artigo descreveu as etapas necessárias para essa integração com as VMs que executam o SO RedHat e forneceu um conjunto de pacotes de scripts de amostra que pode ser usado para acelerar a implementação.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Cloud computing
ArticleID=1004591
ArticleTitle=A integração de autenticação de SO com Microsoft Active Directory no IBM PureApplication System
publish-date=04302015