Samba id mapping, versions 3.6.9 and 3.5.4

berndbausch · 01-14-2014, 09:03 PM

I have two different versions of Samba on different servers, 3.6.9 and 3.5.4.

The 3.6.9 version of testparm reports an idmap parameter that doesn't appear in the smb.conf file.
The 3.5.4 version of testparm doesn't show this parameter.

My 3.6.9 smb.conf file:

Code:

[global]
        workgroup = maison
        netbios name = alice
        security = user

        log level = 2

[tmp]
        path = /srv/samba/tmp
        writeable = yes
        user name = mickey

The 3.5.4 smb.conf is identical except for a netbios name bob and a user guru.

testparm output on 3.6.9:

Code:

.....
Press enter to see a dump of your service definitions

[global]
        workgroup = MAISON
        netbios name = ALICE
        idmap config * : backend = tdb

[tmp]
        path = /srv/samba/tmp
        username = mickey
        read only = No

testparm output on 3.5.4:

Code:

Press enter to see a dump of your service definitions

[global]
        workgroup = MAISON
        netbios name = BOB
        log level = 2

[tmp]
        path = /srv/samba/tmp
        username = guru
        read only = No

The newer version of testparm also remarks that I shouldn't use the username parameter anymore. That's fine; I am just testing.

It would seem that the idmap statement has consequences for user authentication; I am not able to get authenticated on 3.6.9 without adding the user to the Samba user database.

The 3.6.9 WHATSNEW.txt file contains a section on ID Mapping Changes, but it doesn't seem relevant to my case.

So my question is about the background of this. Where does the idmap statement come from, and is my assessment about the consequences correct? And what's the rationale for the change from 3.5.4 to 3.6.9?

Ser Olmy · 01-15-2014, 07:49 PM

The idmap parameter is only relevant in scenarios where Samba is a member of an Active Directory domain. It controls how Security Identifiers (SIDs) in AD are mapped to Unix account and group IDs.

Your authentication issues are most likely related to the SMB protocol version (or the removal of the long-deprecated "share" security mode).

Encrypted SMB authentication requires the password to be stored using an MS/AD compatible hash algorithm, hence the need to add users and passwords to a separate database. You'll either have to add the users to the Samba database or "dumb down" the protocol version with the appropriate setting in smb.conf.

berndbausch · 01-15-2014, 11:59 PM

Thanks! This will help me investigate further. However:

Quote:

Originally Posted by Ser Olmy

The idmap parameter is only relevant in scenarios where Samba is a member of an Active Directory domain. It controls how Security Identifiers (SIDs) in AD are mapped to Unix account and group IDs.

This is strange, as there is no AD in the vicinity (this is a home network), and as you can see from my smb.conf, I didn't even touch the Samba domain parameters. So why does testparm call this parameter out?

Ser Olmy · 01-16-2014, 05:55 AM

Quote:

Originally Posted by berndbausch

This is strange, as there is no AD in the vicinity (this is a home network), and as you can see from my smb.conf, I didn't even touch the Samba domain parameters. So why does testparm call this parameter out?

I believe it simply reflects a change in the defaults. Not having an idmap setting in smb.conf means the setting "idmap config * : backend = tdb" takes effect. I see the same on any system with a recent version of Samba 3.x or 4.x, regardless of whether Samba participates in an AD domain or not.