Eu tenho um Debian/Jessie Samba 4.2.14 rodando como um membro do AD. ADC é um servidor Windows2008R2. Join funcionou sem problemas.
# net ads testjoin
Join is OK
wbinfo -u
e wbinfo -g
funcionam perfeitamente e fornecem uma lista de usuários e grupos do AD conforme o esperado. wbinfo -i <user>
funciona também:
# wbinfo -i TESTAD\\testuser
TESTAD\testuser:*:4294967295:4294967295:testuser:/home/TESTAD/testuser:/bin/false
Editar: algo está errado aqui, porque wbinfo -i
mapeia todos os usuários e grupos para o id 4294967295 que é, como observou @TheSkunk, 2 ^ 32 -1.
Editar 2: wbinfo --sid-to-uid TESTAD\\testuser
falha. Certamente devo configurar explicitamente alguns idmap
parâmetros (os padrões aparentemente não funcionam), mas como?
Editar 3: adicionei essas 2 linhas ao smb.conf:
idmap config * : backend = tdb
idmap config * : range = 10000-30000
E agora ẁbinfo -i TESTDOMAIN\testuser reports a valid id, and a different one for each and every user. However I still have the same problems (all users mapping to nobody,
id and
getent` não conhecendo usuários AD, etc).
No entanto getent passwd TESTAD\\testuser
falha:
# getent passwd TESTAD\\testuser
# echo $?
2
Posso me conectar ao servidor com qualquer conta AD usando smbclient
:
# smbclient //srv1/data -U TESTAD\\testuser
Enter TESTAD\testuser's password:
Domain=[TESTAD] OS=[Windows 6.1] Server=[Samba 4.2.14-Debian]
smb: \> ls
. D 0 Fri Feb 17 16:23:04 2017
.. D 0 Wed Feb 1 16:47:02 2017
test.txt N 5 Fri Feb 17 14:38:21 2017
popo D 0 Fri Feb 17 16:23:04 2017
117125466112 blocks of size 1024. 117052392484 blocks available
smb: \>
No entanto, a conexão é mapeada para nobody/nogroup
, e os arquivos criados também pertencem a nobody
ele. As máquinas Windows falham ao se conectar usando qualquer conta do AD. No entanto, se eu criar uma conta local com smbpasswd -a <user>
, eles poderão se conectar usando-a. No entanto, seus parâmetros de conexão, arquivos etc. são todos mapeados, nobody
embora a conta também exista localmente.
Aqui está o atual smb.conf
(o mais próximo possível do padrão):
[global]
workgroup = TESTAD
realm = TESTAD.lan
server role = member server
security = ADS
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
inherit permissions = Yes
inherit acls = Yes
[DATA]
path = /mnt/raid/
read only = No
guest ok = Yes
aqui está /etc/nsswitch.conf
(eu tentei adicionar e remover 'winbindd da sombra, nenhuma mudança):
# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat winbind
group: compat winbind
shadow: compat winbind
gshadow: files
hosts: files mdns4_minimal [NOTFOUND=return] dns wins
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
Não entendo por que a autenticação nunca parece passar pelo winbind. Estou ficando desesperada, alguma ideia?
Encontrei o problema principal: um pacote ausente. Infelizmente, não é fácil acertar: aqui está a configuração final e funcional (graças a Rowland Penny do samba.org):
verifique se você instalou todos os pacotes necessários (o que faltava era libnss-winbind):
parar os serviços
configure um smb.conf adequado (particularmente os parâmetros idmap):
Nessa configuração, há um arquivo /etc/samba/user.map adicional necessário contendo a seguinte linha:
Não se esqueça de preencher corretamente /etc/krb5.conf:
Tenha cuidado, krb5.conf deve pertencer ao root e ser lido por todos (644 direitos).
Edite /etc/nsswitch.conf e adicione winbind às linhas passwd e group:
Agora junte-se ao domínio:
Finalmente inicie os serviços:
getent passwd
deve funcionar com usuários do AD agora:CAVEAT Como já havia ingressado anteriormente no AD sem ter instalado as bibliotecas necessárias, tive que reiniciar o sistema para conseguir que o sistema após esta configuração autenticasse corretamente os usuários!
4294967295 significa 2^32 - este é um estouro de contador para GID ou UID produzido pelo deamon winbind para traduzir xids do AD. Isso não tem nada a ver com o mapeamento de convidados ... Se você usar idmap config YOUR_DOMAIN : backend = ad , o anúncio significa que as informações não são apenas armazenadas localmente, mas também são replicadas durante o tempo de execução para todos os clientes e também armazenadas neles ( mas onde está, atualmente é minha tarefa descobrir). anúncio significa que, se um cliente se perder, você armazenou todas as informações de mapeamento uid/gid nos outros. Se você restaurar seu cliente, todo o mapeamento será o mesmo novamente. O problema é que, se você tiver esse estouro uma vez, não poderá se livrar dele facilmente, porque todos os clientes o estão replicando (executando windbind) e, talvez (estou tentando descobrir) também o DC.
Aqui está a parte que estou usando para isso (funciona bem, mas tenho outro problema nos idmaps via anúncio):
Tendo chegado aqui, enquanto procurava boas instruções, pensei que deveria adicionar uma atualização a este post...
Daqui para frente, pretendemos usar
sssd
em vez dawinbind
integração do Active Directory no Linux. Emborasssd
não ofereça todos os recursos dowinbind
, ele usa a autenticação Kerberos em vez da autenticação NT Lan Manager (NTLM). Ref: Guia de Integração do Red Hat Windows, Capítulo 4.2Estamos tentando reduzir o uso da autenticação NTLM em favor do Kerberos, já que este último é considerado um protocolo mais seguro.
Com isso dito, configuramos nosso compartilhamento de arquivos SAMBA da seguinte maneira:
realmd
,samba
esssd
todas as dependências. Talvez mais?Junte-se ao reino:
realm join <domain name>
Este comando usará credenciais de domínio para ingressar a máquina no domínio. Isso configurará automaticamente
nsswitch.conf
,/etc/sssd/sssd.conf
e/etc/krb5.conf
, e também obterá um keytab da máquina, em/etc/krb5.keytab
.Certifique-se de que o sistema de arquivos esteja montado com a
acl
opção em/etc/fstab
, por exemploUUID=foo-bar-baz /mnt/share ext4 defaults,acl 0 0
Configure o samba corretamente. Há tantas opções, que isso é um pouco de arte escura. YMMV, mas o que funciona para mim é o seguinte. Qualquer coisa dentro
<
e>
precisa ser configurada para sua própria rede.Se de alguma forma você se bloqueou fora do compartilhamento (como eu mesmo fiz), as permissões do Windows podem ser visualizadas e alteradas usando os seguintes comandos do Linux: -
Eu tive o erro "client_input_channel_req: channel 0 rtype exit-status response 0" em um novo server02, no server01 no. A solução no meu caso foi adicionar duas linhas que por engano não adicionei ao /etc/samba/smb.conf:
shell de modelo = /bin/bash
template home dir = /home/%D/%u
Agora os usuários do domínio estão logados no server02.
Cumprimentos.