Old school: FreeRADIUS and NIS

[Arran Cudbard-Bell]

> I don't think I've ever flamed anyone in my life, but now I believe I
> have to.
> 
> Sadly, it seems like this is a recurring theme with you. I've seen
> literally DOZENS of posts from you in the archives and through google
> and in every single one of them there IS NOT a shred of helpful advice
> except to RTFM.

There's usually a good reason for Alan's terse answers.

> The vaunted documentation is just about the worst I've ever seen.  It
> goes in circles:
> 
> From modules/passwd:
> 
> > #  An example configuration for using /etc/passwd. # #  We do NOT
> > recommend using the configuration below.  See the "unix" #  module,
> > or the "pam" module for a cleaner way to get system passwords. #
> > Using this configuration means that the server will find *only*
> > those #  passwords which are in /etc/passwd, and will *ignore* all
> > of the #  passwords in NIS, LDAP, etc. #
> 
> From modules/unix

Is the reason for not recommending the use of the passwd module 
applicable here?

No.

The documentation assumes that you are able to read, interpret,
and make your own decisions about the validity of information.

> > unix { #  As of 1.1.0, the Unix module no longer reads, #  or
> > caches /etc/passwd, /etc/shadow, or /etc/group. #  If you wish to
> > cache those files, see the passwd #  module.

So use the passwd module.

> From radiusd.conf:
> > #  On systems with shadow passwords, you might have to set 'group =
> > shadow' #  for the server to be able to read the shadow password
> > file.  If you can #  authenticate users while in debug mode, but
> > not in daemon mode, it may be #  that the debugging mode server is
> > running as a user that can read the #  shadow info, and the user
> > listed below can not.
> 
> (FWIW, this documentation is beyond incomprehensible.  The 'group =
> shadow' is not about using the group 'shadow' to access /etc/shadow
> it's changing the group on /etc/shadow to 'radiusd'.)

No. It's about setting the group the FreeRADIUS daemon runs as.

The FreeRADIUS daemon does not switch GID or UID when running in debug
mode, it continues with the GID and UID of the user which invoked it.

That's what the documentation is talking about.

> >>>
> >>> And setting "a+rw" on /etc/passwd and /etc/shadow is probaby
> >>> the single worst thing you can do to your system.

Yes, setting a+rw would be completely idiotic, if you really don't
understand why, you should probably not have permission to make 
such a change.

>   EVER.
> >>> Rather than doing that, read raddb/radiusd.conf, it talks about
> >>> issues with reading /etc/shadow, and describes suggested fixes
> >>> won't
> >> destroy your
> >>> system.
> >>>
> >>> Honestly, I don't understand why it's so hard to read the
> >>> configuration files.

Agreed.

> >>>
> >>> Alan DeKok. -
> 
> Radiusd.conf DOES NOT talk about issues with reading /etc/shadow.
> ANYWHERE.  PERIOD.

Because radiusd.conf is the main configuration file for the server,
why would it be cluttered with module specific configuration snippets
or advice...


>  And I've NEVER dealt with a more unprofessional and unhelpful
> mailing list as I have with this list.  
> What should be a relatively
> 'simple' solution is anything but with this list.  I'm no noob working
> with linux/unix and text configuration files, and yet I feel FARTHER
> away from an answer that I did before I started.

> And due to that 'take two steps forward and half-dozen back', I've
> made it clear to my boss that FreeRADIUS, while it may work just fine,
> will be impossible to manage due to the horrible documentation and
> utter lack of help on the lists. 

An excerpt from the Fedora list:

http://marc.info/?l=fedora-list&m=139426697003081&w=2
> On 03/06/14 20:22, David Beveridge wrote:
>
>>
>> You don't need to lie, or make stuff up, just explain that it IS
>> possible, BUT just not within the timeframe and budget requested.
>>
>
> Thing is, based on my searching, getting FreeRADIUS to work with NIS
> isn't possible.  At least I've found no documentation on how to make
> it work.  There's tons on getting it to work with LDAP, but not NIS.
> Which is the reason for my OP.
>
Except for the fact that I already posted here how you can do it...

eg: Freeradius supports perl module and perl can do NIS Auth.

check out example.pl and then do a google search for "perl NIS"

Looks like you're having similar difficulties over there too.

---
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140310/a6e4675e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140310/a6e4675e/attachment.pgp>