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

[Kacper Wirski]

	Thank everyone for input,


	It seems that using RID is the way to go. I just tried a few things:


	1)


	- made group, assigned unix GID


	- added test PC to this group and set this group as "primary group"


	- added manually to test PC account "uidnumber"


	on server with samba


	getent passwd MYDOMAIN\\testpc$


	returns nicely testpc$ with UID and GID numbers as set in AD, but 
authentication still doesn't work, i.e. no test writes to share


	2)


	- added GID to default "DOMAIN COMPUTERS"


	rest steps are the same, except didn't need to add PC to this group


	getent passwd gives same, OK result, still unable to authenticate


	 


	I'm out of ideas I guess I have to stick with RID, since it "just works"


	 


	So my question is if using RID is reliable across different samba 
installations, that is:


	if I make file-server1, file-server2 and use same idmap range for MYDOMAIN, 
will I get identical UIDs? Since they're calculated from "rid" portion of 
the "sid", they should be, right?


	 


	Also I know the drawbacks of using SYSTEM -> machine accounts for writes. 
Share with said backups is itself backed up to completely different machine 
with completely different methods, so it's safe enough (or should be).


	 


	 


	 


	Dnia 2017-09-18 15:53 Rowland Penny via samba napisał(a):


	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