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?"

Comments

Doesn't that defeat the purpose?

[jroos]

It seems to me that a centralized password system just defeats the purpose of having different passwords. If you can compromize the password system, you've compromized everything.

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

And what if you can't?

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

The purpose is to *NOT* have multiple passwords. The purpose would be to find some secure centralized option so each person has *ONE* secure password.

Re:Doesn't that defeat the purpose?

[Malc]

Did you even read the story part of the way?

"the sheer quantity of passwords is mind-bogglingly difficult to keep track of in a secure fashion"

One of the important steps towards security and managing it effectively is simplicity.

Re:Doesn't that defeat the purpose?

[ltsmash]

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?

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

>The purpose is to *NOT* have multiple passwords. The purpose would be
>to find some secure centralized option so each person has *ONE* secure
>password.
>
>
There ain't no such animal and only a Microserf would think there was.

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

If you have used a password more than a few times, you should be able to memorize it. I use to work in a NOC and had to use at least 20-30 of these type passwords all the time. Its not really some hard feat. Maybe you should go see a doctor if you are finding this hard. There may be some underlying illness they can catch.

Re:Doesn't that defeat the purpose?

[BitterOak]

3.never write your passwords down (WHICH INCLUDES USING A PASSWORD MANAGEMENT SYSTEM).

Err, any password management system worth its salt (pun intended) will not store the plaintext passwords, but rather a one-way hash (eg. MD5, SHA, etc.) of the password. This would make it unfeasable to reconstruct the passwords if the system is compromised.

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

Last summer, I washed dishes in a Waffle House. The cook could remember orders for 60+ people, their order (as in fifo), and the grouping, but he was a stupid mother fucker. Another example; my great grand mother could not read, but she did not forget anything---phone numbers, appointments, shopping lists, or anything else. Contrast thoes observations with PHDs who can't remember anything without an notebook, or PDA, and it becomes obvious that the ability to remember useless bullshit is inversly related to the usefull knowlage in ones head.

Re:Doesn't that defeat the purpose?

[vipw]

Having passwords written down isn't a bad thing; having them written on a post-it note on your monitor is. :)

Passphrases for things like signing keys and such are often kept in a bank vault. Passwords like those are very long though and nearly impossible to remember. The ideal solution is for no unauthorized parties to have the password, but that can't be guaranteed just because it's a long random memorized password. Usually the best you can do is make it so your password can't be found without you knowing about it, and that can be done with written passwords that aren't left laying around.

My method is to have the password in written form in my wallet for about 10-20 uses, after which I'm confident I won't forget it and then I eat or burn the paper.

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

Err, any password management system worth its salt (pun intended)

I'm not getting the pun, enlighten me...

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

I think the password managment system the parent poster was referring to is a personal one that keeps track of your passwords for you, so that you "never write your passwords down". Any such system should definitely encrypt that data, but if it did a one-way hash it would have no way of reminding you of your passwords.

For the type of password managment system this piece is about though, something that actually processes authentication, you are right. The password should not be stored in any way accessible to the system doing authentication. Those should be one-way hashed.

Re:Doesn't that defeat the purpose?

[MadCamel]

Perhaps they are.. But Can you remember 10 phone numbers? If so, you can remember 10 passwords. Once you are up to a certian number of passwords, you can do neat tricks like interleaving them to generate a new password. A simple example would go somthing like this.. You have 10 passwords you know by heart,and you pick two of them:

s3k0Ic$a and f^lPcZtt

You could derive a password such as:
sf3^kl0PIccZ$tat

And not have much problem remembering it (alternating chars between two memorized passes)

I'm sure you can think up more tricks. Personaly, none of my self-chosen passwords are written down, Passwords that are chosen for me, however, are a completely different matter. I keep them stored in simple code, on a notepad, in my home office (Nobody ever comes in here..)

Re:Doesn't that defeat the purpose?

[BitterOak]

I'm not getting the pun, enlighten me...

Well, frequently, password management systems which store one-way hashes of passwords add some randomly "salt" characters to the password before running it through the one-way function, and then store this salt with the encrypted password. This makes it more difficult to use a pre-compiled dictionary to attack badly chosen passwords. The original Unix passwd file did this, for instance.

Re:Doesn't that defeat the purpose?

[Radical Rad]

Of course that is true, but having a dozen hard to remember passwords can be a huge impediment to efficiency. The need for a centralized system is evident in the number of systems to provide just such a thing. Unix has had NIS/Yellow Pages for a long time. Novell followed with their NDS and recently with SSO Single Sign-On which ties in third party systems to NDS. IBM also has software to consolidate passwords but I can't remember the name of it. Microsoft used "domains" for their directory system, tieing multiple servers together with the same password database. So basically, others have already thought about what you said but have decided that the benefits outweigh the drawbacks.

For cross platform password management, chech out Novell's NDS. It is light years ahead of their competitors and you don't even need to run Netware. You can host it on Linux only if you are a web hosting service or ecommerce site. They have been developing it since 1992, I think, so it is a very mature product and free for developers too.

Re:Doesn't that defeat the purpose?

[Quirk]

Aren't security experts being a little hypercritical?

Security experts are perhaps among the most susceptible to being brought up in front of their peers, official bodies and, most fearfully, their clients for being lax in discharging their responsibilities. Anyone, (speaking as a Canadian), who has practised in a professional capacity is painfully aware of how open they are to litigation or loss of a client base. Some form of Errors and Omissions insurance is often a prerequisite for professionals and the premiums paid are a recurrent reminder of how open the practioner is to being sued. As an aside, if software is seen to be a service then software developers should not only have to carry Errors and Omissions but should be as liable as any other Engineer or professional whose work is relied upon to meet specified tolerances. It is for these reasons that professionals are so easily characterized as comically anal and hypercritical.

cheers

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

That's a good point, but take it one step further - signing keys are split into at least two pieces and kept in secure disparate locations, and are not entered by the same person. If it needs to be used, person A puts in the first part, destroys their written copy of the key, then person B enters and repeats the process.

Note that this is for automated systems (eg. the master encryption key for a financial transaction database, which itself is only half the true key, the other half of which is compiled into the application) - this mechanisim is obviously fairly unworkable for your run of the mill authentication purposes.

Re:Doesn't that defeat the purpose?

[mmusn]

WHICH INCLUDES USING A PASSWORD MANAGEMENT SYSTEM

What makes you say that? A correctly encrypted password management system makes security better because it allows you to choose lots of different good passwords for different accounts.

Re:Doesn't that defeat the purpose?

[Anonymous Coward]

Security experts also state that too many passwords is not a good thing, either. This LEADS to writing down of passwords. Perhaps people can remember 3 passwords that change once every six months or so. Add any to those numbers and people start writing them down, which is worse than having one one or two passwords.

Re:Doesn't that defeat the purpose?

[uberdood]

The problem with the 8+ theory is that NT passwords are stored in two 7-character blocks. More than 7 characters nets zero benefit on Windows platforms - at least from a brute-force standpoint.

Re:Doesn't that defeat the purpose?

[gentlewizard]

I disagree. The reason for multiple passwords is historical: each system was an isolated island that had to create its own security checking routines. With everything more and more interconnected, it just makes administrative sense to centralize authentication. Thus the term "single sign on," or SSO.

Now IMPLEMENTING that is a challenge. There are various approaches, such as NIS, Kerberos, RADIUS and LDAP directories with X.509 certificates. We're not there yet but getting closer.

Re:Doesn't that defeat the purpose?

[Rob Kaper]

there is no way I can memorize a 10+ randomly generated strings

The don't have to be randomly generated, they should look like it. It's not that hard to come up with a string that is easy to remember yet hard to guess.

Kerberos

[Anonymous Coward]

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...?

Re:Kerberos

[Woody]

the client doesn't have to support it - only the server... when you ssh to a host, an encrypted tunnel is created. when you send the password, it's authenticated using kerberos if your ssh server is set up to use it. we're doing exactly this at the place i work, and it's a godsend... there are no plaintext password or shadow files anywhere, only kerberos authentication. very clean and nice.

Re:kerberos

[Wicked Panda]

I work at a major ISP and hosting firm (the grand daddy of them), and when I started a couple of years ago, I had to learn all about Kerberos, since that is what they used for all their authentications.

Good points

Single password gives a key token allowing you onto servers that are in that realm (say, all of your web farm). It is a time limited ticket, so you don't have problems with people leaving windows open all the time. All traffic is encrypted, and there is a single point for password management.

Bad points

Single network location for athentication - if you can't reach the master KDC, or the backup, then you can't go anywhere. If your farm and network are global, this can be a bitch. You have a token stored on your system.

Why is the last bad? Well, we have a case where a developer was managing his own workstation, and not doing it securely. Someone cracked his box. The cracker could not get a ticket himself from the KDC, but whenever the developer got a ticket, the cracker could piggyback off of the valid ticket. He got access to a whole farm of BSD machines via the developer's valid Kerberos ticket. We are currently looking at OpenSSH connecting to servers, who then have Kerberos'ized PAM, that then authenticate the user. A little bit better than klogin. In some areas we are strictly using key based SSH access, with keys disted at need.

Just my 2 bits to the discussion.

Re:Kerberos

[Anonymous Coward]

Ah, but if the client fully supports it, can you not use it in a SSO fashion? Like, you sign into your kerberos server on your main desktop login, and get all set up with tickets and stuff, and later when you try to SSH into a server, you won't have to put in a password. The client will just use the tickets already in use to authenticate to log in, all behind the scenes.

So you don't need kerberos in the client, but it sure makes it a lot handier..

Or am I missing something? I'm not too terribly up on the finer details of Kerberos..

Re:Kerberos

[sbrown123]

Kerberos is good.

For regular apps written in Java needing security use the Java Authentication and Authorization Service (JAAS). JAAS has a pluggable security model (modelled off of PAM) and already has a plugin for Kerberos authenication and authorization.

Re:Kerberos

[Woody]

this is true - if you want true single-sign-on abilities, you'll have to have a kerberos-enabled ssh client. sometimes that's not possible, though :) most (if not all) of our linux/bsd/irix/etc. clients are fully sso; the krb tickets are passed and verified so reentry of passwords is not necessary. very good point though. pam, kerberos and ssh have made my job about 500% easier...

anyone know anything about authenticating linux/unix clients to active directory? i haven't researched it at all, just seeing if someone has done my homework for me! this will be a project coming up in the next few months, so any pointers would be nice.

LDAP

[paulexander]

I seem to recall reading somewhere that someone has used LDAP to mitigate the insanity. Maybe start there..... Sorry I have no details

Re:LDAP

[bonius_rex]

When you are mixing different vendor's LDAP implementations together, be real careful about who gets to keep the passwords. IIRC Active Directory stores passwords in a goofy format that nobody else can use, so you will need a product like "Microsoft Meta Directory Services" or Novell's "DirXML" to keep things in sync.

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!

Re:LDAP

[Anonymous Coward]

What are schools teaching now that this person has never heard of Kerberos?

Re:LDAP

[Anthony Boyd]

LDAP is very scalable with an extensible schema, and can provide support for more then usernames and passwords.

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?

Re:LDAP

[Paul Jakma]

openldap has a mysql backend. so you could write the glue to export the mysql data via LDAP.

Re:LDAP

[Anonymous Coward]

i have not found LDAP to be the most secure method of trtansfering sensitive information. I personally wouldnt use it for anything other than email directory services.

Re:LDAP

[H20]

