Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN) [LWN.net]

Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Posted Mar 26, 2007 14:17 UTC (Mon) by muwlgr (guest, #35359)
Parent article: Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Who cares about Flash/Java/filebrowsing ? Why force users to install this stuff by hand ???
You have IT-admin for that, and there should be sshd running on every workstation. Drop a handful of icons on user's desktop and teach him/her how to use these business-related apps, while isolating him/her from other unrelated and probably harmful/wasteful activities.

What FL/OSS really lacks to reach enterprise usability, is Win.Domain or Active Directory replacement. I.e. commodity central directory and single-signon. LDAP+Kerberos ? Good, next, what about email client with KRB authentication forwarding (like Outlook to Exchange) ? What about screen locker with KRB credential refresh on unlock ? What about logon with cached credentials when your DC/KDC is unreachable ? Linux/FLOSS does not give an useful recipe for any of these q's.

(Log in to post comments)

Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Posted Mar 26, 2007 21:04 UTC (Mon) by drag (subscriber, #31333) [Link]

Well for most stuff you have Kerberos PAM plugin, which takes care of all the tedious little authenitcation BS you have to put with in Linux (which there is a very good reason for putting up with). Stuff like screen locker, local logins, sudo, and anything else like that has nice integration.

But you have to BE VERY WEARY of using PAM for kerberos authentication for any network-based authentication.

The problem with PAM is that you have to send any passwords and such to that machine for it to be proccessed by PAM. Were as with kerberos it only works properly if you use your local cache'd credentials/tickets.

For example take FTP.

You can easily do two things for Kerberos integration. You can use a 'Kerbero'-ized FTP server OR you can use conventional FTP server and use PAM authentication.

With the kerberos FTP server you use your local cache'd ticket to the ticket granting service you obtained when you logged in originally (lasts 8 hours). You use that to get a encrypted ticket to the FTP service, then send that to ftp service. FTP service takes that and sends you back another certificate which you decrypt. Then that is authenitcation.

So the authentication goes both ways.. you authenticate to teh FTP server, the FTP server authenticates to you.

That way it totally removes any sort of network-based attack like DNS spoofing, or network sniffing or anything like that. If the FTP server is rooted they won't get your password since your password is NEVER transmited over the network. NOT ONCE at any time is any password EVER transmitted over the network with a proper kerberos-based domain. Encrypted or otherwise.

Now with PAM and convential FTP server you have to send your username and password in plain text over the FTP login protocol. The username and password get sent over the network and your FTP server takes that, runs it using PAM, which then re-does all the authentication stuff over kerberos local to that ftp server.

Needless to say that a improper kerberos domain is MUCH MUCH MUCH more dangerous then a traditional Unix environment with passwords everywere.

And many seperate passwords everywere is much safer then a proper kerberos domain since if your KDC is a central point of failure. If the KDC is rooted then your network has entirely been rooted and the attacker has instance access to any and all services or computers anywere on your network with any network account that they choose.

So whatever KDC server you plan on using it better damn well be a good one.

However Single Sign-on is nessicary (either through Kerberos or maybe a PKI) for a proper modern business desktop. It's may not be strictly nessicary, but it's expect functionality. Its a hard requirement in the minds of many administrators and business owners.

For name caching you have Nscd daemon, which is designed not so much for offline name caching, but for taking the load off of busy servers. But you want to disable that if ever your working on a server or workstation since it can cause havoc with troubleshooting network issues.

For small to medium sized Linux or Linux and Windows mixed networks probably the best solution I think would be SAMBA 4, which is currently in development preview release.

It supports proper Active Directory-based authentication, which depends on kerberos. Currently SAMBA uses the older NT4-style NT Lan manager protocol, which is vastly inferior to what is used in a proper AD place. So the integration between Samba/Kerberos/LDAP in one SAMBA product should make things much easier for small to medium sized networks.

90% of everybody uses Windows somewere and SAMBA is a requirement to support that, so I don't have any problem with using it for a proper domain controller either.

For bigger stuff it's just plain difficult for whatever your using. Probably Fedora directory services plus MIT kerberos (which you can use with samba right now, I beleive).

I'd kinda like to look at PKI-based solutions since everybody in Linux-land understands mostly how that works.

Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Posted Mar 26, 2007 22:25 UTC (Mon) by muwlgr (guest, #35359) [Link]

You are right that PAM as a whole does not give a simple modular solution for Kerberos implementation&deployment. As we know, Kerberos is not just "one of" multiple auth.mechanisms. It wants to be "the" auth.mech. So applications-clients should be "kerberized" as well to support auth.cred.forwarding with optional fallback to traditional login/password. Not PAM, not even SASL are helpful in that. Only GSSAPI, with non-trivial application reworking, and today Kerberos is the only implemented underlying GSSAPI mechanism. I tried to deploy Kerberos "in pilot mode", so I think I had learned it to some degree.

Of course I look at Samba4 previews from time to time. Final Samba4 version would be good for Windows clients, but in most cases the final task is to get rid of Windows ! What adequate functionality is provided for Unix/Linux "workstations" logon ?

PKI with something like ssh passwordless logons - great, but much more client functionality still has to be developed on top of it.

BTW, we are digressing by misleading article title. See markhb note from Mar 26, 2007 17:25 UTC, I think he is right :>

Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Posted Mar 26, 2007 23:12 UTC (Mon) by drag (subscriber, #31333) [Link]

Ya he is.

I don't know how true it is, but I read once about one of the main reasons Microsoft was able to trounce Novell for workgroups back when they released Windows 2000 and AD.

So Novell had directory system stuff locked down pretty well in a technical way AND they released it well in advance to Active Directory.

However adoption was slow because going from a flat file server system for workgroup computing to a directory system setup were you not only have C and D drive and such you have OU's and different positions in the directory system to take account of was to much for most people to handle. So most people were happy to stick with their existing Novell servers.

So resellers and such weren't making much money from Novell.

However here comes Windows 2000 and Active Directory, which is the bee's knees according to Microsoft and numerous articles and such.

So all of a sudden those same resellers and such are pushing Windows and Microsoft very hard because they are making huge commisions off of convincing people to drop a huge amount of money in changing their infrastructure from older Novell workgroup servers to the new Windows 2000-based solutions.

So if this story is true then this illistrates is one of those huge problems faced by Linux commercial distributions. The sales folk that are targetting businesses, governments, and educational institutions have a vested interest in convincing their customers to keep Windows, not because it's better, but because it's _more_expensive_. They make money from commisions, not by saving their customers money.

Bake-Off: 4 Linux Desktops Tackle The Enterprise (CRN)

Posted Mar 28, 2007 0:26 UTC (Wed) by wookey (subscriber, #5501) [Link]

"90% of everybody uses Windows somewere and SAMBA is a requirement to support that, so I don't have any problem with using it for a proper domain controller either."

I'm the other 10% and it seems to me that the functionality of 'general authentication' and 'accessing windows machines' should be separate/separable.

I do agree that 'normal users' can't cope with different passwords for different funcitons on their desktops. They want the same password to work whenever a dialog pops up asking for it. They have no understanding of the difference between the dialog to access the keyring on their machine and the one to access an ftp mount. Even user/root passwords are a problem, which is why the ubuntu 'sudo for everything' approach works well - you always use your password, not sometimes use yours and sometimes use roots.

I have never managed to understand LDAP or PAM, and have never tried to understand kerberos, so thanx for the above idiots guide to how some of this works in practice.