This list is great.
Thanks to Bugs Brouillard, Alan Davis and Ann Majeske
(thanks compaq!!) for your prompt replies.
Ann expanded each individual question in full, so I
appended her message as a summary.
By the way.....as for uid's gid's, i am not planning
to have same passwds all across, i was just checking
on easiest way out to re-organize. All in All, seems a
messy process that I will have to go thru.
Currently struggling to get KDE(on xterms) screen lock
to work with C2!! (thats the current gotcha)
--- Ann Majeske <Ann.Majeske_at_Compaq.com> wrote:
> Tru64 User wrote:
> >
> > Greetings,
> > This switching to C2 really requires a BEST
> > PRACTICES!!
> > Too many gotchas if prior homework is not done
> > properly.
> Reading the Security Manual is the best
> suggestion I can make. The Security Manual
> was pretty confusing prior to V5.*, so you
> might want to look at a more recent version.
> But, there were changes made to how the
> security configuration works, so you can't
> really do that. There was an appendix added
> to the Security Guide in V5.* that describes
> things that you have to do specifically if
> you need a C2 level of security, but part of
> the problem with writing a best practices or
> White paper on how to configure Enhanced
> Security is that the configuration depends
> too much on your system configuration and the
> level and type of security features you need.
> Enhanced Security is definitely not a
> "one-size fits all" or cookbook proposition.
>
> In V5.* the new Enhanced Security configuration
> (secconfig rather than secsetup) is much easier
> to use and does allow for a couple different
> profiles (there's one that you can select if all
> you're interested in is shadow passwords rather
> than fully configuring Enhanced Security). So,
> I think we're at least working in the right
> direction.
>
> >
> > Accounts which were previous locked (b4 going into
> C2)
> > have a Nologin denotation by passwd field in
> > /etc/passwd. Good.
> > BUT, going into dxaccounts, there is no lock sign
> by
> > those locked accounts.Do I have to go thru each
> and
> > every one to lock again? (To achieve visual
> assurance
> > that account is locked?)
> With Enhanced Security there are multiple ways
> that an account can be "locked" or "disabled".
> The administrative lock (the lock sign in the
> gui) is only one of these. Having an invalid
> password in the password field of the protected
> password database (auth.db) is another. There
> are also account and password expirations that
> can disable the account. So, if all you're
> concerned about is that no-one can log into
> these accounts, you're all set. If you want
> the accounts to show as locked in the gui you'll
> have to go through and administratively lock
> each one. This can be done either with the gui
> or with the edauth tool (see "man edauth.8").
> The man pages prpasswd.4 and authcap.4 explain
> the fields that you see with the edauth tool.
>
> With the edauth tool you can also see the
> encrypted password field and verify that it is
> indeed "nologin" or some other value that is
> impossible for an encrypted password. I also
> find it easier to use to check why an account
> is disabled than the gui, but I've been using
> this since before we had the gui, so I'm
> probably biased.
>
> Another database of note is the "default"
> database, /etc/auth/system/default, see
> "man default.4". This database holds system
> defaults for system-wide parameters that
> don't fall into the other databases as well
> as defaults for the other databases. So,
> if you want to set one of the Enhanced
> Security password database parameters for
> all accounts you can set it in here. You
> can override a default by setting the
> changed parameter on the specific accounts.
>
> >
> > Whats the BEST PRACTICE, or suggestion on
> > re-organizing uid's &gid's? I have cross mounted
> > servers, same users on all, and many of the uid's
> not
> > matched!! I need to re-org. Would like any words
> of
> > caution or proper way to proceed. Current i was
> > devoting time to perform it manually, one by one
> (bout
> > 60 users!!, *3 machines=180 possible
> modifications)
> > Manually means change uid first, then find all
> files
> > owned by the precious uid, and chown for them. I
> want
> > to re-org the uid's per gid
> > ie. users primary group=200, then uid's =2000++
> I don't have any brilliant ideas for fixing this.
> (hopefully someone else out there does!) But,
> once you get everything straighted out you should
> probably look into distributing your user accounts
> to all of the systems so that this doesn't happen
> again. Once you get it set up, it should also make
> administration easier because you'd only have to
> set up each new user account in one place rather
> than on each system. NIS still seems to be a
> pretty popular method for distributing account
> information. LDAP is the contender that I know
> of, but I'm not sure if it is available for V4.0*
> systems.
>
> >
> > =====
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
=====
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
Received on Thu Nov 08 2001 - 13:44:32 NZDT