Both PHP and ASP can communicate with LDAP without a problem. Indeed, a surprising amount of free software in the *nix world can communicate with LDAP. I'll bet $5 that the distro you are running on has support for not only authenticating against LDAP, but also pulling service, public key, network, aliases etc. data from the server as well. On the Windows side, that much loved 'Active Directory' is nothing more than an LDAP server with a fancy schema and ranch dressing. You can bridge the gap with increasing success using the Samba development code or TNG branch built with LDAP support. As for Outlook, you get LDAP support in the form of a centralized Address Book that can be contained in the LDAP directory. This goes for many other mail clients as well -- Outlook isn't that nifty no matter what any one tells you. You could complete this recipe by integrating your favorite MTA and POP3/IMAP server into the authentication system (again, you'd be surprised at the amount of software that will build against LDAP) and quite possibly your DNS and RADIUS server.

Re:LDAP

[Anonymous Coward]

>MD5 has with IP addy

Are you talking about using the IP address as the salt? We did this and found it doesn't always work. Some people have load balanaced gateways, which causes them to come out different IP addresses.

Re:LDAP

[prsabc]

And you can use radius for your router's not sure of all brands, but hey buy more cisco stuff so my stock goes up.

LDAP and Novell

[dadragon]

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.

Re:LDAP and Novell

[crowke]

The best way to learn the basics of LDAP is to read the IBM Redbook (PDF) about this subject...

Re:LDAP and Novell

[Phigs]

At the college that I work at, we keep the account information stored in our ERP package. Then by using database queries and the magic of php scripting, create LDAP diff entries effectivly keeping our Windows and Novell networks current.
Although that method had worked for a good amount of time there were definatly possible security flaws that could be seen. With the advent of E-directory and Account Managment through Novell it has made my life much easier keeping my Linux, Windows, and Novell platforms with a curent user database.

Re:LDAP and Novell

[irony nazi]

I don't see anybody mentioning it here, but I use a disk-on-key to manage my passwords. The password files are stored in an encrypted format, and I have OS-X, Linux, and Win32 binaries stored on the key that will decrypt whichever file I choose based on some passphrase. The passphrase is the same for all password files.

The most common passwords, you will constantly use and not need the key for. The less common passwords, however will always be in your pocket, one USB connection and decryption away.

I didn't see any other mention of hardware implemented solutions so I figured I would throw this one out.

-irony nazi

Re:LDAP and Novell

[Anonymous Coward]

what? this makes no sense whatsoever.

Re:LDAP and Novell

[Anonymous Coward]

he's using the word "key" to mean "little thing on my keychain in my pocket". you can buy portable USB storage devices that live in your pocket this way.

Re:LDAP and Novell

[Big Diluth]

Not all console PC's have simple USB access (physically). Places I work at typcally have the workstation base not typically accessible (under console on shelf, behind door and monitor behind hinged window.

That's also assuming there is a USB port on the face of the machine and not on the rear only.

You could get around this using a USB hub, but what are you going to do if you are at another location without a hub (as in in another department meeting with other staff on a project) and the hub is not available? Or the OS on the workstation requires you to have a driver disk to read it (which is back at your desk)?

The token would be nice provided you are never away from a PC that can access it and that it is never lost or stolen. (Hope you have backups.)

The best method might be simple ...

[x-empt]

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

Re:The best method might be simple ...

[__past__]

How exactly does one use a web server as a "password server"?

Re:The best method might be simple ...

[um... Lucas]

Rather than go through the trouble of securing a linux box, one might consider OpenBSD instead? Seems like a very narrow task that it'd be well suited for.

Re:The best method might be simple ...

[pongo000]

How does this help each user keep track of a large number of passwords? What you have here is a centralized NIS-like database of passwords, but it does nothing to help a user remember what password goes with what machine. Also, this seems like an incredible security risk, putting all your chips down on the bet that you can create a super-secure password server that will never be broken. What happens if you're wrong, or make a mistake?

Re:The best method might be simple ...

[Anonymous Coward]

ln -s /etc/passwd /usr/local/www/data.default/AUTHENT ICATION

Re:The best method might be simple ...

[Anonymous Coward]

create a super-secure password server that will never be broken. What happens if you're wrong, or make a mistake?

What happens when people start writing down their passwords because they can't remember them all?

I would assume the poster had an idea about having just one password domain for the whole setup to avoid having to deal with just that problem.

Re:The best method might be simple ...

[Citizen of Earth]

How exactly does one use a web server as a "password server"?

Not sure, but you use one as a credit-card-number server by telnetting to port 1521 and typing "system/manager".

Re:The best method might be simple ...

[Anonymous Coward]

Who said anything about linux?

That's quite a complex you have there, perhaps you should seek professional help.

Re:The best method might be simple ...

[Anonymous Coward]

There is a difference. A Linux box with LIDS, even if the cracker gets root, the cracker can't do anything. LIDS takes total control away from root. Is that possible with OpenBSD?

Also OpenBSD and Linux are only as good as the services they run. So if there is a hole in OpenSSH or OpenLDAP, it doesn't matter if the OS is Linux or OpenBSD, a cracker can get root.

LDAP?

[Anonymous Coward]

HAve a look at LDAP

Migrate to Windows XP

[Anonymous Coward]

It does everything you need - Bill Gates says so.

Seriously, use PAM authentication, and use a module that will do authentication from a central machine - use Kerberos possibly?

Guess what, I don't know a thing about this topic.

Re:Migrate to Windows XP

[Anonymous Coward]

thanks for your help i spent my whole evening trying to figure out how pam. andersen authentication is set up from a central module using microsoft's extensions kerberoes and only then red your last statement. maybe i should listen to someone who knows about security like britney spears or microsoft.

Re:Migrate to Windows XP

[Anonymous Coward]

Not his fault your an idiot who can't follow instructions. (Part of following instructions is to read them completely.)

There are lots of ways to do it.

[Mordant]

LDAP, Kerberos, SecurID, NDS (bleh), Active Directory (double-bleh!), NIS+/Yellow Pages, RADIUS/TACACS, even. Unified cross-platform logon requires a bit of work, but it can certainly be done.

Go look for those terms on yahoo.com, google.com, freshmeat.net, et. al. You'll find there are many different ways to skin that cat.

Re:There are lots of ways to do it.

[Anonymous Coward]

Just the answer I would expect from an I/T person that wont answer question straight forward.
"Go look it up, I wont tell what I've learned"

LDAP

[PatJensen]

Any UNIX that supports PAM (Solaris, Linux, etc) can authenticate against Kerberos or LDAP. Both are also supported by Windows-based OS's and servers. LDAP is very scalable with an extensible schema, and can provide support for more then usernames and passwords. For dial access services, LDAP can also be integrated with RADIUS or TACACS.

Have fun.

Pat

Use the same password for everything

[Anonymous Coward]

What else needs to be said?

Re:Use the same password for everything

[logicnazi]

While this may sound stupid, why not? I mean you don't incur any additional security risk vs. using a password server (if any machine is hacked to which you later log in the hacker has access to all your machines). Yes if you try to change your passwords all the time this might get to be tiresome...but it would be alot of work to set up this server maybe it would just be better to walk around and change 15 passwords once a month.

Re:Use the same password for everything

[cicadia]

While this may sound stupid, why not?

As long as all of your password-authenticated services are controlled by the same authority (i.e., the same company), there is no problem with having a single password for all of them. It may even be more secure to have a single properly administered password database than to have each application managing its own database.

The reason security experts always tell you not to use the same password for everything is that most people have passwords for services from many different organisations, each with its own password database. If any of these databases is compromised, then someone may have access to all of your accounts.

As long as you have one identity in a single security domain, there is (usually) no reason to have multiple passwords.

Re:Use the same password for everything

[Anonymous Coward]

For one... in a large, distributed environment many, if not most, users are going to use the same password for all systems... Also, when you are in a network with 100+ systems, it is impractical to enforce password aging / complexity on all of them and make them all be different... the result of this would be people simply writing them down and sticking them under their keyboard... we are moving to an LDAP solution because once we have centralized authentication, we CAN enforce password aging and complexity...
plus, has anyone thought of the problem of how fast can you remove accounts when someone departs the company? On 100+ systems it can be a nightmare... and you always risk missing one... with centralized auth, you go to one place and that person no longer has an account on ANYTHING...

my .02

kerberos

[gtdistance]

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.

NIS?

[gnu]

NIS should handle all the unix hosts. Throw RADIUS or TAC+ for you network equipment and your set.

Now, I've heard of some projects to tie in NIS with Windows AD, but I've not seen much news recently. Wasn't it called gaynimead or something?

Radius resources...RFC 2865 and 2866.
www.open.com.au great perl based radius I've used before and it's great. Support TACACS and TAC+ to, for you cisco types.
www.funk.com is good, and livingston radius (now it's lucent) is decent also.

Re:NIS?

[lowar]

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

Re:NIS?

[typedef]

NIS isn't that bad, as long as you don't use it as the primary authentication service, and just use it to distribute user/group information across the network. On my network, I have the password field for each user in NIS set to something that dosen't map to a real password (i.e. +++) and I've configured PAM on all hosts to autheticate via Kerberos. Once they've obtained a set of credentails from the KDC, thier group, home directory, shell, etc is obtained from the NIS database. You can accomplish basically the same thing using LDAP to distribute the user/group information, and theoritically (I haven't tried this personally) you could get this all to work out of the box using a Win2k box with Services for UNIX installed. AFAIK, PAM ships on Solaris and most Linux distros, so implementing this on the client end of things shouldn't be too much of a problem either.

Smartcard systems?

[jspaleta]

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

Re:Smartcard systems?

[FreakOfTheWeek]

Take a look at devices like this: http://www.rainbow.com/ikey/
No added readers needed if you have USB.

Also, these come with relatively inexpensive readers: http://www.ibutton.com/

Overall, I agree that if practical, smart card technology is probably the way to go.

Re:Smartcard systems?

[Anonymous Coward]

It could be practical if the smartcart reader came with your motherboard, like it does with the Soyo Dragon+. I have this motherboard, and it includes Windows software for smartcard reader access. You almost fooled me into believing MUSCLE was exactly what I was looking for to revive my six-month-unused SCR slot, but it's nothing to be excited about. For they only aim to benefit one specific Unix distribution, this was definitely done just so they could have a cute acronym.

Re:Smartcard systems?

[jspaleta]

the project name is about as relevant as the misnamed linuxprinting.org website

read muscle frontpage
http://www.linuxnet.com/

Linux is the targeted development platform....but the goal is have a framework portable across the unix based OSes: Linux, MacOS X and Solaris are all mentioned right up front....they even offer binaries for Solaris 8 on sparc for the base pscs software.

The license for the pcsc-lite package that they offer is a BSD variant i believe....perfect for a reference implementation across ALL the unix based OSes out there.

I think the windows world already has a large collection of cardreader software supplied by vendors...so taking care of the windows boxen would probably not need any software like this at all..since you probably get the cardreeader software for windows with the device.

-jef

Re:Smartcard systems?

[jspaleta]

I've looked at the keychain usb devices before...but i thought th at market was moving towards portable data storage with ~100MB type storage...and not something meant primarily for small file storage like password storage.

And are those usb devices supported on Solaris?

I think smartcard/usb-keychain decisions come down to price-feature ratio. If you want real portable storage for files and what not the usb devices are the way to go...if you just want to keep passwords or cyptokeys/sigs then smartcards might be cheaper to implement.

I'd also be concerned about support for the usb devices on the Unixes...
But i havent seriously looked into it...since I dont have a real need for this stuff personally.
My citibank smartcard reader was FREE. so getting it working under linux was a nice bonus.

-jef

Re:Smartcard systems?

[BakaMark]

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

There have been smartcard APIs for Windows NT systems since 3.51.

I used to work for a Major Australian Bank that was using smartcards about 10 years ago for use with controlling access and defining access levels for it's Branch banking systems.

There are a lot of practical issues with Smartcards in a physical and logical sence.

For instance the selection of smart card reader is important. "slide on types" will constantly scratch the surface of the smartcard (wearing them out a lot quicker). Although just about every "el cheapo" smartcard reader that I have seen in the last 2-3 years is the "press down type" where the contact is not made until the card is the last millimeter inside the holder (reducing the wear and tear).

Watching what happens to these things when they get left in someones top pocket as their shirt/pants goes through the clothes washer and tumbe drier is fun. The chip is intact, but the plastic around it will make it impossible for you to insert it into a conventional reader again.

Only store minimal a amount of information within the smartcard. It should not make much difference nowdays, but the interface between the chip and the holder is not that fast. When you start storing copious amounts of data, it may be cheaper to issue each staff member with a 1.44Mb floppy disk and have each computer with a capable disk drive than to fork out for a Smartcard with a sizeable chunk of EEPROM storage.

Unless you want to waste smartcards that have been stuffed by someone feeding in an incorrect number of passwords a number of times, think about you reset strategy, etc. A system that enforces "kill this card" after 5 tries a the pin/password could mean that you cannot do anything with the card afterwards. Leading up to the next point...

Think about you Administrative procedures correctly. The plan is to work with multiple computer platforms here.

Then it is always fun to have a smartcard synced with a Windows NT account, UNIX account, etc. that is individual to the card. You either have to create the account manually, or have the software do it for you when it sees the card for the first time. It depends upon the sensitivity of the user data, and not letting another users see it.

Re:Smartcard systems?

[systemaster]

I think your totally ignoring the point of this topic...the idea is central password managment in a realistic manner...of course there are sercurity risks in doing this. BUT how would one do it in the most secure way possible?

Re:Smartcard systems?

[Anonymous Coward]

And Linuxiso.com is quite misnamed too. I wish webmasters would be less shortsighted... but that's cool how MUSCLE will be supported on all Unixes, thanks. I'll have to check it out.

Re:Smartcard systems?

[|<amikaze]

SunRay's do have USB support, for the keyboard and mouse at least. If there isn't already drivers, it probably wouldn't be too challenging for either the usbkey manufacturer or sun to make up a simple driver for it. USB support is already there.

Single Sign-On

[Reknamorken]

I don't think it's 100% clear what the answer is yet. I've seen some attempts at this using LDAP, but it can become quite messy. For example, if you want to tie routers into it you'll need to integrate LDAP with Radius/TACACS.

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?

Re:Single Sign-On

[Anonymous Coward]

You're correct. Kerberos is the way to go here. LDAP is nice as a directory but storing passwords directly in LDAP is a bad idea and requires special software on the Windows boxes. Kerberos is directly supported and in general will interoperate well with either MIT or Heimdal KDCs. Plus not only do you get single password but you also get single-sign-on if you set it up right.

Samba

[dousette]

Samba should be able to do it, from what I've heard, though I've never personally set it up before to do that.

Use Kerberos

[Anonymous Coward]

Kerberos. Runs everywhere. Is secure if your Kerberos server is secure. Easy to install and run. Even comes with Win2000 Active Directory.

Samba?

[dodald]

The company I used to work for used Samba to conenct the Unix Network to the windows network. All it really does is allow the windows machines to authenticate against the unix network (which you probably already have in place.) With a few scripts you could create new accounts pretty easily (I think we even used LDAP to connect to a corporate interface of some kind)

If you have an existing *nix net Samba would probably be the way to go.

Other benifits include a centralized "Share" so all your machines could easily mount the same drives, and centralized printing (You don't need samba for this unless your network prints from the windows network) Check it out, the new versions also support encyrpted passwords...

Just my 2cents

Re:Samba?

[BenTheDewpendent]

samba 3 will work with Active Directory. and to a point samba does work with PDCs as it can be a SDC. check it out at samba.org.

Re:Samba?

[GombuMstr]

This is interesting as we were wanted desperatly to integrate our AS400 with our WIndows network.. Even though AS400 can do basic NT PDC stuff we needed something better. Well about a month ago I figured it out. We are using Samba-TNG/LDAP to handle domain logins and handle the password scheduling. Then when a user changes their password on the domain the Samba -TNG Server runs the 'unix program sync' option which is a remote exec program that runs WRKUSRPRF on the AS400 to change the password. We thought we were in heaven.. We can now syncronize all the passwords to our samba server.

Re:Samba?

[dodald]

I don't even thick ours was taht complicated. Our Windows boxes just authenticated via Samba, so when a user attemped to change a password it would change via samba which updated the NIS stuff, so most of the password changes were almost instant. Which is a plus becuase most of the time users where required to change the passwords every 3 months or so, and most of the work was done in via an ssh client, so users would need to log in right after changing their passwords. Samba, for this problem, is probably the right way to go.

Re:Samba?

[Anonymous Coward]

its not SDC its BDC (Not Secondary, Backup)

(Hiding my identity becuase I am embarased I know about NT servers :))

Samba?

[Malc]

Can this be managed from a Linux based Windows PDC?

<remove tongue from cheek>

Low-tech solution

[pongo000]

Why not use one or two well-built passwords (mixed case, punctuation, etc.) and then modify it for each host you need access to...so if you have hosts moe, larry, and curly, then your passwords for each would look something like

moe.xy3,3IkshX476
larry.xy3,3IkshX476
curly.xy 3,3IkshX476

Some might argue this is inherently insecure...but I maintain if a password is sufficiently "secure" in terms of randomness, then this method would be no less secure than generating three other random passwords.

The drawback, of course, is that if one password is cracked, you've left yourself wide open...so start with a password you're convinced is secure!

Of course, the better way is some sort of authentication scheme using something like ssh and PKI, which is available on the platforms you mention. But now, you have to worry about securing your private key...to me, it's 6 of one half dozen of the other. Either secure your password or secure your key, because either one stands to be compromized.

Re:Low-tech solution

[JM_the_Great]

I don't really see why you'd need to modify it for each host. Might as well just have one secure password if you're going to do this. So either having one password is inherently secure, or it's not, no need for a whole password scheme to make things complicated.

Re:Low-tech solution

[carm$y$]

if one password is cracked, you've left yourself wide open...so start with a password you're convinced is secure!

This is far from enough. If someone r00tz one of your boxes they can get your raw keystrokes when you logon to the [serial] console, for example. And no matter how strong your password, it takes them the time you type it to crack.

Re:Low-tech solution

[tutal]

Pet pieve alert!

randomness != security

Why?
1. Your typical user (read incompetant) has a tough time either typing or remembering a random password, especially if change frequently.
2. If they can't type it easily they will hunt and peck, and type the password in slowly, which any malicious user can pick up easily.
3. If they can't remeber it they most likely will write it down, and equally as likely put it on a post it note on their monitor.

Solution?
Use long passwords (over 8 characters) with alphanumeric replacement that alternate between hands ie dismantlement (the longest alternating qwerty word) could be dism4ntl3m3nt. And no.. that is not my password on Slashdot or anything else for that matter ;-)

