Suggestions for Company Wide Password Vault?
androidtopp asks: "My company, an IT and business consulting firm of around 150 people, is looking for a Password Vault/Manager/Database solution to manage the numerous passwords we've developed in the course of a major internal network and server upgrade. Our must haves are multiple privilege levels (I don't need to see network passwords, and the network guys don't need to see database passwords, and so on) and it would be nice if we could view when people last retrieved each password. Does anyone manage passwords in this fashion at their work/home? A lot of the free password managers are one user, full access, which is a little less secure than we need. How do other companies (small or large) manage the hundreds of server, network, database, and application passwords that must crop up?"
Um, no. That idea is the central idea behind Active Directory and Novell eDirectory. Its much easier to secure one thing, than lots of excel spreadsheets, stickies on monitors, etc..
At my company, we have been working to get everything integrated with Active Directory, so there is only 1 password to manage. Redhat boxes will authenticate against an AD domain now. Just a few more apps to go.
Another solutions is the Microsoft Identity Management server (I think thats its name) that you can actually script password changes. For example, a user does Ctr-alt-Delete and changes their password, then the IM server grabs that, and you script it to connect to your DB, log in as the user, and change password, do the same for web pages, etc. Looks pretty sweet, but we can't afford it.
What are we going to do tonight Brain?
There is this: http://thycotic.com/products_secretserver_overview .html
http://www.openntf.org/Projects/pmt.nsf/ProjectHom e?ReadForm&Query=Open%20Notes%20Picture%20Database
It's written by Christian Brandlehner, Jason Engel and Hynek Kobelka. Encrypts the password for the chosen people. Requires the Notes ID to get to it. Very secure. You can control who gets onto the server, then another list of who can get into the application, and finally a third list of who is allowed to see each individual password. The passwords are stored in an encrypted format (for each ID file), so cracking the server does you no good. You can allow everyone in the company access to it, but without the document being encrypted for their ID, they can't tell what the password is. VERY secure.
Since the Lotus Notes client has just been released for Linux, all y'all zealots can't complain as much, though I know the "Lotus Notes UI sucks" people will swarm out of the woodwork.
Oh well. It's good enough for IBM and the CIA to use.....
I've used Cyber-Ark's Enterprise Password Vault, it seems extensive as for what it can do. http://www.cyber-ark.com/datasecuritysoftware/ente rprise_password_vault.aspCyber-Ark's website
http://www.debian.org/doc/manuals/reference/exampl es/_vimrc
which will automatically encode/decode .gpg files. If you're daring that is.
If you're going to do that, it really shouldn't be on line. While I agree that someone needs to be able to get to the "God" passwords in the event of a catastrophic event, our solution to that is very low tech. They are written out on a sheet of paper and placed in a slightly special safe. It takes two keys to open and only a few of us have keys. Some of us have the A key and some of us have the B key.
That way if any of us needs a password to which we do not normally have access, we still have to convince another person to help us open the safe. It provides a secure check & balance with very little inconvienence other than filing away a new sheet of paper once a month.
2 cents,
QueenB
HDGary secures my bank
Seems to me it does everything you need and then some.
UNIX? They're not even circumcised! Savages!
3. Passwords must be changed every 90 days (maximum), and there must be a certain length of time before the same password can be reused.
If you want to piss someone off, use a password generator to create a random password whenever the password has to be renewed
While I change mine frequently, and make it extremely random, those two things are going to cause greater insecurity for most of your users. Why? Because they are going to put post-it notes on their desks with the passwords on them, because they won't remember them otherwise. Those two things should make the network more secure. In reality, they don't.
And at my business, we use Novell's eDirectory 8.8.1 product running on SuSE Enterprise Linux 9 and Novell Identity Manager to synchronize passwords in real-time (event driven) to Active Directory, other Novell eDirectory systems, Oracle and MS-SQL databases, PeopleSoft and other systems, some in different cities, all secured with SSL connections. Our system holds over 300,000 accounts, with about 60,000 of those being active. I think we expire about 300 passwords a day on average.
A recent Infoworld article ranked it very highly. Novell Identity Manager is very flexible and powerful product and I highly recommend it, especially if you're not a huge fan of Microsoft. Storing passwords in a centralized system is a valid solution as long as your "identity vault", to borrow Novell's term, is properly secured. Personally, I could never feel safe storing all our passwords in Active Directory. Besides all that, I don't have to worry about the critical security patch of the week since it runs on Linux.
Ouch! The truth hurts!
There's a script wrapper for this, it's called escrow... We've used it for a while and it's really quite handy.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Like me, he probably needs some way to make rarely-used passwords accessible to the staff who need them along with a record of which of those rarely used passwords have to be changed when an employee leaves.
For example, I have switches, routers, PDUs, servers, etc. On the servers I have root passwords, database passwords and so on. The sysadmins need the root password to do a fsck on bootup but that's about it. The rest of the time they use sudo with their own password. The application guys need the database root password once in a while, but only to their servers.
It would be awfully darn convenient if I could say, "Here's a URL and your password to the password keeper. Every password you should have access to is there." Then when an employee leaves I could go to the same password keeper and say, "Show me every password this individual accessed so I know which ones to change."
It would also be very convenient if when my sysadmins finished a new server they had somewhere to log the password in so that the next guy who needed to do an fsck knew where to find it.
Of course, we could just use the same password on everything... But then we're S outa luck when the app guy needs the password to two servers and nothing else.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Greetings,
We did this with a physical vault. Each machine's (routers, servers, kerberos domain key (actually stored on a usb key), etc) was generated randomly and printed out and put in a sealed envelope in a fireproof, keyed safe kept in the NOC. They key for the safe was then put in a key lockbox and locked with an "electricians lockout tag" which allows multiple padalocks to lock the same hasp. All padalocks need to be opened to open tke keybox. We used two keys (enforcing a two-man rule) and a security seal. The only way to open it was to open the two padalocks and break the security seal. The security seal number was recorded in the site log. Every shift change, the keys were passed to the site supervisor and another senior person and the security seal checked to insure that the keybox hadn't been opened.
Any time a root password was required the safe was opened (and the fact logged), and the correct password recovered from it's envelope. After use, a new password was generated and placed in a new envelope. At each safe closing, an inventory was taken to insure that all the envelopes were there.
A bit paranoid, but we certainly passed our auditors requirements.