Re: [Samba] samba 4 ad member - idmap = ad for machine accounts
- Date: Mon, 18 Sep 2017 16:24:23 +0200
- From: "L.P.H. van Belle via samba" <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] samba 4 ad member - idmap = ad for machine accounts
The op tells us :
idmap config *:backend = tdb
idmap config *:range = 100-2000
# idmap config for domain MYDOMAIN
idmap config MYDOMAIN:backend = ad
idmap config MYDOMAIN:schema_mode = rfc2307
idmap config MYDOMAIN:range = 4000-99999
I dont know the OS here, but what happens if uid 100 is a linux system users.
Then it also maps into BUILTIN\username
You might check need to check this out also.
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces@xxxxxxxxxxxxxxx] Namens
> Rowland Penny via samba
> Verzonden: maandag 18 september 2017 15:43
> Aan: samba@xxxxxxxxxxxxxxx
> Onderwerp: Re: [Samba] samba 4 ad member - idmap = ad for
> machine accounts
> On Mon, 18 Sep 2017 14:55:04 +0200
> Denis Cardon <dcardon@xxxxxxxxxxx> wrote:
> > Hi Rowland,
> > >> File server config looks exactly like this, except more
> shares, all
> > >> with same simple config. I know that "use defualt domain" isn't
> > >> necessery, but it's not the issue for me right now.
> > ...
> > > 'SYSTEM' is a Windows group and is meaningless to Unix,
> it should be
> > > mapped to a Unix ID only on a Samba AD DC and there it is an
> > > 'xidNumber' not a 'uidNumber or 'gidNumber'. Running 'wbinfo -S
> > > S-1-5-18' (the SID for 'SYSTEM' is S-1-5-8-18) on a UNIX domain
> > > member, returns:
> > > failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND Could not
> > > convert sid S-1-5-18 to uid
> > >
> > > However "wbinfo -Y S-1-5-18" returns:
> > > 2005 (note your ID may be different)
> > >
> > > As I said, you could use the kerberos machine account
> instead, but
> > > are these scripts being run on the fileserver, Samba DC
> or windows
> > > machines ? if the later, then you shouldn't need a Unix IDs.
> > >
> > >> 2)'m using some machine autostart scripts, for various
> tasks, which
> > >> work again as SYSTEM, so if they have to get anything
> from network
> > >> share, they need to have read/write permission. What I'm
> doing is,
> > >> for example, as autostart run a batch script, that would check
> > >> \\fileserver\public\test-file.txt if %COMPTURNAME%
> exists in this
> > >> file. if not - run some robocopy script, then >>
> %COMPUTERNAME% to
> > >> the end of the file.
> > >> or even something simple like this:
> > >> "if exist \\server\share\%computername%.txt (exit) else robocopy
> > >> some-files echo . > \\server\share\%computername%.txt exit"
> > >
> > > That looks like a Windows script (not that I am an expert
> on Windows
> > > script languages) so I presume that it is run a Windows
> machine and
> > > 'SYSTEM' should be available on it via its name or SID.
> > >
> > >> 3) Some windows applications that I use also run as
> SYSTEM account
> > >> and they have built-in backup utilities, and if I want to backup
> > >> straight to network share - again - machine account needs direct
> > >> write access to share.
> > >
> > > Hmm, I think I am beginning to understand your problem, you are
> > > confusing 'SYSTEM' with the computers account in AD.
> > >
> > > 'SYSTEM' does not exist in AD, so you cannot give it a
> uidNumber or
> > > gidNumber attribute.
> > >
> > > I think you need to find another way to do what you are doing now.
> > Kacper way of doing things is completly correct (at least from
> > authentication point of view). SYSTEM account on Windows uses the
> > machine account for authentication. So for example, using
> psexec ,
> > you can try (on an elevated command prompt):
> > psexec -s -i cmd.exe
> > Check that you are local system
> > whoami
> > then you connect to a share (sysvol is a good choice here since
> > "domain computers" has access)
> > net use F: \\domain.lan\sysvol
> > Then on your DC you can check which account has been used for the
> > connexion:
> > smbstatus
> > You'll see that SYSTEM account uses the Kerberos machine
> account for
> > authentication.
> Yes that works, but it shows that you don't need the
> computers to have uidNumber attributes, which is what I was
> trying to get across to the OP.
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
To unsubscribe from this list go to the following URL and read the