Ypwich -m matches 1:1 as well. As I said I am hoping to get rid of this problem when all machines in our fleet jump to SL 6.5 in the next couple weeks. Bill On 8/1/14, 17:19 MDT, "Steve Rikli" <[log in to unmask]> wrote: >You mentioned you're using shadow passwd in your reply to Gilbert in >this thread -- what does that look like in each nsswitch.conf ? I'd >expect it to be "files nis" as well, but it's a good thing to check. > >Gilbert's other questions about shadow.byname et al NIS maps are also >good to check. You can see all the NIS maps provided by the NIS server >with 'ypwhich -m'. > >sr. > > >On Fri, Aug 01, 2014 at 11:07:35PM +0000, Capehart, William J wrote: >> The nsswitch, ypwich and ypmatch lines match 1:1, There are only file >>and >> nis for the passwd entry on this list. Compat or nis+ isn?t there. >> >> Bill >> >> >> On 8/1/14, 16:02 MDT, "Steve Rikli" <[log in to unmask]> wrote: >> >> >If you believe you have the configs straight at this point, as initial >> >troubleshooting steps e.g. I would compare the outputs of these >>commands >> >on the working and non-working NIS client systems: >> > >> > grep ^passwd: /etc/nsswitch.conf >> > ypwhich >> > ypmatch NISuser passwd >> > >> >Your logs indicate password failure, and assuming you're typing the >> >same password correctly in both attempts, that implies the passwd map >> >entry for NISuser isn't correctly in-place on your failing NIS client. >> > >> >We don't see "error retrieving information about user NISuser" or >> >similar log message, which is an indicator the NIS passwd map is >> >available on your NIS client, but not the password itself. But we >>don't >> >yet know why. >> > >> >Perhaps a "+" or "compat" situation in /etc/passwd and nsswitch.conf? >> ></speculation> >> > >> >Cheers, >> >sr. >> > >> > >> >On Fri, Aug 01, 2014 at 09:46:56PM +0000, Capehart, William J wrote: >> >> >> >> I am using a login via ssh >> >> >> >> >> >> Here is the secure log material for my test USR >> >> >> >> Aug 1 21:26:20 <client> unix_chkpwd[6558]: password check failed for >> >>user >> >> (<NISuser>) >> >> Aug 1 21:26:20 <client> sshd[6556]: pam_unix(sshd:auth): >>authentication >> >> failure; logname= uid=0 euid=0 tty=ssh ruser= >>rhost=<remote.host.name> >> >> user=jtorres >> >> Aug 1 21:26:22 <client> sshd[6556]: Failed password for <NISuser> >>from >> >> <remote.host.up.address> port 65500 ssh2 >> >> >> >> >> >> From a fellow Mandriva box the same request meets as follows. >> >> >> >> Aug 1 21:32:15 <client> sshd[7595]: Accepted password for <NISuser> >>from >> >> <remote.host.up.address> port 54278 ssh2 >> >> >> >> >> >> Passwords should be hashed. I am not using keberos (or at least I >> >>don???t >> >> think it???s in the mix). >> >> >> >> once again, despite what you see above the id command yield the >>correct >> >> uid and gid information for the test user >> >> >> >> Bill >> >> >> >> >> >> On 8/1/14, 15:20 MDT, "Steven Timm" <[log in to unmask]> wrote: >> >> >> >> >What login method is failing? Login from console? ssh? other? >> >> >does /var/log/secure give you anything as far as error messages? It >> >> >should. Is kerberos involved here or do you have hashed >> >> >passwords in the NIS map? >> >> > >> >> >Steve Timm >> >> > >> >> > >> >> > >> >> >On Fri, 1 Aug 2014, Capehart, William J wrote: >> >> > >> >> >>Steve: >> >> >> >> >> >>Normally I do all the pieces normally but I followed your guidance: >> >> >> >> >> >>authconfig --enablenis ???nisserver=(server.name.goes.here) >> >> >>???nisdomain=(mydomain) --update >> >> >> >> >> >> >> >> >>As root, id on one of my test accounts worked. >> >> >>As root, su on the same test account worked. >> >> >>??nis?? has indeed been through the /etc/nsswitch.conf file all >>along. >> >> >> >> >> >>Bill >> >> >> >> >> >> >> >> >> >> >> >>On 8/1/14, 14:51 MDT, "Steven Timm" <[log in to unmask]> wrote: >> >> >> >> >> >>>did you go into the system setup utility and enable NIS >> >>authentication? >> >> >>>(or use authconfig from the command line). That's the best way >> >> >>>to ensure that PAM is configured correctly to use NIS and that's >> >>likely >> >> >>>the problem. >> >> >>> >> >> >>>(does "id" on a yp user name work?) >> >> >>>(does "su" to a yp user name work?) >> >> >>>does "nis" appear in /etc/nsswitch.conf? (setup will do that). >> >> >>> >> >> >>>Steve Timm >> >> >>> >> >> >>> >> >> >>>\On Fri, 1 Aug 2014, Capehart, William J wrote: >> >> >>> >> >> >>>>We are in the process of migrating to SL 6.5 from Mandriva and >> >>things >> >> >>>>have >> >> >>>>been manageable until (of course) today. >> >> >>>> >> >> >>>>The NIS server is still under Mandriva (yp-serve is 2.22, ypbind >>is >> >> >>>>1.29.91) >> >> >>>> >> >> >>>>On the client to be in SL 6.5 the ypbind is 1.20.4. >> >> >>>> >> >> >>>>NIS works on the fellow Mandriva machine clients but when used on >> >>the >> >> >>>>SL >> >> >>>>machine >> >> >>>> >> >> >>>>The username and groups get carried over and match the uids >> >> >>>> >> >> >>>>ypcat gives the correct responses for the arguments passwd and >> >>groups >> >> >>>> >> >> >>>>BUT >> >> >>>> >> >> >>>>I get permission denied errors when logging in. (That is sort of >>a >> >> >>>>deal >> >> >>>>breaker). >> >> >>>> >> >> >>>>Beyond this point is there any troubleshooting advise here? >> >> >>>> >> >> >>>>Thanks Much, >> >> >>>>Bill >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>> >> >> >>>------------------------------------------------------------------ >> >> >>>Steven C. Timm, Ph.D (630) 840-8525 >> >> >>>[log in to unmask] http://home.fnal.gov/~timm/ >> >> >>>Fermilab Scientific Computing Division, Scientific Computing >>Services >> >> >>>Quad. >> >> >>>Grid and Cloud Services Dept., Associate Dept. Head for Cloud >> >>Computing >> >> >> >> >> >> >> >> > >> >> >------------------------------------------------------------------ >> >> >Steven C. Timm, Ph.D (630) 840-8525 >> >> >[log in to unmask] http://home.fnal.gov/~timm/ >> >> >Fermilab Scientific Computing Division, Scientific Computing >>Services >> >> >Quad. >> >> >Grid and Cloud Services Dept., Associate Dept. Head for Cloud >>Computing >> >> >> >> >> >>