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.

Surely LDAP?

[Anonymous Coward]

Using LDAP and PAM/SASL you can use the same set of login credentials for Unix, Novell and NT.

You've also got centralized management and administration, and don't have to limit this to login credentials either - you could store the ip addresses of each host, the configuration of every printer etc...

Re:Surely LDAP?

[Anonymous Coward]

I should also add, that using LDAP allows you to enforce a whole load of profile restrictions ontop of your Unix login restrictions.

For instance, you can make some accounts/groups only able to login between certain hours of the day - and this will be true for everything that uses the LDAP authentication - be it Windows client, firewall, unix workstation - whatever.

Theres a whole bunch of other stuff that you can makes use of too - quota limits across all platforms, the ldap directory also (handily) will serve as an enterprise wide telephone/address book - so you can hook it straight up to your intranet.

Theres a really good book about all this "Understanding and Deploying LDAP Directory services", published by Macmillan technical publishing. Its a weighty tome, but very informative.

Re:Surely LDAP?

[briansmith]

For instance, you can make some accounts/groups only able to login between certain hours of the day - and this will be true for everything that uses the LDAP authentication - be it Windows client, firewall, unix workstation - whatever. I understand using LDAP for authorization, but how would it work for authentication?

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 [aarnet.edu.au] 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! :)

where are the secrets

[Dr. Tom]

You don't want to duplicate secrets. If possible, you don't want to transmit them all over the place either, though that's not so bad if done correctly. One way is to use a public key system, so that the secrets are stored on the client machines. Every server knows all the public keys, because they can be stored centrally on a keyserver or duplicated around the network; republishing them if they change is no big deal 'cause they're public. You could do this with OpenSSH.

If you perhaps do not trust the client machines, though, which you might not if they are Windows boxes, you would not want to use just public key crypto. You would also want to use a passphrase based system, and then you are back to having to have secrets on the servers, which need to be very carefully republished when they change. And you might not trust some of the servers. OpenSSH (and especially OpenSSH with the SRP patch) can do this, and it'll authenticate both the client *and* the server, so that both parties know they are connected with the entity they think they are connected to.

You might also want to look at SFS (a secure distributed filesystem based on NFS but with SRP authentication). Note that there are several projects all called SFS -- I'm thinking of the self-certifiying one [fs.net]. Then you can have central administration of server-side secrets. Probably some of the other projects called SFS would be good too, but I'm less familiar with them.

LDAP

[CounterZer0]

Well, LDAP will do this. And it'll do it on a whole bunch different platforms. If you want really, really, nice LDAP implementation, go for eDirectory by Novell.

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 [cluestickconsulting.com])

V-ONE

[RalfM]

Sounds like what V-One [v-one.com] do...

R

eDirectory (NDS)?

[sphealey]

Have you looked at Novell's eDirectory?

sPh

???

[Raleel]

you looked at krb and ldap and you didn't see enterprise level authentication? Krb is what windows is using here shortly. LDAP along side it. Novell is LDAP. Um, MIT invented krb, it can't suck ;)

Perhaps you are looking for something other than authentication?

Re:???

[csw]

> Um, MIT invented krb, it can't suck ;)

Two words: Athena widgets.

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 [novell.com]. (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.

Re:Excellent question

[cornice]

I too have looked into eDirectory but have yet to implement anything. I have a friend who has worked at Novell for years and is a key developer of the NDS repair utilities. Anyway, I keep asking him why this is so hard to get. I had to spend way too much time researching this. I keep asking why I can't buy an inexpensive package that is designed for small to mid sized corporations running Windows and Linux. There has to be thousands admins out there running Linux and Windows who would prefer not to have a MS solution. NDS is very mature and secure and has ports to everything. I assume Novell still has big plans for NDS. Why can't I get it?

I don't understand

[FreeLinux]

What do you mean you can't get it? You can get it (56bit) free, here [novell.com]. If you want 128bit it costs $2 a seat and if you want NAM, I think it costs $26 per seat. If you can't find a local reseller call Novell. It is available and, apparently, has been for more than a year.

LDAP

[uslinux.net]

libnss-ldap will give you system level users form an LDAP server. pam_ldap will give you LDAP authenticated login via pam. Really, that's all you need. Any service which supports local users will work in this manner. You'll need to add uid, uidnumber, gidnumber, loginshell, homedirectory, and userpassword fields to your LDAP directory for any corresponding users.

FYI, I run a consulting company [uslinux.net] and have done this before. It's *more* difficult to work with NT domains as well, but LDAP is pretty much designed for this. If you don't think LDAP can do it, you haven't looked into it enough.

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.

Enterprise-Level authentication?

[cyberkreiger]

"Computer, identify Riker, William T. Access Code Theta Alpha 2 737 Blue."

PAM and LDAP.

[imagi]

I wrote a document on authenticating enterprise systems agains LDAP. May be of some use to you: http://imaginator.com/~simon/ldap/ [imaginator.com] It's actually pretty easy!