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/
On 14/06/2019 05:50, Stefan Froehlich via samba wrote:> 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: > >> 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.Windows should just work> > 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. >I wouldn't worry about it, it is probably an artefact of SMBv1 being turned off and/or the log level being set too high. Rowland
On Fri, Jun 14, 2019 at 09:09:58AM +0100, Rowland penny via samba wrote:> On 14/06/2019 05:50, Stefan Froehlich via samba wrote: > >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.> Windows should just workUnfortunately not at all. What did work is to switch a PC from the legacy PDC (Debian Squeeze, now questions allowed) to the new ADS-controller and to authenticate against the ADS-controller with a newly created test account. This account can connect to network shares on the file server, including his own home share and the share holding the roaming profile and also is able to create files there. What did not work at all is automatic connection of the home drive and (worse) roaming profiles. (Neither did the windows ADS utitlities, but this did not bother me at that point of time). After that I discovered and resolved some config issues (including not having mapped Administrator to the root user on the file server, not having set SeDiskOperatorPrivilege on the file server, assigning a gidNumber to "Domain Admins" instead of creating a new group). But still, no home drive and no roaming profiles. Windows uses temporary profiles instead of creating the appropriate subdirectory on the file server, and if I create the directory manually, it denotes the profile as "server based" but refuses to save it (as said before, I can manually mount the share and create a test file from within windows). At logout there is a warning telling me to look into the event log for details, and their I can see a message with the source "GroupPolicy" and a german text saying "the network is not available or has not been startet", error code 1222 (German error messages are a pain in the ass when trying to google for solutions). Remarkable is perhaps (in my eyes) that the network neighbourhood on the windows PCs does show the legacy PDC and the other PCs, but neither the new ADS-controller nor the new fileserver (even though the PC is a domain member of the first one and can mount shares of the latter one). As I tried all this with two PCs and two different accounts I highly suspect that the problem is located within my setup, but I simply don't know how and where to start with debugging. I created <http://froehlich.priv.at/samba/> with copies of my config files and LDAP-excerpts to avoid including them all in this mail. The profiles and users share look like this at the moment (I added a g+w to /home/profiles for testing purposes at some point of time): root at herakles:~# ls -al /home/profiles/ total 20 drwxrwx--T 5 root domain users 4096 Jun 21 15:59 . drwxr-xr-x 8 root root 4096 Jun 19 10:41 .. drwxr-xr-x 22 gk domain users 4096 Jun 12 15:04 gk.V2 drwxr-xr-x 2 sf domain users 4096 Jun 21 16:06 sf.V2 drwxr-xr-x 2 test domain users 4096 Jun 21 13:45 test.V2 root at herakles:~# ls -l /home/users/ total 12 drwxrws--- 12 gk 1006 4096 Jun 21 14:13 gk drwxr-sr-x 2 sf domain users 4096 Jun 21 16:42 sf drwxr-sr-x 2 test domain users 4096 Jun 21 13:09 test If anything else could be helpful, just tell; as far as the unix side is concerned I can provide pretty much everything. Bye, Stefan