[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

(fwd) Shadow + NIS + Solaris (fwd)



Hello,

In the forwarded email below Maciek provided a solution for those of us who
wanted to do Shadow + NIS + Solaris.  I implemented his solution and got things
working fine.  Now a little over a year later I find this solution doesn't work
and I have no way for my linux users to authenticate to a solaris NIS domain.  
Any ideas?

Basic setup:

linuxbox (RH6.0, pam-0.72-7, NIS client of Solaris domain)
sunbox (Solaris 2.7, passwd and shadow passwords in passwd.adjunct.byname)

Output of snoop indicates same troubles as before:

linuxbox -> sunbox NIS match user in passwd.byname?
linuxbox <- sunbox NIS match ok
linuxbox -> sunbox NIS match user in passwd.adjunct.byname?
linuxbox <- sunbox NIS match ok
linuxbox -> sunbox NIS match user in passwd.byname?
linuxbox <- sunbox NIS match ok
linuxbox -> sunbox NIS match user in passwd.adjunct.byname?
linuxbox <- sunbox NIS match no such map

Typically in solaris when a user attempts to dump the passwd.adjunct.byname map
the response is 'no such map' so I suspect the second lookup is done as the
user.  What is the workaround on this?  Why can't a permanent fix be made on
this?

michael


---------- Forwarded message ----------
Date: Thu, 07 Jan 1999 16:08:26 +0100 (MET)
From: Maciek Uhlig <muhlig@HELIOS.CTO.US.EDU.PL>
To: kriss@fnal.gov
Newsgroups: comp.os.linux.networking
Subject: (fwd) Shadow + NIS + Solaris


Just in case you could miss it in the news.

Regards,

Maciek

Path: news.cto.us.edu.pl!not-for-mail
From: muhlig@helios.cto.us.edu.pl (Maciek Uhlig)
Newsgroups: comp.os.linux.networking
Subject: Shadow + NIS + Solaris
Date: 7 Jan 1999 13:54:58 GMT
Organization: University of Silesia, Katowice, Poland
Lines: 32
Distribution: world
Message-ID: <772ebi$n0m@helios.cto.us.edu.pl>
NNTP-Posting-Host: helios.cto.us.edu.pl
X-Newsreader: TIN [UNIX 1.3 950726BETA PL0]

There was a thread on the subject in October '98 . Let me summarize (you
could find the details on dejanews): Michael Kriss wanted to have the
abovementioned setup working, he did what he should, but NIS login was
still not allowed. Thorsten Kukuk suggested to install the newest glibc
(supposing buggy passwd.adjunct support). Michael Kriss did it but the
problem was still there. There was no further discussion or solution. 

However there is a solution of the problem which is incorrect coding in 
pam_unix_auth.c which prevents user from logging in. Let me point to the 
problem:

pam_unix_auth module runs as root. It issues getpwnam and gets the 
CORRECT password from NIS (i.e. from passwd.adjunct.byname map). Then it 
issues seteuid and changes uid to logging user id in order to get the 
user password in case of NIS+ running. However it's not the case and the 
second getpwname gets INCORRECT password as ##user from passwd.byname map 
because ordinary user can not see passwd.adjunct.byname map. Obviously 
the salt is then incorrect and pam_unix_auth returns with PAM_AUTH_ERR.

This is the reason why Michael Kriss observed "NIS match" and "NIS no such
map" for passwd.adjunct.byname. For the first time he was root, for the 
second time he was ordinary user only.

So, if you want to get shadow + NIS + Solaris passwd.adjunct running you 
have to modify your pam_unix_auth.c and don't let it issue seteuid call. 
As a quick hack you could comment out "NIS+" support from the source code. 
Don't forget to compile and install pam_unix_auth.so :-))

Regards,

Maciek Uhlig
Computer Center, University of Silesia, Katowice, Poland






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []