Geekly articles weekly

No palco novamente vencedores das competições internacionais SSH e sudo. Sob a orientação do Honored Conductor Active Directory

Historicamente, os direitos do sudo eram regulados pelo conteúdo dos arquivos de /etc/sudoers.d e visudo , e a autorização da chave era realizada usando ~ / .ssh / allowed_keys . No entanto, com o crescimento da infraestrutura, há um desejo de gerenciar esses direitos centralmente. Até o momento, pode haver várias soluções:

  • Sistema de Gerenciamento de Configuração - Chef , Fantoche , Ansible , Sal
  • Active Directory + sssd
  • Várias distorções na forma de scripts e edição manual de arquivos

Na minha opinião subjetiva, a melhor opção para gerenciamento centralizado ainda é um monte de Active Directory + sssd . As vantagens dessa abordagem são:

  • Verdadeiramente um único diretório de usuário centralizado.
  • Distribuir direitos sudo é sobre adicionar um usuário a um grupo de segurança específico.
  • No caso de vários sistemas Linux, é necessário introduzir verificações adicionais para determinar o SO ao usar sistemas de configuração.

O pacote de hoje será dedicado ao pacote Active Directory + sssd para gerenciar direitos sudo e armazenar chaves ssh em um único repositório.
Então, a platéia congelou em um silêncio tenso, o maestro levantou a varinha e a orquestra preparada.
Vamos lá

Dado:

  • Domínio do Active Directory testopf.local no Windows Server 2012 R2.
  • Host Linux executando o Centos 7
  • Autorização configurada usando sssd

Ambas as soluções fazem alterações no esquema do Active Directory ; portanto, verificamos tudo em um ambiente de teste e só então fazemos alterações na infraestrutura de trabalho. Quero observar - todas as alterações são baseadas em pontos e, de fato, adicionam apenas os atributos e classes necessários.

Etapa 1: gerenciar funções sudo através do Active Directory .


Para estender o esquema do Active Directory, você precisa baixar a última versão do sudo - 1.8.27 hoje. Descompacte, copie o arquivo schema.ActiveDirectory do diretório ./doc para o controlador de domínio. Na linha de comando com direitos de administrador do diretório em que você copiou o arquivo, execute:

ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Não esqueça de substituir seus valores)

Abra adsiedit.msc e conecte-se ao contexto padrão:

Na raiz do domínio, crie uma unidade sudoers . (Os burgueses argumentam teimosamente que é nessa subdivisão que o daemon sssd procura por objetos sudoRole . No entanto, após ativar a depuração detalhada e examinar os logs, foi revelado que a pesquisa é realizada em toda a árvore de catálogos.)

Crie o primeiro objeto na unidade que pertence à classe sudoRole . O nome pode ser escolhido absolutamente arbitrariamente, pois serve apenas para identificação conveniente.

Entre os possíveis atributos disponíveis da extensão do esquema, os principais são:

  • sudoCommand - Determina quais comandos têm permissão para executar no host.
  • sudoHost - determina a quais hosts essa função se aplica. Pode ser definido como ALL ou para um host individual por nome. Também é possível usar uma máscara.
  • sudoUser - indica quais usuários têm permissão para executar o sudo .
    Se um grupo de segurança for especificado, adicione o sinal "%" no início do nome. Se houver espaços no nome do grupo, não há com o que se preocupar. A julgar pelos logs, o mecanismo sssd assume a tarefa de escapar de espaços.


Figura 1. Objetos sudoRole na unidade sudoers na raiz do diretório


Figura 2. Associação aos grupos de segurança especificados nos objetos sudoRole.

A seguinte configuração é feita no lado do Linux.

No arquivo /etc/nsswitch.conf , adicione a linha ao final do arquivo:

 sudoers: files sss

No arquivo /etc/sssd/sssd.conf na seção [sssd] , adicione sudo aos serviços

 cat /etc/sssd/sssd.conf | grep services services = nss, pam, sudo

Após todas as operações, você precisa limpar o cache do daemon sssd. As atualizações automáticas são feitas a cada 6 horas, mas por que precisamos esperar tanto quando queremos agora?

 sss_cache -E

