[Samba] BUILTIN\Administrators - failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
rpenny at samba.org
Tue Sep 5 08:57:19 UTC 2017
On Tue, 05 Sep 2017 10:24:58 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:
> Thank you both, Rowland and Louis.
> I'll try to answer you both and give you more info about our domain.
> In the past, we have Samba 3.5 NT4 domain on SLES server (designed
> ages before, never upgraded). In 2015 I finally decided to migrate to
> Samba 4 AD. In those day it was 4.2. samba-tool ntacl sysvolcheck was
> ok, no errors. AD worked (and working) as expected.
> This summer, I managed Samba+ subscription from SerNet, so we upgraded
> to 4.6.X. As I said, everything work, but sysvolcheck throws errors
> that you discussed in other thread.
> Original Samba 3 domain was combination of Samba and LDAP backed. So
> domain scheme was populated by smbldap-tools. Users/groups were added
> by LAM (so smbldap-tools too). UIDs/GIDs were populated by RIDs. ID
> map range was from 500 to 10000, so every group and user in our
> domain have UIDs/GIDs same as their RID. NSS was driven by LDAP
> (passwd, shadow and group in nsswitch.conf had ldap directive).
This was perfectly common, nobody thought this would ever be a problem,
mainly because you had to have a user or group in /etc/passwd
or /etc/group mapped to a Samba.
Now with AD, you do not need a user or group in /etc/passwd
or /etc/group, so any user or group that uses the RID as a Unix ID is
probably too low and is denying the use of any local Unix users
> After migration (in 2015) I changed this at least for new users and
> groups. I know, that's not the best solution, but it worked I hadn't
> to reset all ACLs on our fileservers.
> Yes, our are right. There were UIDs and GIDs set on "system" users and
> groups. I removed all (is removing in AUDC enough? I newer worked with
> ldb tools) except Domain Users and Domain Admins (we use this group as
> owner group on many shares on our fileservers).
I hope you are not thinking of using GPOs, 'Domain Admins' needs to own
things is 'sysvol' and cannot if they are a group (the gidNumber makes
them a group)
> I thing that the "bad" numbers in my domain are legacy pro Samba 3 +
> LDAP. AD service restart and net cache flush were executed many times
> as we run this domain 2 years.
> So what's next?
> Do you think that I have to rearrange UIDs and GIDs in our domain to
> match numeric pattern as in cleanly provisioned domain?
If you can change the Unix IDs, then this is the way to go
More information about the samba