Shadow Password Usage/Install - Issues?

[D Block 2]

Have you installed HP's package: Shadow Password ?

Say, I'm really worried about the OS HPUX with RAC, in particular, 10g.. should I get the vendor Oracle's approval before I install on 11i Production using Rac 10g ? I would hate to break production or wait for a patch from an outside vendor..

Thx in adv..

BTW,

I've installed the package on two test systems, and no problems, but its not production environment running Rac 10g.

see:
http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword

also a thread under HP's Security Form:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=590554

[Jeff Schussele · Accepted solution]

Hi Tom,

We don't take that intermediate step - we convert to full trusted. Every system - period.
Have *not* had a single problem to date.
That covers literally hundreds of systems.
So my advice to you would be - don't mess around with the relatively new shadow PW - do the right thing & go trusted.
It's *much* more secure.

My $0.02,
Jeff

[Dave Olker]

Hi Tom,

I personally haven't played with shadow password support, but one thing I've heard that is different from Trusted Systems is that Shadow Password support will be integrated into NIS in a coming release, where as I've heard of no plans to integrate NIS with Trusted Systems.

Even if NIS is not used in your shop, my point is to get you thinking not only in terms of security, but of integration with your name server and authentication mechanisms. If you choose a security model, either Shadow or Trusted, be sure to understand the implications of integrating support for those security models with whatever authentication back-end name service you plan to use in your environment.

Regards,

Dave

[Gary L. Paveza, Jr.]

We only have a problem with one vendor. Robelle's Qedit product has issues with Shadow passwords. The vendor is aware of the problem and is currently working on a fix.

[D Block 2]

here's an update related to Database vendors: informix and oracle related to HP's Shadow Product on HPUX 11.11

After installing Shadow, the Informix database access users can not login. (The users come in via tcp clients and informix database authenticates via normal unix system login using /etc/password file.)

The Informix versions used are: 7.31 and 9.30.

The fix is simple: take the encrypted password from /etc/shadow and copy it back into the database user's account in /etc/passwd.

The other vendor: Oracle, apparently has patches to use Shadow.

[Jeff Schussele]

Hi (again) Tom,

Well that "fix" kind of negates the purpose of Shadow PW because the "standard" /etc/passwd is world readable whereas the shadow is not.
The purpose being that a "normal" user can't grab a copy of the passwd file, take it off system & run crack or John the Ripper against it.
Personally I've never seen Informix have a problem with the TCB (Trusted Computing Base) structure that a trusted system uses.
You might talk to Informix about using the authentication method on the HP version that they use on Sun because all Sun system utilize the shadow PW principle.

My $0.02,
Jeff

[D Block 2]

Does a "trusted" HPUX system have a file called: /etc/shadow ?

[D Block 2]

I decided to learn on my own:

- turned on Trusted via SAM and here's the difference when looking at file from /.

diff# diff /tmp/nontrusted /tmp/trusted
1264a1265
> /tmp/trusted
58015a58017
> /var/spool/sockets/pwgr/client4708
58017d58018
< /var/spool/sockets/pwgr/client4412
58018a58020
> /var/spool/sockets/pwgr/client4567
58053a58056,58057
> /var/spool/cron/.ataids
> /var/spool/cron/.cronaids
58377d58380
< /var/sam/ann.dion
58378a58382,58383
> /var/sam/sam_tm_work
> /var/sam/ann.dion
59496a59502,59506
> /.secure
> /.secure/etc
> /.secure/etc/audnames
> /.secure/etc/audfile1
> /.secure/etc/audfile2
59512a59523,59594
> /tcb
> /tcb/files
> /tcb/files/auth
> /tcb/files/auth/system
> /tcb/files/auth/system/default
> /tcb/files/auth/system/maxaid
> /tcb/files/auth/a
> /tcb/files/auth/a/adm
> /tcb/files/auth/b
> /tcb/files/auth/b/bin
> /tcb/files/auth/c
> /tcb/files/auth/d
> /tcb/files/auth/d/daemon
> /tcb/files/auth/e
> /tcb/files/auth/f
> /tcb/files/auth/g
> /tcb/files/auth/h
> /tcb/files/auth/h/hpdb
> /tcb/files/auth/i
> /tcb/files/auth/j
> /tcb/files/auth/k
> /tcb/files/auth/l
> /tcb/files/auth/l/lp
> /tcb/files/auth/m
> /tcb/files/auth/n
> /tcb/files/auth/n/nuucp
> /tcb/files/auth/o
> /tcb/files/auth/p
> /tcb/files/auth/q
> /tcb/files/auth/r
> /tcb/files/auth/r/root
> /tcb/files/auth/s
> /tcb/files/auth/s/sys
> /tcb/files/auth/s/smbnull
> /tcb/files/auth/t
> /tcb/files/auth/u
> /tcb/files/auth/u/uucp
> /tcb/files/auth/v
> /tcb/files/auth/w
> /tcb/files/auth/w/www
> /tcb/files/auth/w/webadmin
> /tcb/files/auth/x
> /tcb/files/auth/y
> /tcb/files/auth/z
> /tcb/files/auth/A
> /tcb/files/auth/B
> /tcb/files/auth/C
> /tcb/files/auth/D
> /tcb/files/auth/E
> /tcb/files/auth/F
> /tcb/files/auth/G
> /tcb/files/auth/H
> /tcb/files/auth/I
> /tcb/files/auth/J
> /tcb/files/auth/K
> /tcb/files/auth/L
> /tcb/files/auth/M
> /tcb/files/auth/N
> /tcb/files/auth/O
> /tcb/files/auth/P
> /tcb/files/auth/Q
> /tcb/files/auth/R
> /tcb/files/auth/S
> /tcb/files/auth/T
> /tcb/files/auth/U
> /tcb/files/auth/V
> /tcb/files/auth/W
> /tcb/files/auth/X
> /tcb/files/auth/Y
> /tcb/files/auth/Z
> /tcb/files/ttys
> /tcb/files/devassign
#


I'll have to say, linux rules in this situation. that TCB does not have: /etc/shadow file!

closed.

[D Block 2]

fubar