Re: Obtaining NIS domainname from Gatorbox

[matt () uts EDU AU (Jas)]

npc () minotaur jpl nasa gov wrote this...
> Dave Horsfall said:
> > On Wed, 12 Apr 1995, der Mouse wrote:
> > > > Maybe a good reason to join the crowd and not run NIS?
> > >
> > > I wish.  It's clear to me that NIS is a big problem.  But what else is
> > > out there?  We have a definite need to share passwd databases across
> > > many machines, from multiple vendors, none of which we have source code
> > > to.  How close to a solution can we get?
> >
> > A wild idea, straight off the top of my head: what about using the DNS
> > mechanisms?  Apologies if this has been suggested and flamed before...
>
> A couple of points.  First, in some sense, this has been implemented
> (successfully) before.  Find information on Project Athena's Hessiod
> service.  NIS like information was added to DNS in the form of 
> Hessiod records.  
>
> The problem is that DNS isn't very secure either, plus that's a lot
> more for DNS to handle, so, in general, I don't think it's a great
> design idea, although it's convenient to use a mechanism that's already
> in place.
>
> I'm surprised nobody's mentioned NIS+, although it's not available 
> everywhere yet (and I know of no freely distributable implementation).
> Still, I'm not sure it's all it's cracked up to be.

        i mentioned this to the origional author, but not to the
list. so here goes.

        NIS+ is much much more secure than NIS. it uses random timed
credentials (somewhat like kerberos), and uses securerpc for
communication. every entry in the table has an owner/group, and the
table itself has an owner/group. it also has modes for four catagories
of authentication nobody/owner/group/world (nobody is for
non-authenticated connections, orld is for authenticated connections
but not user/in group). within each catagroies restrictions are placed
on 4 operations rmcd (read,create,modify,delete). thats it for the
quick summary, now for some of the practical implications of this.

        every can own their own passwd entry, hence they can modify
their own passwd entry but cant view it! but the root user can read
the passwd entry but cant modify it, and no-one expect the NIS+
administers can create/delete a passwd entry. modes also affect table
columns so that user can change their shell but not their full name,
or vice versa. one note to all this, how this all works is up to how
the administrator has set up NIS+ (you can achieve even nicer tricks
if you understand NIS+ well). another capability is to have multiple
NIS+ domains on one machine (but the machine will only use one for
lookups of info). control is cool, but it makes for a few performance
issues.

        NIS+ updates are almost instantaneous, if you lock a users
account, they wont be able to log into any machine. the downside to
this is that updating every record in a large table can take quite
sometime (do it over night, and make sure your master NIS+ server has
crunch to spare). if you only every do small updates you can get by on
a small machine (we run all our mail/pd software/NIS+/printing on a
sparc2 running solaris 2.4, and this is for over 3000 users. this
setup runs fine most of the time, mail seems to give us more CPU
hassles than NIS+). anyway enough of that...

if anyone wants more info on how NIS+ works/what it is capable of,
mail me (we have been running it here for almost 6 months). on a final
note, if you need distributed, secure, updatable network files, NIS+
is a good option (unfortunatly it only runs on Solaris/SunOS right now
(yes!! it runs on SunOS! but i havent tried on SunOS yet)).

                        Matt
-- 
#!/bin/sh
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit
Matthew Keenan   Systems Programmer   Information Technology Division
      University of Technology     Sydney Australia

It's nice to be in a position where people apologize because they
assume there's humor in your work, based on past experience,
but they're not sure where it is. -- Rob Pike