Samba: autenticação AD para usuários locais

Question

Temos muitos servidores de desenvolvimento Linux que geralmente são acessados via SSH. Cada desenvolvedor tem uma conta local em cada caixa, gerenciada pelo Puppet. Logins são apenas através de chaves privadas; não há senhas locais.

Gostaria de executar o Samba nessas caixas e autenticar em nosso domínio do AD. Eu não quero autenticação AD para nada além do Samba - todo o resto é acessado via SSH e chaves privadas.

Aqui está o meu smb.conf :

[global]
 workgroup = DOMAIN
 server string = Samba Server Version %v
 security = ADS
 realm = DOMAIN.FQDN
 encrypt passwords = yes
 log level = 3
 log file = /var/log/samba/%U.log

[homes]
 comment = Home Directories
 browseable = no
 writable = yes

Tenho certeza de que a configuração do Kerberos está correta quando entro no domínio.

Relevante (ou seja, não padrão) nsswitch.conf linhas:

passwd:     files winbind
group:      files winbind

Parece que o problema é Mapeamento do UID do AD para o UID do UNIX . O backend padrão do TDB criará contas UNIX 'virtuais' sob demanda quando os usuários do AD se conectarem, mas eu não quero isso - eu quero que o usuário foo mapeie para o usuário local foo . Se eu adicionar linhas idmap uid e idmap gid , os usuários autenticam-se bem, mas suas contas não estão mapeadas para as contas UNIX.

Alguma ideia? Somoene deve ter feito isso antes! Eu não quero mudar para usar winbind e AD para fornecer todas as informações da conta por causa do incômodo com a manutenção de UID / GIDs consistentes em todas as máquinas. Também colocamos muito na configuração de usuário controlada por Puppet que não queremos reinventar.

    

Answer 1

Verifique se o serviço winbind está sendo executado.

Configure o seu /etc/pam.d/samba:

account     [default=bad success=ok user_unknown=ignore]  pam_winbind.so
account     required      pam_permit.so

password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so
session     required      pam_limits.so

auth       required pam_nologin.so
auth sufficient pam_winbind.so use_first_pass
auth required   pam_deny.so

As mudanças de Pam às vezes exigem uma reinicialização do winbind. Não deveria, mas a experiência prática diz que é assim mesmo.

No smb.conf você também precisa:

realm = YOURKERBEROSREALMNAME
password server = the host or IP of your ADC
idmap backend = rid:DOMAIN=5000-100000000
idmap uid = 10000-10000000
idmap gid = 10000-10000000
winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes

Onde DOMAIN é seu grupo de trabalho ou nome de domínio e o reino corresponde ao que está no seu krb5.conf

Reinicie os serviços do samba após as alterações no smb.conf

    

Answer 2

de link

A Samba member of a Windows networking domain (NT4-style or ADS) can be configured to handle identity mapping in a variety of ways. The mechanism it uses depends on whether or not the winbindd daemon is used and how the winbind functionality is configured. The configuration options are briefly described here:

Winbind is not used; users and groups are local:

Where winbindd is not used Samba (smbd) uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming network traffic. This is done using the LoginID (account name) in the session setup request and passing it to the getpwnam() system function call. This call is implemented using the name service switch (NSS) mechanism on modern UNIX/Linux systems. By saying "users and groups are local," we are implying that they are stored only on the local system, in the /etc/passwd and /etc/group respectively.

For example, when the user BERYLIUM\WambatW tries to open a connection to a Samba server the incoming SessionSetupAndX request will make a system call to look up the user WambatW in the /etc/passwd file.

This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

parece que se você tirar o winbind da equação, as coisas serão honkydorey supondo que seus usuários do AD sejam os mesmos que os usuários / etc / passwd locais.