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

Re: How do I get rid of passwd/shadow files



On Wed, 28 Oct 1998, Alan DeKok wrote:

> > > however, PAM has been adopted as standard in redhat linux, and that
> > > carries weight.  if those other protocols are _also_ adopted, then i
> > > will join development lists on them and help out.
> >
> > But in a very real sense, that's not what PAM is for, and it's not
> > what it's used for.
> 
>   But in a very different (and just as real) sense, that's what people
> *need*.  The flurry of activity on the list indicates that there is a
> desperate need for enterprise-wide authentication & authorization.
> PAM handles the authentication, but not the authorization.
> 
>   It seems that the consensus is to use RADIUS for both.  That's not
> too surprising, as that's the problem RADIUS was designed to solve.
> 
> > Red Hat doesn't do this.  With the NSS interface provided by glibc,
> > the best solution is probably to just write a module to interface to
> > RADIUS and let all of your installed programs benefit without the need
> > for recompilation.
> 
>   OK, I'll bit the bullet.  The nss_pwdb seems simple enough, and I've
> spent the last 3 months hacking Cistron at home, and a commercial
> server at work.  I'll try to get an nss_radius done this week, even if
> it means hacking a radius server.
> 
> >  The key assumption made with NSS (AFAIK) is that the user
> > information can be gotten without authenticating to the service, so
> > if all access to a RADIUS database is password-protected, allowances
> > would need to be made.
> 
>   i.e. Extending the RADIUS functionality to handle authorization
> without authentication.  It won't be RFC compatible, but if you've got
> source and a RADIUS server that does what you *need*, we can always
> get the RFC's re-written.
> 
>   For anyone else doing RADIUS, I'd suggest a LGPL'd cross-platform
> library.  I'm not entirely satisfied with the PWDB implemenation of
> RADIUS, and it doesn't do Vendor-Specific attributes, or a number of
> other things.  For Linux/Solaris/WNT source, see my latest CVS snapshot:
> 
> ftp://ftp.striker.ottawa.on.ca/pub/cvs/libradius-981028.tar.gz
> 
>   I've also got a hacked version of Cistron.  Once I get the NSS
> module working, I'll put everything online for public perusal.

I'll just chip in my two cents worth with a basic description of the
functionality that I am looking to get out of a Pam Radius module.

1. We have all authentication information stored on a MS-SQL server that
   is accessed through RadiusUX and the Openlink drivers directly from
   Linux. This works great.

2. The problem is that we have to then create the /etc/passwd|group|shadow
   entries on the Linux box for the E-mail and Shell access.

3. The optimum situation would be where ALL authentication and user
   information is stored remotely in the SQL database. We could them
   either write modules for Pam that directly use the MS-SQL openlink
   drivers -OR- hack functionality into RADIUS to handle the needs.

The benefit of using RADIUS is it works, it's flexible and it's secure.
That would make me rest easier with machines all over the networks..





--
      President of New Age Consulting Service, Inc.  Cleveland Ohio
           http://www.nacs.net   info@nacs.net   (216)-619-2000
         An athletic supporter of the Cleveland Linux User Group
                        http://cleveland.lug.net



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