dcb@dave.mis.semi.harris.com (Dave Brillhart) (03/07/91)
This weekend, we are are planning to enable the ENHANCED security features
on our 2 5830's, a 5820, and a 5500. Currently we are only using the
standard BSD security [features?] with a seperate host file and passwd file
on each (acutally 2 are trying to use YP). We are also planning to run BIND/
Hesiod and Kerberos in an effort to use a secure single host file and single
user authorization file for all systems.
We've run across a few gotchas before this weekend, like:
o All passwords become invalid and are non-recoverable.
o You cannot su to a priv account from a non-secure terminal.
I'm sure this will be an interesting weekend. If anyone can save me a
a few late night hours with tips/hints/suggestions/..., I'd appreciate it.
-- Dave Brillhart
Harris Semiconductor
Palm Bay, FL
(407) 729-5430 grr@cbmvax.commodore.com (George Robbins) (03/07/91)
In article <1991Mar6.212110.22576@mlb.semi.harris.com> dcb@dave.mis.semi.harris.com (Dave Brillhart) writes: > This weekend, we are are planning to enable the ENHANCED security features > on our 2 5830's, a 5820, and a 5500. Currently we are only using the > standard BSD security [features?] with a seperate host file and passwd file > on each (acutally 2 are trying to use YP). We are also planning to run BIND/ > Hesiod and Kerberos in an effort to use a secure single host file and single > user authorization file for all systems. I think you're real brave. Whoever thought that all unix security enhancements could/should be controlled by a single variable of three states should be taken out and shot... > I'm sure this will be an interesting weekend. If anyone can save me a > a few late night hours with tips/hints/suggestions/..., I'd appreciate it. Well good luck. I'd suggest getting it all working between a couple of workstations and after you get all the bugs out, trying to switch over the larger systems. You're likely to get halfway done and then start finding the real problems and have to decide to take the long walk back or let your users suffer until your get it "working". -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
jch@hollie.rdg.dec.com (John Haxby) (03/07/91)
In article <1991Mar6.212110.22576@mlb.semi.harris.com>, dcb@dave.mis.semi.harris.com (Dave Brillhart) writes: |> o All passwords become invalid and are non-recoverable. Because they are stored somewhere else and using a different encryption algorithm. |> o You cannot su to a priv account from a non-secure terminal. Terminals can be "trusted" as well as "secure" The security features are hideously complicated (not a three state variable), so you will need a fair amount of luck. -- John Haxby, Definitively Wrong. Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch>
frank@croton.nyo.dec.com (Frank Wortner) (03/08/91)
The password file change-over is a little bit less traumatic if you go to UPGRADE security rather than enhanced. The system prompts each user to select a new password at the next login. One benefit of this feature is that it lets you know whether or not someone is actually using an account. If the password hasn't migrated from /etc/passwd to the auth database within a reasonable period of time, you know that the account hasn't been used recently. Frank
poirot@aio.jsc.nasa.gov (Daniel T. Poirot) (03/08/91)
We enabled Enhanced security under Ultrix 4.0. Rules here say if you have it, you have to use it. I was suprised by the number of things that broke. Any programs that try to check a password are going to break. Calls to getpwent(), getpwnam() or getpwuid(), for example. Also, password entries are encrypted with a different routine, so calls to crypt() with the password aren't going to match what eventually comes back as the password. The affected programs all came out of the shadows within a month or so. Daniel Poirot poirot@aio.jsc.nasa.gov Lockheed C07A "The mind is a terrable thing." 2400 NASA Rd. 1 tel: (713)483-8793 Houston, TX 77058 fax: (713)483-3204 -- Daniel Poirot poirot@aio.jsc.nasa.gov Lockheed C07A "The mind is a terrable thing." 2400 NASA Rd. 1 tel: (713)483-8793 Houston, TX 77058 fax: (713)483-6120