NIS security issues - SUN

This is a discussion on NIS security issues - SUN ; Wanted a little clarification on a situation currently happening here... At my company, there is a NIS enviroment controlled by Corp IT for production machines (Solaris/Redhat). The development group has a handful of Redhat servers ( currently...might grow to 10 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: NIS security issues

  1. NIS security issues

    Wanted a little clarification on a situation currently happening
    here...

    At my company, there is a NIS enviroment controlled by Corp IT for
    production machines (Solaris/Redhat).
    The development group has a handful of Redhat servers (< 5
    currently...might grow to 10 in a year or so) that are being installed
    in the same location, and will be used by the same users as the prod
    machines. The development servers, however, are owned/admin'd by a
    different team with root access to those boxes - they don't and
    shouldn't have root on production machines. They would like the
    development servers to use NIS for all the current prod users, but
    without giving up root access either way. Is this possible?

    Local user mgmt is out of the question and a new NIS server just for
    development might be overkill....might be looking at rsync if the above
    won't work. And either of these two solutions still doesn;t allow users
    to use their prod accounts on develpmnt servers. Any ideas?


  2. Re: NIS security issues

    %% jdmclemore@gmail.com writes:

    j> The development group has a handful of Redhat servers (< 5
    j> currently...might grow to 10 in a year or so) that are being installed
    j> in the same location, and will be used by the same users as the prod
    j> machines. The development servers, however, are owned/admin'd by a
    j> different team with root access to those boxes - they don't and
    j> shouldn't have root on production machines. They would like the
    j> development servers to use NIS for all the current prod users, but
    j> without giving up root access either way. Is this possible?

    I guess I'm confused: what does using NIS have to do with root access?

    Unless, you're planning on putting an R&D owned account with superuser
    privileges (UID 0) into the NIS passwd database? Just don't do that.
    Have the user accounts in NIS, and maybe a superuser account for the
    admin team in NIS (if the development team is OK with the admin folks
    having root on their boxes).

    Let the development team have a superuser account they manage locally in
    /etc/passwd on their systems.

    Alternatively, if they're OK with it, you could just have them use sudo
    (but, sometimes you just need the root password).

    --
    -------------------------------------------------------------------------------
    Paul D. Smith HASMAT--HA Software Mthds & Tools
    "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
    -------------------------------------------------------------------------------
    These are my opinions--Nortel takes no responsibility for them.

  3. Re: NIS security issues

    jdmclemore@gmail.com wrote:

    >Wanted a little clarification on a situation currently happening
    >here...
    >
    >At my company, there is a NIS enviroment controlled by Corp IT for
    >production machines (Solaris/Redhat).
    >The development group has a handful of Redhat servers (< 5
    >currently...might grow to 10 in a year or so) that are being installed
    >in the same location, and will be used by the same users as the prod
    >machines. The development servers, however, are owned/admin'd by a
    >different team with root access to those boxes - they don't and
    >shouldn't have root on production machines. They would like the
    >development servers to use NIS for all the current prod users, but
    >without giving up root access either way. Is this possible?
    >
    >Local user mgmt is out of the question and a new NIS server just for
    >development might be overkill....might be looking at rsync if the above
    >won't work. And either of these two solutions still doesn;t allow users
    >to use their prod accounts on develpmnt servers. Any ideas?
    >
    >
    >

    I don't recall the details, but it is possible to alter the files from
    which the NIS master builds its database to omit root! Having done
    that, each local machine must rely on its local /etc/passwd and
    /etc/shadow for root.

  4. Re: NIS security issues

    jdmclemore@gmail.com wrote:
    > Wanted a little clarification on a situation currently happening
    > here...
    >
    > At my company, there is a NIS enviroment controlled by Corp IT for
    > production machines (Solaris/Redhat).
    > The development group has a handful of Redhat servers (< 5
    > currently...might grow to 10 in a year or so) that are being installed
    > in the same location, and will be used by the same users as the prod
    > machines. The development servers, however, are owned/admin'd by a
    > different team with root access to those boxes - they don't and
    > shouldn't have root on production machines. They would like the
    > development servers to use NIS for all the current prod users, but
    > without giving up root access either way. Is this possible?
    >
    > Local user mgmt is out of the question and a new NIS server just for
    > development might be overkill....might be looking at rsync if the above
    > won't work. And either of these two solutions still doesn;t allow users
    > to use their prod accounts on develpmnt servers. Any ideas?
    >

    If you're expecting server growth, I'd recommend looking into LDAP as an
    alternative to NIS. LDAP allows for a high level of control over user
    rights via group policy. In your case I'd recommend creating prod-root,
    devel-root, prod-user, & devel-user groups and allocate users that way
    (these are groups of machines which a user associated with that group
    has access rights to). LDAP can easily be made secure via SSL, and it's
    scales fairly well. The environment I previously implemented it on was
    a mix of over 100 Solaris 8/10/RHEL3 machines.

+ Reply to Thread