[Samba] getent not working after installing firewall
Mark Foley
mfoley at ohprs.org
Mon Mar 4 20:57:16 UTC 2019
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
More information about the samba
mailing list