☰

Usando LDAP: como fazer login com SSH, montando o diretório inicial do Samba com autofs?

tag-icon • tag-icon ssh ldap samba autofs
Usando LDAP: como fazer login com SSH, montando o diretório inicial do Samba com autofs?

Passei algum tempo configurando a autenticação baseada em LDAP em minha rede MacOS, iOS e Linux, levando em consideração as peculiaridades especiais do MacOS e Synology (meu NAS). O login SSH (chaves SSH etc.) funciona e as montagens de compartilhamento do Samba funcionam. Foi tudo muito complicado e agora sei mais sobre LDAP do que jamais imaginei.

No entanto...

Tendo chegado a um ponto em que eu poderia (pelo menos em teoria) fazer login em qualquer máquina da minha rede, pensei que seria bom que os usuários também tivessem acesso ao mesmo diretório inicial em todos os lugares. Não tem problema: autofs, que também pode ser gerenciado a partir do LDAP! Ou então pensei...

Estou tentando algo como o seguinte para configurar os diretórios iniciais do Samba para autofs:

cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,username=&,uid=&,gid=& ://s-sy-00.local/home

Alguns antecedentes:

  1. s-sy-00.localé o meu Synology NAS onde os diretórios iniciais ficarão.
  2. /homeé UNC do compartilhamento do diretório inicial que Synology fornece para o usuário definido em username=.

Os problemas começam quando faço login em uma máquina remota com SSH. autofstenta montar o diretório inicial do usuário, mas precisa da senha do usuário. Posso colocar a senha em um password=parâmetro na automountInformationlinha ou posso colocar o nome de usuário e a senha em um arquivo de credenciais que passo com o credentials=parâmetro. Ambas as abordagens levam a maior complexidade (uma automountentrada para cada usuário) e duplicação (mesmo nome de usuário e senha em dois locais diferentes: LDAP e o arquivo de credenciais ou o automounte o posixUserno LDAP).

Existe uma maneira padrão de lidar com esse problema? Minhas habilidades em mecanismos de pesquisa ainda não revelaram nada.

Parece-me que existem três soluções possíveis:

  1. aquela que é óbvia para todos, mas não para mim;
  2. usar a chave SSH para montar um arquivo de credenciais por usuário (possivelmente gerado dinamicamente a partir do LDAP) a partir de um compartilhamento SSHFS;
  3. usando Kerberos para um SSO completo.

Eu preferiria o número 1 :-) Tenho aversão ao Kerberos: parece um exagero e certamente é relativamente complexo.

Alguém pode oferecer algumas palavras de sabedoria para me dar um começo de ano novo?

Responder1

Bem, contanto que você esteja no Linux e usesenhaautenticação para o login inicial, então você pode ter um módulo PAM que armazena a senha em um chaveiro do kernel onde mount.cifs pode pegá-la. Não tenho 100% de certeza se o cifs-utils atualmente vem com um, mas ele possui uma cifscredsferramenta CLI que faz o mesmo.

Ainda assim, pessoalmente, eu apenas configuraria a autenticação Kerberos em vez do LDAP. (Ou seja, deixando o LDAP fazer apenas o trabalho de um serviço de diretório.) No geral, o Kerberos é exatamente como o LDAP: parece complexo visto de fora, revela-se muito simples quando você olha mais de perto, exceto pelos milhões de peculiaridades, casos extremos e decisões estranhas que remontam à década de 1980 e que o tornam complexo novamente.

Será um pouco mais versátil do que hacks PAM específicos para SMB – os mesmos tickets podem ser usados ​​para acessar SMB, NFS, LDAP, HTTP, SSH... Você pode até reutilizar seu servidor LDAP existente como back-end do banco de dados KDC, obtendo replicação gratuita sem ter que lidar com o kprop.

Observe que com mount.cifs,ambosKerberos e cifscreds devem ser usados ​​ao montar o compartilhamento com a multiuseropção, o que oferece um comportamento semelhante ao NFS – a mesma montagem SMB pode ser acessada por vários usuários, e o kernel usará automaticamente as credenciais SMB corretas para cada uid.

E quanto à autenticação de chave pública SSH, não há muito que você possa fazer automaticamente - você recupera um arquivo de credenciais e o usa com cifscreds, ou você recupera um arquivo de credenciais e o usa com kinit... Novamente, acho que o último é mais versátil.

Responder2

Embora eu ache que a resposta de @ user1686 é a correta, ainda gostaria de compartilhar a solução alternativa que encontrei e usarei até encontrar tempo para migrar para uma solução Kerberos.

  1. Criei um usuário no NAS que liguei smbownere atribuí uma senha a ele. Concedi smbownerdireitos de administrador ao NAS, o que significa que ele pode montar um compartilhamento SMB.

  2. Criei um arquivo de credenciais do Samba na máquina necessária para montar o compartilhamento SMB. Coloquei /etc/samba/credentials/s-sy-00e ficou assim:

username=smbowner
password=whatever

Observe que o arquivo de credenciais não contém uma definição de domínio.

  1. Alterei a entrada LDAP para o seguinte:
cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,credentials=/etc/samba/credentials/s-sy-00,uid=&,gid=& ://s-sy-00.local/&

Em sua defesa, pode-se dizer que esta solução funciona, embora não tenha certeza de quão segura seria num ambiente mais hostil que o meu.

Como funciona? smbownertem permissões suficientes para montar qualquer compartilhamento no NAS. Os parâmetros uid=&e gid=&garantem que o compartilhamento esteja acessível ao usuário local. Experimentarei mais tarde as configurações de permissões para o compartilhamento no NAS.

Talvez isso ajude outra pessoa.

Steve

informação relacionada