Muitas vezes acontece que limpar o cache não ajuda. Então paramos o serviço, limpamos a base, iniciamos o serviço.

 service sssd stop rm -rf /var/lib/sss/db/* service sssd start

Nós nos conectamos com o primeiro usuário e verificamos que ele pode ser acessado em sudo

 su user1 [user1@testsshad log]$ id uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_) [user1@testsshad log]$ sudo -l [sudo] password for user1: Matching Defaults entries for user1 on testsshad: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user1 may run the following commands on testsshad: (root) /usr/bin/ls, /usr/bin/cat

Fazemos o mesmo com o nosso segundo usuário:

 su user2 [user2@testsshad log]$ id uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root) [user2@testsshad log]$ sudo -l Matching Defaults entries for user2 on testsshad: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user2 may run the following commands on testsshad: (root) ALL

Essa abordagem permite definir centralmente as funções do sudo para diferentes grupos de usuários.

Armazenando e usando chaves ssh no Active Directory


Com uma pequena extensão do esquema, é possível armazenar chaves ssh em atributos de usuário do Active Directory e usá-las para autorização em hosts Linux.

A autorização via sssd deve ser configurada.

Adicione o atributo desejado usando o script do PowerShell.

AddsshPublicKeyAttribute.ps1
Função New-AttributeID {
$ Prefixo = "1.2.840.113556.1.8000.2554"
$ GUID = [System.Guid] :: NewGuid (). ToString ()
$ Peças = @ ()
$ Parts + = [UInt64] :: Parse ($ guid.SubString (0.4), “AllowHexSpecifier”)
$ Parts + = [UInt64] :: Parse ($ guid.SubString (4,4), “AllowHexSpecifier”)
$ Parts + = [UInt64] :: Parse ($ guid.SubString (9,4), "AllowHexSpecifier")
$ Parts + = [UInt64] :: Parse ($ guid.SubString (14,4), “AllowHexSpecifier”)
$ Parts + = [UInt64] :: Parse ($ guid.SubString (19,4), “AllowHexSpecifier”)
$ Parts + = [UInt64] :: Parse ($ guid.SubString (24.6), “AllowHexSpecifier”)
$ Parts + = [UInt64] :: Parse ($ guid.SubString (30.6), “AllowHexSpecifier”)
$ oid = [String] :: Format ("{0}. {1}. {2}. {3}. {4}. {5}. {6}. {7}", prefixo $, $ Parts [ 0]
$ Peças [1], $ Peças [2], $ Peças [3], $ Peças [4], $ Peças [5], $ Peças [6])
$ oid
}
$ schemaPath = (Get-ADRootDSE) .schemaNamingContext
$ oid = New-AttributeID
$ attribute = @ {
lDAPDisplayName = 'sshPublicKey';
attributeId = $ oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $ true;
adminDescription = 'Chave pública do usuário para login SSH';
}

New-ADObject -Name sshPublicKey -Type attributeSchema -Path $ schemapath -OtherAttributes $ attribute
$ userSchema = get-adobject -SearchBase $ schemapath -Filter 'name -eq "usuário"'
$ userSchema | Set-ADObject -Add @ {mayContain = 'sshPublicKey'}

Após adicionar o atributo, reinicie os Serviços de Domínio Active Directory.
Passamos aos usuários do Active Directory. De qualquer maneira conveniente para você, geramos um par de chaves para conexão ssh.

Inicie o PuttyGen, clique no botão "Gerar" e clique freneticamente no mouse dentro de uma área vazia.

Após a conclusão do processo, podemos salvar as chaves pública e privada, preencher a chave pública no atributo de usuário do Active Directory e aproveitar o processo. No entanto, a chave pública deve ser usada na janela " Chave pública para colar no arquivo OpenSSH allowed_keys: ".



Adicione a chave ao atributo do usuário.

Opção 1 - GUI:



Opção 2 - PowerShell:

get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}

Portanto, temos no momento: um usuário com o atributo sshPublicKey preenchido, um cliente Putty configurado para autorização de chave. Resta um pequeno ponto: como fazer o daemon sshd extrair a chave pública que precisamos dos atributos do usuário. Um pequeno script encontrado nos espaços abertos da Internet burguesa lida com sucesso com isso.

 cat /usr/local/bin/fetchSSHKeysFromLDAP #!/bin/sh ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D Administrator@testopf.local -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp'

Definimos 0500 permissões de root nele.

 chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP

Neste exemplo, a conta de administrador é usada para a ligação ao diretório. Em condições de combate, deve haver uma conta separada com um conjunto mínimo de direitos.

Pessoalmente, fiquei muito confuso com o momento da senha em sua forma pura no script, apesar dos direitos estabelecidos.

Opção de solução:

  • Eu salvo a senha em um arquivo separado:

     echo -n Supersecretpassword > /usr/local/etc/secretpass
  • Defino as permissões no arquivo 0500 para root

     chmod 0500 /usr/local/etc/secretpass
  • Altero os parâmetros de inicialização do ldapsearch: o parâmetro -w superSecretPassword é alterado para -y / usr / local / etc / secretpass

O acorde final na suíte de hoje está editando sshd_config

 cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe" PubkeyAuthentication yes AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP AuthorizedKeysCommandUser root

Como resultado, obtemos a seguinte sequência com a autenticação de chave configurada no cliente ssh:

  1. O usuário se conecta ao servidor, indicando seu nome de usuário.
  2. O daemon sshd, por meio de um script, extrai o valor da chave pública do atributo de usuário no Active Directory e autoriza as chaves.
  3. O daemon sssd autentica ainda mais o usuário com base na associação ao grupo. Atenção! Se isso não estiver configurado, qualquer usuário do domínio terá acesso ao host.
  4. Quando o sudo tenta, o daemon sssd procura funções no diretório do Active Directory. Se houver funções, os atributos e a associação de usuários do grupo serão verificados (se sudoRoles estiver configurado para usar grupos de usuários)

Sumário


Portanto, as chaves são armazenadas nos atributos de usuário do Active Directory, permissões sudo - da mesma forma, o acesso aos hosts Linux por contas de domínio é realizado verificando a associação no grupo do Active Directory.

A onda final da varinha do maestro - e o salão congela em silêncio.

Recursos utilizados por escrito:

Source: https://habr.com/ru/post/pt449702/

More articles:


All Articles