Possível autenticar o Samba via Kerberos, mas sem junção de domínio?

4

Com um arquivo de configuração do Kerberos ...

[realms]
  DOMAIN.COM = {
    kdc = dc1.domain.com
    admin_server = dc1.domain.com
  }

... é possível que o Linux converse com o Active Directory para validação de senha sem necessariamente ser um membro do domínio do AD:

$ kinit jdoe
Password for [email protected]:
$ klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting     Expires            Service principal
01/12/15 15:36:16  01/13/15 01:36:25  krbtgt/[email protected]
        renew until 01/19/15 15:36:16

Neste ponto, você pode usar o PAM para definir usuários locais do Linux em / etc / passwd, mas ter suas sessões TTY autenticadas via Active Directory. Authn via krb5 é feito como um contexto por login:

auth        sufficient    pam_krb5.so use_first_pass

Mas se o krb5 já está implementado como parte dos padrões globais do PAM, por que o Samba também não está pegando? Eu vejo /etc/pam.d/samba faz uma inclusão do arquivo de autenticação de senha Kerberized, mas não há alegria ao acessar um volume SMB. (Logs de depuração indicam um erro de SID com falha para obter, que é muito "você não faz parte do domínio".)

Minha pergunta básica é: uma centralização automática krb5 similar pode ser feita sob o Samba como era para o Shell, sem toda essa sobrecarga / complexidade extra de participação no domínio? Eu preciso ter os serviços do Samba implementados em um grupo de sistemas em cluster NIS, mas não quero ter diferentes backends do TDBSAM em cada sistema, levando à confusão de senhas do SMB. Usar o Kerberos como meu autenticador seria ótimo. No entanto, eu ainda quero definir autorização / acesso através da conta Linux local e não abrir o acesso do Samba a todos os usuários do domínio, como seria o caso com a junção de domínio, a emulação Winbind DC ou o servidor AD completo.

Alternativamente: existe uma opção de authn melhor back-end centralizado para o Samba em um cluster Linux? Eu olhei para o CTDB, mas ele parecia ser voltado para a mediação do armazenamento compartilhado, em vez do authn central com volumes díspares ...

    
por DarkSideGeek 13.01.2015 / 02:16

2 respostas

6

Samba significa coisas diferentes para pessoas diferentes. Para alguns, é uma maneira de implementar a rede no estilo LanMan sem dízimo para a Microsoft, usando o WinBind para fornecer pseudo serviços de controlador de domínio sem realmente executar um Windows Server. Talvez seja por isso que "drookie" fez o comentário "Parece que você tem o AD em execução, mas, por algum motivo, não quer usá-lo. Por que usar o samba então? ” Por quê? Porque estou usando o Samba principalmente para o suporte básico do CIFS. Tudo o que é extra WinBind / ADS home-dir e cache de dados DC em cache é algo que eu realmente não queria. Eu estava procurando Linux para ainda definir autorização & acesso, não abri-lo para todos os usuários do domínio. Mas, para os usuários permitidos, use a autenticação Kerberos. (O Samba - especialmente o Samba4 - está se dirigindo para a emulação completa do Active Directory dos nós do Linux em um domínio do Windows AD, até a herança do SID / GUID, participação na UO etc. Seu objetivo é não ter necessidade de criar contas locais do Linux porque o Samba irá criá-los on-the-fly com base nos perfis do AD Superando minhas necessidades.)

Desde que eu estava olhando para o Samba principalmente para a funcionalidade do CIFS, eu esperava que o AD pudesse ser usado apenas para a parte de autenticação através das chamadas do Kerberos (como eu já implementei para o SSH). Se eu não precisava de junção de domínio para que o Kerberos funcionasse no nível TTY / SSH, eu realmente precisava dele para o Samba + Kerberos? Infelizmente, a resposta é sim. Mas apesar disso, eu ainda era capaz de realizar meu objetivo de AD / Kerberos authn sem transformar o host Linux em um PDC / BDC ou adiar todo o controle authz para o modo ADS. O que eu tenho funciona, e esta é a minha interpretação do porquê:

O Kerberos básico funciona no nível PAM / TTY porque o usuário está digitando sua senha interativamente, alimentado diretamente na biblioteca krb5; quando executado no contexto do usuário que faz a solicitação, nenhuma junção de domínio é necessária. No entanto, no caso de autenticar compartilhamentos do CIFS, o cliente do Windows já criptografou a senha que o usuário digitou, portanto, quando o Samba a obtiver, será o hash NTLMv2. É provavelmente por isso que o “livro de Hornbill” da O’Reilly diz que “as linhas do módulo auth PAM são completamente ignoradas” pelo Samba. Nesse caso, o Samba deve entrar em contato com o servidor do AD com segurança para recuperar os detalhes da credencial para saber com certeza se o usuário / senha está correto. Por esse motivo, uma junção de domínio é necessária. Em essência, o Samba associado a um domínio está atuando como um proxy Kerberos para entrar em contato com o AD e verificar as credenciais do cliente.

Descobri que mesmo com um domínio obrigatório, não é necessário executar um daemon WinBind local ou transformar o host Linux em um servidor AD completo. Aqui está o que eu fiz no arquivo de configuração do Samba4:

security = ADS 
passdb backend = tdbsam

realm = DOMAIN.COM 
password server = * 
encrypt passwords = yes 
lanman auth = no 
ntlm auth = no                    # NTLMv2
kerberos method = system keytab 
username map = /etc/samba/smbusers 
guest account = nfsnobody 
map to guest = Bad User 
obey pam restrictions = yes

É provavelmente mais significativo apontar o que eu não faço:

  • directivas winbind são omitidas do arquivo de configuração smb.conf
  • o serviço winbind não está ativado / em execução (para armazenar em cache os dados do AD como se fossem um DC)
  • O winbind não foi adicionado ao /etc/nsswitch.conf (para usar o domínio como um fonte válida de usuário local)
  • winbind e mkhomedir não são adicionados ao /etc/pam.d/system-auth (para permitir que os usuários do domínio façam login e criem contas dinamicamente)

O mínimo é que uma junção de domínio é necessária para ativar a pesquisa Kerberos em relação ao acesso de usuário local:

# net ads join -U Administrator
# net ads keytab create

No entanto, nenhum serviço é habilitado para transformar o host Linux em um substituto PDC / BDC ou ADS de autorização de acesso para transporte de cartão. Eu estou usando o Samba + Kerberos estritamente para validação de usuário local e nada mais.

    
por 18.01.2015 / 06:56
0

Você pode executar o samba na parte superior do NIS, nesse caso, o banco de dados do usuário será sincronizado por ele e, sem ingressar no domínio, você terá vários servidores samba independentes. Isso também significa que você terá que adicionar manualmente os usuários do domínio ou pelo menos suas senhas em cada servidor. Isso provavelmente não é o que você quer.

Você também pode experimentar usar o AD LDAP como o backend do ldap para usuários do samba, sem ingressar no domínio.

Portanto, há muitas opções, mas, para ser sincera, não entendo seu ponto de vista. Parece que você tem o AD em execução, mas, por algum motivo, não quer usá-lo. Por que usar o samba de qualquer maneira?

    
por 13.01.2015 / 05:54