A atualização do Samba de 3.0 para 3.6 quebrou minha autenticação de ADS

Question

Acabei de atualizar meu Samba 3.0.33-3.15.el5_4 para 3.6.4 do CentOS 5.4 construído a partir da fonte. Copiei a configuração e o material das antigas localizações da distribuição para a localização esperada em / usr / lib. Copiei as opções de configuração que alterei do smb.conf padrão de 3.0.33 para a nova configuração padrão. Estou usando uma configuração de ADS e meu cliente Windows agora diz que minha senha de domínio está incorreta. Eu não vejo nada acontecendo em log.smbd

Saída antiga do testparm:

Load smb config files from /etc/samba/smb.conf
Processing section "[hactar]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

[global]
        workgroup = XXX
        realm = DS.XXX.EDU
        server string = Samba Server Version %v
        interfaces = lo, eth0
        security = ADS
        username map = /etc/samba/smbusers
        log file = /var/log/samba/log.%m
        max log size = 50
        socket options = TCP_NODELAY IPTOS_LOWDELAY
        local master = No
        wins server = 10.109.18.219
        cups options = raw

[hactar]
        comment = Galactic Supercomputer Filesystem
        path = /hactar
        valid users = root
        read only = No
        delete readonly = Yes

NOVA saída testparm:

Load smb config files from /usr/lib/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[hactar]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

[global]
        workgroup = XXX
        realm = DS.XXX.EDU
        server string = Samba Server Version %v
        interfaces = lo, eth0
        security = ADS
        username map = /etc/samba/smbusers
        log file = /var/log/samba/log.%m
        max log size = 50
        socket options = TCP_NODELAY IPTOS_LOWDELAY
        local master = No
        dns proxy = No
        wins server = 10.109.18.219
        idmap config * : backend = tdb

[hactar]
        comment = Galactic Supercomputer Filesystem
        path = /hactar
        valid users = root
        read only = No
        delete readonly = Yes

O que está acontecendo?

    

Answer 1

Eu tive o mesmo problema, foi causado pela compilação com configurações de caminho erradas. Enquanto rastreia wbinfo -t usando strace e procurando por fd aberto do daemon winbind usando lsof -p . Notei que os novos binários no rpm estavam procurando em lugares errados para o pipe e alguns arquivos .tdb. Então, depois de recompilar o rpm com novos caminhos, funcionou bem.

/tmp/.winbindd/pipe -> /var/run/winbindd/pipe
/etc/samba/secrets.tdb -> /var/lib/samba/private/secrets.tdb
/etc/samba/passdb.tdb -> /var/lib/samba/private/passdb.tdb