Gerenciamento de usuário e permissão do Linux em um ambiente do AD

Question

Problema: gerenciamento centralizado de usuários e gerenciamento de permissões de usuário para recursos de acesso do usuário (acesso a serviços, diretórios base, participação em grupos de usuários locais, permissões do sistema de arquivos etc.) em servidores Linux forma de associação ao grupo no Active Directory.

Contexto: Temos vários servidores Linux, alguns CentOS e outros Ubuntu, que são usados para desenvolvimento, hospedagem na web, hospedagem de banco de dados, serviço PXE, etc. Também temos um Active Directory centralizado ambiente no qual todos os usuários são adicionados e fornecidos com membros do grupo no momento de ingressar na organização.

Exemplo: Bob e Alice participam da organização, são adicionados em seus grupos apropriados no AD e agora eles têm acesso ao SSH ou MySQL em um ou mais dos nossos servidores Linux. Uma vez que Bob sai, nós o removemos do (s) grupo (s) AD e ele não tem mais acesso aos servidores Linux para SSH, MySQL, etc.

Notas: Como alguém aborda essa tarefa? Existe um conjunto de utilitários disponíveis no Linux que permitam esse tipo de operação? O acesso que precisamos conceder a um usuário dependerá das associações de grupo de usuários das quais ele é membro do Active Directory. Por exemplo, todos dentro do Grupo de Desenvolvimento do AD precisarão ter acesso SSH, acesso ao MySQL e um diretório inicial nos servidores de versão Linux 1 e 2. Todos que estiverem no grupo AD do administrador de sistemas precisarão ter acesso SSH e Permissões do SU para todos os servidores Linux, etc. Examinei vários artigos existentes no serverfault e não encontrei nada que corresponda às necessidades listadas aqui.

    

Answer 1

Existem duas técnicas básicas que eu conheço -

Método um: Gerenciamento de identidades para UNIX da Microsoft - Isso permite expor o ActiveDirectory como um servidor NIS.
Isso funciona com praticamente qualquer sabor * NIX (todos eles suportam NIS) e tem todos os benefícios (e desvantagens) do NIS. Também é oficialmente suportado pela Microsoft, o que significa que você tem alguém para chamar se o material quebrar.

Método 2: pam_ldap / nss_ldap (ou sistemas semelhantes, mais recentes).
Isso funciona com qualquer sabor moderno * NIX capaz de autenticar em relação a diretórios LDAP, e pode ser incluído por padrão com o Ubuntu e o CentOS atualmente. É um pouco mais robusto / moderno do que a hack do tipo Método NIS, mas é menos provável que seja oficialmente suportado pela Microsoft.

Ambas as técnicas exigem que você estenda os usuários e grupos do AD para serem usuários POSIX & Grupos, respectivamente, para que haja UIDs POSI e GIDs utilizáveis para seus sistemas * NIX - a Microsoft fornece esse recurso no Active Directory. Um benefício adicional ao método dois acima é que você pode estender ainda mais os usuários para que você possa usar a chave pública do OpenSSH LDAP patch, que permite armazenar chaves SSH no LDAP e elimina a tarefa de sincronizar os arquivos authorized_keys em sua rede.

    

Answer 2

Pelo que estou lendo aqui, você quer ter todas as outras coisas típicas do Linux armazenadas na moda típica do Linux, e apenas ter membros do grupo vindo da AD?

A maioria dos exemplos que você pode encontrar vai falar sobre fazer puxando do AD / LDAP (talvez auth kerberos e LDAP para todo o usuário), parece que você só quer LDAP para o material do grupo. Se eu estiver errado, você precisará também fazer algumas coisas sobre o PAM.

Dependendo de qual versão (que mudou com o CentOS / RHEL entre as versões 5 e 6), você pode usar "nss_ldap" ou "sssd" para isso. O sssd é mais novo. É difícil dizer qual é mais flexível, pois eles parecem ser flexíveis de maneiras diferentes. O sssd parece mais flexível sobre a configuração de partes específicas para origens específicas, enquanto o nss_ldap parece mais flexível sobre o esquema LDAP que está sendo usado. Você precisará dos pacotes apropriados instalados. sssd-client , sssd-tools , sssd , libnss-sss , libnss-ldap e / ou nss_ldap . (o material de autenticação é pam_ldap ou sssd)

Terá de existir algum ID numérico exclusivo nos grupos no AD. Basicamente, você precisará extrair toda a definição do grupo do AD via LDAP, não apenas a associação ao grupo (a definição do grupo inteiro é basicamente nome, identificação numérica exclusiva e associação). Pode ser possível evitar isso com o sssd e configurá-lo para procurar IDs de grupo em arquivos e associação de grupo do LDAP. Realmente, o correto é estender o esquema do AD com as extensões UNIX apropriadas para que ele tenha os dados de usuário / grupo RFC2307 ou RFC2307bis.

Em /etc/nsswitch.conf você precisará de group: files ldap ou group: files sss . Você pode colocar "arquivos" em segundo lugar, em vez de primeiro.

nss_ldap ("ldap" no nsswitch.conf) é configurado via /etc/ldap.conf e documentado no pacote nss_ldap. Você precisará definir uri, binddn, bindpw, nss_base_group, pam_member_attribute, grupo nss_map_objectclass, nss_map_attribute.

sssd é configurado via /etc/sssd/sssd.conf. Concentre-se nas coisas nss e id_provider, não nas coisas pam e auth_provider. Leia as páginas de manual sssd.conf, sssd-ldap e sssd. Você precisará configurar um "domínio" e configurar algumas coisas "ldap_group" junto com as coisas básicas id_provider e ldap_uri.

Nota: Eu corro as coisas nss_ldap e sssd contra um ambiente OpenLDAP atualmente. Faz anos desde que usei nss_ldap / pam_ldap com um ambiente AD.

Também pode valer a pena investigar o que o Samba pode fazer. É tipicamente usado para compartilhamento de arquivos / impressão, mas o material de logon e o material do controlador de domínio podem ser configurados para o que você precisa.

    

Answer 3

Dê uma olhada em do mesmo modo aberto (ou agora chamado de PowerBroker Identity Services Open Edition) . Eu usei o Likewise aberto em um trabalho anterior e trabalhei muito bem com o Samba e nossos desenvolvedores.