[SUMMARY] Preventing application account access

From: Roberts, Blake (broberts@ercot.com)
Date: Thu Aug 15 2002 - 16:40:57 EDT


Thanks goes to Chris Ford (Chris.Ford@acxiom.com)

To do this properly, there is no easy way. You have to make an addition to the profile of each user (will probably add it to /etc/skel) and call a script which reads a file similar to /etc/securettys. I tested the solution, and it works like a champ!

Best regards,
--Blake Roberts
UNIX Systems Administrator
ERCOT-Austin
512.225.7178
512.695.5071 (cell)

-----Original Message-----
From: Roberts, Blake
Sent: Thursday, August 15, 2002 1:42 PM
To: Tru64-Unix-Managers@Ornl. Gov (E-mail)
Subject: [ADDENDUM] Preventing application account access

I forgot to mention, I have sudo installed on the system, but I have not found a way for it to prompt me for the password of the administrative account. Since, by default anyway, it prompts for your own password, if the user's password is compromised (by writing it down and leaving it on their desk, etc), there is no way to keep people away from the big accounts.

--Blake

-----Original Message-----
From: Roberts, Blake
Sent: Thursday, August 15, 2002 1:32 PM
To: Tru64-Unix-Managers@Ornl. Gov (E-mail)
Subject: Preventing application account access

Folks,

I'm running a Tru64 5.1 PK5 Enhanced Security environment. Per a new (and decent) password policy that is being implemented, I need to restrict the application admin accounts so that they will su from a personal account to the administrative account (such as oracle), similar to what you need to do if root is locked down properly.

My problem is, in base security, if I lock the account, you can log in as a user, then su to it just fine. In enhanced security, you can't do that. It needs to be unlocked to be able to log into it. Does anyone know of a trick, edauth flag, etc, that needs to be set for the account to be able to be su'd to, but not directly logged in to?

Best regards,

--Blake Roberts
UNIX Systems Administrator
ERCOT-Austin
512.225.7178
512.695.5071 (cell)



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:49 EDT