Estou tentando obter um compartilhamento de samba funcionando com IDs corretos em clientes Windows (SID) e Linux (uid/gid). O problema é que os uids e gids não são mapeados corretamente de volta para SIDs e os SIDs não são resolvidos para nomes. O que poderia levar a esse problema e como ele pode ser corrigido?
O que funciona
- mapeamento de atributos UNIX do Active Directory para uid/gid no Linux
- acesso ao compartilhamento
- Windows: UNC-Path no Explorer, tíquete Kerberos é aceito (sem dúvida para credenciais)
- Linux:
sudo mount -t cifs //ribonas2/test /mnt/ribonas2/smb/ -o domain=DOMAIN,username=paul.jaehne
- trabalhando com arquivos no compartilhamento
O que não funciona
- arquivos criados no Windows têm
Unix User\
eUnix Group\
(o UNIX uid e gid também fica visível por um tempo muito curto ao abrir a guia de segurança) em vez deDOMAIN\
como prefixo para usuários e grupos - adicionar permissões é falho: consigo adicionar principais do domínio e logo depois o
DOMAIN\whatever
é exibido corretamente. Quando espero algum tempo ou vejo o compartilhamento de outro computador, apenas o SID é exibido (o SID está correto, mas não resolvido para o nome):
Ambiente/Configuração
- Usei os seguintes guias (não é possível adicionar links reais por causa dos requisitos de reputação):
- vários controladores de domínio (Windows Server 2003 e Windows Server 2012 R2)
- Esquema do Active Directory do Windows Server 2003
- Servidor Ubuntu 16.04
- SSSD 1.13.4-1ubuntu1.1
- SMB 2:4.3.8+dfsg-0ubuntu1
- juntou-se a ambos
realm join
enet ads join
sssd.conf
:
[sssd]
domains = domain.company.com
config_file_version = 2
services = nss, pam
[domain/domain.company.com]
realmd_tags = manages-system joined-with-adcli
ad_domain = domain.company.com
krb5_realm = DOMAIN.COMPANY.COM
id_provider = ad
cache_credentials = True
krb5_store_password_if_offline = True
enumerate = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
default_shell = /bin/bash
# use uid and gid from active directory
ldap_id_mapping = False
# needed to use correct active directory properties (Windows Server 2003)
ldap_schema = ad
ldap_user_object_class = person
ldap_user_name = msSFU30Name
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_gecos = displayName
ldap_group_object_class = group
ldap_group_name = msSFU30Name
ldap_group_gid_number = msSFU30GidNumber
smb.conf
(as configurações do arquivo de configuração padrão são recuadas):
[global]
server role = member server
workgroup = DOMAIN
realm = DOMAIN.COMPANY.COM
security = ads
password server = dc1.domain.company.com # shouldn't be necessary and same problem without this line
idmap config * : backend = tdb
idmap config * : range = 100000-999999
idmap config DOMAIN : backend = ad
idmap config DOMAIN : range = 10000-20000 # the UNIX attributes are manually assigned in this range
kerberos method = secrets and keytab
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
log level = 10
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
# needed for Windows ACL/ACE
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
[test]
path = /srv/samba/test
writable = yes
TL;DR : Por que os atributos UNIX não são resolvidos para SIDs e por que os SIDs não são resolvidos para nomes?
Eu tenho a mesma situação. E consertei instalando o samba-winbind. Eu acho que a causa principal é que o samba não sabe como procurar o nome corretamente. Quando você instala o winbind, o smbd usará o winbind para resolução de nomes. Caso contrário, basta usar o linux UID, GID, é por isso que você viu o Unix User/Unix Group no Windows.
Eu não poderia explicar mais, mas espero que isso ajude você.
A resposta para isso é com os back-ends de mapeamento de id usados no Samba e no SSSD. O winbind "rid" e "auto-rid" do Samba não mapeia o SID do Windows para os números uid/gid da mesma forma que o SSSD. Portanto, se seu servidor CIFS ingressar no domínio com Samba/winbind e seus clientes estiverem conectados via SSSD com as opções padrão, o mapeamento de id falhará.
O SSSD tem uma configuração
ldap_idmap_autorid_compat
que você pode definirTrue
no arquivo sssd.conf que (deveria): " Altera o comportamento do algoritmo de mapeamento de ID para se comportar de maneira mais semelhante ao algoritmo "idmap_autorid" do winbind. " e, assim, permitir que seus clientes SSSD resolvam esse assunto.Eu uso
use_fully_qualified_names = True
em sssd.conf ele funciona sem nenhum pacote winbind.