Slashdot Mirror
Cross-platform Password Management?
Martin Blank writes "I work in a NOC, and one of the debates you will find in any strongly-mixed environment like this is preferred OS. We have people who prefer Windows, some who like Linux, and some who do almost everything on Solaris boxes. However, this also means that much software is not available over all three. With all of the servers, routers, and various other protected systems we have, the sheer quantity of passwords is mind-bogglingly difficult to keep track of in a secure fashion. Are there any packages out there right now running on at least Windows and Linux, and preferably also Solaris, that can access a central password file?"
Look into Kerberos. About the only thing that has kept us from going full Kerberos is the lack of support on the Windows commercial SSH client (the one from ssh.com). It might even be there now, I don't know. I think some of the free clients support it though...?
My school (Mount Royal College) uses a LDAP database to store the user's passwords. It works with all their windoze boxes (95,98,NT,2000) AND their Red Hat system they teach programming on.
Might be worth a look. They use PAM on Linux, and Novell client on Windows, and the mac.
God save our Queen, and Heaven bless The Maple Leaf Forever!
Create a box running Apache SSL and have it firewalled / protected like crazy and locked down with LIDS or the NSA patches to linux. Use this box as the "password server" and have access to each and every password logged. And have each NOC employee be part of access groups that say "router access" or "colo access" or something so they can ONLY access data available for their group.
On the logging tables in the database, make sure they aren't readable or writeable by the web-user. They should only allow INSERT queries.
This might be the best way.
x
Ever need an online dictionary?
Have fun.
Pat
At University of Michigan they use kerberos for (almost) everything. Basically only the kerberos server has the passwords. I believe that when you want to log into a machine you actually get a ticket from the kerberos server, and the ticket is what is used for authentication.
As a user I find it pretty convenient. I think it's pretty straightforward from an admin standpoint too, but I wouldn't know from experience.
Have you looked into using smartcard technology.
I realise it isn't very pratical adding smart card readers to every machine..but im just starting to look into smartcards on *nix and the msucle project seems to suggest that you can roll smartcard verification into your login procedure.
http://www.linuxnet.com/apps.html
I'm just psyched that i got my citbank serial port smartcard reader up and running under the pscsd smart card daemon. Now i can play around with this very idea.
-jef
Suprisingly, it seems that almost everything out there has Kerberos support these days. I'm going to start an experiment soon to see how well this works with Windows, but some of the websites seem to indicate that there is a reasonable amount of cross-functionality.
Does anyone else have actual experience implementing Kerberos in a mixed Unix/Windows environment?
Linux is UNIX.
I just attended a network security seminar at a small university in Virginia this past week. I manned the booth for my company, but between rush times I spent most of my time speaking with the people (sometimes competitors) from other booths. One of the engineers at another booth was kind enough to give me an RSA SecurID demo box with two key fobs and all the software I needed to set up a server.
Within an hour of arriving back at my hotel room, I had the software up and running (had to download the Win2K agent from the RSA website), and my login to my laptop was secured via SecurID. Once I arrived home last night, I set up the server on my home network, and now all of my workstations and server (Linux included!) are using RSA SecurID login.
You can run the server on NT/AIX/Solaris (probably more by now because I have an old kit), and there are agents out there for just about any operating system. In addition, you can have routers access the server as if it were a TACACS+ or RADIUS server.
Check the RSA website for more information. The part you'll care most about are the agents (client side of the equation), and I know for sure that there are agents available for Windows, Linux, and Solaris.
Good Luck!
-- Stu
/. ID under 2,000. I feel old now.
It is extremely cross-platform compatible
Sig: What Happened To The Censorware Project (censorware.org)
The thing your looking for is called NIS. A vastly oversimplifed explanation of NIS goes something like this: An NIS-capable host is a system where passwd and group information is kept, and subsequently "pushed" to other hosts. Users log into local machines, the local machines reference their latest NIS maps, and log you in based on that. Its not difficult to set up or maintain, no more difficult than handling localized passwords, at least. Look into it.
NIS is what Sun used to call YP, or Yellow Pages. Pick up a book on NIS administration, and knock yourself out.
I'm sorta surprised this ended up on Slashdot. You'de think that a predominantly Unix-reading crowd would have rejected this one flat out due to it being so obvious.
Bowie J. Poag
In the past I have very sucessfully used PGP for password management. I set up a shared fileserver (in our case it was an NT server, but it could easily be Samba or NFS), then create a text file with all the passwords in it, encrypted against everyone's public key. All users were then able to access these since since PGP was (and still is) available on multiple platforms.
_______
2B1ASK1
NIS???
Maybe it will solve the single logon problem, but it's a nightmare from a security POV.
Type "ypcat passwd" on a NIS enabled box, you will see what I mean...
CU Micha
Linux and Solaris are pretty easy to accomodate with PAM.
Microsoft also makes a product called "Services for Unix" which will (among other things) make your Active Directory Domain controller act like an NIS server so you can setup Linux/Solaris boxen as slaves.
Just make sure NOTHING transmits password across the wire in clear text. If everything uses the same username/password, a simple packet sniff can conpromise the whole works!
Security experts always say: 1.passwords should be 8+ characters 2.passwords should look like they were randomly generated (esp. no English words) 3.never write your passwords down (WHICH INCLUDES USING A PASSWORD MANAGEMENT SYSTEM). Personally, I usually follow rules #1 and #2, but there is no way I can memorize a 10+ randomly generated strings. Aren't security experts being a little hypercritical?
The way I understand it, UIUC is skipping Kerberos in favor of a new authentication system that they're developing. It is based on an advanced, self-aware AI technology, and it uses a voice-only interface.
It was supposed to be deployed last year, but they are having problems with the beta systems; one system that controls pod bay doors has been especially trouble prone.
Novell hasn't gotten much right except their directory services. By far, Novell NDS/E-Directory is the best you can get in the industry. If you just want password management, openldap is good enough. However, if you want better user/group/server/services/application management, give eDirectory a shot. There's nothing else better to manage mid-enterprise corporations. It really does kick ass.
I apologize for the lack of details but I don't know any of the specifics on whether or not it is a central password file or different servers all keep a current copy of the same file.
:).
They use a program called actmaint, which I think is custom written. What happens is when you change your password using passwd at a unix prompt, it activates actmaint to go and propagate your password though all the Sun systems, all the Windows NT domains, all the Windows 2000 domains, and the custom NIS authentication (how do they authenticate the Macs to a Sun box, hmmm?) and other Unix systems across campus (like the engineering machines) that are linked to your password. This allows the regular Purdue network to be kept separately maintained from say, the engineering systems, but allows you to have a common password for conveinence. How does PC-RDist fit into this? It doesn't as far as I know; it is activated when a reboot is initiated to keep the hard drive data in a consistent fashion (i.e., all data you added is removed, all data you changed / deleted since login is replaced). Try the new WinXP stations to prove this; you have to login to a domain controller before it can auth you to a Sun box. _That_ may be using kerberos, but as fas as actmaint goes, it's not using kerberos tickets cause there are a significant number of Windows NT 4 machines out there (like the ones running student services...) that the passwords have to sync to, and kerberos didn't come out till Win2k.
But like I said, I think actmaint is an in-house custom written program, so your argument is moot
I attended an event in November 2000 hosted by Collective Technologies called Shared Authentication Solutions. Collective Technologies developed an in-house solution permitting single sign-on and application control. The tools used were:
1. Win2k password server running Active Directory (which is really LDAP, with a twist) and the M$ bastardized version of Kerberos. Collective Technologies extended the Win2k password file with Active Directory to contain the usual UNIX password fields and the ACLs for each application.
2. Solaris and RedHat Linux boxes running Kerberos, PAM, and LDAP.
3. NT and Win2k boxes running either NTLM or the newer Win2k Authentication client.
Once a user logged into any session on the Collective Network, they had instant, secure access to all the resources they were supposed to have, and no other.
The only downsides to this entire setup I could see were:
1. The authentication server ran on Win2k and not UNIX.
2. The weak link in this chain was the Win2k authentication server. Collective Technologies suggested that their implementation relied on physically securing this one box in a locked server room.
I was unable to find information on the Collective Technologies web site about this presentation. Please contact me if you would like more information and I'll try to dig up the documentation provided by Collective Technologies.
"I'm The Bounty Bear. I will find him anywhere. I'm searching."
We currently use 3 headed Solaris Boxes, and for windows we use citrix. We use NIS and NFS to mount a shared binary directory. We have a program we run from a command prompt that will give us the username/password. You can only see the command from the shared directory, and its not shared with non-noc people. It reads a file thats encrypted and not readable by the user. You cant copy the encrypted password file to your local workstation.
.dat file (encrypted) on a windows share. The share is only available to the engineers. Like any program, if you use weak passwords, you can do a dictionary attack on it. Winsafe is freeware.
We do regular updates to passwords on routers/servers/etc. So we just update the file. Our NOC doesnt have root on the servers, they log into with a program that controls the permissions, kinda like sudo with server based auth. I dont want to mention the name of the program on slashdot...
For our engineers, we use a program for windows called "WinSafe" that loads a shared
Basically, a client program that reads an encrypted password file on an authenticated non-shared resource over an encrypted channel.
-
I have left orders to be awakened at any time in case of national emergency, even if I'm in a cabinet meeting. - Ronald Reagan
Well, I shouldn't complain, since you helped me find the Redbook web site. But you have to admit you're just barely on-topic. And it would have been more useful to point to the main page for this Redbook, which includes various useful links, including an HTML version, the FTP directory for related files, a place to submit review comments, and other good stuff.
I think Pat Jensen has really got some good advice here. At SST, we're slowing moving to a "universal login" system for our Web sites. There are about 5 internal & external sites, each requiring different usernames & passwords. Our solution is to set up a MySQL database with login data and nothing more, and then each Web site will check for a cookie (MD5 hash with IP addy, so the cookie is difficult to spoof). Since all our sites operate under sst.com, they should all be able to view the cookie and verify it.
However, and as an inevitable side-effect, people are now asking why we can't use that same system for NT logins and Outlook and yadda yadda. If we had chosen LDAP, this would have solved the issue, as LDAP can be plugged into a bit more than MySQL can. We will still do this, it just means we have to revise, revise, revise. I have yet to look into how well PHP and ASP support LDAP, and just how much LDAP can do, but it appears to be much more in line with our needs. Can anyone speak definitively about what PHP and ASP and NT and Outlook can do with LDAP?
My Greasemonkey scripts for Digg &
LDAP is a great idea, but it's only half of the problem - it specifies the cross-platform interface, but not the database to store that information in. OpenLDAP sounds like a step in the right direction.
MS has their ActiveDirectory that fully supports LDAP, but the database is very Windows-centric and you'd be taking on all of Microsoft's security issues related to hosting ANYTHING on a Win2K server.
Really, seriously, definitely have a look at Novell eDirectory (a.k.a. NDS) as your foundation - replicas of NDS partitions can be *hosted* on Solaris, RedHat Linux, Netware, NT and Win2K (note: you do NOT NEED A NETWARE SERVER ON YOUR NETWORK TO RUN eDIRECTORY! :) You can use the proprietary Novell client software for various OSes to access this information, or make standard LDAP calls to it.
NDS (the database part) is dynamically extensible, totally replicated (for performance and auto failover) & almost completely automatic... very little maintenance is required. It supports hooks for almost all OSes for authentication (look at Novell Account Manager for Linux & Solaris, for example) and directly supports smartcards/biometric/SecurID/etc. It's "light" meaning you wouldn't have to dedicate entire servers to host the information. The security is awesome and the you get very fine-grained control over everything. It's relatively inexpensive these days, too. (You can practically get it for free if you're a developer - check the website for a free eval copy, too)
These days, Novell also has all sorts of whiz-bang products (i.e. DirXML) that integrate with eDirectory - do bulk-loads or automatic synchronization of other proprietary directories using your own XML interfaces. They even have a bunch of tools & apps that let you take existing apps and set them up as "single sign on" so you don't have to keep track of multiple passwords for multiple databases.
The other advantage is that Novell has about ten years of lead time over everyone else's directory implementation right now.. I'm lucky enough to have had a chance to play with NDS on several large networks and continue to be amazed at the technology behind it.
more info: http://www.novell.com/edirectory
I see many folks saying to stick with just kerberos, or just LDAP or even Active Directory. I work at a largish university and had to come up with a roll your own solution a while back mainly due to political reasons (the NT group would only use Active Directory, the UNIX guys wanted Kerberos, the dialup used Cisco Secure, other systems stored digested passwords in an oracle table, some things required LDAP, etc., etc.) What we decided on, and what I wound up writing was a bunch of perl code to synchronize ALL of these different schemes. We have upwards of 50k users, and we've been using this for 3 years now with no problems.
Then again, this is a university where we basically provide services that faculty request and we don't have the luxury of not using software x because it uses authentication scheme y and we only support authentication scheme z. If you have a situation like this, it isn't that difficult to come up with the glue you need.
It sounds like you need to break out your authentication from your authorization a little. Unless you need to replicate user records for availability reasons, keep them on the master servers. On your LDAP servers maintain a group containing a list of those users that are permitted access to your systems. Link them together using LDAP referrals (main organizational server delegates to your server for your organizational unit, and your server refers unknown requests to the main server).
When the user tries to log in, they'll be authenticated from the central servers, and authorizated to use the servers based on whether or not they're in the group.
However, directory services are better suited than classical RDBMSes, because they are optimized for fast lookups. An RDBMS in contrast focuses on concurrent updates - all this ACID stuff is basically not needed if all you want to do is providing authentication services (as long as you don't frequently try to update your password from 10000 workstations at once).
Programming can be fun again. Film at 11.
It is a bit difficult to get working, but it is "strong", centralized, password and user management.
The only thing I've found missing from kerberos, is simplified high-level documentation in a cook-book format for different ways of implementing and administering the KDC and the realms.
Fortunately I'm working on such documentation, and it may become part of the FAQ. After I make some adjustments, maybe it will.
--SuperBug
Password management like this is a nightmare. Some of the options suggested (LDAP, SecurID etc) rely upon the system you are accessing being able to talk to an external authentication system of some sort.... which means you're up a certain creek in a chickenwire canoe if that facility isn't working.
SSH with RSA keys. Change the management problem into the simpler (and more scalable) one of managing RSA public keys on the boxes (which can be automated).
Job jobbed.
Even if you can control the logins on the major operating systems, your users will still encounter other passwords everywhere. I think rather than trying to control the uncontrollable, a better solution is to get them Palm Pilots with encrypting password managers.
Samba is well known for its ability to act as an NT File/Print server, but it can also act as a primary domain controller. I believe that its PDC capability along with its Unix Password Sync functionality will allow you to accomplish most of what you want. Alternatively Samba also comes with windbindd which allows you to have your Linux and Solaris clients participate in an NT domain.
With Unix password sync, you are likely to be tempted to use NIS to distribute your passwords to your Linux and Solaris clients. While that would work just fine, NIS is known for its lack of security (search for my other post on this subject). If you use NIS initially (potentially to integrate with your existing NIS environment), consider shifting over to LDAP. Samba 2.2.x has had significant work done to provide integration with LDAP. Check the docs for the latest release and the samba mailing lists for details.
Check out PasswordCourier (Warning - Flash required). I know it works well - I work there :-).
Use a phrase to generate a suitable password. Try and use a phrase that has something to do with the system. For example, a server at a company office. "This building has 8 floors and 3 elevators" could generate "tbh8fa3e". Not bad. We can improve it by adding caps and some substitution: "TBh8f&3e". Now we have a password with mixed case, alpha-numerics, and non-alpha-numeric characters with a random appearance. And it has meaning to the user in the form of a phrase that can be remembered and repeated to regerate the password.