Re:Low-tech solution

[Permission Denied]

moe.xy3,3IkshX476
larry.xy3,3IkshX476
curly.xy3,3IkshX476

The drawback, of course, is that if one password is cracked, you've left yourself wide open

I have an easier method:

On moe, larry and curly, you have these corresponding passwords:

.xy3,3IkshX476
.xy3,3IkshX476
.xy3,3IkshX476

Like your system, if one password is comprimised, the others are also comprimised. So the security of the systems is equivalent. However, my method has one serious advantage: you can save three to eight keystrokes every time you type your password :)

Re:Low-tech solution

[Anonymous Coward]

Why not use one or two well-built passwords (mixed case, punctuation, etc.) and then modify it for each host you need access to...so if you have hosts moe, larry, and curly, then your passwords for each would look something like

moe.xy3,3IkshX476
larry.xy3,3IkshX476
curly.xy 3,3IkshX476

getting close. but instead of imbedding the hostname, apply a mnemoic. for example, "moe" might remind you of "moxy", likewise "larry" -> "laugh" and "curly" -> "chunky". -then- append the nescesary psuedorandom fluff.

moxy.xy3,3IkshX476
laugh.xy3,3IkshX476
chunky. xy3,3IkshX476

on the same machine, i might imbed an additional 'R' for root, 'A' for admin, etc.

or not.

posting AC not to give anyone ideas;

RSA SecurID

[Gunfighter]

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!

Re:RSA SecurID

[13013dobbs]

It is an awesome package. Plus the key fobs have a very high geek factor.

Re:RSA SecurID

[Anonymous Coward]

We've used the SecureID fobs at my work place ofr secure remote access. While the system works well, and seems secure (based on the "know something (a password) and bring something (the fob)" principle, like ATM cards), you have to have the fob with you whenever you *might* need access to a secured system. So, if you leave home and forget to pack it... Or, if your fob dies (and I've seen about 60% of ours fail over the last 3 years)... Or if you break it (about 10% of our fobs)... If the fobs are available in a credit card form factor (thickness, too!), they'd be easier to keep on your person than the ones we have.

Re:RSA SecurID

[Myrcurial]

This is absolutely the best suggestion. It's not cheap, but it is absolutely effective.

Do ensure that you've got at least two servers though. You might be surprised if you end up completely locked out.

Re:RSA SecurID

[dondiego]

gack, do a google search and read up about how "SecurID" has been cracked and is not nearly as secure as vendors might lead you to believe... (As far back as 1996 they started finding problems) Here's an example discussion: http://www.linuxsecurity.com/articles/cryptography _article-2336.html

Re:RSA SecurID

[Zeinfeld]

Or, if your fob dies (and I've seen about 60% of ours fail over the last 3 years)... Or if you break it (about 10% of our fobs)... If the fobs are available in a credit card form factor (thickness, too!), they'd be easier to keep on your person than the ones we have.

Look at the activecard tags, we switched to them because they are half the price of SecureID and more reliable to boot.

Re:RSA SecurID

[geirt]

Zeinfeld wrote:
Look at the activecard tags, we switched to them because they are half the price of SecureID and more reliable to boot.

Can these be used with Linux? I couldn't find any info on their web site (www.activcard.com ?)

Re:RSA SecurID

[Anonymous Coward]

SecurID has proven insecure, it is possible to break.

Re:RSA SecurID

[sulli]

You can get them in credit card form. The fob is a bad idea because it gets smashed by keys.

Re:RSA SecurID

[raymondlowe]

If the fobs are available in a credit card form factor (thickness, too!), they'd be easier to keep on your person than the ones we have.

SecurID come as a "card" as well which is the same form factor as a credit card but about twice the thickness. Doesn't fit into a wallet easily but is fine in a jacket pocket which is where mine lives.

However the security offered by these things is pure smoke and mirrors -- it is really only casual security. If the black hats want to get into your account that is protected by SecurID they will do so very easily; even without social engineering.

"Hello is that the corporate helpdesk? The is [insert name of CEO], I'm travelling and I left my securid at home; can you set my account to lost card mode pls and give me a static password? Thanks so much!".

R.

LDAP is very cross-platform

[Seth Finkelstein]

LDAP is definitely something you should investigate.

It is extremely cross-platform compatible

Sig: What Happened To The Censorware Project (censorware.org)

NIS/YP..Take your pick.

[Bowie J. Poag]

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.

Re:NIS/YP..Take your pick.

[ghack]

NIS works great - I would highly recommend it. I agree with the parent poster in that using NIS is the obvious thing to do - the most simplistic google search would reveal that.

http://www.linuxfocus.org/English/July2001/article 148.shtml is a good NIS howto.
http://www.isi.edu/~govindan/cs558/nis/ is a good basic overview.

NIS is a solution that will work on linux, solaris, and windows 2000 - so it is perfect for your application.

Re:NIS/YP..Take your pick.

[Anonymous Coward]

The thing your looking for is called NIS.

I really don't think so. It may have the features, but it's horribly insecure, and there are at least 3 different implementations that work together if you don't have more than a couple of hundreds users/groups/hosts.

Re:NIS/YP..Take your pick.

[Anonymous Coward]

I believe NIS+ solved many of the
security problems with NIS. And the
University of MD appears to use
it for Linux/Solaris/Irix/WinNT/Mac
and probably more.(VAX?)
And before you start wringing your hands
about NIS insecurities, I'd suggest
adequately Firewalling,IDSing,logging
and compartmentalizing your network,
if its like most its probably got
unaddressed problems.

Re:NIS/YP..Take your pick.

[j-turkey]

NIS+ is great, except that I'm pretty sure that Windows NT (any version) can authenticate from an NIS server. Microsoft has written an NIS server, but no client.

Re:NIS/YP..Take your pick.

[Gerdts]

NIS is bad because it allows you to display the encrypted password for every user using the command "ypcat passwd". It is a required part of the protocol that cannot be disabled. It would be possible to disable ypcat, but the underlying API call yp_all cannot be removed or blocked. Encrypted passwords can then be guessed with a program call "Crack" (and others).

Furthermore, NIS is succeptible to attacks that use the faked NIS server. You can create your own fake NIS server (laptop running linux) for the domain, create an account "myroot" with uid 0, and a password that you know. Next, you unplug the ethernet of the machine that you want to break into, and plug it into a hub that only your trojan laptop is on. Assign your laptop the IP address of one of the NIS servers. No, log in as "myroot". You now have root access on the machine. The only protection I know against this attack is to implement IPsec between your NIS servers and all clients.

NIS+ works around these problems as it uses a public key cryptography system for all transactions. The problem with NIS+ is that it is not widely implemented and Sun (the primary vendor behind it) has announced that its upcoming release of Solaris, Solaris 9, will be the last one to have NIS+. Sun recommends shifting to LDAP.

Re:NIS/YP..Take your pick.

[yukonbob]

NIS is the obvious thing to do

I was looking at implementing NIS, but I ran into problems w/ the method I wanted to do it by...First of all NIS is a 'flat' database, which is the crux of my problems, I think (NIS+ hierarchical, but not widely available...not recommended for Linux). I wanted seperate maps for each campus server, for staff/students at that campus (smaller maps to distribute to all sites, publishing less information), but some services (email serving multiple campuses) required a 'super map' that was all the maps combined... not inherintly possible by the flat NIS model. To keep two copies is silly-ish, since the idea is to eliminate duplication and ease administration... I looked into having the email service try binding to multiple maps in turn until a hit (or exhaustion), and scripts to build a 'super' map from all the other maps, but was never satisfied. What to do?

-yb

Re:NIS/YP..Take your pick.

[Surak]

NIS will work well. You can also use LDAP or Kerberos. Furthermore, you could run Samba on all your Unix boxes, setup one of them as a PDC, and make all the passwords sync between the PDC and the local passwords.

General Motors (my former employer) uses NIS. They have a mixed environment with Solaris, HP-UX, AIX, IRIX, and Windows 2000 boxes. They have everything tied to the NIS servers so that your login on your Windows 2000 EC2K box is the same as your Solaris CEe seat.

Re:NIS/YP..Take your pick.

[MontyP]

At Southern Connecticut State University we are currently using NIS+ for our Solaris authentication. This system is effective for the Solaris boxes. It is a similar system to NIS, but includes encryption and other features that make it a better all around package. The majority of systems on campus run 2K. In the upcoming months we will be phasing into the Campus Pipeline [www.campuspipline.com] software package, and authenticate against LDAP servers. We are planning on integrating all logins with LDAP. The Solaris boxes and OS X boxes will have no trouble authenticating in this manner, however, with our current setup on the Solaris machines, OS X will not work with NIS+. IMHO, LDAP is a better solution for our current setup then would an implementation of NIS.

Re:NIS/YP..Take your pick.

[JLouder]

The thing your looking for is called NIS...

NIS is simple to set up, but any user on one of your systems can run ypcat passwd (or ypcat shadow, depending on how you've set things up) and see everyone's encrypted passwords.

Another problem with NIS is that is distributes the complete maps every time a change is made. If you're looking for an enterprise solution, you'll have a passwd map with thousands of entries, and you don't need to be pushing that whole thing around the network every time a user changes his password.

NIS+ solves both of these problems, but is more complicated. But more importantly, Sun plans to remove NIS+ from Solaris after Solaris 9. They're encouraging everyone to switch to LDAP.

LDAP

[mnordstr]

For best support I'd say use LDAP. Everything seems to support it, Windows/*nix, Apache, PHP, Perl, etc., and I think it can be integrated into Active Directory for further customizability.

PGP

[eyeball]

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.

Re:PGP

[Anonymous Coward]

How can you encrypt against everyone's public key? What happens if a new user account is created?

Re:PGP

[eyeball]

redundant? hey fuck you i was first! :)

Re:PGP

[Anonymous Coward]

the document can be encrypted against multiple keys, and if someone new starts, it's a simple matter to decrypt, the re-encrypt the document against all the old keys plus the new one. With the Windows PGP application will even let you decrypt to the clipboard, edit the clipboard, then re-encrypt the clipboard.

Re:PGP

[pknut]

There is some uncertainty as to the future of PGP. Network Associates (pgp.com) appears to be trying to bale out of encryption, post 9/11... thus GnuPG is the way to go.

Incidentally, I use GPG to store a growing list of passwords. It is very useful to maintain a central list, for when I forget my passwords. However, this is not the way for large organisations to go (read: kludgey).

Re:PGP

[stevey]

PGP for password management

I too use this system for storing all my passwords - I have a single file 'accounts.txt.asc' which stores all the passwords.

This is shared with the other sysadmin at the place where I work, and as a backup measure we both have Palm Pilots which have the accounts on them too - this is insanely handy for fixing things when you're at home, or in a webcafe connected through SSH/a VPN.

One big advantage of having something like this is that it is simple to print out all the passwords, and leave them in the company safe. (You need to do this in case the you get run over by a bus, or similar..)

Java Smartcards

[Anonymous Coward]

Sun is pushing the use of Java Smartcards for this and similar problems. You can use the J2ME and card APIs for chips on plastic cards, rings, and such to log onto systems. (Before we hear the tired old refrain that "java is too slow", realize that the Java card uses Java as a language, but compiles down to an instruction that gets executed in a chip. That is, there's no VM; there's a physical chip that runs Java, and fast.)

This does not solve your problem of a central secure set of passwords, but it's an idea for local authentication that might reduce the number of stored key entries for administered systems.

Re:Java Smartcards

[Anonymous Coward]

That is, there's no VM; there's a physical chip that runs Java, and fast

Not to mention a complete waste of money, as well as electrons and protons.

winbind

[Anonymous Coward]

check out winbind from samba.

Lets unix users use a windows PDC for authentication.

Re:winbind

[AaronMB]

> check out winbind from samba.

With microsoft's desire to squelch competing open source software, making your authentication scheme dependant on MS might leave you SOL if they decide to patent some part of authentication, and deny licenses to free software os's.

Re:winbind

[Anonymous Coward]

With knowing that, everyone still says Microsoft is the best. Just install XP... What a bunch of Fucks that have no clue...

Can't anyone just get it in their head! MS is a bitch of a company.

Re:winbind

[Anonymous Coward]

It's a valid concern, but in most shops the NT Domain is there, and NIS/LDAP/NDS isn't. Why do work today that you can put off to tomorrow?

LDAP?

[Anonymous Coward]

Try LDAP it works great. I've done it with all the above mentioned platforms. Solaris ran the LDAP database, Iplanet directory server. It's not easy the first time. LDAP does have a bit of a learning curve to it especially if you try to customize anything. There's a good book out there for Solaris and LDAP. Sun Blueprints, Solaris and LDAP Naming Services, Deploying LDAP in the Enterprise. Their example uses Iplanet. It's expensive though. There's OpenLDAP as well and you can hook it into a Relational Database if you like MySQL, postgres, oracle etc etc. Iplanet can use a backend DB as well.

P-Synch

[lbmouse]

This works pretty good.

Use LDAP And Single Sign On (SSO)

[Anonymous Coward]

I guess the only way to integrate all your passwords is using a Directory Server (LDAP). There are lots of tools available for Single Sign On (SSO) and we have sucessfull integrated Solaris / Windows / ERP systems using SSO.

Of course, our clients being paranod had multiple firewalls between every system.

It exists.....

[ruvreve]

At Purdue University students use one password to access almost every online university resource. 90% of the computer labs use some sort of Windows variant. They use PC-R Dist to verify the user and keep the computers installed with a 'fresh' copy of Windows everytime a user logs on.

Most servers are all *nix based with the majority being sun servers. When a user changes their password anywhere, it gets distributed across the entire system.

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.

Re:It exists.....

[Anonymous Coward]

It's called .... K E R B E R O S.

That's not what the user was asking for, but it's interesting to see what linux users do with free association on security topics.

Re:It exists.....

[cscx]

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 :).

