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
Am 04.03.19 um 21:18 schrieb Mark Foley via samba:>> 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.how does that matter? your gateway is only part of the game when you try to reach an IP outside your LAN you said "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" but above you said "The Windows computers likewise show the AD/DC (192.168.0.1) as the gateway" so hell, what is the IP of your "Sonicwall firewall between the Internet and office LAN" and if it's 192.168.0.1 that don't match "The Windows computers likewise show the AD/DC (192.168.0.1) as the gateway" the AD/DC *is not your gateway* - it's the "Sonicwall firewall" connecting your LAN to the internet and nothing else
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. Rowland
On Mon, 4 Mar 2019 21:28:19 +0100 Reindl Harald <h.reindl at thelounge.net> wrote:> > Am 04.03.19 um 21:18 schrieb Mark Foley via samba: > >> 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.2) as the gateway > > and they all work fine. > how does that matter?No sure what you mean by "how does that matter?"> your gateway is only part of the game when you try to reach an IP > outside your LAN > > you said "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" but above you said "The Windows computers likewise show the > AD/DC (192.168.0.2) as the gateway" > > so hell, what is the IP of your "Sonicwall firewall between the Internet > and office LAN" and if it's 192.168.0.1 that don't match "The Windows > computers likewise show the AD/DC (192.168.0.2) as the gateway"Well, I figured someone might catch that, but I didn't want to muddy things further by posting a follow-up. But, since you've noticed ... To clarify: Without the Sonicwall, host 192.168.0.2 (DC) had the ISP's gateway 98.102.63.105 configured. All the LAN workstations had 192.168.0.2 (DC) set as the gateway (route command output). The dhcpcd client sets the IP, mask, nameserver and gatway so *it* set the DC as the gateway, not me directly. Regardless, this had worked for years. When I configured the Sonicwall (IP 192.168.0.1), it got configured with the ISP gateway. I configured the DC (192.168.0.2) gateway with the Sonicwall's IP: 192.168.0.1. Since the DC is still the DHCP server, it is still passing 192.168.0.2 to clients' dhcpcd as the gateway: On a domain member: # 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 1 15:45:31 root at labrat:~ # host mail.hprs.local mail.hprs.local has address 192.168.0.2> the AD/DC *is not your gateway* - it's the "Sonicwall firewall" > connecting your LAN to the internet and nothing elseNow, I could configure the Linux domain members to hard-code 192.168.0.1 (Sonicwall) as the gateway, and I'll try that as an experiment, but I'll repeat, none of the client workstation/ domain-members on the LAN are having any problem resolving names or getting outside the LAN. So, I don't think the gateway is the problem. If you see the message I sent later, I'm only having a problem with getent, and only for domain members who had not previously logged onto a given Linux workstation. I don't think the gateway is the issue with that. --Mark
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