[Samba] samba 2.4.6 to 2.4.7 update on Fedora update 26 to 27, can't connect to shares

[Rowland Penny]

On Sat, 3 Mar 2018 17:27:56 +1100
Norman Gaywood <ngaywood at une.edu.au> wrote:

> On 2 March 2018 at 20:37, Rowland Penny via samba
> <samba at lists.samba.org> wrote:
> >
> > Your Samba machine can be a Unix active directory domain member or
> > it can be a member of an NT4-style domain that uses ldap, it cannot
> > be both.
> > It can also authenticate from an ldap server on another machine, in
> > this case, it wouldn't be a domain member.
> > It should be possible to authenticate to the ldap server (or AD),
> > but you are getting into a bit of a mess here. Your users will need
> > to exist (separately) everywhere.
> >
> 
> The users do exist separately everywhere (openldap and AD). Both
> openldap and AD are provisioning targets from the identity management
> system, so they both contain the users. AD does not have uid/gid
> information.
> 
> 
> > I think you should consider just joining the Samba machine to the AD
> > domain and use the 'rid' backend. This way, your users & groups are
> > only stored in one place and you do not need to add anything to AD.
> >
> 
> So the way I understand this, my samba server is joined to the AD
> domain. I think I know this because I can retrieve usernames and SID
> info from wbinfo.
> 
> Also, reading the idmap_rid man page, unix uid/gid numbers are
> determined algorithmically from the SID. But that would be wrong
> would it not? The uid/gid numbers are already defined on the unix
> system. So idmap_rid would not use the correct uid/gid numbers.
> 
> Or am I missing something?

No, that is how the 'rid' backend works.
> 
> I'm thinking perhaps I should implement an idmap_script backend that
> does something similar to idmap_nis.sh
> 
> https://searchcode.com/codesearch/view/29414590/
> 
> But, instead of using ypmatch (as in idmap_nis.sh) I would use "getent
> passwd" calls instead to map between uid/gid and the SID number from
> wbinfo.

Well, you could, but I feel you are missing the whole point behind AD,
it gives you just one point of management. You create your users and
groups as windows users and groups, then extend them into Unix users
and groups. You can do this by adding uidNumber and gidNumber, or by
using the 'rid' attributes. You can extend the schema for things like
email etc. Once properly set up, you will be able to turn off the
openldap server, because there will be no need for it.

If you do go the way you are proposing, you will have multiple points
to manage if you change things, passwords for instance. To ensure
that passwords match everywhere, you would have to change the users
password in AD and the Unix users password, you would also have to
change it in the openldap server (and the Unix users password if you
running it this way). So that is three or four places to change the
password, but if you use AD correctly, there is only one!

What I am trying to get across to you is, AD can do everything you
require, just all in one place, without any complications like your
proposed idmap_script.   

Rowland