On Mon, Aug 8, 2016 at 5:06 PM, Michael Adam <obnox at samba.org> wrote:> On 2016-08-08 at 16:31 -0300, francis picabia wrote: > > I'm reading the man page for idmap_rid over and over and I can't > understand > > it. I think it needs a rewrite so a normal user can understand. Using a > > practical example. > > I admit it is a little terse. > But in principle, assuming a little bit of > general knowledge about how idmap backends are configured > (see man smb.conf), it's all there. > > Before proposing a patch that will elaborate the manpage > a bit, let me explain here: > > > Step 1: determine the highest UID in use for your /etc/passwd file > > (can we assume everyone has a passwd file?) > > Step 2: I don't know... > > > > Optionally at this point, document how to plug that into the formula > > > > RID = ID + BASE_RID - LOW_RANGE_ID > > > > and then show how we set the lines: > > > > range = low - high > > This 'low' here is the LOW_RANGE_ID referenced above > in the formula. More concretely, this config would be > > idmap config DOMAIN : backend = rid > idmap config DOMAIN : range = low-high > > > base_rid = INTEGER > > My suggestion: Forget about the 'base_rid' value. This optional parameter > is only needed for corner cases, where you are very limited in the amount > of unix ids available. It allows you to filter out the lower part of the > rids in your domain. I have never seen it used. (i.e. use the default > value of 0.) > > > The man page examples do not line up with any numbers practical outside > of > > smb.conf > > So in order to decribe how the rid module works for a given > config, you need to describe how unix-id-->sid and sid-->unix-id > mappings are calculated. The manpage offers this: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > THE MAPPING FORMULAS > The Unix ID for a RID is calculated this way: > > ID = RID - BASE_RID + LOW_RANGE_ID. > > Correspondingly, the formula for calculating the RID > for a given Unix ID is this: > > RID = ID + BASE_RID - LOW_RANGE_ID. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > As said above, here LOW_RANGE_ID is the id that is the lower > number of the configured range. Now for the sake of simplicity, > say that we did not configure the base rid, so BASE_RID is 0 in > the above formulas and they simplify to: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ID = RID + LOW_RANGE_ID > RID = ID - LOW_RANGE_ID > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > More concretely, assume that you have a domain MYDOM > and a config > > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 100000-200000 > > Now calculate a few examples: > > - The administrator of MYDOM has rid=500 (the admin > of each domain has). So it's unix ID would be > > 500 + 100000 = 100500 > > - The Domain Users group has rid 513. > So the associated unix group id would be > > 513 + 100000 = 100513 > > - A Unix group of GID = 100512 would > map to the SID with the rid of > > 100512 - 100000 = 512 > > i.e. the domain admins group. > > - A unix user of UID = 123456 would be associated > to a sid with the rid of > > 123456 - 10000 = 23456 > > - A unix ID of 200001 would be bigger than > the high id of the range and hence NOT be > treated by this idmap module. > > - A SID with a rid of 100001 would be calculated > to yield a unix id of > > 100001 + 100000 = 200001 > > but this is bigger than the high upper limit of > the configured range, hence the sid would be > 'filtered', i.e. this object would not be mapped. > > Do these examples make it more clear? > > The low id of the range determines where the unix IDs of > your domain will start, and the high id of the range > determines how big the rids can get. More concretely, > the largest mapped rid would be > > high id - low id > > > > Say my UID on the Linux side would never exceed 70000. How do > > I configure range and base_rid? > > The only important thing here is that the low id in the range is > LARGER than the largest unix id used otherwise in your system. > (That does not only mean passwd or group file, but also other > possible nsswitch sources like ldap or nis...) > So if you know you won't have unix user or group ids above 10000, > then you could start your idmap rid range at 10001; this would > be the lowes possible start of a range. But you could as > well start it at 20000 or 100000 or 1000000. And so on. > > Also note that all other idmap ranges you configure must > be disjoint from this idmap range. More generally, all > configured idmap ranges must be mutually disjoint. > > See the example in the manpage for complete example > idmap configs. > > Hope this helps at least a bit.. > >Thanks for the detailed response. It is very extensive for my purposes, but it still feels over analytical for what we need. I believe the Unix UID doesn't exceed 65534. If this is a constant, why don't we just produce an example for that? Out of the box, this is what many users will want to use. I don't understand when we want values to never overlap and when we want them to be in a matching range. I would think this setting would work for everyone not using NIS or LDAP in nsswitch: idmap config *:backend = tdb idmap config *:range = 100001-110000 idmap config MYDOM : backend = rid idmap config MYDOM : range = 65535-100000 I've set that and restarted nmbd, smbd and winbind services When I do a wbinfo look up on my user with a UID of 1000, it has this: theusername:*:16777216:16777220:The Username:/home/MYDOM/theusername:/bin/false Is this set up well or do I want the upper range to overlap with 16777216?
On Tue, 9 Aug 2016 09:37:13 -0300 francis picabia <fpicabia at gmail.com> wrote:> Thanks for the detailed response. > > It is very extensive for my purposes, but it still feels over > analytical for what we need. I believe the Unix UID doesn't exceed > 65534. If this is a constant, why don't we just produce an example > for that? Out of the box, this is what many users will want to use. > > I don't understand when we want values to never overlap and when > we want them to be in a matching range. > > I would think this setting would work for everyone not using NIS or > LDAP in nsswitch: > > idmap config *:backend = tdb > idmap config *:range = 100001-110000 > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 65535-100000The only problem with that is, what happens if you do manage to get to user '100001' in 'MYDOM' ? This would probably be better: idmap config *:backend = tdb idmap config *:range = 65535-100000 idmap config MYDOM : backend = rid idmap config MYDOM : range = 100001-110000 This way, if you ever get to 'MYDOM' user '110001', you can just extend the range in smb.conf. However, a better way would be to find out who set nobody/nogroup to '65534' (there was probably a logical reason at the time it was set) and get it changed to '499' or whatever. Anybody know who to contact ?> > I've set that and restarted nmbd, smbd and winbind services > > When I do a wbinfo look up on my user with a UID of 1000, it has this: > > theusername:*:16777216:16777220:The > Username:/home/MYDOM/theusername:/bin/falseThose numbers look suspiciously like what I used to get out of sssd, are you also running this ?> > Is this set up well or do I want the upper range to overlap with > 16777216?You cannot have ranges that overlap, if you had something like this: idmap config *:backend = tdb idmap config *:range = 2000-10000 idmap config MYDOM : backend = rid idmap config MYDOM : range = 9000-11000 Now, there are two users with the RIDs 9999 and 2999, the first is a member of the '*' domain and the second is a member of 'MYDOM' domain As the algorithm to calculate the Unix ID is this: ID = RID + LOW_RANGE_ID We get two calculations 9999 + 2000 = ID 2999 + 9000 = ID ID in both cases will be '11999' so how is Unix to know which user is which ? Rowland
I can't add anything useful to the ID mapping discussion, but 65,535 is a very well known number to those of us that started in bits and bytes of embedded systems and assemblers. 65,535 is the largest unsigned integer in a 16-bit system, which is where UNIX started (mostly). They used (int) 0-65,534 as the valid user IDs, and "(unsigned int)-1", which is (int)65,535, as a check for invalid user ID.> On Aug 9, 2016, at 8:21 AM, Rowland Penny <rpenny at samba.org> wrote: > > On Tue, 9 Aug 2016 09:37:13 -0300 > francis picabia <fpicabia at gmail.com> wrote: > >> Thanks for the detailed response. >> >> It is very extensive for my purposes, but it still feels over >> analytical for what we need. I believe the Unix UID doesn't exceed >> 65534. If this is a constant, why don't we just produce an example >> for that? Out of the box, this is what many users will want to use. >> >> I don't understand when we want values to never overlap and when >> we want them to be in a matching range. >> >> I would think this setting would work for everyone not using NIS or >> LDAP in nsswitch: >> >> idmap config *:backend = tdb >> idmap config *:range = 100001-110000 >> idmap config MYDOM : backend = rid >> idmap config MYDOM : range = 65535-100000 > > The only problem with that is, what happens if you do manage to get to > user '100001' in 'MYDOM' ? > > This would probably be better: > idmap config *:backend = tdb > idmap config *:range = 65535-100000 > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 100001-110000 > > This way, if you ever get to 'MYDOM' user '110001', you can just extend > the range in smb.conf. > > However, a better way would be to find out who set nobody/nogroup to > '65534' (there was probably a logical reason at the time it was set) > and get it changed to '499' or whatever. Anybody know who to contact ? > >> >> I've set that and restarted nmbd, smbd and winbind services >> >> When I do a wbinfo look up on my user with a UID of 1000, it has this: >> >> theusername:*:16777216:16777220:The >> Username:/home/MYDOM/theusername:/bin/false > > Those numbers look suspiciously like what I used to get out of sssd, > are you also running this ? > >> >> Is this set up well or do I want the upper range to overlap with >> 16777216? > > You cannot have ranges that overlap, if you had something like this: > > idmap config *:backend = tdb > idmap config *:range = 2000-10000 > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 9000-11000 > > Now, there are two users with the RIDs 9999 and 2999, the first is a > member of the '*' domain and the second is a member of 'MYDOM' domain > > As the algorithm to calculate the Unix ID is this: > > ID = RID + LOW_RANGE_ID > > We get two calculations > > 9999 + 2000 = ID > > 2999 + 9000 = ID > > ID in both cases will be '11999' so how is Unix to know which user is > which ? > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
On Tue, Aug 9, 2016 at 10:21 AM, Rowland Penny <rpenny at samba.org> wrote:> On Tue, 9 Aug 2016 09:37:13 -0300 > francis picabia <fpicabia at gmail.com> wrote: > > > Thanks for the detailed response. > > > > It is very extensive for my purposes, but it still feels over > > analytical for what we need. I believe the Unix UID doesn't exceed > > 65534. If this is a constant, why don't we just produce an example > > for that? Out of the box, this is what many users will want to use. > > > > I don't understand when we want values to never overlap and when > > we want them to be in a matching range. > > > > I would think this setting would work for everyone not using NIS or > > LDAP in nsswitch: > > > > idmap config *:backend = tdb > > idmap config *:range = 100001-110000 > > idmap config MYDOM : backend = rid > > idmap config MYDOM : range = 65535-100000 > > The only problem with that is, what happens if you do manage to get to > user '100001' in 'MYDOM' ? > > This would probably be better: > idmap config *:backend = tdb > idmap config *:range = 65535-100000 > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 100001-110000 > > This way, if you ever get to 'MYDOM' user '110001', you can just extend > the range in smb.conf. > > However, a better way would be to find out who set nobody/nogroup to > '65534' (there was probably a logical reason at the time it was set) > and get it changed to '499' or whatever. Anybody know who to contact ? >I'm entertaining all your suggestions of workarounds and values. I've changed nobody to UID and GID 499 in /etc/passwd and /etc/groups It had no conflicts with another user. However nobody doesn't exist in AD. Now testparam reports: # testparm /etc/samba/smb.conf Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters [global] workgroup = MYDOM realm = AD.MYDOM.CA server string = Debian2 Server security = ADS log file = /var/log/samba/%m.log max log size = 50 unix extensions = No load printers = No printcap name = /dev/null disable spoolss = Yes dns proxy = No winbind use default domain = Yes idmap config mydom : range = 100001-110000 idmap config mydom : backend = rid idmap config *:range = 65535-100000 idmap config * : backend = tbd nt acl support = No printing = bsd [homes] comment = Home Directories path = %H read only = No create mask = 0700 directory mask = 0700 browseable = No wide links = Yes Restarted smbd and winbind. $ smbclient -L //debian2 -U username Enter username's password: session setup failed: NT_STATUS_UNSUCCESSFUL Logfile for client's IP ends: [2016/08/09 11:48:32.793696, 1] ../source3/auth/token_util.c:430(add_local_groups) SID S-1-5-21-82194667-1315141139-1877560073-12331 -> getpwuid(16777216) failed [2016/08/09 11:48:32.793746, 3] ../source3/auth/token_util.c:316(create_local_nt_token_from_info3) Failed to finalize nt token There don't seem to be any values which can dodge this bug. Maybe there were for awhile, but in the meantime, security patches have changed things.> > > > I've set that and restarted nmbd, smbd and winbind services > > > > When I do a wbinfo look up on my user with a UID of 1000, it has this: > > > > theusername:*:16777216:16777220:The > > Username:/home/MYDOM/theusername:/bin/false > > Those numbers look suspiciously like what I used to get out of sssd, > are you also running this ? > >There is no sssd. No process, no package installed.