Re:It exists.....

[ComputerizedYoga]

its actually ACMAINT, not ACTMAINT (most people confuse those). You'll find some helpful links about basics of it at purdue's labinfo pages (search) and off google (search key=acmaint). It is house-written, but all in all pretty dang effective. PCR-dist doesn't fit into the login scheme of things at all. Its just there so the win98 machines provide the same environment to everyone and give you the freedom to install your own software. Sadly, we're moving away from that model with winxp, replacing it with roaming profiles. In any case though, if you have the ability to pursue something custom, purdue's system is a pretty good model if your setup is large enough to justify something like it. (note that the recent hack was on a non-acmaint machine, though details haven't been too publicized about that either).

Re:It exists.....

[spikedvodka]

If it's custom written, the wheel has been reinvented a few times at least.

RPI has a similar system... we have a web-interface for passwd... I think how it's done, is we wrote custom passwd and the web ap, to update the AFS and Kerberos, and the win domains. I don't know exactly how it works.

My point... It's done quite regualrly

Re:It exists.....

[cscx]

its actually ACMAINT, not ACTMAINT (most people confuse those).

No wonder I couldn't find any literature on it!

Here is a link to a paper describing ACMAINT (Z'd PostScript format)

Here is a readme for ACMAINT. It is open source, as its source is publicly accessable and located here. There is a homemade software license in the file headers, which basically says give us credit where credit is due... no GPL constraints, etc. (Makes me wonder why people actually bind themselves to the GPL anyway; whatever happened to good old "I trust you with the source and you won't rip me off." Anyway...) It looks like it requires a dedicated database server to do its operations, according to the article linked above. However, it is a very conveinent solution to what the original article was indicating (he never said he was using Kerberos). The plus for ACMAINT is that is works with pretty much any Unix; Solaris is used heavily in its primary implementation, though.

About PC-RDist, I believe that they are sticking with it for WinXP last time I checked. Which, although nice, sucks as it flushes and refreshes the registry at logout, a feature, although nice, takes about 5 minutes.

I completely agree

[Mdog]

I did my undergrad. at U-Missouri - Rolla, which had mostly switched to Kerberos as I left. It was great, authenticate once, do what you want.

I'm now at U-Illinois Urbana-Champaign, and for being such a well regarded school in computer science, I can't believe how many different identities/passwords it takes to get by here...it's a really big hassle. I pray for Kerberos :)

Re:I completely agree

[Ophidian P. Jones]

Hahahahah, shut up fag.

Re:I completely agree

[Waffle Iron]

I'm now at U-Illinois Urbana-Champaign, and for being such a well regarded school in computer science, I can't believe how many different identities/passwords it takes to get by here

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.

Re:I completely agree

[(startx)]

agreed. I'm at UMR now, and it's extremely simple to remember 1 name/passwd. everything is kerberos authenticated, and it makes my life much more enjoyable.

Re:I completely agree

[Anonymous Coward]

Now I see your mistake. You think that UIUC is a "well regarded school" in anything.
I pray that you may discover your mistake before too long.

Re:I completely agree

[Anonymous Coward]

Shut up fag.

Re:I completely agree

[CaptainTylor]

On the bright side, when there's a kernel panic, you are entertained by a rendition of "Daisy."

I can see it now...

[VistaBoy]

You make a bunch of password-protected accounts, then you store all the passwords in a file. This file will be password protected as well. Slowly, you forget all the other passwords, and the only one you have left is the main one. Finally, you hit your head against an I-Beam on your way home and get amnesia.

There goes your career!

Re:I can see it now...

[Anonymous Coward]

Then you wake up, look on the back of your right hand - and there's your password. You knew you wrote it down somewhere!

Re:I can see it now...

[VistaBoy]

Ah, but you wouldn't know what that mysterious word on the back of your right hand was... you have amnesia.

Reason why this isn't such a good idea...

[jacobb]

is that it gives the MEDIUM far too much responsibility.
If one password is transmitted insecurely, they're all compromised. Even worse, if Skriptkiddie01 has access to, say, one email account belonging to you (perhaps through no fault of your own... say a hotmail bug... and there has been no shortage of those) then most of the time he can get one of your passwords (through those damn "I forgot my password - email it to me") and then extrapolate.
The only way to make this method any good is to "nickname"... instead of actual host names, nickname them something that looks random - say x512, y513 or whatever; then use that to attach. Of course this doesn't really pertain to the original question, which i think was authentication, but anyway. Go for Counterpane's Password Safe: endorsed by Bruce Schneier and soon-to-be opensourced! It uses Blowfish for encryption, and Yarrow for PNG. :)

Re:Reason why this isn't such a good idea...

[AaronMB]

> and Yarrow [counterpane.com] for PNG. :)

Confused the hell out of me. I thought for a second bruce had gotten into computer graphics. ;)

