samba - Mar 2018 - samba 2.4.6 to 2.4.7 update on Fedora update 26 to 27, can't connect to shares

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?

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.

Thanks for listening and helping :-)

-- 
Norman Gaywood, Computer Systems Officer
School of Science and Technology
University of New England
Armidale NSW 2351, Australia

ngaywood at une.edu.au  http://turing.une.edu.au/~ngaywood
Phone: +61 (0)2 6773 2412  Mobile: +61 (0)4 7862 0062

Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

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

Thanks Rowland,

On 3 March 2018 at 19:31, Rowland Penny via samba <samba at
lists.samba.org>
wrote:
>
> No, that is how the 'rid' backend works.

Would love to know what my misconceptions are. But yeah, this is not a
tutorial group :-)
>
> > I'm thinking perhaps I should implement an idmap_script backend
that
> > does something similar to idmap_nis.sh
>
> Well, you could, but I feel you are missing the whole point behind AD,

I get the central management thing. Point is we are centrally managing
users. It's done by the identity management system. The IDM provisions both
LDAP and AD (and other targets). Passwords and many other attributes are
also managed centrally.

To get new attributes in AD would require probably 6 months of change
requests, committees, contractors, stuff-ups, and all the rest that goes
with working in big organization :-(

Point is the samba update from 4.6.x to 4.7.x broke my samba shares and the
problem seems to be in how idmap is handled now.

My fault for not doing enough testing, but this is where I am now.

Rolling back samba is difficult also. Means I would have to install outside
the package management system, I don't want go back to those days.

Thanks for your help, I do appreciate it.
-- 
Norman Gaywood, Computer Systems Officer
School of Science and Technology
University of New England
Armidale NSW 2351, Australia

ngaywood at une.edu.au   http://turing.une.edu.au/~ngaywood
Phone: +61 (0)2 6773 2412  Mobile: +61 (0)4 7862 0062

Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Am Samstag, 3. März 2018, 17:27:56 CET schrieb Norman Gaywood via 
samba:
> 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.
Your IM is the source for users and groups and fill both AD and openldap 
with the identical information. Is this true?
> > 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.
This is not necessaryly true. I assume your AD and your Samba/Ldap has 
different domain names and different SIDs.
 
> 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.
Yes. The standard setup use one DB of any kind for local unix users, via 
NSS and AD or NT style SAM for windows users.

The solution for you could be an other approach.

First one question:
The subject of this mail indicates that you have problems after updating 
from Fedora 26 to 27, versus samba 4.6 to 4.7. 
So, your Fedora 26 setup has worked properly? If this is true, why are you 
searching for new solutions. You should fix your upgrade procedure.


> Or am I missing something?
> 
> 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.
> 
> Thanks for listening and helping :-)

-- 

Gruss
	Harry Jede

On 3 March 2018 at 20:40, Harry Jede <walk2sun at arcor.de>
wrote:
>
> Your IM is the source for users and groups and fill both AD and openldap
> with the identical information. Is this true?
>
Yes. Passwords are also managed this way.
> I think I know this because I can retrieve usernames and SID
>
> > info from wbinfo.
>
> This is not necessaryly true. I assume your AD and your Samba/Ldap has
> different domain names and different SIDs.
>
wbinfo only gives me information  from my AD domain (I think). I'm not sure
how to query our local samba but I guess the users  and where they come
from was expressed in the deprecated line in my old config:

      auth methods = guest sam_ignoredomain winbind:ntdomain

> The solution for you could be an other approach.
>
>
>
> First one question:
>
> The subject of this mail indicates that you have problems after updating
> from Fedora 26 to 27, versus samba 4.6 to 4.7.
>
> So, your Fedora 26 setup has worked properly? If this is true, why are you
> searching for new solutions. You should fix your upgrade procedure.
>
Yes the samba broke when I updated Fedora 26 to 27 when samba went from 4.6
to 4.7

My fault for not testing enough. But samba is an add on feature of the
system and I overlooked it. Roll back is not possible.
Installing an older samba I guess could be possible but it means stepping
outside package management.

.
> Greeting
>
> Harry Jede
>

Cheers.
-- 
Norman Gaywood, Computer Systems Officer
School of Science and Technology
University of New England
Armidale NSW 2351, Australia

ngaywood at une.edu.au   http://turing.une.edu.au/~ngaywood
Phone: +61 (0)2 6773 2412  Mobile: +61 (0)4 7862 0062

Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html