Enterprise-Level Authentication for Linux?

Jon Hill asks: "Authentication is an integral function of any network but the problem of unified authentication on large distributed systems becomes daunting when you look for Linux based solutions. I am the MIS Director for a technical R&D company with 10 locations in several states and have pushed Linux at the server level successfully for several years. As the system has grown the need for a unified authentication scheme has become a necessity. I have looked over NIS, NIS+, LDAP, Kerberos, and others but haven't found anything that will unify even our servers (ie. file/email/FTP). All sites are linked via a static VPN so there is good secure communication available. What suggestions do readers have to solve what I'd have thought was a common problem? Any case studies, product links, code, and other examples will be appreciated." Any Slashdotters who run enterprise-level installations care to comment on how well Linux's authentication works? In your mind, what does Linux need to do to improve it's profile in this regard? Could PAM at least provide a partial answer to this question, considering that it would provide a way for any authentication scheme to link into the system as a whole, without having to force hard-to-maintain code changes in the user-land applications.

Comments

The kernel dosent need it.

[AntipodesTroll]

Everyone considering auth inside the corporate structure should already know that the kernel is not the place for any-and-all auth schemes. Sun know this, thats why PAM is part of Solaris, and that seems good enough for the Solaris commercial environments.

This is the whole idea behind PAM. Give the hooks needed to implement your own modules, that is the simplest and best thing *LINUX* can do for auth. Let other groups, like Samba, and those who work on Netware, and other groups who concentrate on interoperability, come up with modules for PAM. People who are interested should read the stuff on winbindd in Samba 2.2.2, its good stuff. And that said, nowdays the auth options for Linux-based OS's are good and getting better.

ObSlashdot: "In your mind, what does Linux need to do to improve it's profile in this regard?" Well, why do Slashdot editors wish to insult those posters that have a clue, while patronising everyone else? If you wonder why people troll, your answer is right there. (Watch me get slapped for this! :)

What kind of research did this guy do, anyway?

[disappear]

You can do this with NIS, Kerberos, or LDAP on Linux, using PAM modules. In fact, out of the box, Red Hat can support any of those three. New versions of SAMBA have a beta-quality utility to do the same from a Windows domain controller, IIRC.

Now, it's entirely possible that this guy has some needs that weren't articulated in his message --- but if so, he should have articulated them in the message, as the basic case is trivial on Linux. AFAIK it should be no problem to authenticate for any of the afforementioned tasks.

That said, PAM is a major PITA to configure: the files are rather opaque if you haven't used them before. (Need a consultant? I'm available: www.cluestickconsulting.com)

Excellent question

[FreeLinux]

This is an excellent question. One that I have done a couple of AskSlashdots on in the past. I too encountered a similar situation where, I would like to use Linux but was not interested in yet another authentication mechanism. Nor was I slightly interested in managing, potentially, thousands of workstation user lists individually. I wanted a mechanism that was more reliable and functionally scalable than NIS and I wanted it to be usable by all systems. Basically I wanted a single directory for the entire enterprise.

I have done a lot of research on the subject and extensive testing. Naturally I would have preferred a free solution, which suggested that OpenLDAP would be the solution of choice. But there are numerous issues with OpenLDAP.

One big problem is that it does not scale well. Sure it can handle massive volumes of users but, redundancy and more importantly distribution or replication are not yet adequate for enterprise use. This is also compounded by the fact that I also had to tie in Windows 2000 systems and applications. While active directory claims to be LDAP compliant, it is broken from a standards perspective. This severely limits the use of Active Directory as the central directory, not to mention the fact that it requires add-on software from Microsoft in order to authenticate *nix systems against it. Furthermore, because of Microsoft's proprietary extensions it is not possible to use OpenLDAP as a replacement for Active Directory.

Thus far, the best that I have found is Novell's eDirectory. There is also a second Novell package that is required if you will also be integrating Windows 2000 and Active Directory, you cannot eliminate Active Directory. The second package is Novell Authentication Management (NAM). This allows eDirectory to manipulate and synchronize Active Directory to eDirectory pretty seamlessly.

eDirectory runs on almost any platform. It runs on Netware, Windows 2000, Solaris, AIX and most importantly Linux. It is super scalable and easily handles distribution and replication. It offers authenication management for just about any platform and it has reasonable support from various application developers.

If you use Windows 200 apps like Exchange 2000 you still *have* to run Active Directory as well as eDirectory but, with the NAM package there is no need to ever manage Active Directory. All of the management is done in eDirectory and anything that needs to go into Active Directory is automatically pushed there.

Novell also has a product which I have not yet tried. It is an XML based add-on to eDirectory. Basically it will handle synchronizing other various directories to eDirectory. For instance, if you run SAP or some such application that has it's own authenticatioin system, the XML product will perform two way synchronization between eDirectory and your applications native directory. This propogates any changes made in one directory to the other.

You can get a free copy of eDirectory for Linux here. (Registration required) It's not the free solution that I had hoped for but, it seems to be the best around and it isn't too expensive for enterprise level software.

Maybe not such a good idea

[tdyson]

While the dream of a single password is a cool idea, I have concerns about how secure that is. Sure, you can probably get LDAP to do it all, but should you? Picture an environment that is a mix of ftp and ssh. You use SSH, because we all know telnet is insecure. If you have the same password on both ftp and SSH, you have given up a major layer of security. If you want to limit the number of passwords, you should, at a minimum, probably have one for "more secure" systems and one for "less secure". Anything that transmits in plain text, like stock telnet, ftp and POP, should be separate from anything that transmits encrypted data, like SSH and HTTPS. Defense in depth encourages multiple passwords. Strong security always seems to be at odds with ease of use. You don't have the same root password on all your boxes, do you?

Re:Maybe not such a good idea

[Anonymous Coward]

1) In practice, having different passwords for different systems is more insecure because the users write down the passwords on a stickynote and never change them. Just run your POP3 or whatever over SSL.

Maybe I'm the only one here old enough to recall Novell 3 networks with 100s of servers, each with their own password list. Living Hell On Earth.

2) The simple answer to your question is that if SSH doesn't recognize your directory service because it's a dumb point-to-point system, then don't use SSH. There's various Kerberos-ized telnet solutions out there. FTP should probably be mercykilled and replaces with HTTP/WebDAV over HTTPS.