The open source community has mastered many challenges and has been successful in numerous areas. However, there is one glaring weakness that needs to be remedied.
Introduction
Without progress in this area, open source in the enterprise will always play second fiddle to Microsoft, Novell, and other corporate computing entities. What is this critical weakness? Lack of support for Internet Explorer and MS Office? Hardware compatibility issues? Retraining users?
No.
The critical weakness relates to a very basic function of any network operating system. That weakness is the lack of a standardized, secure, interoperable network authentication system. This is a very real stumbling block to the adoption of open source in the enterprise.
“But wait!”, you say. “A stock *BSD or GNU/Linux system has hundreds of security tools! Compared to Windows XP, my open source workstation is more secure, has more security tools, and is infinitely more flexible! What about S/KEY Kerberos, OpenLDAP, IPSec, OpenSSL, OpenSSH, RADIUS, PAM, GnuPG, and Samba 3?”
Big deal.
By default, your system uses flat files. It does not use secure, network-based authentication. “But that can be installed and configured!”, you say. Sure it can, but it always ends up being a customized, site-specific solution that requires lots of time and effort to test, document, setup, and maintain. Making multiple Linux distributions and Unices work together is a time-consuming nightmare. Do organizations typically do lots of in-house development work to make sure that web browsers and web servers on their intranets can talk to each other? Do they develop custom routing protocols for their internal networks?
No. So why do we put up with this for network authentication?
IT managers want to be able to install servers and desktop client machines on their network that securely authenticate users against a centralized database. This should be a straightforward procedure. Until there is a standardized, interoperable, community and industry supported network authentication system included with most open source operating systems, Microsoft will continue to rule the enterprise.
The Problem Described
There are two issues that need to be solved in a network authentication system for Unix-like operating systems:
- global naming
- authentication
Global naming has to do with storing globally unique UIDs, GIDs, usernames, groupnames, and other network-wide information such as a user’s login directory and preferred shell. This can be handled by protocols like Hesiod, LDAP, and NIS/NIS+. This data is sometimes called directory information.
Authentication is the process of actually allowing (or not allowing) a user to login to a host or access a resource. Authentication can be handled by many protocols, including TACACS+, RADIUS, and Kerberos. In addition, authentication systems should be able to log authentication transactions.
For the remainder of this article, “network authentication system” will refer to both naming and authentication, since both are necessary to login to Unix-like systems and to access resources.
Microsoft, Novell, Sun, and Apple already support unified network authentication, and have been doing this for a long time. As long as you exclusively use the vendor’s proprietary system, all of your hosts will play together nicely. Microsoft, Sun, and Apple can utilize Kerberos and LDAP in their current systems. Novell is working on a Kerberos interface to their successful eDirectory system, and they can already authenticate Linux hosts to eDirectory via LDAP.
What we need is a system that is standardized to the point that any GNU/Linux or *BSD based system can be easily configured to use a standard network authentication scheme. I should be able to configure any common open source operating system to use centralized naming and authentication services after editing no more than two config files. It should just work.
In the Linux world, there is the Filesystem Hierarchy Standard (FHS) and the Linux Standard Base (LSB). These standards help all distributions work together nicely, and make life easier for application developers. Shouldn’t we have a standardized network authentication system? Having such a system would give IT managers more choices, prevent vendor lock-in, and make life easier for administrators and users.
For example, let us look at OpenSSH. OpenSSH runs on almost any Unix-like host, binary packages are available for most operating systems, and it allows terminal communication and file transfer between any two hosts. OpenSSH is ubiquitous. It is used as secure transport for an amazing number of protocols and applications. Wouldn’t it be nice if you could depend on your network authentication system to have the same amount of interoperability and flexibility between different Linux distributions and Unix flavors?
Solution
If IT vendors continue to develop their own special authentication systems and organizations using open source technology continue to “roll their own” custom authentication schemes, only Microsoft wins. An open source alternative is imperative.
I would like to see the open source community develop and promote a standard, open, easy-to-deploy network authentication system. The community should put funding, muscle, and top developers behind this effort. Obtaining corporate support may also be a good thing. Sun, Novell, and Apple have already done quite a bit of work in this field and could lend enormous credibility to the project. However, the project must stay completely vendor neutral and utilize existing open standards to the maximum extent possible.
For lack of a better term, I will call this system the Open Directory and Authentication System, or OpenDAS.
Key protocols/applications/functions which should be able to use OpenDAS for naming and authentication:
- Host logins
- Name Service Switch (NSS) lookups called by programs on the client
- E-mail (POP3/IMAP4/SMTP)
- Web (HTTP/HTTPS/WebDAV)
- Network File Systems (NFSv4, OpenAFS)
- File Transfer (FTP, SFTP, SCP, rsync)
- Remote Terminal (SSH, TELNET, RLOGIN)
- News (NNTP)
- Chat (IRC)
- Instant Messaging (XMPP/Jabber)
- Printing (IPP)
These are just examples of the types of applications and protocols which could be supported by OpenDAS.
What does an IT organization gain from a system like this?
- Unified sign-on (or single sign-on if certain technologies like Kerberos 5 are used)
- Centralized user and group administration
- Global password and account policy enforcement
- Enhanced security
- Vendor lock-in avoidance
- Ease of system configuration/deployment
- True choice in client and server operating systems
The server side of the system should be relatively simple to install, setup, and maintain. All the components would be integrated and work together nicely. Excellent documentation would be included. It should be vendor/OS independent, and allow replication and clustering for redundancy. Standard, scriptable command-line tools should be available for administering the servers. A standardized administrative web UI should also be developed (think of SWAT for Samba), which would obviate the need for installing a GUI on the OpenDAS servers. If installation and configuration is a grueling, arcane process, expect the adoption rate to be very low. Keep configuration simple, and standard.
It should only take a few moments to configure the client side of OpenDAS. It should work “out of the box” with Debian, Slackware, Fedora Core, Red Hat, SuSE, Mandrake, FreeBSD, etc. In other words, the client-side programs should be part of the base operating system release. Documentation should be excellent.
In addition to supporting open source GNU/Linux and *BSD operating systems, providing clients for Windows, Mac OS X,
and commercial Unix systems should be a priority. This will speed the acceptance and adoption of standardized, open,
network authentication systems in the enterprise.
Components
Which components should OpenDAS be based on? There are many options, but we can look at what large IT vendors are deploying and what some organizations using open source solutions have already done. Utilizing existing open source projects that are relatively mature should be explored first.
For example, we could construct the system from the following protocols and components:
- Kerberos 5
- NTP
- OpenLDAP(LDAP)
- PAM
- OpenSSL(TLS/SSL)
- Perl
Kerberos is used for authentication, NTP is used to keep all of the client and server clocks synchronized. LDAP is used for global naming and directory information. PAM is used on the client to allow applications to make calls to different authentication sources (like Kerberos) in a specific order, rather than having to hard-code authentication calls. OpenSSL can be used to encrypt plaintext authentication data or sensitive directory information. Perl can be used to integrate all of the server-side administration/configuration tools and processes.
SASL, GSS-API, and other protocols may be utilized as well. In this case, though, fewer is better.
The design should be such that a user with root access to an OpenDAS client machine cannot compromise the server-side authentication and naming infrastructure. In other words, there are no shared secrets between OpenDAS clients and OpenDAS servers.
On the OpenDAS server side, it may be wise to use some type of modular framework, so that adding things in the future like token cards or biometric information would be possible.
In order for OpenDAS to gain traction in the enterprise, all major open source operating systems would need to include the client software in the base install. On the server-side, the OpenDAS packages should be available as easy-to-install binary packages from the OS distributor’s CD or HTTP/FTP site. Automated, dependency-checking installs would be available for FreeBSD in the “ports” collection and for Debian in the APT repositories. RPM-based distributions could use Yum. It should be as easy to find and install OpenDAS as it is to find and install Samba.
Some people will argue that we can implement this type of OpenDAS today with Samba 3, or some type of Active Directory clone. However, I believe that the open source community can do better than simply mimicking Microsoft’s proprietary scheme, which can be changed at any time. The system should be completely open, and designed primarily for open source operating systems.
Being an open specification, commercial Unix systems could interoperate with the new standard. Mac OS X and Windows machines with OpenDAS client software could easily be added to the network.
Conclusion
If IT managers could add any Unix-like OS to the network with no authentication interoperability worries, then enterprise adoption of non-Microsoft platforms would accelerate.
Concerning the relative importance of this task in the hierarchy of open source projects:
- It is more important than new wireless card drivers
- It is more important than adding IPv7 support to the Linux kernel
- It is more important than supporting 256 CPUs
- It is more important than 3D video support or gee-whiz sound
Successful completion of a project like OpenDAS would push open source into the enterprise and the data center faster than many of the other projects that are being funded and pursued.
In short, centralized authentication and naming would become standardized, commoditized, and ubiquitous. This might be bad news for Microsoft and Novell, but everyone else would benefit.
The open source community has pulled together on many projects and standards. This particular challenge: developing, standardizing, promoting, and commoditizing an open source network authentication system, is both possible and practical to pursue.
This is a worthy goal. Let us join forces to accomplish it.
Links and References
Apple
OS X Server ships with OpenDirectory, which uses OpenLDAP and Kerberos 5. The server can also be configured to authenticate to other systems, such as NIS, eDirectory, and Active Directory. Regular OS X machines ship with MIT Kerberos, kerberized applications, and LDAP support.
Sun
Included with Solaris 9 and Solaris 10:
Kerberos 5 KDC
Sun One Directory Server
LDAP Support in Solaris Management Console
Secure LDAP Client
Solaris 9 Security Features
Solaris 9 Manageability Features
Novell
Novell’s eDirectory uses LDAP and works with Linux, Windows,
Solaris, AIX, NetWare and HP-UX.
Open Group
The Open Group’s DCE utilizes LDAP and Kerberos.
OpenLDAP
http://www.openldap.org/
MIT Kerberos 5
http://web.mit.edu/kerberos/www/
Heimdal Kerberos 5
http://www.pdc.kth.se/heimdal/
Pluggable Authentication Modules (PAM)
http://www.kernel.org/pub/linux/libs/pam/
About the Author:
Van Emery is a data Network Engineer/System Administrator. Currently he is working as a system administrator at Academia Sinica in Taipei, Taiwan. His homepage is here.
Great article. May his call to arms be heeded.
Well said that man. Far far far better than the usual “Linux is ready for the desktop and here’s why! I put my dog and gerbil infront of a Linux PC and they used it just fine!”
to paraphrase a friend, “funny how all these lucid solutions always solve problems that have been solved for like years.”
use pam (standard on most distributions accept for slackware) or kerberos.
next.
It’s already been done. Many times over. The last time I isntalled redhat it asked me about it during the install.
There are a few… Kerberos and NIS… and if you want, there is PAM which allows you to authenticate against various methods.
Want PAM? Forget it to become standard in OpenBSD. OpenBSD doesn’t like PAM. OpenBSD uses BSD_Auth because PAM is according to the developers (Theo) a mess and a security hazard.
If the latter is true, then why would you want that as part of a standard on all *NIX OSes?
If you make the program modular (or in this aspect) that problem would be solved.
But i don’t get the premises in the article. What is wrong with LDAPize all the daemons and use built-in LDAP support or NSS/PAM (except for unsupported NSS OSes like OpenBSD)? If you don’t want to configure flat files over SSH [for which you easily can write scripts which also exist for this example] then you can use Webmin to configure your daemons. There are even GUI’s to configure certain daemons, and to administrator LDAP (but i’d recommend scripting; much more faster). You could toss in Kerberos too (which Microsoft actually embraced & extend in AD).
Also keep in mind OpenLDAP is “bloated” and pretty much the only open, workable choice. It slows authentication down in my experience. Also see http://www.fefe.de/tinyldap/
After setting up OpenLDAP to hold user account info , and a kerberos server to do authentication, I’m impressed. This is really nice. Only one place to hold user info, and one place to do the authentication. And not having to type the password
all the time for secure web pages, ftp servers IMAP mail et.c. is nice. Only whish is more tools(especially GUI programs) had
support for Kerberos/GSSAPI.
Maybe Novel donates some of the stuff. They are like the new hero of open source.
i beg to differ, 3D video support or gee-whiz sound is more important
looks like a pretty dead project to me.
Now we only need a good administration tool that makes easy to install, configure and administer it all (like the Active Directory MMC snippet).
Doing it as separate pieces is a mess and too time-consuming.
Having set up a few of the “roll your own” solutions he talks about in the article I must say that he has a point. I think what everyone is missing is that this stuff is not easy. I don’t have as much trouble with openldap/kerberos as I use to, but that doesn’t make it trivial by any means. Everyone here that is commenting that it already exists needs to try to set it up on your network sometime. The point he is trying to make is that it needs to be EASY. Not stupid easy…but easy. Yes all the tools exist, but it’s NOT easy to implement not is it documented well. What he is wanting is for the existing applications to be integrated into one modular easy to install and maintain package. I have to agree. But there is no reason to why this should be limited to unix-like systems only. Surely there could be windows/novell clients as well. If it were dead simple to setup and administer a FREE directory server there would be no reason to buy a commercial product. This would be one killer app.
the long and often winding and branching history of authentication systems is littered with many good-but-not-quite-good-enough schemes.
all we need is some good well-thoughtout and differentiated protocols. they will implement themselves.
it is my humble opinion that the second larger icons which appear on the osnews news items are not needed. they are larger (take up space), they are not as informative as the normal smaller icons. just my opinion.
Kerberos,SASL,GSSAPI and LDAP as well as how to store user info etc. have been standarized years ago.
TinyLDAP was more a proof of concept than a real end-user LDAP implementation. It lacks quite a lot features; hence i said OpenLDAP is the only FLOSS LDAP solution.
“Having set up a few of the “roll your own” solutions he talks about in the article I must say that he has a point. I think what everyone is missing is that this stuff is not easy. I don’t have as much trouble with openldap/kerberos as I use to, but that doesn’t make it trivial by any means. Everyone here that is commenting that it already exists needs to try to set it up on your network sometime. The point he is trying to make is that it needs to be EASY. Not stupid easy…but easy. Yes all the tools exist, but it’s NOT easy to implement not is it documented well”
I have set part of this structure up (a Qmail-LDAP cluster; no KRB) and yes, it isn’t easy. Because you need to know what you’re doing. I wouldn’t say it is hard either, because there actually _is_ a lot good information about LDAP, Qmail, NSS, PAM and integration of that available. O’reilly also sells a few good books concerning these; one about network administration, one about OpenLDAP, one about Kerberos too iirc.
Because of that, you hire professional people who do have knowledge and studied for it. If you make it so much easier than it is now, you also make the bridge smaller. I, for one, don’t want Joe Doe with GUI skills to administrator a data center. I want a professional person with background knowledge instead and i still stand strong that CLI + scripting is _much_ more powerful than some GUI application. In the case of problems -for example this service goes down- one will have a problem themselves leading to ie. downtime or instability whereas the professional is able to log in and use the CLI plus his knowledge to find out and solve the problem.
Suffice to say is that i am not saying this idea is wortless or bad or something. It’s a double-edged sword, imo.
Standardized, with standard implementations yes. Unfortunately, this does not a system make. Compare it to what MS Active Directory or Netware e-Directory (NDS) let you do. You can provision software, assign end-user policies, manage computers. OK, that is authorisation, the step after authentication, but it is generally bundled up with authentication in a management sense.
The author is correct. It is one thing having lots of jigsaw pieces. What we need is the completed picture.
I second that opinion. Basically, I don’t think it’s about limiting choice or re-inventing the wheel. A lot of posts around here are right – all the components necessary for that are already here, but that is not the point. The point is: It indeed _is_ a time consuming work getting a combination of, say, samba, kerberos, ldap, postgresql, postfix and cyrus (that’s what I am currently messing with) up and running (a) in a way they fit together well and (b) in a meaningful way also accessible to other applications or services inside a network. Probably, the only difficulty is that all this technology is missing some “glue” to allow easy integration and configuration to fit all the pieces together. No – I am not too lazy to spend some weeks, probably months reading documentation and figuring things out since that’s how I learned all my life. But yes – my company surely will refuse spending time that long waiting for me to get something implemented which in several proprietary products is there, ready to use within a few hours if you know what you are doing. Having OpenDAP around would be of immense help in situations like those…
Cheers,
Kris
I want to wish you GOOD LUCK with Cyrus! Are you going to use Cyrus + SASL?
“I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you’re missing out on the fun.”
— Patrick Volkerding, Slackware 9.1 changelog
Now all we need is to get Novell to Open Source e-directory. add a couple of clients, adjust the distros to use it during install. hear me Novell??? you can be a looked upon with lovce if you set it free.
I believe it’s essential to have the clientside in the base package.
If the server side becomes easy to setup (as the intend is here), central authentication will also become more common and hence required. So shipping a basepackage without the client will be like selling cars without wheels. Some will argue that cars without wheels represent the freedom to chose the ones you like, but for the masses it’s simply annoyance.
I’m drooling… thats some good shit he’s smoking
He should talk to that d00d who’s doing Mono and take Linux to the next level
Every sysadmin had probably a dream like that, but let’s face it, we probably all have a directory already setup for that purpose…Hmm, yes every big corporation today has a Active Directory running somewhere…whether you like it or not, this is here and will probably stay! Why bother to install, maintain and synchronize a new one? You want a standalone directory, good, you just created a duplicate…You want to use some sort of metadirectory, good luck with the APIs.
AD is here, it works, it’s up and up and up (if not, fire your windows admins!).
Okay, what technology then? Kerberos is good (don’t you hate when M$ makes a smart choice! 😉 ). AD servers LDAP and encryption as well. Unix can do that so why not? Because for everybody who tried in the past, every Unix flavor (AIX, HP-UX, Solaris, Linux,…) does it “its own way”! PAM, BSD_Auth, NSS, IRC, SSL/TLS, Kerberos, LDAP, that’s a heck of a lot of technology to know about. Most of corporation needs to run a business, they do not have the time to play with that stuff.
What we need is a common client package that installs on the system as a legacy package for that platform. What we need is a common way to configure and manage.
Check this out then, I know it’s not free, but the idea is really cool and the best of all it works!
http://www.vintella.com/products/vas
Like another poster said…it’s not that it can’t be done, but I got the MS system up with one good book and a couple of weeks. I am in Kristian’s boat. So far I have books on BIND, postfix, samba, general linux administration. I am now to the point of looking for books on ldap, kerberos, and something for cyrus. It’s a TON of material to go through.
Yes when I am done I will understand it better, but in the end a simpler solution that I could read 1-2 books through to set up would be awesome.
>.Hmm, yes every big corporation today has a Active Directory >running somewhere
Ofcourse. But what about small to meduim sized businesses that
don’t run windows anywhere(Yes, they do exist, quite a few btw). They need an alternative as well.
Liberty Alliance Project
http://www.projectliberty.org/
for open specs/standards
—-
Interoperability Prototype for Liberty
http://liberty.sunsource.net/
for an opensource prototype implementation
its license is SISSL, from
http://liberty.sunsource.net/license.html :
“This license is recognized as a free and open license by The Free Software Foundation and The Open Source Initiative (OSI).”
…
I want to wish you GOOD LUCK with Cyrus! Are you going to use Cyrus + SASL?
…
Cyrus itself is running pretty well here as corporate mail server keeping around 80 gigs of mail stored for a bunch of users in several offices. Those days we chose Cyrus because it seems to be the best free-as-in-free-speech IMAP software when talking about “shared folders” in an office environment, and same I always enjoyed messing around with Cyrus, I feel quite different about SASL, where just a very small amount of documentation, a couple of really “bizarre” errors and (on my Debian machines) a bunch of problems resulting from having sasl and sasl2 mixed up each and everytime make touching sasl a frightening experience. IMO this is a good example what free software should never be like.
Cheers,
Kris
Why not use Apple’s OpenDirectory? It’s open source (even under a OSF certified “Free” license) and it works perfectly. Now that there’s a company that does not only take open source software but also gives back, why not use their results?
…
Every sysadmin had probably a dream like that, but let’s face it, we probably all have a directory already setup for that purpose…Hmm, yes every big corporation today has a Active Directory running somewhere…whether you like it or not, this is here and will probably stay!
…
No, AD is _not_ here, and won’t come, as a matter of fact. Right now we are in a step-by-step way planning and migrating our Windows NT – style domain to open software and open technologies. Things worked well around here while we still were “only” running NT boxes but the network itself changed into a poorly organized mess whenever the first GNU/Linux- and WXP – boxes showed up around. Personally, I see that thinking about something as essential to your network as your authentication service / user directory, you can’t be careful enough in staying away from being sort of “locked” with some proprietary technology that will limit your freedom of choice in many other respects for the next couple of years.
Cheers,
Kris
It’s amazing how, in just the fourth comment someone creeps in to mention the age old:
“There are a few… Kerberos and NIS… and if you want, there is PAM which allows you to authenticate against various methods.”
In fact, the other of the article aknowledges this and DISMISSES it in the article.
Simple proposition:
Anyone posting here that has not read the original article should be BANNED BY IP forever from the site. Or maybe it’s whole IP range should be banned. Too bad if it is a proxy.
That’ll show ’em.
I’m glad other people than me actually consider a “linux desktop” _not_ business ready unless stuff like this has been dealt with.
Other things to be dealt with consistently:
– Software distribution and authorisation
– Workstation deployment and monitoring
And these are just two I can think of in a hurry, there are more.
We need a project to address “business desktop”, which *doesn’t* focus on applications, and how good they’ll look or interoperate, but management.
So, who’s starting one? 🙂
I’m sorry, but I read this article, and Kerberos/GSSAPI does all this. It may not be laid out perfectly (but it’s not hard), and it has support for hardware-based authentication as well as support for client programs. The sample programs that come with the kerberos distribution include rcp, rsh, ftp, rlogin, login and more, and adding support for other programs is relatively easy. There is support in the ssh client as well.
http://web.mit.edu/kerberos/www/
Not sure about Linux, but FreeBSD comes with it in the base…
The LDAPv3 kit of OpenLDAP, SASL, and Kerberos 5 is a complete b**ch to get set up. There should be something similar to Apache toolbox for LDAP:
http://apachetoolbox.com
As far as a good admin interface, check this out:
https://gosa.gonicus.de/
Good stuff.
It was mentioned as was then went on to be dismised as a actual solution, when it does work.
The big problem here is that some deamons are badly writen(are hard to setup in the auth area). Most are not fun to integrate into what ever the base OS is running.
Another thing, a GUI specifically for this is not needed, what is needed is a good MMC clone, both CLI, GTK+, and if some one gets bored QT too. No I am not counting webmin as something like this since it has it does not respect permisions nicely and afaik can’t set the ID it is running as to the user that is accessing it.
PS: I wrote that first one at 2:30am and forgot to include why this is mostly bunk…
I totally disagree with who ever wrote the article. any one in an enterprise usage situation would; for one have the knowlege of installing what ever they wanted and or needed for authentication. It is really quite simple; Linux is strong because of its lack of structure standards. as soon as there are absolute standards you end up with “MS-Windows”
This is your court! Many eyes are looking to you. Good chance for major good juju here!
Well, in my experiance, if you willing to put in as much time as it takes to setup an active directory based network, try openLDAP, Samba, with PAM and Free Radius, you can do it all, Mail, Net logon, shares, Router Logons, and pretty much any other authentication for many domains.
I’m glad other people than me actually consider a “linux desktop” _not_ business ready unless stuff like this has been dealt with.
If that is your opinion, i suggest you do not generalize “Linux desktop” as some common, popular or all “Linux distrubutions”.
I do not know wether Novell will open up their eDirectory. I do not know wether they’ll port it. I do not know wether you’d use it when it were proprietary. I do not know wether you’d use it when it were FLOSS. But, in the end, it might just as well be an ingredient which gives SUSE an edge; leading to the statement of ie. “all Linux distributions, except SUSE”.
@ Kris we share the same opinion about SASL. SASL has become a curseword in my dictionary.
Novell has had the best directory in the business for many years. Netscape’s directory and Microsoft’s directory are distant seconds and thirds to Novell’s eDirectory. eDirectory not only runs natively on Linux it is also LDAP compliant so it can be used by most operating systems and countless applications right now. eDirectory also includes GUI management tools that are excellent.
Novell has already made eDirectory free to use or inexpensive to purchase, depending on what level of functionality you choose to get. Start here to find it http://www.novell.com/products/edirectory/ down loads for most platforms including Linux are available.
For those that would like eDirectory to be open sourced, this will probably never happen. eDirectory is a core component of Novell and its applications. Being a for profit company eDirectory will certainly remain closed source. But, it can be used freely and there are lots of free development tools for it. The SDK is free and include all the libraries you need to make your application realize the power of eDirectory. The fact is that if you haven’t tried eDirectory, you are missing out!
Yeah, but you better hope you’re not billed by the hour because it will take *a lot* of time.
Like stated before, all the components are there, but it’s by no means trival to make them all work together.
Ever tried to integrate both Samba(2) and PAM authentication into the same LDAP? You can’t do it. And that’s only two authentication mechanisms to take into account. Throw in the abundance of other possibilities too, and you have one royal mess. Let alone the fact that most of it is poorly documented, or described in outdated documents…if there are any *at all*. A good start would be to bring all the snippets of documentation out there together, creating a bigass howto for directory based authentication. Then make an inventory what’s missing, and write it. Then try to find common denominators in all documentation, and define a good LDAP schema, which accomodates pretty much everything you can think of. Lastly, the project can start to make all services which need authentication play nice together.
Sounds like fun? This project plan is GPL’ed, take it and go implement 🙂
I don’t generalize at all.
For myself I see a clear differentation between a desktop for home us and one for business use. In fact, IMO they’re pretty much mutually exclusive, too.
The generalizations are made by people who never worked in a corporate (desktop) environment, never had to design, implement, administer and support any large desktop deployment. I mean the kind of people who think that games and media players belong on Joe Secretary’s desktop, and are willing to write complete essays on it on e.g. OSnews.com, claiming that because all those high profile, neato gadgets and toys are available and somewhat mature the “Linux Desktop” (in the broadest sense of the term) must be ready for primetime. Well, for Jack HomeLuser, maybe, but not for Joe Secretary, and definately not for Simon Bofh who has to actually support luser desktops.
You just don’t get it.
1. The games don’t all run on Linux – because they don’t is one of the reasons Linux isn’t ready for the desktop of a lot of home users.
2. The home and corporate desktop environments are not mutually exclusive but different overlaping sets of requirements.
3. The ability to play a full range of media codecs is an important requirement for a sector of the corporate desktop – corporate presentations may come in realplayer, quicktime, wmv and mpeg etc.
4. Linux desktops are best deployed in a thin client configuration far easier to support than windows rich (fat or obese) clients.
Back on topic I think the article pointed out an important area where it would be possible make a significant advance in the ease of deployment of Linux in Linux server/Win client, all Linux and Linux server/mixed client environments.
No one is saying that these things are not valuable, but it is a matter of prioritization. It’s true that corporate and home desktop share applications and many building blocks, but you simply dont have to deal with the whole centralized admin/management issue on home desktops. In that sense, it’s a whole different ball-game. It’s also fair to assume that if you’ve got a large enterprise with a lot of money for IT, then you can go out and hire smart, educated, in-the-know people to set up and manage your LDAP/Kerberos authentication, but it’s completely unrealistic to assume that small to medium businesses are willing to throw the time and money at building an open source solution when pretty much any dummy can set up a windows domain or a simple active directory system with nothing more than the prompts on the screen. Ask any IT director at a small outfit how easy it is to hire and _keep_ unix gurus with the typical small business budget. Now lets ignore the fact that it’s probably not set up as best it might be, but for a small business, it isn’t that big of a deal. Then again, if you’re a big IT shop, you can afford to go out and buy a nice neat packaged all-in-one system – and _many_ corporations like to buy into a _solution_ (integrated, geddit) even if it is proprietary, rather than try and integrate a collection of (possibly better) discrete, unrelated, and poorly documented apps. Most companies have more pressing needs for their time and energy.
>3. The ability to play a full range of media codecs is an important requirement for a sector of the corporate desktop – corporate presentations may come in realplayer, quicktime, wmv and mpeg etc.
This CAN be implemented on Linux, and I seriously doubt that this will EVER hold back corproate adoption. Most likely, inhouse programs and ISV client programs’ll be holding back many many corporate desktops for a VERY VERY long time. Authentication, pftt. It’s important but it is absolutely a moot point when dealing with problems that can’t be fixed for a corporation. They can’t just say: Switch to Linux. It takes a lot of time, planning and well justification. It would take a long time to rebuild their programs on Linux from the windows world. The EU anti-trust investigation thinks so anyways.
> 4. Linux desktops are best deployed in a thin client configuration far easier to support than windows rich (fat or obese) clients.
I would say both are a tie. The windows world has metaframe and Terminal Server. If they wanted, thin computing can be done just as well on MS/Citrix tools than it can on *nix. That is in the short term, anyways.
> Back on topic I think the article pointed out an important area where it would be possible make a significant advance in the ease of deployment of Linux in Linux server/Win client, all Linux and Linux server/mixed client environments.
That I can agree with. Every little bit that helps on the server front, great. But remember, there are many different server offerings that we have to fight MS on:
File services – Adv. Linux
Authentication services – Adv. MS/Novell
Vendor services – Adv. Windows (We are growing rapidly here though)
ISV services – Adv. Microsoft (Deeply entrenched)
Mail services – Adv. Microsoft (Need MAPI Exchange-clones!)
Web services – Adv. Linux
General internet services – Tie (Some tread in both directions)
I don’t get it? Goody, tell that to my boss to who I just delivered a 900 node XP desktop deployment.
1) Home desktop users don’t need directory managed users either. Please stick to the subject at hand. You’re one of the people who constantly confuse any sane discussion about how to manage corporate desktops by looking at the subject from a (home) user point of view.
2) Okay, I’ll grant you that one. “Mutually exclusive” is a bit over the top. I meant to say that what people are used to on their home machine is in a well managed desktop environment pretty much entirely different. Even if it were only for the fact that, well, $user can’t actually *do* anything else than what his job requires. Let alone having the freedom to do anything about that.
3) “Corporate presentations”? I don’t know what kind of users you have in your organisation, but the best 99% are capable of is a powerpoint slide presentation right from a template. I’m sure you work in an environment where people constantly watch audiovisual presentations on their PC, driving pretty much everyone in their working environment insane with all that noise.
4) Thin clients are a nice concept but not fit for any situation. Besides, the misguided idea that linux thin clients are easier to manage than fat windows clients is probably based on what you think you know about managing Windows desktops. You throw the complexity back to the server, but that doesn’t mean deploying and managing applications will get any easier. You know…applications? The stuffies people actually use to get work done? On a side note, ever tried to play one of your audiovisual presentations on a thin client?
Anyway, the article points out an important field where a lot of work needs to be done. And directory based authentication is just the start, really. It’s always too bad that any discussion gets a lot of added noise from home users, who have only one way of using their computer, and that is with total freedom….freedom you generally don’t have in a corporate setting.
“Mail services – Adv. Microsoft (Need MAPI Exchange-clones!)”
How do you conclude that?
“Mail services – Adv. Microsoft (Need MAPI Exchange-clones!)”
Make that “Groupware services”, and I’d agree somewhat.
I would turn that the other way around though: “Need a FLOSS groupware server which can service MAPI clients without the need and burden of external plugins (Outlook!)”
Why not just write a front end to make it simple then, like a MMC clone, instead of reinventing everything. Everything needed is all ready there, it is just that the ppl with the skills have never been interested enought in making it happen.
i agree wholeheartedly with this article. ive been saying it for years. its not that the mechanisms arent already there, its that implimenting them is such a pain in the arse unless you already know how.
i was trying to set up a redhat box to auth against ldap following along with redhat’s online docs for doing so. never got it working. the migration script failed (probably because i wasnt entering something right, but i didnt know exactly what to put for some of the questions)
i learn by doing, i learn better by watching someone do it first and then trying to repeat what they did. unfortunately noone i know has gotten ldap authentication fully working on *nix yet.
i come from a novell background. i love how during the install the base nds/edirectory tree is set up wizard style. setting up a linux box to auth against ldap or whatnot else isnt that bad (as was stated, alot of distros ask you during the install) but setting up that initial server is quite difficult.
having an easily set up, or at least easier to set up, central console for controlling authentication, permissions, etc…. accross the board would be wonderful and IMO would speed up OSS/FS *nix adoption in businesses.
Clearification:
For all my points, we have many concerns that apply to any given product: We have to:
1. have a workable replacement to the existing Windows/*nix product
2. Develop a tool which replaces the functionality of the other-platform equivilent
3. Improve the product to work better without the old-technology that the product was initially based on.
Note: This is the Microsoft technique of innovation. I doubt anyone can contend how effective this has been in the past!
We have to reach stage 2 with a FOSS groupware solution. We have many of the pieces, btu not MAPI, and not xyz. You and I may not like to use Outlook, but the world won’t change around us. We just can’t throw up IMAP and SMTP and expect a mature company to take it. People like to schedule meetings on their calanders. They like to have email arive when it hits the server… Etc.. There are a lot of ways that I see MAPI being better from a users prespective.
We can either duplicate MAPI, or create an open protocol for today’s groupware needs and build Outlook, Outlook-Express plugins to support it.
Or, we can assume that everyone will magically switch to our tool just because its open source! Well, at least our mail client won’t support ‘active’ content.. (I hope).
Yes, but they are eye catching and they have the user to think twice before they pass by the story without clicking through. Every site needs to promote original articles, and this is just one of the ways to do it.
We are working on it on UserLinux, take a look at some proposal:
http://www.userlinux.com/cgi-bin/wiki.pl?Proposals/CoreServices
It’s the same as the Open Directory 2 from Apple’s Panther.
Regards.
You might want to look for “LDAP Links:” on this page:
http://yolinux.com/TUTORIALS/LinuxTutorialLDAP.html
I completely agree with the author. This would be a godsend for any admin with more than one Un*x box on his network.
Aiming for the enterprise is ambitious and as a couple of other posters have allready mentioned they allready have this kind of stuff.
I think aiming for the smaller shops (say > 3 people) would be much better. They usually don’t have something like this or they have it in some very primitive form. I should know I have been in three of these smaller companies and a system like OpenDAS has been a wet dream in all of them.
Building it yourself is allways possible, but the only problem is that it takes time. Time which is needed to make the money which in the end pays your salery.
A good, simple system which is easy to get up and running would be a fantastic thing to have and definately improve the situation for many people like me who have sys-admining as a secondary part of their job.
Yes, I agree, something like an MMC (or Webmin) would be an excellent beginning, but I do not believe that it is sufficient. In some of the discussions here (mentioned in another post on OSNews: http://groups.google.com/[email protected] and here: http://primates.ximian.com/~miguel/archive/2004/Apr-24.html Miguel and Brenden are talking about integrated frameworks for the implementation and deployment of applications (ala Longhorn/Avalon). Authentication and authorization is a central part of that vision, and right now, the fragmented OSS tools cannot in my opinion be unified simply by writing an MMC work-a-like. I’m not saying it’s a bad idea, because we need high-producivity management tools too, but the underlying pieces need to be able to talk to each other without having to go through integration work yourself. It’s not that much of an improvement to have a unified adminstration tool that administers programs that cannot meaningfully interact without the user having the same knowledge that they would need to have to set it up CLI/.conf. One of the things I think is really needed is a framework for all these apps and projects to fit into. It’ll be hard to come up a particular combination of tools that will be supported on every *nix/*BSD platform without some abstraction. I’m not sure what the solution is but the present mess is counterproductive. Having set up and managed several 1500+ user Exchange implementations and now running Cyrus+SASL on my home server, I think I have right to express my own annoyance at how hard it is to not go back to MS, simply because it causes so much fewer headaches.
“I think aiming for the smaller shops (say > 3 people) would be much better. They usually don’t have something like this or they have it in some very primitive form. I should know I have been in three of these smaller companies and a system like OpenDAS has been a wet dream in all of them.
Building it yourself is allways possible, but the only problem is that it takes time. Time which is needed to make the money which in the end pays your salery.”
I agree totally, though I think that a lot of somewhat larger shops would be interested as well. Several health care companies I’ve worked for (hospital, county health dept) would also have loved something like this. In both places we looked at FOSS software only to go with proprietary solutions because of the time constraints. Free software doesn’t end up saving that much when you need to hire a $50+ unix guru to manage all the stuff because you don’t have the time to do it/learn it.
Si, that deployment prob is the last one that needs to be solved. It is current possible to do it using cron or the like, but there are limits to that, what is needed is a way to add stuff that a user will run when they login.
What I am thinking is a file in a ~/ that will be run upon login that will do what ever. This will must not be editable or executable by that user and possible not viewable too. The other thing that is needed is a small little deamon running on the machine that can be poked to make the changes happen and real them in from a central repository.
For the most part I think this can be accomplished using sftp/nfs/sfs/nis with minimal changes.
With sftp/nfs/sfs/whatever(should be easily changeble) used for grabing files then the deamon reads a attached config file to see who they should run as, when, and ect.
@AnonymousBosch
There seems to be a “LDAP Users and Groups” module included:
http://www.webmin.com/standard.html
(I have no idee if it works, as i have not tried that.)
um, hello?
ever heard of novell edirectory? Ah, thought you might have!
Oh, and BTW novell is also a major linux vendor, can you beleive it?
We use edirectory on RH and SuSE and like it, problem solved.
I’ve been wanting to do something like this for quite some time. I’ve gotten OpenLDAP and Kerberos 5 working, and it’s a solution, but far from an elegant solution. It is difficult to figure out how to get everything working the first time, and I have a few gripes about things (perticularly with OpenLDAP and using authentication through it).
First of all, OpenLDAP lacks 3 major things to make it a viable enterprise directory service. First off, OpenLDAP needs online shcema and indexing changes. This is not a dealbreaker, but it would make things easier, not having to down the server for the occasional index or schema changes. Next, ACLs must be editable online somehow. This is a must! Things like delegation of access to certian ou’s requires this. Third, and most important, is data inheritance. There should be the ability to inherit data onto an object, if it is specified as such, from it’s parent. The whole point of creating ou’s is to seperate users based on a common attribute. Being able to inherit information from the parent is a must here.
There are a few other things that are needed. A caching daemon is needed for disconnect capabilities, and gui and text mode utilities are needed for easy administration of the directory.
Now, I’ve gone and grabbed the domain opendas.org, and I’m going to think this over a bit, and over the next few days I’m going to put something up there. If anyone is interested in this, drop me a line at mike [at] tuxnami [dot] org.
—
Mike Crawford
The fine details of this are open to discussion, but the main point of the article is true.
This is a major systems integration issue that could make or break free software/open source going forward.
It’s going to be as difficult as some of the issues that have faced desktop Linux, and will take several years to make real progress. But it can happen.
Don’t let this subject die.
Check into NIS, if the OS you are using has a decent implementation, the textmode tools are most likely all ready there, all that is needed is a nice front end to it all.
The only thing I am not certian of is if it is possible of getting more than one domain per IP#.
The problem with webmin is it has to run as root(can’t change to the UID of the invoking user), which makes it annoying to manage. It is decent for admining a system when ssh is not aviable, but misses a nice bit of usability since it is not easily tweakable like a actual GUI can be.
V. Velox wrote:
> The problem with webmin is it has to run as root(can’t change to the UID of the invoking user),
Nonsence: either invoke it from something like “su”, “sudo” or “login”. Or write a wrapper in a language that can do syscalls like C or PERL …
> which makes it annoying to manage. It is decent for admining a system when ssh is not aviable,
Don’t you have serial-console or KVM access then?
> but misses a nice bit of usability since it is not easily tweakable like a actual GUI can be.
Well, i don’t know about that, i think it’s tweakable just fine. But then who am i to say, _i_ only use a GUI for things it’s good at, like: Pan, Mozilla, Xine, et all …
Uhm, look at webmin and the way it works… and you will see why it likes to run as root and the like and why it can’t easily change to UID of the invoking user.
KVM and the like requires being there locally. Nah, it is not easily tweakable, with out editing the actual theme files.
Must be because you need hard math to do this, and Leenox Kidz and the “release often, release early, fix bugs later” open-source crowd just isn’t up to the task.
A _lot_ more discipline is needed for this stuff than “just hacks”, like ESRs-clones propose.
The day open-source development tries to follow industry standards in things like documentation, project management, etc, this kind of stuff, as a team work, will come to fruition. Anyone who’s ever tried coordinating a bunch of think-they-know-it-all morons from Leenox world, for even a small-sized project knows what I’m talking about.
This is *the* major problem in managing non-windows endpoints. There is no reasonable opensource/free way to do this that doesn’t make severe compromises on a) interoperability or b) security. For a couple of servers, no problem, flat files are reasonable. But if you want to push out 500 end user desktops that are used as business desktops, this is an absolute necessity.
Reasonable solutions exist for authentication (kerberos, PKI) and authorization, and reasonable solutions exist for directory services, but the integration work and higher level management tools (read: GUI to reset a password, disable an account, change the users’ login name, whatever) are essentially non-existant, at least insofar as they abstract or unify the authorization/authentication. Since PKI is a necessity for cross platform interop, this needs to be rolled into this solution as well.
Basically, people who underestimate AD have not looked deeply into the scope of that product. I wholly agree that we in the open source community need to implement similiar levels of functionality, with similiar levels of ease of deployment, maintainability and security, in fact more so when possible.
V. Velox wrote:
>Uhm, look at webmin and the way it works…
I just did (i have used it before, though).
> and you will see why it likes to run as root
I doesn’t. The the “setup.sh” script does. You can always setup a reverse-proxy such as Pond in front of it (ofcource) http://www.apsis.ch/pound/
> and the like and why it can’t easily change to UID of the invoking user.
Well, just comment out the check in setup file, like:
# Only root can run this
#id | grep “uid=0(” >/dev/null
#if [ $? != “0” ]; then
# …
#fi
And the hardcoded access right it changes:
mv setup.sh setup.sh.std
sed -e s/chmod/’#chmod’/ -e s/chgrp/’#chgrp’/ setup.sh.std > setup.sh
> KVM and the like requires being there locally.
That depends on what kind of setup we are talking about here … The relatively hi-end (19″ rack mounted) ones generally allow for access over Ethernet (so you can VPN into it). Serial-consoles are normally connected to a terminal-server to which you can either ssh/telnet or dial-in over POTS moden cq ISDN, and fireup “cu”, “microcom” or some such.
> Nah, it is not easily tweakable, with out editing the actual theme files.
I didn’t look at the LDAP user thingy before, now i did, and you’re correct in it needing some heavy tweaking. Maybe have a look instead / as well, at:
http://igloo.its.unimelb.edu.au/LDAPExplorer/
http://phpldapadmin.sourceforge.net/
Have fun.
Uhm, nice, but does not change any thing I said what so ever…
LOOK AT HOW IT BLOODY WORKS AND YOU WILL SEE THE BLOODY PROBLEM!!!! IT ONLY RUNS AS ONE USER!!!!
“can’t change to the UID of the invoking user”
Use Usermin then; part of Webmin.
See http://www.webmin.com/index6.html
Heving never looked at webmin, really, I can only guess, but…
The stuff webmin does will need UID 0 privileges no matter how you look at it. The fact that the process itself runs as an unprivileged account only means that either the used binaries need to be suid, *or* that webmin will change its user to an UID 0 account (usually root, probably with sudo) to do its stuff.
That’s another problem with current FLOSS solutions to “manage” an enterprise…no way easy, transparant, administrable way to delegate control.
Basically i agree and understand what you mean. However you could -in theory- also privsep Webmin and make it able to interact with the services it needs to using a privsep’ed UID and a GID which has access to the config file (ie “group webmin”). The problem then lies in using ie. start-stop-daemon or an equivelant. I know, it isn’t very good either, but at least it is better. I don’t like the concept much either…
13 Feb 2004
[…]
Also, I started hacking on tinyldap again. A friend of mine reverse engineered the database format on a “telephone book CD” for Germany. I thought to myself: this would be a formidable data set to put into tinyldap to prove that it is not just a toy. So he wrote a converter that spit out tab separated data and I converted it to LDIF and it’s over 2 Gigs worth of ASCII LDIF. Whew. tinyldap assumes that all your data fits into memory. Not so much tinyldap itself but the programs that create the data file tinyldap serves from. So I started hacking on parse (which creates the binary data file but no indices on it). I ended up completely reworking it and over days my local source tree would not create correct data files. It was a strange experience for me because normally I only do small changes on my local cvs checkout and check every change in immediately. On the other hand, I always wait until it at least compiles and survives very basic tests. But now I checked everything in.
The next step is to convert the index generation to work like sort(1), i.e. quicksort on smaller blocks and then mergesort on these blocks.
That’s harder than it sounds because I am sorting offsets. The comparison function has to seek to the offset and compare the data there. So the merge sort would drown the disk in wild seeking around unless I attach the first n bytes behind the offset to the offset before the merge sort and throw it away afterwards. I’m curious how much seeking I will end up doing.
I am also seeking sponsors for my work on tinyldap. If you run company working with LDAP, please go to your LDAP admin when he is doing LDAP administration and see for yourself. Chances are, he will be cursing all the time. Why not spend some money on the development of an LDAP server that does not suck? Hey, you can even say what features you want implemented! If you are interested, please contact me.
by Fefe, author of TinyLDAP. Taken from: http://www.advogato.org/person/Fefe/
Personally, i’d rather have a _fast_, FLOSS LDAP implementation than a wrapper around some common UNIX services, but reading some posts here there’s demand for the latter (too?).
Anyway, this seemed to be a relevant item and perhaps someone here can help.
Perhaps of interest for some as well. I haven’t read it through much. It is dependant on Java.
http://tools.arlut.utexas.edu/gash2/