(for those who don't know, he meant PRNG or Psuedo-Random Number Generator)

Re:Reason why this isn't such a good idea...

[jacobb]

PNG == Pseudorandom number generator.... that's just the way i spell it. i know the so-called "correct" spelling is hyphenated, but i hate hypens. Besides, _every_ other pseudo-xxxxx word is spelled as one word, without the hyphen. But hey, to each his own and appy polly loggies for the confusion.

Re:Reason why this isn't such a good idea...

[Anonymous Coward]

Screw hyphens, even Knuth despises them and wants to drop the hyphen in email. I tend to agree because Knuth has great wisdom, as well as common sense.

Novell eDirectory

[c-town]

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.

Re:Novell eDirectory

[Anonymous Coward]

Do I have to change my Layer 3 protocol?

Re:Novell eDirectory

[Anonymous Coward]

I must agree. Novell does this better than anybody. They also make the most efficient and fast NOS around. They just suck at marketing. But Microsoft hurt them badly during the 90's when M$ was breaking the Novell client with every patch they released.
eDirectory is probably a great solution. I am not as familiar as I once was. I guess I should get my CNE up to date.

Re:Novell eDirectory

[Eristone]

Novell eDir -- highly recommended. Cross platform, etc.

Re:Novell eDirectory

[eer]

No - just use the LDAP PAM module on UNIX and Linux and possibly Windows (if you don't want to use Novell's Client32 stack on your NT servers - Microsoft doesn't have an IP-only Novell client). And eDirectory is totally IP, including the directory-to-directory synchronization and management protocols (not LDAP, but IP).

Re:Novell eDirectory

[sphealey]

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.

Well, I would disagree with that first sentence a bit ;-)

However, don't you know that your second sentence violates the Slashdot Code of Posting, which states that Slashdotters can never suggest a Novell (or Lotus Notes) product as a viable solution to any problem?

sPh

PS I think NDS/eDirectory would be an excellent solution to the problem stated - IF enough vendors would support it.

Another "Ask Google" question?

[Anonymous Coward]

"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?" Jesus tap dancing Christ. How *do* you people get jobs?

Re:Another "Ask Google" question?

[autocracy]

I think perhaps it was meant more to see what was missed. And to get a view of the responses. I would have to say that kerberos/ldap seem to be popular. I now have more of a background and some actual user opinions and experiences. Very helpful in a decision.

Re:Another "Ask Google" question?

[Anonymous Coward]

You may have all the answers oh networking god, but if the employer won't send you out on a customer site for fear of how you will act, then you're no good.

How do we get jobs? By having better social skills than you.

(but then again, Slashdot isn't known for being the friendiest place on the net :)

Collective Technologies Does This

[ayden]

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.

Re:Collective Technologies Does This

[Trepalium]

Microsoft has similar software for their Win2K servers. They offer MS Windows Services for Unix which can allow your Windows 2000 server to act as an NIS+ server (along with NFS, etc), and extends the Active Directory schema to support UNIX user attributes.

Re:Collective Technologies Does This

[--daz--]

More ignorant BS.

MS' implementation of Kerberos is 100% compliant with the v5 protocol of Kerberos as specified by MIT.

MS makes use of the "Vendor Specific" area of the ticket to add features for Win2KWin2K systems (Group policy, multiple group memberships, explicit denial of permissions, certificates, etc).

A Win2K server can authenticate a Unix Kerberos client without any difficulty. Likewise, a Win2K client can authenticate to a Unix server without any problem.

MIT provides some test clients and servers and Win2K worked 100% with these.

The "Bastardization" you refer to is not a bastardization at all since MIT provide for "Vendor Specific" functionality such as this.

If/when Linux implements Group Policy (never?), then it can use this functionality. Otherwise, that information just gets discarded. Who cares? Unless you're running a Win2K client, you don't care about that information anyhow and it just gets ignored.

Re:Collective Technologies Does This

[Anonymous Coward]

Best response on the whole damn page, if you ask me....

Re:Collective Technologies Does This

[aminorex]

Now this is also only a partial solution, the flip
side of the coin from my earlier post in this
thread. SSH is essential for network
communication. It is the single cross-platform
standard that interoperates perfectly, without
any realistic competition (certainly not Kerberos,
which has vast administrative overhead by
comparison). Any solution that does not address
SSH does not provide single or even uniform login,
as far as I am concerned.

Welcome to the world of SSO

[Rhonabwy]

What you're asking for is Single Sign On - or a variation on the theme. Frankly, with Win2K and Active Directory, you've about got it all there. Linux+PAM+Kerb5 links in there beautifully, as does Solaris+Kerb5. The requirement then becomes to use Windows Active Directory as your Key Distribution Center, but if you lock the box down to some insane level, the risk is probably minimal.

I've used Linux Kerberos5 + Merit Radius as the KDC's in a previous job, as I prefered the security to Microsoft's relatively non-existant security.

As soon as you get the passwords all working from one point, you'll want account management... it goes to SSO from there.

Re:Welcome to the world of SSO

[Anonymous Coward]

The problem here being, of course, the Microsoftized version of Kerberos...

Okay, okay, _one_ of the problems here being...

AC
Don't get MAD, get NDS

Our Noc

[BrookHarty]

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.

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 .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.

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

So how do you...

[fm6]

Don't say "Yellow Pages." Trademark. Lawyers. Cease-and-desist. You know the drill.

I guess NIS is an obvious choice if you have a lot of Unix/Linux boxes -- especially servers. But what's the drill for enabling NIS network logins on Windows? Does it work if you have NT servers too?

Shadowed password maps

[Cadre]

linvilaw@dogbert-/~-16:21% ypcat passwd | grep helldraw
helldraw:x:20750:200:Lucifer Java Drawer:/home/mathcs/users/fall00/helldraw:/bin/tcs h
linvilaw@dogbert-/~-16:22%

It's not so bad with if you use shadowed password maps...

Samba TNG + LDAP

[greyguppy]

Samba TNG is optimised as a PDC for your windows clients, and can run on a LDAP backend, as can PAM modules for Linux/Solaris.

NIS/YP..Secure?

[zenyu]

My shop uses NIS and you can print out the passwords /etc/passwd style. This makes it easy for anyone to copy them and do an offline dictionary attack.

Maybe they just set things up improperly but this doesn't qualify as secure in my book.

Kerberos has some holes too, but it's prolly a little better.

Re:NIS/YP..Secure?

[GrenDel Fuego]

Holes in Kerberos? Are you referring to Krb4 or Krb5?

If it's krb5, what holes are you referring to?

Re:NIS/YP..Secure?

[zenyu]

Holes in Kerberos? Are you referring to Krb4 or Krb5?

I was thinking of v4. But Isn't the whole system still based on trusting the host machines? This certainly can't be the case with machines that users have physical access to. Which is probably the case at most organizations.

Plus there is the deployment problem, if a hole is found in v5 protocol you'll be stuck with them until you can upgrade every machine in the organization. MIT is still running v4....

Plus with tickets expiring people have to re-login every once in a while. And it isn't very friendly to different administrative domains, so you might be stuck with single point of failure, or even worse all accounts and machines would have to go through some bureaucratic hassle to do anything.

Still it might work for his situation which is why I sorta recommended it.

Re:NIS/YP..Secure?

[Ewan]

NIS does indeed have that security problem, and it cant be avoided as far as I know.

NIS+ is not as vulnerable, but not as widespread either.

Re:NIS/YP..Secure?

[GrenDel Fuego]

I'm probably wasting my time posting a reply to an old article, but kerberos dosen't trust anything, machines, users or servers.

The user must authenticate themselves to the kerberos server to recieve a ticket. The service you're trying to use has to authenticate itself to the kerberos server as well.

Check out http://www.isi.edu/gost/brian/security/kerberos.ht ml for information, or http://web.mit.edu/kerberos/www/

And as an FYI, MIT uses krb5, not krb4. krb4 is broken by design and considered "DEAD" when it comes to development by MIT.

Re:NIS/YP..Secure?

[Anonymous Coward]

You have to trust the local machine that you're typing your password into not to steal it.

Re:NIS/YP..Secure?

[GrenDel Fuego]

That's the same with EVERY form of authentication. If you type a password into a compromised machine, your password can be compromised. It's not really a flaw in the protocol itself.

Easiest solution

[TheMonkeyDepartment]

use a big marker board in the middle of your office. Hire some migrant workers to keep it updated. We have implemented this here in the Monkey Department offices and boy, does it work.

Fortunately...

[Anonymous Coward]

...you post was chock full of information and goodness.

Thank heavens for you. Your parole officer must be very proud.

This seems easy...

[rainmanjag]

One word: Kerberos

One of the advantages of Kerberos is not having to have multiple passwords across multiple boxes/changing a password on one box affects the passwords on all other boxes.

Anyways, Krb5 is supported on almost all platforms, I think. Definitely the ones you listed.

Funny :)

[damas]

WinXP 2003. It does your dishes and dirty laundry too. Hell, it'll even marry you and make you seven billg lookalike children. And it screams in pleasure when you "tickle" it.

Debian comes with Mozilla and office apps. Windows comes with IE. Hard choice, huh?

Re:I have the way out!

[nackrm]

3. Use your favourite partintioning software to delete all partitions and replace it with one large FAT32 "C" drive.

When one large partition has an operating system that fails, it can be irritating to save files stored on it.

4. Get a copy of windows XP $179, which is cheaper than the phone bills for "FREE" software.

You can order a CD of whatever "FREE" operating system you want to be sent to you for under $10 if you don't have a fast internet connection. Besides, would you want an operating system that has a huge market share and no reason to compete, or one made by people with making something better as their main motivation. This is a tough on to think about....

7. USE YOUR COMPUTER WITH EASE

This really depends on your definition of what "EASE" really is. If you want to watch everything using Windows Mediaplayer then things are easy. If you want to chose other software that impoves itself over releases instead of just adding backwards incompatable technology to squeeze a couple more bucks out of my poor bank account, then you may want to stay with the "FREE" OS.

8. If you really want the command line, install DOS, the original and best!

If DOS was the original, then who originally wrote it? A quick look at the history shows that unlike what is popularly believed, Bill Gates didn't author DOS himself. Another thought, DOS may be a command line, but it doesn't have that much power. If someone wants to write a script, they use VB. And VB isn't much of an improvement on anything, except that its the chosen virus writing language because of its ease of allowing stupid people to do stupid things.
Oh yeah, and being the first doesn't really mean being the best anyways.

Paper.

[dsb3]

Easy! Just print them out on little sticky notes and keep them under your keyboard like everyone else.

Now, you say that security is important. Always remember that if it wasn't you can always relocate the stickies to the sides of your monitor for easier access.

Human readable databases are needed too

[Snow_Bonobo]

I think the question isn't so much about storing passwords for systems to use, such as in LDAP or NIS directories, but about storing passwords for humans to access. The other half of a password system is also very important.

Directories like LDAP, Kerberos and NIS can reduce the number of passwords on a network and make maintenance easier (normal users can have one password for all systems they access) but there will still be many passwords. It's a very bad idea to give every workstation and server the same root password, for example.

Ordinary users can get by with one universal password for their network identity, but for system administrators it can be a nightmare. I've got about 130 passwords to keep track of.

The best solution I've come up with so far is to use cheap Palm PDAs to store the passwords, encrypted and locked with a good password itself, on special password storage apps. Each sysadmin can have a PDA with just their passwords on it. For about £80 each it isn't cheap, but it's a lot better than using password potected Word files, which I've seen other companies using. Don't use the Palm's own "secure" storage, it's useless for things that need to be really secure.

I'm still looking for a better solution - some way to store the passwords centrally and distribute them to each PDA depending on the requirements of each sysadmin would be great.

Of course, the way that passwords become so cumbersome in large quantities just shows how flawed passwords are. Hopefully Kerberos will catch on more - the advanced features of Kerberos help reduce the number of passwords needed.

Re:Human readable databases are needed too

[vsync64]

The best solution I've come up with so far is to use cheap Palm PDAs to store the passwords, encrypted and locked with a good password itself, on special password storage apps

Such as Keyring.

Re:Human readable databases are needed too

[Anonymous Coward]

What's the point of having 130 different root passwords if they can all be accessed by a single password?

Re:Human readable databases are needed too

[Snow_Bonobo]

Each sysadmin only has the passwords they need, not the whole lot, and the pdas are looked after carefully. Each PDA has a different password, known only to the sysadmin.

You can't remotely bruteforce a Palm PDA. If it's stolen, then the batteries will die before the password is brute-forced by hand.

Well, that's the theory, but I know it isn't perfect. I'm still looking for a better solution.

There are many ways of doing this....

[Fnord]

It all depends on what kind of machine you want to host the passwords on, and how much functionality you want on the clients. If you're okay with using a UNIX machine for the server, then the most optimal solution is to put either an LDAP or NIS server on there (personally I'd suggest LDAP but that's a matter of preference) and have UNIX machines authenticate off of that. Then you also put Samba on the server an use it to create an NT domain. Then with a clever stacking of PAM modules on the server side you can make it so that any password change requests for either LDAP or Samba propagate to the other. This does require you to create each account twice (once in the LDAP directory and once in the smbpasswd file), but its a one time hassle.
On the other hand, if you're forced to use Windows on the server (maybe Samba doesn't quite do the domain tricks you want it to), then there is a PAM module distributed with the samba project called pam_smb. It should work on any PAM enabled UNIX and should allow you to log into UNIX machines using domain usernames (as long as samba is installed on the unix machine and configured to be part of the domain).

Re:There are many ways of doing this....

[stevey]

PAM module distributed with the samba project called pam_smb. It should work on any PAM enabled UNIX and should allow you to log into UNIX machines using domain usernames

I've used this a lot, to allow several of our Linux servers to share usernames + passwords with our NT domain.

I found it tricky to setup and a little flaky to start with - but once its up + running then it works wonderfully.

Take a look at it here.

Novell NDS Authentication Services

[Anonymous Coward]

NDS-AS provides password redirection from lots of platforms to eDirectory. It supports a bunch of different Unix's (and Linux) as well as OS/390 and Windows. It's easy to plug into various webservers, database, and routers since it also ships with an API. Check it out here: http://www.novell.com/products/ndsas/

What about RADIUS?

[slasher999]

I know RADIUS would authenticate for the network gear and the NT/Win2K hosts, and I imagine there must be a RADIUS "client" for Solaris and Linux as well. NIS (or YP) would also be a possible solution, but I've never used either to authenticate Windows.

Re:What about RADIUS?

[halfelven]

Radius client for Unix = PAM ;-)

Yuppers: LDAP can do this.

[JDizzy]

It can slice, it can dice, it can keep track of your credentials across your heterogeneous environment. It can be a repository of key-pairs, a DNS cache, an address book, or a database of your favorite mp3's. However, the most common use of LDAP is for your HOST files, and your PASSWD database. NIS cannot do that, it only has a single domain. You have to write scripts to sync the various NIS domains, or use NIS+. NIS+ can handle multiple domains (aka authentication realms) but cost money, and is a bit more complex. Besides, Sun Microsystems is dropping development of NIS. Another item of interest is using an SQL server as the authentication core. For example, ProFTP can use MySQL to authenticate. Since you can have a centralized DB communicate over SSL, this can be done relatively securely on Unix. Microsoft is the wildcard. They are a closed system, and getting at the sources (aka the PAM like things) is not easy. However, this is when LDAP comes into play. Since Microsoft dropped their crappy NT4 domain structure in favor of Active Directory (LDAP). Samba + OpenLDAP can be configured on a Unix box to sync up with active directory, or it can be made to host the active directory, and push the mess out to the NT authentication realm.

Multi-platform passwords...

[Anonymous Coward]

/me looks at his pen...

/me looks at a scrap of paper...

/me looks at his pen...

/me looks at a scrap of paper...

Keep it Simple!

[Anonymous Coward]

Yes, there is a very simple solution. All systems can ssh into a central system that has an encrypted password file...

IBM Redbooks

[fm6]

Karma Whore!

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.

Re:IBM Redbooks

[Anonymous Coward]

Meta-Karma Whores!

Anyone who would pay to read slashdot has no right to question anyone!

Re:IBM Redbooks

[Iamthefallen]

Karma whores? On Slashdot?!

I for one am shocked and outraged by this!

Use a fricken database

[Tablizer]

Databases have been dealing with the issues of management of lots of X's (big collections) for years and years. Why do people keep trying to *re-invent* them with registries, arrays, persistent objects, file managers, directory managers, etc? You can't integrate and share all of those very well and they are too proprietary and too different from each other.

Cut out the fricken middle-men and wannabees, and use a RDBMS for peats sake.

(end clue)

Re:Use a fricken database

[Anonymous Coward]

And how do you propose to keep the database entries secure? If you attempt to encrypt the database, you have to store a decryption token for that somewhere, which leaves you back at sharing that with everyone, or writing it down on a sticky next to your monitor. You can't hash a traditional database, because you can't authenticate against it in most cases, especially not when we're talking about trying to secure an enterprise wide solution (or even possibly larger).

Single Sign On isn't the answer either -- if people know the password, then someone else can figure it out, and having the same password for every resource then leaves your enterprise in the same state it was before. Imagine your Network/Server Architect out at a bar getting liquored up one night, and then tell me that one password for all your devices is a good idea.

The **BEST** solution is something like a SecurID token -- you take something you know (A pin number) and combine it with something you have (a 6 digit random number provided w/ your securID token) to create a one-time use password. If someone has your token, they still need to know your PIN, and if they have your PIN they still need your token.

Re:Use a fricken database

[__past__]

First of all, using an RDBMS is not an answer to this question - just storing your password(s) somewhere will not automagically make it possible to actually use it for login

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).

Re:Use a fricken database

[Tablizer]

(* 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 *)

Different engines and configurations are optimized for different things.

Sure, anything built for a very specific purpose will possibly be faster, but if the complexity deviates away from that special purpose for any reason, then a generic collection management system may be more flexible and cheaper.

Re:Use a fricken database

[mortonda]

*Dons Asbestos suit*
So... you are talking about using mysql then?!

;)

Novell eDirectory

[plieb]

aka NDS will run on all 3 platforms and over you centralized user account management and a single login.

Paul

Re:I have the way out!

[Empty Threats]

It was a joke. Those points were deliberately poorly made.

cfengine also

