[Samba] Automatic creation of local users

[L.P.H. van Belle]

See below..  

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Rowland Penny via
> samba
> Verzonden: dinsdag 20 december 2016 11:26
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Automatic creation of local users
> 
> On Tue, 20 Dec 2016 11:10:30 +0100
> "L.P.H. van Belle via samba" <samba at lists.samba.org> wrote:
> 
> 
> > >
> > > No, a user is either a Unix user or a windows user that is also a
> > > Unix user. You cannot have a user in /etc/passwd and in AD.
> > Thats not what i meant its OR a linux user OR a windows user.
> > But which you create is depending on the need.
> > I can create a linux user to manipulate things as windows user on
> > windows shares per server. Or i can create a windows
> > "buildin\username" which can be use "per server" But with care for
> > both since, the id of this user dont have to be the same.
> >
> > Your ok with this? This is how i use it.
> > I'll try to make these thing more clear next time.
> 
> The only thing I would change there would be is 'dont', you cannot have
> a user with the same in /etc/passwd and AD, i.e. the user 'fred' cannot
> exist in /etc/passwd and AD. If you do have the user 'fred'
> in /etc/passwd and AD, which ever is found first by nsswitch will be
> used and to be honest, if you are using AD, there is absolutely no
> reason for user 'fred' to exist in /etc/passwd if he also exists in AD.

But not clear enough? That exactly what i ment. 
Arg..  i see , 
> > I can create a linux user to manipulate things as windows user on
> > windows shares per server. Or i can create a windows
> > "buildin\username" which can be use "per server" But with care for
> > both since, the id of this user dont have to be the same.

What i mean here is. 
You can create  a windows user in the AD ( windows\buildin user ) 
Which wil be a local user. 
This one can be used on multple servers but only localy per server. 

OR 
You can create on server 1 a linux user which maps to idmap config *
A buildin user and is seen as a local user. 
This user MUST NOT be used on multple servers but only localy on the server its created on. 

And in general you SHALL NEVER create the same username as linux user and windows user.


Now Rowland an idea.. . im thinking, i was reading a lot of RFC's lately.
And this maybe very handy to use on the list also. Think about it. 
And what do others think about this? Of the use of these Terminology. 
User who help others on the list can be bit more clear this way. 


2.3 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described below.

   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
      the definition is an absolute requirement of the specification.

   2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
      definition is an absolute prohibition of the specification.

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.

   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean
      that there may exist valid reasons in particular circumstances
      when the particular behavior is acceptable or even useful, but the
      full implications should be understood and the case carefully
      weighed before implementing any behavior described with this
      label.

   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because the vendor feels
      that it enhances the product while another vendor may omit the
      same item.  An implementation which does not include a particular
      option MUST be prepared to interoperate with another
      implementation which does include the option, though perhaps with
      reduced functionality.  In the same vein an implementation which
      does include a particular option MUST be prepared to interoperate
      with another implementation which does not include the option
      (except, of course, for the feature the option provides.)


Greetz, 

Louis



> 
> Rowland
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba