[Samba] getent not working after installing firewall

Rowland Penny rpenny at samba.org
Mon Mar 4 21:18:36 UTC 2019


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



More information about the samba mailing list