[rm -rf /etc/*]

Here's my take... LDAP in my opinion is not ready for prime time. It's going to be a great solution, but right now different implementations don't always play nice. For example, solaris includes LDAPv3 but not ssl support (which, ssl is part of the v3 spec...). Who knows how nice these things play with NT/2000 as well.

Kerberos is great, however it's also somewhat complex and has the added problem of needing users to switch to kerberized versions of applications (or setting up some tricks to use normal access methods but having the servers authenticate against kerberos). It's worth investigating, but it's non trivial in my opinion.

NIS, well, let's not go there.

So what we do is use cfengine (http://www.gnu.org/software/cfengine), which is basically a client/daemon system to sync configurations across different machines on a network. We keep our real password file seperate, and then use cfengine to copy it around to all clients when it changes. Of course the real benefit to cfengine is that it allows you to do much much more (for example, we keep all modified config files and programs in a cfengine tree and when we install a new machine, just run cfengine and it's customized automatically).

For the windows machines, you can throw a samba server out there to act as a PDC/authentication machine.

really, seriously look at eDirectory

[deviator]

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

Re:really, seriously look at eDirectory

[Anonymous Coward]

After reading all these "I think so and so will do this.." and "LDAP/NIS/Kerberos/whatever will save the world", it's nice to see some one with a practicle and responsible answer. Thank you.

So yes, eDirectory will do all of this, and no, it doesn't have anything to do with NetWare.

Re:really, seriously look at eDirectory

[deviator]

Thanks. :)

Yeah, most of the functionality this guy wants comes bundled in... and I think it's also really important to stress that eDir is a *distributed* *pervasive* database.. that alone marks a clear distinction from other products. (No, not "Pervasive" as in the company...)

If a server tanks, you don't lose any access to your auth info. If multiple servers tank, you STILL don't lose any access to your auth info. There are no single points of failure (note: Active Directory actually has (I believe) up to FOUR single points of failure- you have to manually reassign servers in case one of them crashes in order to have write access to your data. At least this was the case last time I checked it a few months ago.). Most other LDAP implementations are single-server as well. eDir really is as good people say it is... a good case study was CNN when they built a web portal... they were deciding whether or not to build their own custom auth database, but ended up choosing eDir instead because everything was already included. here's the story: CNN eDirectory success story

Similarly, Yahoo! picked eDir & Novell's Portal offering for their business portal... check it out: Yahoo! success story.

Both talk about scalability (replication), LDAP & cross-platform abilities. Anyhow, give it a look. It's really cool. :)

Disclaimer: I do not work for, nor have I ever worked for Novell...

what about delegation?

[CoughDropAddict]

Here is the situation I am in, and LDAP doesn't accommodate for it well:

I work in the Advanced Computing Lab. We get the list of usernames and passwords from a university-wide LDAP directory.

However, only a subset of the university-wide accounts should be able to log into the Advanced Computing Lab (this is mandate from the department head). We don't want to have to modify some property in the global directory to make this distinction, we need to be able to locally define this subset.

From what I can tell, the only way to implement this functionality is to use the LDAP concept of "chaining," however OpenLDAP doesn't seem to support this yet.

This seems like a very common situation, why is there no easy way to accomplish this??

Re:what about delegation?

[cheezit]

I wouldn't call this delegation proper---the problem being that LDAP has overridden the generic term with their goofy concept.

What you are really talking about is authorization, right? Storing an application's permissions set out in LDAP generates exactly this problem. Yes, that's what LDAP is supposed to enable, but just coz it's there doesn't mean you should use it.

You're saying to use chaining for delegation to a local application-specific directory, allowing for local administration of the DS. Instead, what about using LDAP for authentication and identity mapping, and then writing your own application permissions map (perhaps even using LDAP, but using the app to link the two, not chaining) with an admin interface? More work but it will be much easier to administer.

Re:what about delegation?

[CoughDropAddict]

I wouldn't call this delegation proper---the problem being that LDAP has overridden the generic term with their goofy concept.

Sorry, I wasn't using "delegation" in a technical sense, but in a political one. I want the global directory to define the list of usernames and passwords, but I want the decision of which accounts to recognize to be politically delegated to me as admin of the local server.

Instead, what about using LDAP for authentication and identity mapping, and then writing your own application permissions map
(perhaps even using LDAP, but using the app to link the two, not chaining) with an admin interface? More work but it will be much
easier to administer.

If I understand what you're saying, we would have to write client code to support this. Since there would be a diverse mix of clients, I want to keep as much of the intelligence in the server as possible, so that client-side LDAP authentication modules will work out of the box. The alternative is maintaining 5 different versions of the client-side code.

Passwords via LDAP

[Anonymous Coward]

What I would do for your unix hosts is this:
1) Get an ldap server, ( www.openldap.org )
2) Add the standard POSIX attributes ( look in the nis schema )
3) Add all the data from all your password files to this.
4) Create a schema for uid managent, so that you have the same uid's for users accross platforms.
5a) Write a program in perl or something to Make the diff pw files for the diff boxes, then scp it to the remote hosts.
5b) OR!! look at ypldapd or something ( see www.padl.org
6) As far as the windows hosts go, this will be a bit harder to sync your user data.. They don't play nice, it's either AD or nuttin.. However if you have a small environment then you can load up unix services for windows, and run NIS on your windows boxes.. HOWEVER all your user data would have to be in thoes unix boxes ;-)
YUCK

a feww ideas.
l8r

Commercial solution

[Rand]

Novell's NDS is available for Windows, Linux, Solaris, and several other OS's. It's very secure, very easy to administer, and very, very stable.

My network uses it for Netware, and NT, and I've toyed with adding a Linux server into the mix.

Kerberos & Hesiod

[jdreed1024]

Kerbeos for authentication.
http://web.mit.edu/kerberos/www/

Hesiod is used to obtain the equivalent of what
would be stored in /etc/passwd (but because Kerberos is used, there's no crypted password in the password field, only a Asterisk (*) which indicates Kerberos authorization should be used.) Hesiod is based on bind, so clients exist for most platforms, and if they don't, you can simply use nslookup as the client.

Re:Kerberos & Hesiod

[Anonymous Coward]

there is almost NO documentation on using hesiod, however, after about 2 months of tinkering with it, I got it working. It's much faster than NIS, and, when using secure dns (dns/tls), it's far more secure.

we use passkeep

[npietraniec]

At my work we use Password keeper. It's a windows program, but it runs perfectly under wine... Just store your password file in a central location that is accessible to all your workstations.

Passwords are not always for security

[Anonymous Coward]

Many times, a password is a just a word you need to enter
the system because the program said so. For my need,
passwords are an inconvinience, thus passwords is an evil.
For my situation, the "best" password should be
as simple as possible and should always be posted on
the monitor. Ideally, the binary should arrive
in a wrapper and at startup prints on thes screen
you password before it asks for it!
My needs are different.

Re:Passwords are not always for security

[blue trane]

passwords suck. why should I have to prove who I am? if people had no incentive to lie passwords would be uneccesary.

Re:Passwords are not always for security

[NorthDude]

It's more like: "if people had no incentive to steal*, passwords would be uneccesary". *credit card number, the money in my bank account, etc etc.

Re:Passwords are not always for security

[blue trane]

I was thinking, people might still steal, but if they didn't lie about it, you'd catch them quickly, and so deal with the problem more directly and efficiently than by using passwords.

Single Sign On

[YakumoFuji]

you want an SSO. I'm looking into this for my work. I want to be able to use our NT logon password for all things, so when it changes in on place, its changed for all. that covers logging into our AS400's, NT boxes, and our apps. Most people skip over the apps and just do central box logging, which is only 3/10'ths the problem.

eg: one of our apps requires this;
log onto box (nt/unix whatever) -> log into application -> app logs into db server (as400/db2) -> app also logs into 2nd db server (essbase).

there is 4 passwords righ there!

making inhouse apps support LDAP is easy, making 3rd party apps support it is hard. lucky our tivoli servers, essbase, as400's, nt boxes can all support ldap.

I suggest you do a lot of research befor jumping into any one solution.

(and dont buy into passport as an SSO option! licensing is $$$$ for passport.)

UNIX and Windows account synch

[pbegley]

Depending on your environment and the functionality you desire there are several solutions.

If you want to synch UNIX (NDIS) and Windows 2000 account information and passwords, one way to do this is to use Windows Services for UNIX (SFU).

The down side with this is Windows must be the NIS master, but it offers some nice features for Windows/UNIX environments. The price is reasonable (~US$150).

Some of the UNIX guys get indigestion over Windows as a NIS master, but it works out of the box where there are fewer UNIX hosts and clients than Windows boxes.

DANGER! DANGER, WILL ROBINSON!

[Anonymous Coward]

On many UN*X systems still around today, only the first 8 characters of the password are significant. A cracking program might reasonably try the hostname (which itself could be 8 letters long) followed by just a few more characters and guess your passwords in a few minutes if not seconds.

Password Management

[LazLong]

One solution would be to use one of the various PAM modules that allow you to authenticate against a Windows domain - blaspemy, I know. You could also use RSA SecureID. This would give you a central crossplatform authentication system along with two-factor/one time password authentication. Of course you have to carry around a SecureID fob....

Another option is software for syncing passwords across various platforms (and software packages). The solution I use is called P-Synch (http://www.p-synch.com/). It works quite well, and is quite inexpensive (we paid something around $20/user).

AOL NOC employee

[Anonymous Coward]

You must work at the AOL NOC because you don't seem to know anything about Radius or LDAP or Kerberos.

good luck

[Chundra]

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.

Re:good luck

[CowbertPrime]

that works. However, our centralized system is THECICSLDAP authentication provided by our VM/CMS systems running on S/390. Our primary difficulty is lab logins to win2k. We want to have students (25000) able to log in to win2k workstations but authenticate to their accounts on the S/390, since every student has an S/390 account and university email there. How would LDAP running on VM/CMS interface with active directory on win2k? We surely don't want to sync 30,000 accounts on the win2k PDC.

Re:good luck

[Anonymous Coward]

You might consider looking at Novell's DirXML technology. It lets each system maintian it's own security structures and keeps it all in sync via XML. It's really slick stuff and sounds perfect for the environment you describe.

Re:good luck

[Chundra]

Well that's definitely an issue. :)

Basically what we do is use a data warehouse that contains faculty & staff data from human resources plucked from peoplesoft, and from CICS for students. We treat that as the definitive list of who should have accounts (at least on the high volume everyone-has-an-account machines). The vast majority of our machines rely on LDAP, Kerberos, Active Directory, and NIS. So on the relevant boxes we have some perl scripts that run daily and pull a list of users from the database that should have accounts, as well as a list of users using that particular authentication scheme. From those two sets we can trivially create and delete the various accounts that should be created/deleted.

Changing passwords on all these systems is pretty simple too. The users hit an ssl webpage which authenticates through kerberos and then goes out and hits various machines using whatever hook is appropriate (some use Net::SSH::Perl and login to a box and call some sudoed program, some use Radius, some dump an md5 digest into a table, etc.).

Admittedly, if a user changes their password on one machine e.g. via passwd it's not going to propagate out to every other machine, but we also don't want to *force* users to use a single sign on either.

I don't think this is the *best* scheme out there, but it works a lot better than I would have ever imagined when I wrote it. The big pluses as I see them: it's easy to integrate new software into the scheme that doesn't use ldap, kerberos, active directory, etc. (stuff I've done recently: imp/horde web based student mail, blackboard courseinfo), if a domain controller or kdc or whatever goes down your whole authentication scheme doesn't go down the tubes until it's fixed, and last but not least just about everything uses ldap, kerberos, active directory and nis. Take your pick. :)

Re:good luck

[Chundra]

Hmmm. Thanks, but I'll leave that to whoever comes in to take my place. I hate my job and am currently looking for something else.

Fucking economy.

Anyone hiring? :-D

Re:good luck

[jonabbey]

Or Ganymede, which is designed for the same purpose.

Funny, cause it's true.

[FSK]

This is soooo easy. Just make everyone logon with username: user and use the company name as the password.

Seriously, someone suggested this in a meeting at the company I worked for.

Two that might work!

[kwishot]

vi and notepad! =)

eDirectory by Novell Rocks

[udaryls]

Cross platform user and resource management. Can run on linux only if you wish.

use your Thumb and Retina !

[da5idnetlimit.com]

Well, get 1 thumb scanner, one retina scanner , get both systems to generate one signature and find a crative way of mixing the numbers (Prime Exponential is good 8)

if this third number correspond, give access.

Retina + Thumb scan supported under Linux (Unixs) and Windows.

Just a bit steep on the budget part, but damn efficient.

Oh yes. Get at least TWO redundant password / verification servers, if possible one offsite.

Why ? Gess 8) a whole company unable to connect because one poor server went dead ...(actually seen at the workplace... Pass server down. Please have a cup of coffee 8)

I love your sig. No really !

[Anonymous Coward]

And please do tell me, Paladins are immune to moderation, or was it Berserks ?

Been done

[Anonymous Coward]

I'm a student at RPI, and they have the passwd DB synched across Solaris, AIX, IRIX, Linux, and Win2K. Not sure of the specifics, but it does work.

Authentication vs. Authorization

[Fastolfe]

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.

Re:Authentication vs. Authorization

[CoughDropAddict]

Thank you for your reply.

Let me see if I understand what you mean. I'll call our local LDAP server A and the global LDAP server B.

Someone tries to log onto a computer in the Advanced Computing Lab. The LDAP authentication module sends the username and password to server A. A looks only at the username, if it's not in the local group of approved users it denies access, if it IS in the local group of approved users, it refers the client to server B, saying "if the password matches, approve it."

Is that right? Would OpenLDAP support the server side of this? Would most LDAP clients support the client side?

Re:Authentication vs. Authorization

[Fastolfe]

It's up to your application to determine whether that authenticated user is authorized to do what it is he's requesting to do. You do an LDAP 'bind' to perform the authentication, and if you wanted, you could perform another LDAP check (e.g. presence in a group) for the authorization.

Say you have a LDAP hierarchy like:

o=Foo,dc=example,dc=com

And you have your organizational unit:

ou=Bar,o=Foo,dc=example,dc=com

Your local servers (A) handle this suffix, and refer everything else to the main LDAP servers (B) that handle the root suffix further above. A client (your OS, C) would make a request like this:

Step 1: Authorization
C -> B* (who's uid=example?)
B -> C (dunno, let's ask A)
C -> A (who's uid=example?)
A -> C (it's uid=example,ou=Users,o=...)
C -> A (I'd like to bind as uid=example..)
A -> C (OK, the password was right)

The OS now knows that the user claiming to be 'example' really is 'example'. But we still don't know if the user is allowed on this system.

Step 2: Authorization
C -> B* (is 'example' in the group cn=Authorized Users,ou=Bar,o=...?)
B -> C (yep.)

The OS now knows that the user is allowed to use the system.

Realistically, if you have your referrals set up correctly, where you send unknown requests to the main server, and the main server knows to delegate that LDAP suffix to *your* server, the initial request can go to either your local servers or the main LDAP servers, it doesn't matter. (In theory, it's like DNS, where your resolver can hit the local name servers, but realistically it can hit any name server in the world and it'll get referred to the right place eventually.)

There are other ways you can do your authorization, though. My main point was that you needed to break these two concepts apart. Let your main LDAP servers do the authentication, and do authorization in a second step.

Kerberos, Plain and simple.

[SuperBug]

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.

Dont use passwords....

[Llanfairpwllgwyngyll]

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.

Re:Dont use passwords....

[aminorex]

That's fine for remote logins. It doesn't address
the central problem as posed, however, which is
to gain access to a system via it's primary
interface, not via network-only interfaces. You
can't use ssh to authenticate for windows 2000
login, for example, nor to authenticate to a web
page. I wish that you could. SSH is essential.
Any system that doesn't address SSH authentication
is partial at best -- as for example, LDAP.

There is software available

[Anonymous Coward]

http://www.psynch.com/

looks to me like it isn't free .. but it should do what you want.

LDAP + Siteminder

[stonebeat.org]

RSA SecureID might be good. but it doesnt integrate with all systems :( try to look into LDAP + siteminder. That might be the answer to your problems.....

blockade communications

[mazdak_rezvani]

http://www.blockade.com/

seems to offer password synchronization services across multiple platforms

it's a losing battle

[mmusn]

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.

Re:it's a losing battle

[halfelven]

Like Keyring

The Microsoft answer

[trbraun]

This is somewhat along the same lines as Samba, but it's made by Microsoft which some managers seem to prefer -- MS has a little advertised product called Services for Unix that let's windows boxes speek NFS and NIS. What *nis you have on the other end is irrelavent.

I was required to set it up at work about a year and a half ago, and it worked fairly smoothly (on MS smoothness standards anyway)

Again, Kerberos!

[oddityfds]

You have a choice between three KDCs: Heimdal (that's what I use), MIT Kerberos and Windows 2000.

It can be used to authenticate logins on Windows 2000 (and probably XP), Unix (use PAM on Linux, Solaris etc., SIA on Tru64 and hack the XDM on others).

Use it to authenticate telnet and ssh logins. There are clients for MacOS, Windows, and Unix. Use it for authenticated X11 forwarding. Use it for FTP. Use it for POP3 and IMAP4 with Kerberos authentication or SSL-encrypted passwords (cyrus-imapd). Use it for AFS to replace the insecure NFS and to allow your users to access their home directory from home. Clients exist for most Unix variants (including MacOS X) and Windows 95/98/2000/XP.

Kerberos has single sign-on.

Why Kerberos instead of LDAP? Because Kerberos is an authentication scheme, not a password database.

Works with MacOS X too

[oddityfds]

Of course, with Kerberos, you can have single sign-on login on MacOS X as well, and it works even if you have your home directory in AFS.

Novell eDirectory

[VikingBrad]

Novell does many things wrong but their eDirectory ( http://www.novell.com/products/edirectory) product is clearly the leader

It runs native on Windows NT4, 2000, Linux, Solaris, AIX and Netware 4, 5 & 6.

It also is LDAP 3.0 compliant and is managed through a Java-based console that will run on any platform with a JVM.

It also has flexible Authentication extensions and Account Management for Windows, Linux & Netware that enable administration of file system shares.

And for all that developers can bundle a 250,000 user version of eDirectory with their Apps for free (http://developer.novell.com/edirectory/)

Although its not open-source it should be bundled with Linux distributions targeted at large organisations to provide a scalable, cross-platform secure directory system

Lots of options

[--daz--]

The two main options you have are:

- Kerberos
- LDAP

Kerberos is supported very well on Windows 2000 (and XP/.NET) and Solaris. Last time I checked, kerberos support on Linux was luke warm, but that may have changed and I may not have been looking in the right place.

Despite the myths, Win2K kerberos is 100% compatible with Unix kerberos. If you're using Windows 2000 servers and Windows 2000 clients, there's some extra stuff they pass in a "Vendor Specific" section of the Kerberos ticket. Unix systems will ignore this and can authenticate with a Win2K server.

Likewise, Win2K clients can authenticate against a Unix kerberos server. The Win2k clients won't be able to take advantage of the Win2K ADS features (like Group Policy or multiple group membership) but if you have a Unix server, you're probably not using these features anyhow.

- LDAP

Active Directory for Windows uses LDAP to communicate. Unix and Linux hosts can authenticate against it.

I don't think, however, that Windows clients can
authenticate against a Unix LDAP server without special software on the Win2K boxes.

If you go Novell NDS, however, you not only add a third or fourth OS (and why would you want to add Novell? It sucks compared to Windows, Linux, and Solaris), but you have to start installing their stupid software on all or most of your boxes. It's a nightmare you don't want.

Another alternative is NIS. There are 3rd party NIS vendors that make NIS GINAs for Windows 2000.
NIS is pretty hairy and less favorable than Kerberos or LDAP.

If I were you, I'd probably go Kerberos assuming that Linux kerberos support has grown up lately.

LDAP isn't a bad alternative assuming that you don't mind having a Windows 2000 server control the authentication for your systems.

Re:Lots of options

[Anonymous Coward]

Sounds like your ignorant adivice is the nightmare "you don't want". eDirectory hasn't required NetWare (the OS of which you speak cluelessly) for 5 years. Wake up and join the 21st century! Or better yet, go back to sleep and keep your mindless so-called "advice" to yourself.

>If you go Novell NDS, however, you not only add a third or fourth OS (and why would you want to add Novell? It sucks compared to Windows, Linux, and Solaris), but you have to start installing their stupid software on all or most of your boxes. It's a nightmare you don't want.

Re:Lots of options

[Anonymous Coward]

If you go Novell NDS, however, you not only add a third or fourth OS (and why would you want to add Novell? It sucks compared to Windows, Linux, and Solaris), but you have to start installing their stupid software on all or most of your boxes.

NDS (now called, urgh, eDirectory) runs natively on Windows, Linux and Solaris. No NetWare or IPX required.

Microsoft and Unisys have this problem solved.

[tshak]

Apparently, Microsoft and Unisys have launched a website dealing with people who have "Cross Platform Issues": http://www.wehavethewayout.com/.

You certainly get what you pay for.

[Nick Driver]

This product definitely bears a notable price tag, but then you get what you pay for too. I especially like the way they express the requirements to get authenticated:

#1) you have to have something... and

#2) you have to know something

Works on all platforms seamlessly

[Anonymous Coward]

Marble Composition Notebook, UPC #26538-10100, Publisher: American Scholar, Bay Shore, NY 11706

Works on all platforms, if you get the 80 sheet version, slightly different last couple of digits on UPC. Even works with MS embrace and extend code. Compatible with all browsers as well.

Windows Active Directory and pam_smb

[TheCow]

In the Computer Science Department of Graceland University we needed to fulfill the same type of problem you are having. We wanted to authenticate to the Universities Active Directory for out Linux and Sun labs, however we didn't want to have to set up the kerberos keys for each client that would be authenticating.

We found a pam module that allows any pam enabled program/OS to use the Windows Active Directory for password authentication using pam_smb.

Further information can be found at: http://www.csn.ul.ie/~airlied/pam_smb/

Hope this helps.

Todd Volz
Graceland University
CS Lab Administrator

Re:Windows Active Directory and pam_smb

[TheCow]

If you have a Windows Active Directory already set up and contains everybody, then it might also be benificial to look at setting up the Services for Unix from Microsoft which includes NFS server and an NIS server along with some other tools. This can allow a central home directory (if offered) and a central user database. In this case you wouldn't necesarily have to use the pam_smb module I described before.

The white paper of Services for Unix from Microsoft

Re:I have the way out!

[Anonymous Coward]

YHBT

NIS...

[capsteve]

is your friend. LDAP could be your friend as well, but the adoption of NIS by the major unices, and it's strong connection with NFS make it an ideal solution for one login/passwd for multi-server authentication, and email.

we used to authenticate via NIS+(before we were purchased and told we were going to LDAP, still waiting after three years, but that's another story...) and i loved it! we were a prepress company with 6 seperate locations and several dozen servers scattered thru out the enterprise serving appletalk, email, home directories, and data collection. no matter which location you were at, you could use your single login/passwd to login to any other server, mount you home dir, and go about your business.

it took a bit of end user training(users wanting to save their mail on local drives instead of home directories, among other issues) but it was well adopted, and easy to maintain thru sun's solstice frontend.

the environment was hetrogeneous(solaris, aix, irix, linux, nt, macintosh) and all machines authenticated nicely, with the exception of earlier windows machines. had we deployed samba we would have had an easier time.

beware the difference of NIS and NIS+: NIS+ was sun's "updated" version of NIS. NIS is far more open and friendlier than NIS+... the irix and linux boxes preferred plain NIS.

the best benefit was the ease of administering the end users. one entry change propogated thru all machines... no more rushing from box to box when someone was getting canned. user can't remember email and filesharing password? no problem.

wan to migrate to LDAP cause NIS doesn't have everything you need? no problem with that too, tools exist for easy migration.

Here is the recipe!

[Anonymous Coward]

This is what I do for a living...full time.

First, you need a repository for all the authentication and authorization info. Novell eDirectory is the best choice for many reasons. One of the best reasons is because eDirectory can store information that not even the directory admin can access....it's possible to build system that the admin can't compromise.

Second, you need a variety of ways to access this information. The common ones are PAM modules, direct LDAP calls, redirection modules, NIS redirection, RADIUS, RACAF, TACACS+, Screen scraping/keyboard stuffing, SecureID interface, and biometric interfaces.

Third, you need a way to synchronize with legacy systems that can't be bypassed using one of the above methods. DirXML is one of the best ways to make this happen.

JC
JWCOMBS@LDAPEXPERTS.COM

Easy using apache/mod_ssl/PHP/mysql

[dfn5]

I put together a system that I use in-house for doing just that (hence it wouldn't be hard for anyone else to reproduce).

The way I did it such that the passwords are never stored on disk is to encrypt the passwords using MySQLs built-in encryption with a really long password randomly generated by perl.

But then I would have to store this password somewhere if I wanted to decrypt any password thereby defeating the purpose. So what I did was to encrypt this password using the user's apache auth password which wasn't stored anywhere but in the user's head. A consequence is that if everyone forgets their password then all the passwords are lost forever.

Therefore, to view a list of passwords, a user would go to the SSL encrypted web page and enter their password to authenticate against the web server. The web server would take that password and use it to decrypt the key stored in the database. That decrypted key is then used to decrpyt all the passwords and display them.

The web page was also set to not cache on the client side.

Now granted, this isn't fool proof, such as the browser could ignore the caching hints, and the fact that the decrypted password key would exist in the apache process for short periods of time, but it is good enough for me.

Samba

[Gerdts]

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.

PasswordCourier

[kwelch]

Check out PasswordCourier (Warning - Flash required). I know it works well - I work there :-).

Re:OpenSSH supports Kerberos

[Anonymous Coward]

The awesome BSD-licensed OpenSSH server can support Kerberos (as well as several other authentication methods including SecureID).

putty

[morgajel]

putty is a good ssh client for windows- I'm not sure if it's what you meant tho... really configurable, and we we normally reccomend to freshmen who are still using telnet.

SeOS

[Anonymous Coward]

I'm a systems administrator for a large telco. We use "SeOS" on most of our boxen. http://www.astrom.se/cai/etrust/ac/index.html

It's not bad and it allows such functionality like allowing certain groups and users trusted su capibility. Performs scheduled required password changes and other fun stuff..

P-Synch

[shking]

M-Tech, a Calgary company makes P-Synch, a cross-platform password management system. P-Synch supports over 60 types of systems including: Unix servers, Windows NT, Windows 2000 active directory, OS390 / MVS mainframes, LDAP directories, email, groupware and popular ERP applications, such as SAP and PeopleSoft.

M-Tech showed P-Sync off to the Calgary Unix Users Group last year. When I saw your story, I immediately thought if them.

The Passphrase Method

[_Sprocket_]

2.passwords should look like they were randomly generated (esp. no English words)

...

...there is no way I can memorize a 10+ randomly generated strings. Aren't security experts being a little hypercritical?

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.

Try this

[crivens]

Try M-Tech's PSync.

Cross-Platform Password Database

[SkewlD00d]

Pencil and paper.

To backup, simply hit [COPY] on the copying machine! Want security you say? Simply buy a safe and install your database there.

Re:"Active Directory" was re: LDAP

[rkhalloran]

"that much loved 'Active Directory' is nothing more than an LDAP server with a fancy schema and ranch dressing".

Unfortunately, it's a little more (but just a little) than that. The Empire took the public LDAP spec and glued in a tweaked version of the public Kerberos spec [for the actual 'password'] to create a bastard blend supported by no one outside of Redmond WA.

And of course they then turn around and trumpet how they really DO support open standards, see?

PHP LDAP

[gkhopper]

PHP includes a module for LDAP (search for 'ldap' in your php config file). I'm using LDAP with the win32 binary distribution, running as an ISAPI module for IIS 5, and it works great. (Well, the PHP part works great, anyway)

Keyring - a PDA-based passwd management app

[halfelven]

I know this is not an answer to the original question, but merely a finger pointing in a different direction. ;-)
When you have a lot of passwords and other sensitive data to manage, give a serious thought to buying a PDA. You can get a Handspring these days for $100, and with the right application you can keep all your passwords secure.

Here's the magical application: http://gnukeyring.sourceforge.net/

Shortly, it's like Memo Pad, but it's password-protected and encrypted. Now there's no need to remember hundreds of passwords, you only have to remember one - the master password that protects the entire content of Keyring. ;-) You cannot access anything in the Keyring unless you know the master password.
The data is kept under strong crypto: Keyring uses 3DES and other crypto voodoo to make sure no one is able to snoop on your data. It's enough to pick a good master password and that's it.
The application is quite carefully designed. I'm using it to keep all the root and enable passwords for all servers and routers that i'm in charge of, and also my banking accounts passwords, credit card numbers, etc.
It's quite cool, give it a try. ;-)

LDAP + non-PAMified systems

[chrysalis]

LDAP is a nice answer. Because it's simple, extensible, and supported by a lot of operating systems and daemons.

But there are exceptions. Like BSD systems, that don't provide nss_* hooks (unlike Solaris and Linux). PAM isn't enough. PAM only provides authentication. It doesn't provide home directory, shell, gecos, etc.

Does anyone know of a library (that you preload with LD_PRELOAD) that replaces getpw*() functions with LDAP lookups, and that would work on BSD systems?

kerberos and development

[SgtChaireBourne]

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.

From a developer's point of view this was great -- no (well, almost none) user management hassle, few worries about password files, etc. We could concentrate on building the service rather than managing accounts, passwords, and groups. The kerberos / LDAP servers verified the user and group memberships and passed that information on to the service being used.

I'd strongly advocate any large institution to check out the University of Michigan's computing infrastructure, both the general one and the engineering one. Do it before the MS Sale Strike Force hits your IT-Council, IT-Advisory group or IT managment group with free doughnuts and WinXP coasters. :P

Re:kerberos and development

[cymen]

This looks to be one place to start:

http://www.lsa.umich.edu/lsait/default.asp

Do you have anymore?

Anecdotes from Chalmers?

[SgtChaireBourne]

Is there anyone from Chalmers who can describe the computing environment there?

Doing it with ADS

[Babel]

Here's an article on doing what you want, using Active Directory. It's not a good solution (NDS eDirectory is better, like others have posted) but it does work:

http://online.securityfocus.com/infocus/1563

Enterprise Solution

[Chas2K]

enRole from Access360 does this and whole lot more. You can use it to provision every component of an employee's profile including all network, email, computer systems access. Individuals can make these changes in a trusted system or it can be left up to an admin.

http://www.access360.com

Ganymede

[jonabbey]

Take a look at Ganymede.

Ganymede is designed to provide a single multithreaded network directory store for (among other things) password information, then to write out datafiles and runs scripts to propagate your directory information into your environment whenever a user commits a transaction to change anything.

Ganymede is useful for people who want to unify differing directory mechanisms, and who don't need a full hierarchical domain structure like those supported by Active Directory or Novell's eDirectory products.

We use Ganymede to synchronize passwords across UNIX NIS, Windows NT, Samba, Apache, and more. We have a userKit that provides for password management across NIS, NT, and Samba 'out-of-the-box'.

That said, Ganymede is mostly useful for people who can't force-fit all their clients to use one network authentication system, although it does provide a very high level of convenience and hand-holding for your users.. Ganymede has support for setting expiration dates on accounts, and for sending email when an account is about to expire, etc. It also maintains full auditing trails for everything, and allows controlled delegation of permissions to administrators.

If you can live within the limitations of its orientation around a flat namespace, Ganymede's flexibility makes it hard to beat.

Unix Services

[Arricc]

Don't have any personal experience of them (not yet, anyway...) but I know that Windows 2000 Unix Services (comes with the Resource KIT IIRC) allow your Win2K box to serve NFS and NIS out of your Active Directory... More info

P-Synch allows cross-platform password synching

[UncleDuncan]

There was review in Linux Journal back in 1999 of a product that addressed this problem:

http://www.linuxjournal.com/article.php?sid=3040

The company is M-Tech http://www.m-tech.ab.ca/, and they have a product called P-Synch that allows you to do cross-platform password syncing.

I've never used p-synch. We use openldap instead of a commercial product, but we don't use it for root passwords. Seems to me to be a security risk to have root the same on all boxes. You might be better served by having some sort of password scheme/algorithm rather than a common login, especially if the issue is being able to remember the password, rather than ease of mass changing/syncing of passwords.

RADIUS on Windows

[Thumper_SVX]

I use Windows 2000 server at work, simply because that's what's been mandated by management. On one of the servers (the Exchange server) I installed LDAP and RADIUS. This allows me to extend my system using Linux boxes I use for development.

Basically, the way it works is the Linux boxen, Cisco PIX firewall etc. all use RADIUS for authentication... I even have the RADIUS plugin for PERL that allows my intranet applications on Linux to use the same authentication database. I use LDAP to grab the actual user information when I need it; user name, location etc. The PIX gives us VPN capability using the normal Windows passwords.

Food for thought perhaps?

There is no Perfect Solution

[ThrobbingGristle]

I also worked in a NOC that faced serious password overload issues. Now I work in the engineering group at that same company as a UNIX admin and it's almost as bad for me personally as it is for the NOC.

The problem is simply that there is no solution that will do it all. There are simply too many devices in a modern network (especially if your company is into telephony as well) to find an easy solution.

However, the best solution is probably to figure out what the "big three" devices/operating systems are in your network. Then I'd try and figure out what authentication method is supported natively (or with little trouble) by all three. You're in luck with Solaris and most linux distros (all?) because they natively support PAM. (Many other unices probably could use PAM with a little work or may support it out of the box these days.) PAM is nice in that it supports many authentication methods/protocols including LDAP, Radius, and authentication against a mysql database. Cisco supports radius (and probably tacacs, maybe others.) These are the big three I have to deal with and I will probably try to implement a radius solution soon for that reason. But then I also have SCO OpenServer to deal with (unfortunately). And OpenBSD, and HP-UX. And a couple of NT boxes. And some Radlinx PassAPort terminal servers. And some web-servers that need authentication. And likely a whole bunch of other systems/servers/services that I can't remember that could really use to be unified.

The solution? Like the guy above said, stick the info into a database (mysql is painfully easy to set up but obviously you need to pay attention to the security of your mysql server, but you can use Persistent::File perl modules or anything really) and provision radius or kerberos or LDAP or /etc/passwd files from that with perl or the language of your choice. Why put the passwords into a database and not straight into LDAP? For all the reasons that people choose to put data into an sql database usually. (And because then you can claim to be a database admin when you go looking for your next job, and DB's can make some serious money.)

Good luck! (And someone wish me luck too.)

Novell eDirectory

[wilpig]

http://www.novell.com/products/edirectory/

This is a cross platform directory service that would suit your needs. I have seen it in use between Novell systems and NT systems but I was told that it works with UNIX based systems as well. As a database it is very quick for accessing and changing information between NT and Novell systems. Can't speak for the UNIX environments, yet, But I would love to hear how it works from anyone else in the field.

Access360 has an excellent commercial ...

[Anonymous Coward]

... product for password management called "enrole" ... http://www.access360.com

What about software tokens?

[Anonymous Coward]

At one of the places I work, we have both physical (SecureID) and software based tokens. I've wondered why no one has come up with an open-source initiative to make a software token system. This passwords are generated with complex seed info (user's name, password/PIN, secret passphrase and MAC address all used together), and constantly changing, but the token is in sync with the authentication server. It seems to work well for my employers. If it could be combined with VPN (IPSwan) I think we'd have a winner. Anything like this out there? I haven't seen it.

Re:What about software tokens?

[eno2001]

This person makes some really good points. I've seen others mentioning security dynamic's secure id tokens, but no one seems to have mentioned the idea of a software based token that you install on your machine. Or.. even better, a PDA. Virtual tokens should be what we are considering. I understand that there are software based tokens from RSA/Security Dynamics. Why aren't we doing this? (Yes, I can't code, but I am sure someone else has gotten "the itch")

NIS for Windows

[Anonymous Coward]

Has anyone looked at NIS for Windows?

Control-SA PassPort - password synch & self-se

[CoderDevo]

BMC Software's Control-SA PassPort is very popular for large organizations. They have an offering called QuickPass Self-Service Password Management that solves the poster's problem.

Users are able to change and reset passwords 24x7 from any Web browser or automated telephone system. They can solve their own password problems immediately instead of calling the helpdesk or a sysadmin.

Control-SA's bi-directional management capabilities automatically detect and propagate user-initiated password changes throughout the enterprise, ensuring that a user's passwords on all platforms are always synchronized.

For example, if someone changes their password in Solaris, Control-SA will immediately propogate that new password to their accounts on Novell, Active Directory, RACF, NIS, LDAP, Oracle, etc.

I enjoy working as a developer for BMC.

Aaaaarggghhhhhhh!!!!!

[juliao]

Please, not NIS... I'll do anything you ask, bot _NOT_ NIS again...

Oooohhhhhhhh, the undead are rising.......

LDAP w/Kerberos

[Edgester]

I would suggest LDAP with Kerberos v5 for the passwords. LDAP gives you the user info such as username, uid, and home directory. Kerberos v5 would be used for the passwords.

Just about everything can support kerberos.

Scary thought: Do kerberos authentication against an Active Directory tree.

Did anyone read the article?

[Diamon]

The original poster is asking for a system to store passwords not an authentication mechanism. Every post rated 4 or above is suggesting Kerberos, SSH, LDAP and other authentication mechanisms, all of which are off topic for the post.

There were a few on topic replies suggesting web servers etc, unfortunately they were never modded high enough, and unfortunately I have no mod points at the moment.

Re:Did anyone read the article?

[novikov]

Did you?

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?"

accessing a central password file sounds to me like they are trying to authenticate...

Re:Did anyone read the article?

[Diamon]

Yes.

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.

It's kind of obvious the poster is trying to keep track of passwords not authenticate passwords.

Meta-meta ....

[fm6]

No wait, you're an AC. Never mind.

Iow tech, very effective

[strombrg]

gpg. ssh. designate one of your linux or solaris boxes with a little local disk space. Get everybody to ssh into this box to look up passwords when needed. Make sure to wrap it with a umask-aware shell script.

BTW, if someone steals your password list, you're probably SCREWED, just like we would be. Hence we don't do our entire password list this way. We prefer to sacrifice convenience for security by keeping our list on paper in a safe. Recently, we've decided to keep the most recent stuff on paper, but to keep an older copy on cd-r. They're both equally likely to be stolen I suppose, but we don't have to type the entire paper list back in every time we want to overhaul the list (crossing and rewriting gets to be too much after a while)

directory service

[ezs]

Many people have found a cross-platform directory service useful for such purposes; plug in LDAP, PAM, NT Domain, Active Directory etc etc etc.

One thing to be aware of is that centralised identity management is not single sign on; ultimately customers need the freedom to use their authentication credentials to best suit their environment (whether that is uid/pwd pair, digital certificate, token, biometrics, kerberos cert ..) lowering everything down to the lowest common denominator doesn't really sound too much use!

Why They Lie

Novell - eDirectory

Novell Single Sign on

[travellerw]

Novell's single sign on product will do exactly what you are asking for. Currently their product snaps into e-directory which can run on all platforms that you mentioned (Windows, Linux, Solaris and Netware). Take a look at it.. Novell has really gone out of their way to support multiple platforms. As a bonus they are one of the only company's embracing the open source community. Some of their products are developed for Apache and Jakarta Tomcat. They are also actively contributing code to both of those projects.

UNIX/Windows/ Solaris

[dlazar]

I work for a company by the name of DataLynx and we can handle all the issues you have specified in your posting. We specialize in Identity Management-User priveledge-auditing. I invite you to visit our web site www.dli-security.com and download our product to evaluate. If you have any questions, please feel free to contact me. Regards, Luke Bischoff 858-560-8112

eh?

[jonr]

Maybe I'm misunderstanging the problem, but wouldn't a secure webpage with all your passwords be enough. Only thing that I can think of against it, is that people can peek over your shoulder.
But the web is 100% cross-platform. (Isn't it?)

Synchronize instead of Centralize?

[Thwyx]

Instead of centralizing with one database, which isn't practical in a diverse OS environment, you could consider synchronizing instead? Courion - http://www.courion.com - , password synchronization software, has agents for Linux, LDAP, Solaris, AIX, HP-UX, NT, and many others. Unfortunately, it's not free. You keep a centralized account database, and when you change a password, it connects to all systems and uses OS native methods to change the passwords on those systems, too. It also lets you specify password complexity, expiration times, etc. It's really a pretty cool system if centralization isn't practical for OS'es that won't support real LDAP (like Windows).

X.500

[Anonymous Coward]

Metadirectories and X.500 :)

distributed s/key?

[Anonymous Coward]

It should be possible to write an encrypted distributed login application using s/key or even secureID.. I've never actually seen one, but it gets around the single password on each system, and worrying about passwords being compromised.

Oldman's memories

[chanio]

I remember I used the ancient MsDOS and in the manual it explained that it was aiming to become a UNIX version for PCs. Unix was meant for big hosts that were really multitasking.

Besides, I think that admitting that the comfort of Windows is better that LINUX or GNU is admitting that one has never written a line of code.

And especially that one has never had the needs of reading the obscure manuals of Microsoft.

Or never knew that that company makes it hard to any competence to get the code to plug something new to MS!
Those things show that the real intention is to prevail as the only company that would survive (in a comercial world).

But when I discovered LINUX I found every single line of good code that I thought that was lost in the history of PCs. LINUX is people!