CentOS - Jan 2019 - Inconsistent NIS Client Behavior w/ Centos 7.6

Hi All.

I am working on bringing back a number of Centos 7 rigs in our student computer
lab back online. No change was made to the existing server machine [running
Scientific Linux 6]



Right now there is one remaining thing to resolve: an inconsistency with the
rigs' NIS Clients.



I have configured rcpbind and ypbind following guidance from Server World (
https://www.server-world.info/en/note?os=CentOS_7&p=nis&f=2 )
identically on all of the client machines.  I have done this before with
previous installs before this.  The last time was this summer.   Three are
behaving as they are supposed to do. Five, however, are not.



In this process I have repeatedly checked that support files ..



/etc/sysconfig/network

/etc/yp.conf

/etc/pam.d/system-auth-ac

/etc/pam.d/system-auth

/etc/login.defs

/etc/sysconfig/authconfig



They are identical.



IP addresses, Netmasks, Gateways, DNS, etc. are correct and all rigs (Server and
Clients) do not conflict on any of the machines or /etc/host files.



Disabling firewalls don?t impact the problem.



NFS and other services work fine. All other aspects of networking is fine. You
can ssh and access the Server rig from the Client rigs and for locally installed
accounts on the clients go the other way.  Accounts that leverage NIS cannot log
into the Client from the Server or any other remote system.



rpcbind shows that the ypbind/ypserv services are up and Clients and Server,
respectfully (and it works on some of the machines).



The rigs that are not working exhibit the following (satisfactory) behavior.



  *   yptest -u [valid nis username] works with no errors.



  *   yppasswd will change a password on the NIS server with no errors and other
commands like ypchfn will work as well.



  *   ypwhich, ypcat, ypmap, etc. give the same values we'd see on the NIS
server.



...BUT...



  *   You cannot console-login, ssh, or su into the rigs with valid NIS
accounts.



     *   (The local ypbind -d "debug mode" shows no response to a
login, the "secure" log responds to a valid NIS account login with an
"invalid user" a the [preauth] phase)



  *   uids of valid NIS users are not recognized.



     *   With ls -l, we see the uid of a file?s owner and not the username. 
(gids are explicitly declared locally on all rigs so they?ll match anyway.)



  *   The id command for any valid nis user fails with "no such user"



  *   cd ~[Valid NIS User] responds with "no such directory" even if
the home directory exists (and the uid matches the uid on the NIS server).



I am totally at a loss here.  I cannot see the difference in what I did on the
machines that work and the machines that do not work.



Is there any test that I am missing or are there any files or setting where the
culprit(s) on the errant machines may be?



Cheers and Thanks
---------------------------------------------------------------------------------------
Dr. Bill Capehart <William.Capehart at sdsmt.edu<mailto:William.Capehart
at sdsmt.edu>>
Director, Atmospheric and Environmental Sciences Program
Department of Civil and Environmental Engineering
201 Mineral Industries Building (MWRF)
123 Civil Mechanical Building (T)
South Dakota School of Mines and Technology
501 East St Joseph Street
Rapid City, SD  57701-3995 USA
Ph: +1-605-394-1994   Mobile: +1-605-484-5692

On Wed, Jan 16, 2019 at 04:26:49PM +0000, Capehart, William J
wrote:
> I am totally at a loss here.  I cannot see the difference in what I
> did on the machines that work and the machines that do not work. 
> 
> Is there any test that I am missing or are there any files or
> setting where the culprit(s) on the errant machines may be? 
Do you have the SELinux boolean 'nis_enabled' turned on?

# setsebool -P nis_enabled 1

That should be required for NIS logins to work, I believe.

Check out if there are other SElinux AVCs, by trying to log in and
then run:

# ausearch -m avc -ts recent

This will show any AVCs on the system from the past 5 minutes.
Replace 'recent' with 'today' to show all from today.

-- 
Jonathan Billings <billings at negate.org>

Capehart, William J wrote:
> 
> I am working on bringing back a number of Centos 7 rigs in our
> student computer lab back online. No change was made to the existing
> server machine [running Scientific Linux 6]
> 
> Right now there is one remaining thing to resolve: an inconsistency
> with the rigs' NIS Clients.
> 
> I have configured rcpbind and ypbind following guidance from Server
> World ( https://www.server-world.info/en/note?os=CentOS_7&p=nis&f=2
)
> identically on all of the client machines.  I have done this before
> with previous installs before this.  The last time was this summer.
> Three are behaving as they are supposed to do. Five, however, are
> not.
> 
> In this process I have repeatedly checked that support files ..
> 
> /etc/sysconfig/network
> /etc/yp.conf
> /etc/pam.d/system-auth-ac
> /etc/pam.d/system-auth
> /etc/login.defs
> /etc/sysconfig/authconfig
Do you have nis set up in /etc/nsswitch.conf ?

James Pearson

Hi James.

Thanks for bringing that up.

In reviewing the /etc/nsswitch.conf files they LOOKED identical.  I then went
into one of the errant ones and saw that passwd looked odd in the editor.

I retyped that line and the and shadow and group lines and restarted and indeed
it worked.  Not sure how that occurred but it did work.

Thanks Much!
Bill


?On 1/16/19, 10:32 MST, "James Pearson" <james-p at
moving-picture.com> wrote:

    Capehart, William J wrote:
    > 
    > I am working on bringing back a number of Centos 7 rigs in our
    > student computer lab back online. No change was made to the existing
    > server machine [running Scientific Linux 6]
    > 
    > Right now there is one remaining thing to resolve: an inconsistency
    > with the rigs' NIS Clients.
    > 
    > I have configured rcpbind and ypbind following guidance from Server
    > World (
https://www.server-world.info/en/note?os=CentOS_7&p=nis&f=2 )
    > identically on all of the client machines.  I have done this before
    > with previous installs before this.  The last time was this summer.
    > Three are behaving as they are supposed to do. Five, however, are
    > not.
    > 
    > In this process I have repeatedly checked that support files ..
    > 
    > /etc/sysconfig/network
    > /etc/yp.conf
    > /etc/pam.d/system-auth-ac
    > /etc/pam.d/system-auth
    > /etc/login.defs
    > /etc/sysconfig/authconfig
    
    Do you have nis set up in /etc/nsswitch.conf ?
    
    James Pearson