On Thu, Jun 13, 2019 at 07:02:27PM +0100, Rowland penny via samba wrote:> On 13/06/2019 18:21, Stefan Froehlich via samba wrote: > >File server and Linux clients shall use the AD-backend, so I read > >and followed <https://wiki.samba.org/index.php/Idmap_config_ad>. > >There it says: > > > >"Whichever setting you use, the group (or groups) set as the users > >primary group must have the gidNumber attribute set" > > I thought that was plain enough, but obviously not ;-)Yes and no.> All domain users are members of the 'Domain Users' group as their > primary group and to make the group known to the Unix OS it must > have a gidNumber attribute. Also winbind relies on the group being > known to the Unix OS, if it isn't, then (whatever you do), no > users will be known to the Unix OS. There are very few domain > users and groups that need to be known to Unix.I did understand this (some parts were really obvious, some parts only after browsing through the docs). What I did not get was that besides the various config files and control programs like samba-tool and net you need to dig into the LDAP database to set the gid for "domain users" (at least I have basic knowledge about LDAP, but I did not need this for the last 20 yrs). There are: $ samba-tool user add --gid-number --uid-number $ samba-tool group add --gid-number ...so I was looking for a corresponding option of "samba-tool domain provision" or for something named like "samba-tool group modify".> It used to be easy from Windows using the Unix Attributes tab in > ADUC, but this has been removed from Windows 10. > > The easiest way is to script around ldb-tools or ldap-utils.Windows is no option anyway, I only have ssh access and do all the stuff from remote. But ldbedit did the trick, thanks a lot.> >| root at fileserver:~# wbinfo -i test > >| failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND > >| Could not get info for user test > This should have worked.And - heureka! - now it does: | root at fileserver:~# wbinfo -i test | test:*:10001:10000::/home/test:/bin/bash So for the moment I can continue - let's see if anything else comes up. Thanks, Stefan -- Stefan - das faulste Werbegeschenk, welches es je gab. Sloganizer, https://www.poetron-zone.de/
On 13/06/2019 19:57, Stefan Froehlich via samba wrote:> On Thu, Jun 13, 2019 at 07:02:27PM +0100, Rowland penny via samba wrote: >> On 13/06/2019 18:21, Stefan Froehlich via samba wrote: >>> File server and Linux clients shall use the AD-backend, so I read >>> and followed <https://wiki.samba.org/index.php/Idmap_config_ad>. >>> There it says: >>> >>> "Whichever setting you use, the group (or groups) set as the users >>> primary group must have the gidNumber attribute set" >> I thought that was plain enough, but obviously not ;-) > Yes and no.I will try and make it more obvious.> >> All domain users are members of the 'Domain Users' group as their >> primary group and to make the group known to the Unix OS it must >> have a gidNumber attribute. Also winbind relies on the group being >> known to the Unix OS, if it isn't, then (whatever you do), no >> users will be known to the Unix OS. There are very few domain >> users and groups that need to be known to Unix. > I did understand this (some parts were really obvious, some parts > only after browsing through the docs). What I did not get was that > besides the various config files and control programs like > samba-tool and net you need to dig into the LDAP database to set the > gid for "domain users" (at least I have basic knowledge about LDAP, > but I did not need this for the last 20 yrs). There are: > > $ samba-tool user add --gid-number --uid-number > $ samba-tool group add --gid-number > > ...so I was looking for a corresponding option of "samba-tool domain > provision" or for something named like "samba-tool group modify".No there isn't I am afraid.> >> It used to be easy from Windows using the Unix Attributes tab in >> ADUC, but this has been removed from Windows 10. >> >> The easiest way is to script around ldb-tools or ldap-utils. > Windows is no option anyway, I only have ssh access and do all the > stuff from remote. But ldbedit did the trick, thanks a lot. > > > And - heureka! - now it does: > > | root at fileserver:~# wbinfo -i test > | test:*:10001:10000::/home/test:/bin/bash > > So for the moment I can continue - let's see if anything else comes > up.It already might have ;-) wbinfo reads directly from AD, but doesn't mean that? the OS knows your users & groups, does 'getent passwd test' produce the same output ? Rowland
On Thu, Jun 13, 2019 at 08:10:01PM +0100, Rowland penny via samba wrote:> On 13/06/2019 19:57, Stefan Froehlich via samba wrote: > >On Thu, Jun 13, 2019 at 07:02:27PM +0100, Rowland penny via samba wrote: > >>On 13/06/2019 18:21, Stefan Froehlich via samba wrote: > >>>File server and Linux clients shall use the AD-backend, so I read > >>>and followed <https://wiki.samba.org/index.php/Idmap_config_ad>. > >>I thought that was plain enough, but obviously not ;-) > >Yes and no. > I will try and make it more obvious.A small hint how to set the gidNumber would be enough (in my case, that is).> >$ samba-tool user add --gid-number --uid-number > >$ samba-tool group add --gid-number > > > >...so I was looking for a corresponding option of "samba-tool > >domain provision" or for something named like "samba-tool group > >modify".> No there isn't I am afraid.Which might be a problem for people with no ldap experience at all, but otherwise this is only a luxury problem.> >And - heureka! - now it does: > > > >| root at fileserver:~# wbinfo -i test > >| test:*:10001:10000::/home/test:/bin/bash > > > >So for the moment I can continue - let's see if anything else > >comes up. > > It already might have ;-) > > wbinfo reads directly from AD, but doesn't mean that? the OS knows > your users & groups, does 'getent passwd test' produce the same > output ?Fortunately yes, and as I can do ssh logins with this account, even based on group membership, the unix side of the job seems to be quite settled. The windows side will have to wait a little bit as it requires my physical presence. The only cosmetic thing is that I still get this in my log files: | [2019/06/14 06:04:22.007350, 4] ../source3/nmbd/nmbd_workgroupdb.c:276(dump_workgroups) | dump_workgroups() | dump workgroup on subnet 192.168.1.13: netmask= 255.255.255.0: | WORKGROUP(1) current master browser = CONTROLLER | CONTROLLER 40849a03 (Samba 4.9.5-Debian) | MAC01 40001003 (Mac01) | RNP002673E572C4 40000203 () | [2019/06/14 06:04:22.007420, 4] ../source3/nmbd/nmbd_workgroupdb.c:165(find_workgroup_on_subnet) | find_workgroup_on_subnet: workgroup search for SAMDOM on subnet 192.168.1.13: not found. | [2019/06/14 06:04:22.007432, 0] ../source3/nmbd/nmbd_serverlistdb.c:340(write_browse_list) | write_browse_list: Fatal error - cannot find my workgroup SAMDOM | [2019/06/14 06:04:22.007448, 4] ../source3/nmbd/nmbd_workgroupdb.c:165(find_workgroup_on_subnet) | find_workgroup_on_subnet: workgroup search for SAMDOM on subnet UNICAST_SUBNET: not found. | [2019/06/14 06:04:22.007457, 0] ../source3/nmbd/nmbd_browsesync.c:595(collect_all_workgroup_names_from_wins_server) | collect_all_workgroup_names_from_wins_server: | Cannot find my workgroup SAMDOM on subnet UNICAST_SUBNET. | [2019/06/14 06:04:22.007469, 4] ../source3/nmbd/nmbd_workgroupdb.c:165(find_workgroup_on_subnet) | find_workgroup_on_subnet: workgroup search for SAMDOM on subnet UNICAST_SUBNET: not found. I do not see any practical problems resulting from this up to now, so I won't further investigate it, but if this is pointing to something really obvious mistake, I'd of course fix it. Bye, Stefan -- Stefan konnte immer schon mehr als Spa? machen! Sloganizer, https://www.poetron-zone.de/