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

[Denis Cardon]

Hi LPH,

> 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.

I think this line is an unfortunate "copy & paste" from a TDB backend 
disadvantage listing. Indeed IDMAP RID is based on RID like its name 
states, so there is no mapping database, only a local cache.

IMHO the only item that really matters in the "disadvantages" section is 
: "All users on the domain member get the same login shell and home 
directory base path assigned", and the others points are not that relevant.

> 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 )

The only two cases where I keep a rfc2307 mapping during a migration are 
technical/historical constraints (eg. uidnumber are used all over the 
place in UNIX contexts, like NFS mounts, user profiles, mail servers 
user mappings, old solaris workstations, etc.), or it is too much of a 
hassle to reset too many ACLs on too many file servers. In other cases, 
during classic upgrade I just switch old rfc2307 mapping to RID.

Handling rfc2307 mapping is not (yet) fully transparent, its command 
line tooling is not fool proof, RSAT rfc2307 on win7 isn't really 
ergonomic, and the "unix attributes" tab disappeared on win10...

msSFU30MaxUidNumber attribute has no pooling system like RID, so there 
is nothing preventing you from having two users with identical uid on a 
large domain... I had a talk with Andrew Bartlett about having a pooling 
system for uidnumber/gidnumber like the RID one, that would indeed make 
rfc2307 a first class citizen.

If you have scripts/automation for user creation from HR department 
database, above rfc2307 issues are void, but such setup is unfortunately 
not yet so common.

Cheers,

Denis


>
>
> 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
>>
>
>

-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr