[Samba] samba 4 ad member - idmap = ad for machine accounts

[L.P.H. van Belle]

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. 

Greetz, 

Louis


 

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Rowland Penny via samba
> Verzonden: maandag 18 september 2017 15:43
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] samba 4 ad member - idmap = ad for 
> machine accounts
> 
> On Mon, 18 Sep 2017 14:55:04 +0200
> Denis Cardon <dcardon at tranquil.it> 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 [1], 
> > 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.
> > 
> 
> Thanks
> 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.
> 
> Rowland
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>