On Mon, 4 Mar 2019 20:43:17 +0000 Rowland Penny wrote:> > On Mon, 04 Mar 2019 15:18:31 -0500 > Mark Foley via samba <samba at lists.samba.org> wrote: > > > On Mon, 4 Mar 2019 18:31:07 +0000 From: Rowland Penny wrote: > > > > > > On Mon, 04 Mar 2019 12:58:17 -0500 > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > On Mon, 4 Mar 2019 17:18:31 +0000 Rowland Penny wrote: > > > > > > > > > > On Mon, 04 Mar 2019 11:48:00 -0500 > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > On Mon, 4 Mar 2019 14:50:38 +0000 Rowland Penny wrote: > > > > > > > > > > > > > > On Mon, 04 Mar 2019 09:15:12 -0500 > > > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > > > > > I have a rather strange and urgent problem. Last evening I > > > > > > > > installed a Sonicwall firewall between the Internet and > > > > > > > > office LAN. The only change that I know of for the LAN > > > > > > > > workstations was that the gateway is now 192.168.0.1 > > > > > > > > instead of 192.168.0.2. All workstations: Windows, Linux > > > > > > > > and Mac use DHCP and the AD/DC is the DHCP server, so I > > > > > > > > wouldn't think that mattered. > > > > > > > > > > > > > > > > All Windows workstations work fine, I didn't even have to > > > > > > > > reboot them. Windows Users can log in, they have their > > > > > > > > redirected folders, etc. > > > > > > > > > > > > > > > > Having a problem on Linux. When I run 'getent passwd' it > > > > > > > > returns only the list of users in /etc/passwd on the > > > > > > > > AD/DC. No domain users are returned. 'getent passwd > > > > > > > > <domainuser>' return status 2. > > > > > > > > > > > > > > > > The domain user can log on to Linux. > > > > > > > > > > > > > > > > Any idea what's up with this? I use getent on Linux for > > > > > > > > various things. > > > > > > > > > > > > > > > > Thanks, Mark > > > > > > > > > > > > > > > > Samba 4.8.2 > > > > > > > > > > > > > > > > > > > > > > Lets see if I have this correct, you have installed a > > > > > > > firewall on something between the original gateway and your > > > > > > > LAN, you have not touched anything else, except to point > > > > > > > your computers to the new firewall as the gateway > > > > > > > (presumably by DHCP). Is this correct ? > > > > > > > > > > > > > > You have logged into a DC and run: > > > > > > > > > > > > > > getent passwd username > > > > > > > > > > > > > > Which produces no output, where previously it did. > > > > > > > > > > > > > > Is the DC using itself as the nameserver ? > > > > > > > Is the DC using the correct gateway ? > > > > > > > > > > > > > > Rowland > > > > > > > > > > > > Partially correct. Before installing the firewall, the > > > > > > Gateway on the AD/DC was configured as the ISP's gateway > > > > > > (98.102.63.105). I changed the gateway to be 192.168.0.1 > > > > > > (the Sonicwall). I believe that's all I did. I did reboot > > > > > > the AD/DC. The AD/DC is also the DHCP server. > > > > > > > > > > > > I've testing with stopping the firewall on the AD/DC as well. > > > > > > Didn't help. > > > > > > > > > > > > On the AD/DC 'getent passwd' does work. > > > > > > > > > > > > $ getent passwd mark > > > > > > mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > > > > > > > > > On the Linux domain member workstation it does not. > > > > > > > > > > > > $ getent passwd mark; echo $? > > > > > > 2 > > > > > > > > > > > > However, the user of that workstation is able to log in using > > > > > > domain credentials, ntlm_auth also works: > > > > > > > > > > > > $ ntlm_auth --username=mark --password='mypass' > > > > > > NT_STATUS_OK: Success (0x0) > > > > > > > > > > > > BTW - The MAC workstations cannot now authenticate with domain > > > > > > credentials. I tried to unbind and rebind one of the > > > > > > workstations, but when trying to unbind I got the message, > > > > > > "Unable to access domain controller". It can see the domain > > > > > > controller: > > > > > > > > > > > > $ host mail > > > > > > mail.hprs.local has address 192.168.0.2 > > > > > > > > > > > > However, this is possibly an additional/separate (though > > > > > > related) issue. I don't want to complicate the original > > > > > > question. I can deal with the Macs later and perhaps solving > > > > > > the Linux issue will magically solve the Mac issue. I've > > > > > > including the Mac information in case it provides additional > > > > > > clues. > > > > > > > > > > > > As I said, no problems whatsoever with the Windows 7 domain > > > > > > members. > > > > > > > > > > > > --Mark > > > > > > > > > > > > > > > > OK, just a thought, is there a dhcp server running on your > > > > > sonicwall ? > > > > > > > > No. I configured the Sonicwall with the tech last night and I'm > > > > sure it's not running the DHCP server. The AD/DC (Mail) is > > > > running dhcpd. (but I'll double-check) > > > > > > > > > What does running 'route' show (you will probably have to do > > > > > this as root or via sudo). It should show your sonicwall as the > > > > > gateway. try running these: > > > > > > > > Yes, shows Sonicwall On the AD/DC: > > > > > > > > $ route > > > > Kernel IP routing table > > > > Destination Gateway Genmask Flags Metric Ref > > > > Use Iface default 192.168.0.1 0.0.0.0 UG > > > > 1 0 0 eth1 loopback * > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > * 255.255.255.0 U 0 0 0 eth1 > > > > > > > > On the domain members, shows the AD/DC as the gateway: > > > > > > It shouldn't, you normally only have one gateway, it is by > > > definition the 'gateway' to the WAN & internet, so I would use the > > > same one on all your machines. > > > > The LAN host gateways are assiged by the dhcpd server. Unless I > > hard-code static IP's I can't really change that. The Windows > > computers likewise show the AD/DC (192.168.0.1) as the gateway and > > they all work fine. > > > > > > # route > > > > Kernel IP routing table > > > > Destination Gateway Genmask Flags Metric Ref > > > > Use Iface default mail.hprs.local 0.0.0.0 UG > > > > 202 0 0 eth0 loopback * > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > * 255.255.255.0 U 202 0 0 eth0 > > > > > > > > > hostname -s > > > > > hostname -d > > > > > hostname -i > > > > > hostname -I > > > > > > > > > > Do they show what you expect ? > > > > > > > > On the domain member (labrat): > > > > > > > > $ hostname -s > > > > labrat > > > > > > > > $ hostname -d > > > > hprs.local > > > > > > > > $ hostname -i > > > > 127.0.0.1 > > > > > > > > $ hostname -I > > > > hostname: invalid option -- 'I' > > > > > > > > I believe these show as expected (except for -I). Agreed? > > > > > > Sorry, but no, '127.0.0.1' is the ipaddress for 'localhost', it > > > should the actual ipaddress of the computer. What is in /etc/hosts ? > > > > /etc/hosts: > > 127.0.0.1 localhost > > 127.0.0.1 labrat.hprs.local labrat > > > > The IP of the computer is assigned by DHCP, so it won't be > > in /etc/hosts. There was a reason to have the /etc/hosts IP as > > 127.0.0.1, but I can't remember. I'll see if I can find my notes. > > Meanwhile, I've removed that entry from /etc/hosts. Now I have: > > > > # hostname -i > > 192.168.0.99 > > > > Which is the correct IP for labrat. > > > > > > > What is in /etc/resolv.conf > > > > > > > > On AD/DC (MAIL 192.168.0.2, is the LAN DNS server): > > > > > > > > domain hprs.local > > > > search hprs.local > > > > nameserver 192.168.0.2 > > > > > > What do you mean 'LAN DNS server' ? is 192.168.0.2 not the DC's > > > ipaddress ? > > > > The DC is the local DNS server and DHCP server -- as I assumed was > > required for a AD/DC. The DC has been running Samba4 for Active > > Directory for about 4 years and has always done DNS serving for the > > LAN (domain) and DHCP. > > > > > > On Domain Member (labrat) > > > > > > > > # Generated by dhcpcd from eth0.dhcp > > > > # /etc/resolv.conf.head can replace this line > > > > domain hprs.local > > > > nameserver 192.168.0.2 > > > > nameserver 192.168.0.3 > > > > # /etc/resolv.conf.tail can replace this line > > > > > > It should be 'search' not 'domain' > > > > Well, as it says, the domain member's resolv.conf is generated by > > dhcpcd. This also has remained unchanged for years. > > > > > I will be honest, I am not a fan of dhcpcd, I cannot really see a > > > need for it. > > > > Otherwise I'd have to configure IP, Gateway, Netmask and nameservers > > for each host on the network, which is quite a few. > > > > > > None of the hosts have problem resolving internal or external > > > > hostnames. > > > > This doesn't seem like a gateway or name resolution issue. All domain > > members can resolve internal and external host and domain names. The > > Linux domain members can authenticate and log in with domain > > credentials; ntlm_auth works. Just getent is not working on the Linux > > domain members. getent's return status is 2 which is, "One or more > > supplied key could not be found in the database", get ntlm_auth > > works ... ? > > > > I'll modify the gateway on a linux domain member to point the the > > Sonicwall, but I'm skeptical that will fix getent. I'll report back. > > > > ******************************* > > MORE INFO! > > ******************************* > > MEANWHILE, after more testing I've refined the problem statement. On > > labrat (domain member), I can: > > > > $ getent passwd mark > > mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > Yeah! But, just 'getent passwd' returns only DC:/etc/passwd entries, > > no domain users. Also, I cannot 'getent passwd' for any other domain > > user on labrat, just 'mark'. If I log onto another Linux workstation, > > ccarter, I can: > > > > $ getent passwd charlie > > charlie:*:10003:10000:Charlie Carter:/home/HPRS/charlie:/bin/bash > > > > but I cannot 'getent passwd mark' on this computer. > > > > So, it seems that if a domain user was previously logged on to a > > Linux domain member, he/she can do a getent for him/herself only. A > > getent cannot be done for any other domain user. > > > > Kerberos issue? > > > > --Mark > > > > Something strange going on here, If you use dhcp to set your IP info, > you only need this in /etc/hosts: > > rowland at devstation:~$ cat /etc/hosts > 127.0.0.1 localhost > > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > > Which if you then run the commands I asked you to run, you get these: > > rowland at devstation:~$ hostname -s > devstation > rowland at devstation:~$ hostname -d > samdom.example.com > rowland at devstation:~$ hostname -f > devstation.samdom.example.com > rowland at devstation:~$ hostname -i > 192.168.0.88 > > and getent returns this: > > rowland at devstation:~$ getent passwd rowland > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > I do not use dhcpcd, I just use the isc-dhcp-client. > > I repeat, I do not see the point of dhcpcd, it is just another layer in > the dhcp stack and, in my opinion, an unnecessary layer.I'm probably not going to disassemble use of dhcpd/dhcpcd. Too much uses it. I'm not familiar with isc-dhcp-client. I have changed /etc/hosts as you suggested. This did not help with the 'getent' problem, nor do I see how that would affect 'getent' working for the usual user of the workstation, but not for other domain users, nor why 'getent passwd' returns NO domain users. As an experiment, I will hard-code the IP, etc. for one of the workstations so as to elimimate the dhcp and gateway possibilities from the discussion. I'll post back results. --Mark
On Mon, 04 Mar 2019 15:57:16 -0500 Mark Foley via samba <samba at lists.samba.org> wrote:> On Mon, 4 Mar 2019 20:43:17 +0000 Rowland Penny wrote: > > > > On Mon, 04 Mar 2019 15:18:31 -0500 > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > On Mon, 4 Mar 2019 18:31:07 +0000 From: Rowland Penny wrote: > > > > > > > > On Mon, 04 Mar 2019 12:58:17 -0500 > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > On Mon, 4 Mar 2019 17:18:31 +0000 Rowland Penny wrote: > > > > > > > > > > > > On Mon, 04 Mar 2019 11:48:00 -0500 > > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > > > On Mon, 4 Mar 2019 14:50:38 +0000 Rowland Penny wrote: > > > > > > > > > > > > > > > > On Mon, 04 Mar 2019 09:15:12 -0500 > > > > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > > > > > > > I have a rather strange and urgent problem. Last > > > > > > > > > evening I installed a Sonicwall firewall between the > > > > > > > > > Internet and office LAN. The only change that I know > > > > > > > > > of for the LAN workstations was that the gateway is > > > > > > > > > now 192.168.0.1 instead of 192.168.0.2. All > > > > > > > > > workstations: Windows, Linux and Mac use DHCP and the > > > > > > > > > AD/DC is the DHCP server, so I wouldn't think that > > > > > > > > > mattered. > > > > > > > > > > > > > > > > > > All Windows workstations work fine, I didn't even > > > > > > > > > have to reboot them. Windows Users can log in, they > > > > > > > > > have their redirected folders, etc. > > > > > > > > > > > > > > > > > > Having a problem on Linux. When I run 'getent passwd' > > > > > > > > > it returns only the list of users in /etc/passwd on > > > > > > > > > the AD/DC. No domain users are returned. 'getent > > > > > > > > > passwd <domainuser>' return status 2. > > > > > > > > > > > > > > > > > > The domain user can log on to Linux. > > > > > > > > > > > > > > > > > > Any idea what's up with this? I use getent on Linux > > > > > > > > > for various things. > > > > > > > > > > > > > > > > > > Thanks, Mark > > > > > > > > > > > > > > > > > > Samba 4.8.2 > > > > > > > > > > > > > > > > > > > > > > > > > Lets see if I have this correct, you have installed a > > > > > > > > firewall on something between the original gateway and > > > > > > > > your LAN, you have not touched anything else, except to > > > > > > > > point your computers to the new firewall as the gateway > > > > > > > > (presumably by DHCP). Is this correct ? > > > > > > > > > > > > > > > > You have logged into a DC and run: > > > > > > > > > > > > > > > > getent passwd username > > > > > > > > > > > > > > > > Which produces no output, where previously it did. > > > > > > > > > > > > > > > > Is the DC using itself as the nameserver ? > > > > > > > > Is the DC using the correct gateway ? > > > > > > > > > > > > > > > > Rowland > > > > > > > > > > > > > > Partially correct. Before installing the firewall, the > > > > > > > Gateway on the AD/DC was configured as the ISP's gateway > > > > > > > (98.102.63.105). I changed the gateway to be 192.168.0.1 > > > > > > > (the Sonicwall). I believe that's all I did. I did > > > > > > > reboot the AD/DC. The AD/DC is also the DHCP server. > > > > > > > > > > > > > > I've testing with stopping the firewall on the AD/DC as > > > > > > > well. Didn't help. > > > > > > > > > > > > > > On the AD/DC 'getent passwd' does work. > > > > > > > > > > > > > > $ getent passwd mark > > > > > > > mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > > > > > > > > > > > On the Linux domain member workstation it does not. > > > > > > > > > > > > > > $ getent passwd mark; echo $? > > > > > > > 2 > > > > > > > > > > > > > > However, the user of that workstation is able to log in > > > > > > > using domain credentials, ntlm_auth also works: > > > > > > > > > > > > > > $ ntlm_auth --username=mark --password='mypass' > > > > > > > NT_STATUS_OK: Success (0x0) > > > > > > > > > > > > > > BTW - The MAC workstations cannot now authenticate with > > > > > > > domain credentials. I tried to unbind and rebind one of > > > > > > > the workstations, but when trying to unbind I got the > > > > > > > message, "Unable to access domain controller". It can > > > > > > > see the domain controller: > > > > > > > > > > > > > > $ host mail > > > > > > > mail.hprs.local has address 192.168.0.2 > > > > > > > > > > > > > > However, this is possibly an additional/separate (though > > > > > > > related) issue. I don't want to complicate the original > > > > > > > question. I can deal with the Macs later and perhaps > > > > > > > solving the Linux issue will magically solve the Mac > > > > > > > issue. I've including the Mac information in case it > > > > > > > provides additional clues. > > > > > > > > > > > > > > As I said, no problems whatsoever with the Windows 7 > > > > > > > domain members. > > > > > > > > > > > > > > --Mark > > > > > > > > > > > > > > > > > > > OK, just a thought, is there a dhcp server running on your > > > > > > sonicwall ? > > > > > > > > > > No. I configured the Sonicwall with the tech last night and > > > > > I'm sure it's not running the DHCP server. The AD/DC (Mail) is > > > > > running dhcpd. (but I'll double-check) > > > > > > > > > > > What does running 'route' show (you will probably have to do > > > > > > this as root or via sudo). It should show your sonicwall as > > > > > > the gateway. try running these: > > > > > > > > > > Yes, shows Sonicwall On the AD/DC: > > > > > > > > > > $ route > > > > > Kernel IP routing table > > > > > Destination Gateway Genmask Flags Metric > > > > > Ref Use Iface default 192.168.0.1 0.0.0.0 > > > > > UG 1 0 0 eth1 loopback * > > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > > * 255.255.255.0 U 0 0 0 eth1 > > > > > > > > > > On the domain members, shows the AD/DC as the gateway: > > > > > > > > It shouldn't, you normally only have one gateway, it is by > > > > definition the 'gateway' to the WAN & internet, so I would use > > > > the same one on all your machines. > > > > > > The LAN host gateways are assiged by the dhcpd server. Unless I > > > hard-code static IP's I can't really change that. The Windows > > > computers likewise show the AD/DC (192.168.0.1) as the gateway and > > > they all work fine. > > > > > > > > # route > > > > > Kernel IP routing table > > > > > Destination Gateway Genmask Flags Metric > > > > > Ref Use Iface default mail.hprs.local 0.0.0.0 > > > > > UG 202 0 0 eth0 loopback * > > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > > * 255.255.255.0 U 202 0 0 eth0 > > > > > > > > > > > hostname -s > > > > > > hostname -d > > > > > > hostname -i > > > > > > hostname -I > > > > > > > > > > > > Do they show what you expect ? > > > > > > > > > > On the domain member (labrat): > > > > > > > > > > $ hostname -s > > > > > labrat > > > > > > > > > > $ hostname -d > > > > > hprs.local > > > > > > > > > > $ hostname -i > > > > > 127.0.0.1 > > > > > > > > > > $ hostname -I > > > > > hostname: invalid option -- 'I' > > > > > > > > > > I believe these show as expected (except for -I). Agreed? > > > > > > > > Sorry, but no, '127.0.0.1' is the ipaddress for 'localhost', it > > > > should the actual ipaddress of the computer. What is > > > > in /etc/hosts ? > > > > > > /etc/hosts: > > > 127.0.0.1 localhost > > > 127.0.0.1 labrat.hprs.local labrat > > > > > > The IP of the computer is assigned by DHCP, so it won't be > > > in /etc/hosts. There was a reason to have the /etc/hosts IP as > > > 127.0.0.1, but I can't remember. I'll see if I can find my notes. > > > Meanwhile, I've removed that entry from /etc/hosts. Now I have: > > > > > > # hostname -i > > > 192.168.0.99 > > > > > > Which is the correct IP for labrat. > > > > > > > > > What is in /etc/resolv.conf > > > > > > > > > > On AD/DC (MAIL 192.168.0.2, is the LAN DNS server): > > > > > > > > > > domain hprs.local > > > > > search hprs.local > > > > > nameserver 192.168.0.2 > > > > > > > > What do you mean 'LAN DNS server' ? is 192.168.0.2 not the DC's > > > > ipaddress ? > > > > > > The DC is the local DNS server and DHCP server -- as I assumed was > > > required for a AD/DC. The DC has been running Samba4 for Active > > > Directory for about 4 years and has always done DNS serving for > > > the LAN (domain) and DHCP. > > > > > > > > On Domain Member (labrat) > > > > > > > > > > # Generated by dhcpcd from eth0.dhcp > > > > > # /etc/resolv.conf.head can replace this line > > > > > domain hprs.local > > > > > nameserver 192.168.0.2 > > > > > nameserver 192.168.0.3 > > > > > # /etc/resolv.conf.tail can replace this line > > > > > > > > It should be 'search' not 'domain' > > > > > > Well, as it says, the domain member's resolv.conf is generated by > > > dhcpcd. This also has remained unchanged for years. > > > > > > > I will be honest, I am not a fan of dhcpcd, I cannot really see > > > > a need for it. > > > > > > Otherwise I'd have to configure IP, Gateway, Netmask and > > > nameservers for each host on the network, which is quite a few. > > > > > > > > None of the hosts have problem resolving internal or external > > > > > hostnames. > > > > > > This doesn't seem like a gateway or name resolution issue. All > > > domain members can resolve internal and external host and domain > > > names. The Linux domain members can authenticate and log in with > > > domain credentials; ntlm_auth works. Just getent is not working > > > on the Linux domain members. getent's return status is 2 which > > > is, "One or more supplied key could not be found in the > > > database", get ntlm_auth works ... ? > > > > > > I'll modify the gateway on a linux domain member to point the the > > > Sonicwall, but I'm skeptical that will fix getent. I'll report > > > back. > > > > > > ******************************* > > > MORE INFO! > > > ******************************* > > > MEANWHILE, after more testing I've refined the problem > > > statement. On labrat (domain member), I can: > > > > > > $ getent passwd mark > > > mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > > > Yeah! But, just 'getent passwd' returns only DC:/etc/passwd > > > entries, no domain users. Also, I cannot 'getent passwd' for any > > > other domain user on labrat, just 'mark'. If I log onto another > > > Linux workstation, ccarter, I can: > > > > > > $ getent passwd charlie > > > charlie:*:10003:10000:Charlie Carter:/home/HPRS/charlie:/bin/bash > > > > > > but I cannot 'getent passwd mark' on this computer. > > > > > > So, it seems that if a domain user was previously logged on to a > > > Linux domain member, he/she can do a getent for him/herself > > > only. A getent cannot be done for any other domain user. > > > > > > Kerberos issue? > > > > > > --Mark > > > > > > > Something strange going on here, If you use dhcp to set your IP > > info, you only need this in /etc/hosts: > > > > rowland at devstation:~$ cat /etc/hosts > > 127.0.0.1 localhost > > > > # The following lines are desirable for IPv6 capable hosts > > ::1 localhost ip6-localhost ip6-loopback > > ff02::1 ip6-allnodes > > ff02::2 ip6-allrouters > > > > Which if you then run the commands I asked you to run, you get > > these: > > > > rowland at devstation:~$ hostname -s > > devstation > > rowland at devstation:~$ hostname -d > > samdom.example.com > > rowland at devstation:~$ hostname -f > > devstation.samdom.example.com > > rowland at devstation:~$ hostname -i > > 192.168.0.88 > > > > and getent returns this: > > > > rowland at devstation:~$ getent passwd rowland > > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > > > I do not use dhcpcd, I just use the isc-dhcp-client. > > > > I repeat, I do not see the point of dhcpcd, it is just another > > layer in the dhcp stack and, in my opinion, an unnecessary layer. > > I'm probably not going to disassemble use of dhcpd/dhcpcd. Too much > uses it. I'm not familiar with isc-dhcp-client.Again I ask, are you using dhcpd or dhcpcd ? they are different programs. Normally you do not have to configure isc-dhcp-client, just install it.> > I have changed /etc/hosts as you suggested. This did not help with > the 'getent' problem, nor do I see how that would affect 'getent' > working for the usual user of the workstation, but not for other > domain users, nor why 'getent passwd' returns NO domain users. >This is something I don't understand either, just installing a firewall device shouldn't affect getent, but it is possible that it has highlighted an underlying problem.> As an experiment, I will hard-code the IP, etc. for one of the > workstations so as to elimimate the dhcp and gateway possibilities > from the discussion. I'll post back results. > > --Mark > >Lets see what happens. Rowland
On Mon, 4 Mar 2019 21:18:36 +0000 Rowland Penny wrote:> > On Mon, 04 Mar 2019 15:57:16 -0500 > Mark Foley via samba <samba at lists.samba.org> wrote: > > > On Mon, 4 Mar 2019 20:43:17 +0000 Rowland Penny wrote: > > > > > > On Mon, 04 Mar 2019 15:18:31 -0500 > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > On Mon, 4 Mar 2019 18:31:07 +0000 From: Rowland Penny wrote: > > > > > > > > > > On Mon, 04 Mar 2019 12:58:17 -0500 > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > On Mon, 4 Mar 2019 17:18:31 +0000 Rowland Penny wrote: > > > > > > > > > > > > > > On Mon, 04 Mar 2019 11:48:00 -0500 > > > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > > > > > On Mon, 4 Mar 2019 14:50:38 +0000 Rowland Penny wrote: > > > > > > > > > > > > > > > > > > On Mon, 04 Mar 2019 09:15:12 -0500 > > > > > > > > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > > > > > > > > > > > > > > I have a rather strange and urgent problem. Last > > > > > > > > > > evening I installed a Sonicwall firewall between the > > > > > > > > > > Internet and office LAN. The only change that I know > > > > > > > > > > of for the LAN workstations was that the gateway is > > > > > > > > > > now 192.168.0.1 instead of 192.168.0.2. All > > > > > > > > > > workstations: Windows, Linux and Mac use DHCP and the > > > > > > > > > > AD/DC is the DHCP server, so I wouldn't think that > > > > > > > > > > mattered. > > > > > > > > > > > > > > > > > > > > All Windows workstations work fine, I didn't even > > > > > > > > > > have to reboot them. Windows Users can log in, they > > > > > > > > > > have their redirected folders, etc. > > > > > > > > > > > > > > > > > > > > Having a problem on Linux. When I run 'getent passwd' > > > > > > > > > > it returns only the list of users in /etc/passwd on > > > > > > > > > > the AD/DC. No domain users are returned. 'getent > > > > > > > > > > passwd <domainuser>' return status 2. > > > > > > > > > > > > > > > > > > > > The domain user can log on to Linux. > > > > > > > > > > > > > > > > > > > > Any idea what's up with this? I use getent on Linux > > > > > > > > > > for various things. > > > > > > > > > > > > > > > > > > > > Thanks, Mark > > > > > > > > > > > > > > > > > > > > Samba 4.8.2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lets see if I have this correct, you have installed a > > > > > > > > > firewall on something between the original gateway and > > > > > > > > > your LAN, you have not touched anything else, except to > > > > > > > > > point your computers to the new firewall as the gateway > > > > > > > > > (presumably by DHCP). Is this correct ? > > > > > > > > > > > > > > > > > > You have logged into a DC and run: > > > > > > > > > > > > > > > > > > getent passwd username > > > > > > > > > > > > > > > > > > Which produces no output, where previously it did. > > > > > > > > > > > > > > > > > > Is the DC using itself as the nameserver ? > > > > > > > > > Is the DC using the correct gateway ? > > > > > > > > > > > > > > > > > > Rowland > > > > > > > > > > > > > > > > Partially correct. Before installing the firewall, the > > > > > > > > Gateway on the AD/DC was configured as the ISP's gateway > > > > > > > > (98.102.63.105). I changed the gateway to be 192.168.0.1 > > > > > > > > (the Sonicwall). I believe that's all I did. I did > > > > > > > > reboot the AD/DC. The AD/DC is also the DHCP server. > > > > > > > > > > > > > > > > I've testing with stopping the firewall on the AD/DC as > > > > > > > > well. Didn't help. > > > > > > > > > > > > > > > > On the AD/DC 'getent passwd' does work. > > > > > > > > > > > > > > > > $ getent passwd mark > > > > > > > > mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > > > > > > > > > > > > > On the Linux domain member workstation it does not. > > > > > > > > > > > > > > > > $ getent passwd mark; echo $? > > > > > > > > 2 > > > > > > > > > > > > > > > > However, the user of that workstation is able to log in > > > > > > > > using domain credentials, ntlm_auth also works: > > > > > > > > > > > > > > > > $ ntlm_auth --username=mark --password='mypass' > > > > > > > > NT_STATUS_OK: Success (0x0) > > > > > > > > > > > > > > > > BTW - The MAC workstations cannot now authenticate with > > > > > > > > domain credentials. I tried to unbind and rebind one of > > > > > > > > the workstations, but when trying to unbind I got the > > > > > > > > message, "Unable to access domain controller". It can > > > > > > > > see the domain controller: > > > > > > > > > > > > > > > > $ host mail > > > > > > > > mail.hprs.local has address 192.168.0.2 > > > > > > > > > > > > > > > > However, this is possibly an additional/separate (though > > > > > > > > related) issue. I don't want to complicate the original > > > > > > > > question. I can deal with the Macs later and perhaps > > > > > > > > solving the Linux issue will magically solve the Mac > > > > > > > > issue. I've including the Mac information in case it > > > > > > > > provides additional clues. > > > > > > > > > > > > > > > > As I said, no problems whatsoever with the Windows 7 > > > > > > > > domain members. > > > > > > > > > > > > > > > > --Mark > > > > > > > > > > > > > > > > > > > > > > OK, just a thought, is there a dhcp server running on your > > > > > > > sonicwall ? > > > > > > > > > > > > No. I configured the Sonicwall with the tech last night and > > > > > > I'm sure it's not running the DHCP server. The AD/DC (Mail) is > > > > > > running dhcpd. (but I'll double-check) > > > > > > > > > > > > > What does running 'route' show (you will probably have to do > > > > > > > this as root or via sudo). It should show your sonicwall as > > > > > > > the gateway. try running these: > > > > > > > > > > > > Yes, shows Sonicwall On the AD/DC: > > > > > > > > > > > > $ route > > > > > > Kernel IP routing table > > > > > > Destination Gateway Genmask Flags Metric > > > > > > Ref Use Iface default 192.168.0.1 0.0.0.0 > > > > > > UG 1 0 0 eth1 loopback * > > > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > > > * 255.255.255.0 U 0 0 0 eth1 > > > > > > > > > > > > On the domain members, shows the AD/DC as the gateway: > > > > > > > > > > It shouldn't, you normally only have one gateway, it is by > > > > > definition the 'gateway' to the WAN & internet, so I would use > > > > > the same one on all your machines. > > > > > > > > The LAN host gateways are assiged by the dhcpd server. Unless I > > > > hard-code static IP's I can't really change that. The Windows > > > > computers likewise show the AD/DC (192.168.0.1) as the gateway and > > > > they all work fine. > > > > > > > > > > # route > > > > > > Kernel IP routing table > > > > > > Destination Gateway Genmask Flags Metric > > > > > > Ref Use Iface default mail.hprs.local 0.0.0.0 > > > > > > UG 202 0 0 eth0 loopback * > > > > > > 255.0.0.0 U 0 0 0 lo 192.168.0.0 > > > > > > * 255.255.255.0 U 202 0 0 eth0 > > > > > > > > > > > > > hostname -s > > > > > > > hostname -d > > > > > > > hostname -i > > > > > > > hostname -I > > > > > > > > > > > > > > Do they show what you expect ? > > > > > > > > > > > > On the domain member (labrat): > > > > > > > > > > > > $ hostname -s > > > > > > labrat > > > > > > > > > > > > $ hostname -d > > > > > > hprs.local > > > > > > > > > > > > $ hostname -i > > > > > > 127.0.0.1 > > > > > > > > > > > > $ hostname -I > > > > > > hostname: invalid option -- 'I' > > > > > > > > > > > > I believe these show as expected (except for -I). Agreed? > > > > > > > > > > Sorry, but no, '127.0.0.1' is the ipaddress for 'localhost', it > > > > > should the actual ipaddress of the computer. What is > > > > > in /etc/hosts ? > > > > > > > > /etc/hosts: > > > > 127.0.0.1 localhost > > > > 127.0.0.1 labrat.hprs.local labrat > > > > > > > > The IP of the computer is assigned by DHCP, so it won't be > > > > in /etc/hosts. There was a reason to have the /etc/hosts IP as > > > > 127.0.0.1, but I can't remember. I'll see if I can find my notes. > > > > Meanwhile, I've removed that entry from /etc/hosts. Now I have: > > > > > > > > # hostname -i > > > > 192.168.0.99 > > > > > > > > Which is the correct IP for labrat. > > > > > > > > > > > What is in /etc/resolv.conf > > > > > > > > > > > > On AD/DC (MAIL 192.168.0.2, is the LAN DNS server): > > > > > > > > > > > > domain hprs.local > > > > > > search hprs.local > > > > > > nameserver 192.168.0.2 > > > > > > > > > > What do you mean 'LAN DNS server' ? is 192.168.0.2 not the DC's > > > > > ipaddress ? > > > > > > > > The DC is the local DNS server and DHCP server -- as I assumed was > > > > required for a AD/DC. The DC has been running Samba4 for Active > > > > Directory for about 4 years and has always done DNS serving for > > > > the LAN (domain) and DHCP. > > > > > > > > > > On Domain Member (labrat) > > > > > > > > > > > > # Generated by dhcpcd from eth0.dhcp > > > > > > # /etc/resolv.conf.head can replace this line > > > > > > domain hprs.local > > > > > > nameserver 192.168.0.2 > > > > > > nameserver 192.168.0.3 > > > > > > # /etc/resolv.conf.tail can replace this line > > > > > > > > > > It should be 'search' not 'domain' > > > > > > > > Well, as it says, the domain member's resolv.conf is generated by > > > > dhcpcd. This also has remained unchanged for years. > > > > > > > > > I will be honest, I am not a fan of dhcpcd, I cannot really see > > > > > a need for it. > > > > > > > > Otherwise I'd have to configure IP, Gateway, Netmask and > > > > nameservers for each host on the network, which is quite a few. > > > > > > > > > > None of the hosts have problem resolving internal or external > > > > > > hostnames. > > > > > > > > This doesn't seem like a gateway or name resolution issue. All > > > > domain members can resolve internal and external host and domain > > > > names. The Linux domain members can authenticate and log in with > > > > domain credentials; ntlm_auth works. Just getent is not working > > > > on the Linux domain members. getent's return status is 2 which > > > > is, "One or more supplied key could not be found in the > > > > database", get ntlm_auth works ... ? > > > > > > > > I'll modify the gateway on a linux domain member to point the the > > > > Sonicwall, but I'm skeptical that will fix getent. I'll report > > > > back. > > > > > > > > ******************************* > > > > MORE INFO! > > > > ******************************* > > > > MEANWHILE, after more testing I've refined the problem > > > > statement. On labrat (domain member), I can: > > > > > > > > $ getent passwd mark > > > > mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash > > > > > > > > Yeah! But, just 'getent passwd' returns only DC:/etc/passwd > > > > entries, no domain users. Also, I cannot 'getent passwd' for any > > > > other domain user on labrat, just 'mark'. If I log onto another > > > > Linux workstation, ccarter, I can: > > > > > > > > > > > > but I cannot 'getent passwd mark' on this computer. > > > > > > > > So, it seems that if a domain user was previously logged on to a > > > > Linux domain member, he/she can do a getent for him/herself > > > > only. A getent cannot be done for any other domain user. > > > > > > > > Kerberos issue? > > > > > > > > --Mark > > > > > > > > > > Something strange going on here, If you use dhcp to set your IP > > > info, you only need this in /etc/hosts: > > > > > > rowland at devstation:~$ cat /etc/hosts > > > 127.0.0.1 localhost > > > > > > # The following lines are desirable for IPv6 capable hosts > > > ::1 localhost ip6-localhost ip6-loopback > > > ff02::1 ip6-allnodes > > > ff02::2 ip6-allrouters > > > > > > Which if you then run the commands I asked you to run, you get > > > these: > > > > > > rowland at devstation:~$ hostname -s > > > devstation > > > rowland at devstation:~$ hostname -d > > > samdom.example.com > > > rowland at devstation:~$ hostname -f > > > devstation.samdom.example.com > > > rowland at devstation:~$ hostname -i > > > 192.168.0.88 > > > > > > and getent returns this: > > > > > > rowland at devstation:~$ getent passwd rowland > > > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > > > > > I do not use dhcpcd, I just use the isc-dhcp-client. > > > > > > I repeat, I do not see the point of dhcpcd, it is just another > > > layer in the dhcp stack and, in my opinion, an unnecessary layer. > > > > I'm probably not going to disassemble use of dhcpd/dhcpcd. Too much > > uses it. I'm not familiar with isc-dhcp-client. > > Again I ask, are you using dhcpd or dhcpcd ? they are different > programs. Normally you do not have to configure isc-dhcp-client, just > install it. > > > > > I have changed /etc/hosts as you suggested. This did not help with > > the 'getent' problem, nor do I see how that would affect 'getent' > > working for the usual user of the workstation, but not for other > > domain users, nor why 'getent passwd' returns NO domain users. > > > > This is something I don't understand either, just installing a firewall > device shouldn't affect getent, but it is possible that it has > highlighted an underlying problem. > > > As an experiment, I will hard-code the IP, etc. for one of the > > workstations so as to elimimate the dhcp and gateway possibilities > > from the discussion. I'll post back results. > > > > --Mark > > > > > > Lets see what happens.Ok, to hopefully dispense with all gateway/nameserver issues, I've modified one Linux domain member to have a static IP and gateway and hand edited resolv.conf as follows: # ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.60 netmask 255.255.255.0 broadcast 192.168.0.255 # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 1 0 0 eth0 /etc/resolv.conf: nameserver 192.168.0.2 nameserver 209.18.47.62 /etc/hosts: 127.0.0.1 localhost 192.168.0.60 ccarter So, the gateway is the Sonicwall firewall, 192.168.0.1. Nameservers are the DC (192.168.0.2) and one of the ISP name servers. The IP is static and is set in /etc/hosts. At this point, there should be no issues or questions with respect to which gateway or DHCP usage (DHCP is not being used). Nevertheless, On this host I can still 'getent' for the user that normally uses this host, but not for any other domain user: $ getent passwd charlie charlie:*:10003:10000:Charlie Carter:/home/HPRS/charlie:/bin/bash $ getent passwd mark At this point I think we can agree that this issue has nothing to do with gateway or DHCP settings. The fact that I can 'getent' for a recent user but not for other users hints at some kind of credential caching. More information: I thought I'd try un-joining one of the Linux domain members, then re-joining to see if it would reset things. I was able to successfully un-join: $ net ads leave -U Administrator But when I tried to open ADUC on a Windows workstation to confirm, I got the error: "Naming information cannot be located for the following reasons: The server is not operational." Normally, I use ADUC all the time. When I tried to re-join the domain on the same computer: $ net ads join -U Administrator Enter Administrator's password: Failed to join domain: failed to lookup DC info for domain 'HPRS' over rpc: Undetermined error The Sonicwall tech insists that no ports are blocked within the LAN. Is there any way to get more information about what is failing? Nothing is logged on the domain member in syslog, messages, debug or log.samba. On the DC, nothing is logged in /var/log/log.samba. On the DC /etc/samba/smb.conf has: log level = 2 passdb:5 auth:10 winbind:2 lanman:10 Would setting this log level higher give us more information? There is no specific log level set on the domain member. Or - I can throw away the firewall! --Mark