[Samba] Failed to create BUILTIN\Guests group NT_STATUS_ACCESS_DENIED! Can Winbind allocate gids?
Rowland penny
rpenny at samba.org
Mon Oct 7 09:15:43 UTC 2019
On 07/10/2019 09:19, lejeczek via samba wrote:
> On 05/10/2019 15:20, lejeczek via samba wrote:
>> On 05/10/2019 14:10, Rowland penny via samba wrote:
>>> On 05/10/2019 13:41, lejeczek via samba wrote:
>>>> hi everyone,
>>>>
>>>> I believe a resolution is there -
>>>> https://access.redhat.com/solutions/4367771
>>> Which is behind a paywall ;-)
>>>> But what I'm hoping for is an expert would comment how
>>>> would this apply
>>>> to Samba with LDAP backend?
>>> What do you mean 'Samba with LDAP backend' ????
>>>
>>> You really shouldn't be running Samba with LDAP any more
>>> and the problem only occurred on a standalone server and
>>> was fixed here:
>>> https://bugzilla.samba.org/show_bug.cgi?id=13697
>>>
>>> Rowland
>>>
>>>> many thanks, L.
>>>>
>> It's not a paywall, suffices to register with Redhat and to
>> this content access if free of charge.
>> Here:
>>
>> Environment
>>
>> Red Hat Enterprise Linux 7
>>
>> Issue
>>
>> After upgrading to samba-4.9.1, samba failed to restart with
>> error messages like:
>> Raw
>>
>> Nov 09 10:00:00 example.com smbd[13641]: [2018/11/09
>> 10:00:00.000000, 0]
>> ../source3/auth/auth_util.c:1382(make_new_session_info_guest)
>> Nov 09 10:00:00 example.com smbd[13641]:
>> create_local_token failed: NT_STATUS_ACCESS_DENIED
>> Nov 09 10:00:00 example.com smbd[13641]: [2018/11/09
>> 10:00:00.000200, 0] ../source3/smbd/server.c:2000(main)
>> Nov 09 10:00:00 example.com smbd[13641]: ERROR: failed to
>> setup guest info.
>>
>> Resolution
>>
>> 1) Ensure the id map is configured in smb.conf, like:
>> Raw
>>
>> [global]
>> ...
>> idmap config * : backend = tdb
>> idmap config * : range 10000-199999
>> idmap config DOMAIN : backend = autorid
>> idmap config DOMAIN : range = 200000-2147483647
>>
>> 2) Map group BUILTIN\Guests to group nobody with following
>> command:
>> Raw
>>
>> # net -s /dev/null groupmap add sid=S-1-5-32-546
>> unixgroup=nobody type=builtin
>>
>> 3) Restart samba services and replicate the issue:
>> Raw
>>
>> # systemctl restart {smb,nmb,winbind}
>> # smbclient //$(hostname)/<share> -U DOMAIN\\<user> -d10
>>
>> Root Cause
>>
>> samba-4.9.x expands guest handling to differentiate
>> between anonymous and guest sessions. This required a proper
>> handling of BUILTIN\Guests.
>> Old-style configuration does not handle BUILTIN\Guest.
>> Thus samba fails after upgrade when administrators unaware
>> of this change.
>>
>> Diagnostic Steps
>>
>> Ensure the id map is configured in smb.conf, like:
>> Raw
>>
>> [global]
>> ...
>> idmap config * : backend = tdb
>> idmap config * : range 10000-199999
>> idmap config DOMAIN : backend = autorid
>> idmap config DOMAIN : range = 200000-2147483647
>>
>> Ensure the BUILTIN\Guests is mapped
>> Raw
>>
>> net groupman list sid=S-1-5-32-546
>>
>>
>> Does not bother me shoulds and shouldnots, I'm doing it, and
>> facing a problem which I'd hope can be solved without
>> changing a lot. User db is in LDAP and winbind is not used.
>> many thanks, L.
>>
>>
>>
> any experts roaming around?
Sort of ;-)
>
> To make it a bit bizarre - it only happens to one of the three Sambas
> which re virtually identical(same versions on the same Centoses). LDAP
> user db replicates so all three Sambas see the same stuff yet only one
> fails spitting errors as in the subject.
>
> Would there be someting outside of LDAP which might be different on the
> one Samba which is the root problem?
This sounds like it is a problem with just that one machine, you will
have to compare it with the other two, to try and find any differences.
I have done some checking, your link becomes this:
https://bugzilla.redhat.com/show_bug.cgi?id=1648399
Which links to this:
https://lists.samba.org/archive/samba-technical/2018-September/130375.html
Which ultimately links to this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909465%C2%A0
Which links to this Samba bug report:
https://bugzilla.samba.org/show_bug.cgi?id=13697
Which shows that it is fixed and went into Samba at 4.9.5
Having got that out of the way, I cannot recommend you continue running
Samba in this way, you might just as well upgrade to AD, but it is your
network ;-)
Rowland
More information about the samba
mailing list