[Samba] Access to shares is denied after upgrading from 3.6.3 (openSUSE 12.1) to 4.1.17 (openSUSE 13.2)

[Rowland Penny]

On 20/03/15 13:35, Reinhard Nißl wrote:
> Hi Rowland,
>
> Am 20.03.2015 um 12:45 schrieb Rowland Penny:
>
>> Try replacing the global part of your smb.conf with this:
>>
>> [global]
>>       netbios name = PLATON
>>       workgroup = FEE
>>       security = ADS
>>       realm = FEE.DE
>>       dedicated keytab file = /etc/krb5.keytab
>>       kerberos method = secrets and keytab
>>       server string = Web- und Internet-Mail-Server
>>       interfaces = 10.73.0.6/255.255.0.0
>>       bind interfaces only = Yes
>>       username map = /etc/samba/smbusers
>>       name resolve order = wins hosts
>>       os level = 0
>>       local master = No
>>       wins server = 10.73.0.7 10.73.0.21
>>
>>       guest ok = Yes
>>       hide dot files = No
>>
>>       idmap config *:backend = tdb
>>       idmap config *:range = 2000-9999
>>       idmap config FEE:backend = rid
>>       idmap config FEE:range = 10000-20000
>>
>>       winbind cache time = 10
>>       template shell = /bin/false
>>       template homedir = /tmp
>>
>>       winbind use default domain = yes
>>       winbind enum users = yes
>>       winbind enum groups = yes
>>       winbind expand groups = 1
>>       winbind trusted domains only = no
>>       winbind refresh tickets = Yes
>>
>>       deadtime = 1
>>       load printers = no
>>       printing = bsd
>>
>> Remove all the 'valid users' etc from the shares and use ACLs instead ,
>> either from windows or with setfacl on the member server, see:
>>
>> https://wiki.samba.org/index.php/Setup_and_configure_file_shares_with_Windows_ACLs 
>>
>
> ACLs -- actually, I was about to add   nt acl support = no   to get 
> back the behaviour of the gone *security* config entries (at least I 
> was told on #samba that this setting would prevent changing the 
> "rights" of existing files, as the former *security* entries did).
>
> Maybe I need to explain the purpose of the samba installation on this 
> server. It's not meant to be a sophisticated windows file server, it 
> acts as mail and web server.
>
> winbind is used to authenticate and authorize mail and web users via 
> pam, and the file server is only used to upload webpages (web share) 
> or access some files regarding mail, e. g. via the spamlog share.
>
> There are only a couple of users which are allowed to do that and as 
> you can see for the web share, certain rights and groups must be 
> enforced to suit the webserver.
>
> Sure, if ACLs would have been used and been properly configured for 
> the whole filesystem, then I would accept your suggestion immediately, 
> but for now, I still hassle to go that way.
>
> I see the problem in this line of smbd's log, as mentioned in the 
> initial email:
>
>> SID S-1-5-21-2807186310-4085009417-2666197100-1000 -> getpwuid(10938) 
>> failed
>
>> platon:~ # wbinfo -s S-1-5-21-2807186310-4085009417-2666197100-1000
>> PLATON\root 1
>
> This only happens when smbusers contains the mapping to root.

The SID 'S-1-5-21-2807186310-4085009417-2666197100-1000' is (as I am 
sure you know) is composed of a set of letters and numbers that identify 
the domain and a number (RID) that identifies the user/group/computer. 
The number '1000' is usually given to the first user you create, this is 
not root!
You seem to be mapping ordinary AD users to the Unix user 'root', I 
would suggest that you either add these users to 'Domain Admins' or 
create a group and then give this group the required permissions, you 
could then set an ACL on the various directories via windows and you 
will end up with similar conditions to what you have now, mapping 
ordinary users to 'root' is not a good idea.

>
> In my opinion, it should use the SID for unix user root. Let's see:
>

'root' shouldn't have a SID, 'Administrator' does though.

>> platon:~ # wbinfo -n root
>> failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
>> Could not lookup name root
>

Yes, that happens on my DC, because 'root' is a Unix user.

>> platon:~ # wbinfo -U 0
>> S-1-5-21-4224351836-719640785-1152632845-1000
>

This shouldn't happen, on my DC :

root at dc01:~# wbinfo -U 0
S-1-5-21-2025076216-3455336656-3842161122-500

>> platon:~ # wbinfo -s S-1-5-21-4224351836-719640785-1152632845-1000
>> failed to call wbcLookupSid: WBC_ERR_DOMAIN_NOT_FOUND
>> Could not lookup sid S-1-5-21-4224351836-719640785-1152632845-1000
>

Hmm, on my DC, it is the DC!

root at dc01:~# wbinfo -s S-1-5-21-2025076216-3455336656-3842161122-1000
HOME\DC01$ 1


> I cannot tell whether it is expected that two of the three commands fail.
>
> So for now, I'd like to make as few changes as possible to get that 
> user mapping working again.
>
> It seems I haven't mentioned yet, if I disable that mapping in 
> smbusers, I can access the shares as long as they grant access to an 
> unmapped domain user (for example share FactWork, as I 
> (fee\reinhard.ni) am a member of group fee\g_tb3).
>

I come back to my original idea, use ACLs.

just one other thought, you really shouldn't use your registered domain 
for your AD domain.

Rowland

> Bye.
> -- 
> Reinhard Nißl, TB3, -198