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

Mon Sep 18 14:31:56 UTC 2017

Drawbacks for RID, yes, multiple, but maybe it does not apply for you. 

Read the Advantages and Disadvantages
https://wiki.samba.org/index.php/Idmap_config_ad
https://wiki.samba.org/index.php/Idmap_config_rid

My reason for NOT using RID on FILESERVER setups. 
Only one : File ownership of domain users and groups are lost, when the local ID mapping database corrupts. 

With Ad, i just remove and reinstall samba again and im up and running, no worries about incorrect ACL's. 

But again, this is a choice. 
An good example for RID. 
A proxy server member set, does get RID setup. 
( if you dont login with ssh as an AD user and use the shared homedir over nfs ) 

Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Kacper Wirski via samba
> Verzonden: maandag 18 september 2017 16:20
> Aan: "samba at lists.samba.org"
> Onderwerp: Re: [Samba] samba 4 ad member - idmap = ad for 
> machine accounts
> 
> 
> 	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
> 
> 	 
> 
> 
> 	 
> 
> 
> 	 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 