I don't think they ever used the 64 bit version of flash, they just pulled in the 32 bit version so this shouldn't affect OpenSUSE at all. They always used nsplugginwrapper before for flash on x86_64 (although maybe they've changed this lately).
It's important to note that at least the hybrid models have brake override, meaning that if you depress the brakes and the accelerator at the same time, the brakes take precedence and the engine is idled (or shut off). This makes the unintended acceleration issue almost impossible. I have a 2005 Prius and made sure to test this during my first test drive as I didn't fully trust drive by wire technology and computer controlled everything to be fool proof. That's not to say that the brake override is perfect (since it's still just software) but it's an important safety addition. What boggles my mind is that every drive by wire car doesn't have this feature. It adds nothing to the cost of the car and is a critical safety feature which can mitigate some software errors as well as sensor failures.
I have to second the Meraki, I've worked with them a little and they are stupid simple to setup and maintain. From a price perspective they kill Cisco and a lot of the other big vendors as well so it can be a big win all around.
As a disclaimer I don't use an iPod or iTunes so I might be making this up as I go along:
>1. You can use your iPod with other software.
Do people really do that? I was under the impression that if you have an iPod you really only ever use iTunes. Since iTunes is the only way to update an iPod you have to at least have it installed so using something else to manage an iPod doesn't sound like something most people would do. Not that there's anything wrong with that, iTunes is a superb app from what I've heard so there's no harm in bundling it as it gives the consumer what they want (good media app with good iPod integration).
>2. With the exception of older DRM'ed tracks, you can put your music from iTunes on any device with any other software that supports said device and the proper file formats.
I know a lot of people stuck with those old DRM'ed tracks who are too cheap/lazy/ignorant to update them. If you use iTunes, "Everything Just Works(tm)"
>3. Palm is taking the lazyass way out and piggybacking on iTunes when anyone with three braincells could see this leapfrog coming a mile away. Yes, Apple is being dickish about this, but Palm damn well knew this would happen and they have a lot more to lose from pissed off customers than Apple does. The iTunes library is just an XML file. It would be trivial for Palm to make an app that reads said file and syncs without the need for iTunes to be running.
This is certainly true, writing their own sync application would probably cost less than the lawyers they have on retainer preparing for the eventual Apple lawsuit. This is probably more of a press battle than anything else and Palm is playing it pretty smart by staying in the public eye with this. Apple looks bad for deliberately locking them out and Palm looks technically savvy for coming up with another workaround. For everyone I know with an iPod though, iTunes is The Music App. I used to see the same thing where IE was The Internet. If you have to use something else it looks like a kludge to end users so integrating with what they already know and use is a win for consumers.
Why as a consumer would I be so dumb as to buy anything Apple if they're only goal is to extract as much money from me as possible by forcing me to use only their products? If a company like Apple wants to specifically break compatibility with their products for third parties then I would choose not to use their products. Why is it that people jump on Microsoft when they trap consumers but applaud Apple for the same behavior? I'm not saying Apple doesn't make good products (I think they do), but the price of it is vendor lock-in the likes of which Microsoft can only dream about.
FWIW, there is a nice search tool for finding packages for OpenSUSE at Webpin. They've made adding repositories much easier and faster now in 11 as well (zypper is light speed ahead of the old package management tools in OpenSUSE).
Enterprise users still want to play all the same multimedia on a Linux desktop that they can on a Windows desktop. While I wouldn't mind locking them out of it to make them more productive, since I use SUSE (SUSE Linux Enterprise Desktop) I would most certainly want the capability to have all the shiny bells and whistles for me. I also have to be sure our CEO and CFO (who also both run SUSE) have access to whatever they want so if this helps with that, great.
This wasn't a cross patent license between them, just an agreement not to sue each others customers. They can still sue the hell out of each other for patent infringement. Both Novell and Microsoft have large patent portfolios so it's a bit like the cold war where either side could drop a patent litigation bomb on the other but they both have a huge arsenal to counterattack with. The agreement they made was more of a form of detentes than anything else. Novell can't use any of Microsoft's patents and Microsoft can't use any of Novell's without fear of litigation. They can't sue end customers though so it gives customers a nice safe feeling that long before a lawyer ever shows up at their door, either Novell or Microsoft will be long gone.
From what I understand the energy used to create ethanol (in the form of fuel for farm vehicles, energy for refinement and distillation, distribution costs) nearly equal the energy you get out of producing ethanol. Apparently there is also controversy in South America about the use of maize for ethanol due to it being a staple crop and almost religious item. That being said, if you're opposed like I am to sending oil money to the Middle East then ethanol has a large benefit there. In any event, it seems like ethanol is more of a stepping stone towards a real sustainable energy source and not a solution in and of itself. Since the American automotive industry is hyping ethanol so much right now that means it has to be a sham in my book. Clearing the rain forest is never a good idea for such short term gains for reasons stated in the previous post.
With path based you do open yourself up to problems with evil people doing things with links and whatnot but the general idea of AppArmor is that you wouldn't let someone get that far in the first place, or if you did, they belonged there. Node based eliminates that problem but opens up a new set of issues in terms of backing up filesystems (many commercial and even some open source backup solutions are brain dead when it comes to preserving extended information from the filesystem and will just ignore inode data they don't know how to handle). One of the cooler things you can do with AppArmor is create multiple links to a shell (they call it rbash I think) and then creating a profile for each link to a shell (i.e., ln/bin/bash/bin/rbash). You can give someone uid 0 but if their login shell is/bin/rbash they're confined to whatever binaries and directories you've limited them to in the policy. It makes it very easy to give out administrative roles to users. But if you access a system through some means not confined by an AppArmor policy and have the appropriate access, sure, you can do all kinds of badness with links. The best defense against that is to profile every entry point so that no one can create links who shouldn't be able to. Inheritance goes a long way towards making that achievable.
It seems to me that AppArmor is still a much more suitable tool for MAC under Linux for 99% of the systems that need it. Unless you have very complex security requirements and are defending national secrets, all the extra effort it takes to setup SELinux isn't needed. By taking the approach of hardening the weakest points of the system (network applications, processes that run as root, etc...) you can gain almost all the security benefits without having all the added complexity. And yes, as a disclaimer, I know many of the Immunix crew behind AppArmor and have worked with them at Defcon and such. Having used both SELinux and AppArmor I can say there's no comparison in terms of effectiveness. If a security tool it too complex to use it will be used incorrectly and can lead to even worse security problems. I would rather stick with a much simpler approach that still provides all the confinement of MAC but only where I need it.
There isn't actually a license to use each others patents, only an agreement not sue each others customers for any products they sell which might infringe on their patents. They can still sue the hell out of each other, just not the end customers.
The balance of payments are by far in Novell's favor from what I've seen. I don't remember the exact numbers but Microsoft is paying far more than Novell is paying them for the patent agreement. It isn't costing Novell anything to add the patent agreement, in fact, they're making a lot of money from Microsoft by doing it. It still seems like a weird deal but Microsoft is the one paying Novell not the other way around.
I've been on the beta the entire time and I have to say that I'm very happy with what they've done. Yes, I work quite a bit with Novell so I'm biased but having tried to support desktop Linux deployments using other solutions has been miserable. The amount of time and money that's gone into making SLED 10 enterprise ready is impressive. They even have an intro video with clips for all the major pieces of the desktop for helping new users (similar to the Windows XP new user intro) so that it's as easy as possible for new users to get up and running. The gnome menu interface is very slick with the beagle integration and the end result is a very clean desktop. For anyone who is interested in trying it out you can get it from Novell (you have to fill out a survey first). I highly recommend just giving it a try to at least see what Novell's been up to.
I've only used v2 so far but I use it pretty extensively. It actually has a conflict bin so that if there is some type of conflict it wil prompt you for what to do. I haven't had one in a long time so I don't remember exactly how it behaves but it won't just overwrite everything. It additionally had basic versioning support so that you can specify on the server side how many versions of a file to keep. This comes in pretty handy when a user gets a virus that wipes out their data as you can roll back whatever they had in ifolder to a previous version.
I couldn't agree more. For anyone who hasn't tried out AppArmor I highly recommend giving it a try with the distro of your choice or trying OpenSUSE as all of the newer SUSE products (SLES/NLD 9 sp3+, OpenSUSE 10+, OES sp2+) have it integrated with a stupid simple YAST interface for using it. I'm definitely biased as I've been friends with the Immunix crew for quite some time and work closely with Novell but having used a variety of MAC products (Argus Pitbull, SELinux, and AppArmor) I can say that AppArmor is the only tool that doesn't require weeks to configure. People who say MAC is difficult just haven't tried AppArmor yet. It's really quite easy to get a very high level of security by profiling the few applications of concern (anything running as root, anything that talks on the network, user apps like Firefox, Evolution, Kmail, Konqueror, GAIM, etc....).
We actually use ZLM at my workplace and maintain and patch numerous RHEL systems. While ZLM7 does require SLES, it would probably be pretty difficult for them to support installing it on anything else as there is so much involved with the product (eDirectory, Extend, etc...). It's really only one server you're talking about anyway and a single SLES license doesn't cost much at all. The new version also offers so many more features such as imaging, policy distribution, arbitrary remote execution, replication, and more that it doesn't even compare to the old version. I'm not sure why you couldn't get the agent to work under RHEL but if you need any help feel free to send a message.
It is unfortunate that the security features of Windows are almost never used properly but they've gone to great lengths to cultivate a user community that cares only about features and not about security. It's kind of like Intel hyping up their MHz myth and then getting killed when their latest and greatest processors don't have an insane clockspeed but have a decent pipeline. Proper priviledge seperation is difficult to do under any OS so lets hope that people take the time to do it right under Linux/BSD/Whatever and don't go for what's easiest for an out of the box setup.
Sure you can, I'm running firefox right now in an AppArmor environment. Setting up SELinux is quite a bit more difficult but not impossible. I have to admit that I'm an AppArmor fanboy but the capabilities it gives you make hardening applications dirt easy. It comes with SUSE 10 but I don't believe it's turned on by default. My firefox profile only allows it to execute certain viewer applications and only access certain parts of the filesystem, i.e. firefox can't read anything in/etc. I have evolution setup the same way. You should have a look at it, I think you'll find that MAC really isn't that hard at all once you have the right tools to manage things.
What we have in the Linux and BSD world at least are very good Mandatory Access Control systems that help mitigate some of this risk. In the Linux world you can use SELinux (shudder) or use something even easier, AppArmor. If you properly profile an application to determine what it should and should not do you'll be in much better shape when new exploits like this come out. It won't save you from everything since they can still get access to anything the program could legitimately access in the first place but it's much more efficient than setting up sandboxes for everything like chroot and much more secure.
We've been using Groupwise for a long time now and it's been a solid platform for us. Version 7 also natively supports pretty much all the functionality of the native Windows client with Evolution as well which is a big draw for us since we don't use Windows for our desktops. I haven't had a chance to try it out yet but I've been waiting for native calendar access for some time from Evolution to Groupwise.
Novell's eDirectory satsifies all of those requirements. It installs as an rpm (everyone else will have to alien it to a deb or whatever you like). The ldap schema is completely hidden unless you want to extend it in which case you can use either a web frontent (iManager) or a java app (ConsoleOne). The same two tools will let you manage everything you would ever need to touch on it as well as manage just about every other Novell application. Both tools work fine under the browser/os of your choice as well. If you're using SUSE the PAM setup takes about 2 minutes using YaST. Otherwise, you just have to create and/etc/ldap.conf file and modify whatever services you want to authenticate via ldap under/etc/pam.d/. If you want it even eaiser you can setup the entire thing from the web interface with very advanced ACLs for who can access what server which will setup pam_nam automatically for you. I've used OpenLDAP a number of times and while it works well in smaller environments, the ability of eDirectory to scale out to millions of objects and transparently replicate bidrectionally with no setup required makes it quite a bit more useful. It's not OSS, but they practically give it away so you usually never even have to pay for it.
Forcing the smtp server at the network level would work great if all your workstations are on a local network, but if you're managing users worldwide roaming around with laptops it's not really an option. Anyway, with the security policies for application/desktop configuration, you can choose whether you're setting defaults for a user that are locked (they can't change them) or unlocked (they can). A read only config file would also work but it's not that convenient to have to manage several dozen config files in/etc/skel and then have to script out changes to every user's account anytime you want to force a change on everyone. With Zen you can have as many different groups of users as you want and each group (or even machine if you want) can have a separate set of policies applied to it, minimum list of software packages to have installed, etc.... All policy is group based so if I have a group of office workers who only need OpenOffice and Firefox and shouldn't be able to make changes to their preferences I can put them in a separate group from my power users who I can trust not to set their incoming imap server to something non-existant and then complain to the helpdesk. You would never use Zenworks to harden a single machine, you would use is to manage at least several hundred out to several hundred thousand. You're absolutely right about it being overkill for just a few machines.
Unfortunately, the current version of Zenworks Linux Management really is just Red Carpet Enterprise with a little more polish. The next version which is due out in a few months if I'm not mistaken is worlds appart and is almost on par with the feature set currently available for Windows. Everything you could want is built in. I don't think there will really be a desktop and server line as Linux is Linux. The remote access via VNC and application security policies (Firefox must have x as it's home page, evolution can't change the smtp server, etc....) are more desktop oriented but the end result is the same. You have one tool to perform all your system management if you're a Linux shop.
Yes, version 7 is quite an improvement over what is essentially Red Carpet Enterprise. If they can integrate AppArmor security policies into it there really won't be any need for any other tools. The difference in the web interface alone is enough to make an admin cry. Just out of curiousity, you're not the same gentleman from Novell whose business cards actually read "Evil Zen Scientist" are you?
Slashdot Mirror
I don't think they ever used the 64 bit version of flash, they just pulled in the 32 bit version so this shouldn't affect OpenSUSE at all. They always used nsplugginwrapper before for flash on x86_64 (although maybe they've changed this lately).
It's important to note that at least the hybrid models have brake override, meaning that if you depress the brakes and the accelerator at the same time, the brakes take precedence and the engine is idled (or shut off). This makes the unintended acceleration issue almost impossible. I have a 2005 Prius and made sure to test this during my first test drive as I didn't fully trust drive by wire technology and computer controlled everything to be fool proof. That's not to say that the brake override is perfect (since it's still just software) but it's an important safety addition. What boggles my mind is that every drive by wire car doesn't have this feature. It adds nothing to the cost of the car and is a critical safety feature which can mitigate some software errors as well as sensor failures.
I have to second the Meraki, I've worked with them a little and they are stupid simple to setup and maintain. From a price perspective they kill Cisco and a lot of the other big vendors as well so it can be a big win all around.
As a disclaimer I don't use an iPod or iTunes so I might be making this up as I go along:
>1. You can use your iPod with other software.
Do people really do that? I was under the impression that if you have an iPod you really only ever use iTunes. Since iTunes is the only way to update an iPod you have to at least have it installed so using something else to manage an iPod doesn't sound like something most people would do. Not that there's anything wrong with that, iTunes is a superb app from what I've heard so there's no harm in bundling it as it gives the consumer what they want (good media app with good iPod integration).
>2. With the exception of older DRM'ed tracks, you can put your music from iTunes on any device with any other software that supports said device and the proper file formats.
I know a lot of people stuck with those old DRM'ed tracks who are too cheap/lazy/ignorant to update them. If you use iTunes, "Everything Just Works(tm)"
>3. Palm is taking the lazyass way out and piggybacking on iTunes when anyone with three braincells could see this leapfrog coming a mile away. Yes, Apple is being dickish about this, but Palm damn well knew this would happen and they have a lot more to lose from pissed off customers than Apple does. The iTunes library is just an XML file. It would be trivial for Palm to make an app that reads said file and syncs without the need for iTunes to be running.
This is certainly true, writing their own sync application would probably cost less than the lawyers they have on retainer preparing for the eventual Apple lawsuit. This is probably more of a press battle than anything else and Palm is playing it pretty smart by staying in the public eye with this. Apple looks bad for deliberately locking them out and Palm looks technically savvy for coming up with another workaround. For everyone I know with an iPod though, iTunes is The Music App. I used to see the same thing where IE was The Internet. If you have to use something else it looks like a kludge to end users so integrating with what they already know and use is a win for consumers.
Why as a consumer would I be so dumb as to buy anything Apple if they're only goal is to extract as much money from me as possible by forcing me to use only their products? If a company like Apple wants to specifically break compatibility with their products for third parties then I would choose not to use their products. Why is it that people jump on Microsoft when they trap consumers but applaud Apple for the same behavior? I'm not saying Apple doesn't make good products (I think they do), but the price of it is vendor lock-in the likes of which Microsoft can only dream about.
FWIW, there is a nice search tool for finding packages for OpenSUSE at Webpin. They've made adding repositories much easier and faster now in 11 as well (zypper is light speed ahead of the old package management tools in OpenSUSE).
Enterprise users still want to play all the same multimedia on a Linux desktop that they can on a Windows desktop. While I wouldn't mind locking them out of it to make them more productive, since I use SUSE (SUSE Linux Enterprise Desktop) I would most certainly want the capability to have all the shiny bells and whistles for me. I also have to be sure our CEO and CFO (who also both run SUSE) have access to whatever they want so if this helps with that, great.
This wasn't a cross patent license between them, just an agreement not to sue each others customers. They can still sue the hell out of each other for patent infringement. Both Novell and Microsoft have large patent portfolios so it's a bit like the cold war where either side could drop a patent litigation bomb on the other but they both have a huge arsenal to counterattack with. The agreement they made was more of a form of detentes than anything else. Novell can't use any of Microsoft's patents and Microsoft can't use any of Novell's without fear of litigation. They can't sue end customers though so it gives customers a nice safe feeling that long before a lawyer ever shows up at their door, either Novell or Microsoft will be long gone.
From what I understand the energy used to create ethanol (in the form of fuel for farm vehicles, energy for refinement and distillation, distribution costs) nearly equal the energy you get out of producing ethanol. Apparently there is also controversy in South America about the use of maize for ethanol due to it being a staple crop and almost religious item. That being said, if you're opposed like I am to sending oil money to the Middle East then ethanol has a large benefit there. In any event, it seems like ethanol is more of a stepping stone towards a real sustainable energy source and not a solution in and of itself. Since the American automotive industry is hyping ethanol so much right now that means it has to be a sham in my book. Clearing the rain forest is never a good idea for such short term gains for reasons stated in the previous post.
With path based you do open yourself up to problems with evil people doing things with links and whatnot but the general idea of AppArmor is that you wouldn't let someone get that far in the first place, or if you did, they belonged there. Node based eliminates that problem but opens up a new set of issues in terms of backing up filesystems (many commercial and even some open source backup solutions are brain dead when it comes to preserving extended information from the filesystem and will just ignore inode data they don't know how to handle). /bin/bash /bin/rbash). You can give someone uid 0 but if their login shell is /bin/rbash they're confined to whatever binaries and directories you've limited them to in the policy. It makes it very easy to give out administrative roles to users. But if you access a system through some means not confined by an AppArmor policy and have the appropriate access, sure, you can do all kinds of badness with links. The best defense against that is to profile every entry point so that no one can create links who shouldn't be able to. Inheritance goes a long way towards making that achievable.
One of the cooler things you can do with AppArmor is create multiple links to a shell (they call it rbash I think) and then creating a profile for each link to a shell (i.e., ln
It seems to me that AppArmor is still a much more suitable tool for MAC under Linux for 99% of the systems that need it. Unless you have very complex security requirements and are defending national secrets, all the extra effort it takes to setup SELinux isn't needed. By taking the approach of hardening the weakest points of the system (network applications, processes that run as root, etc...) you can gain almost all the security benefits without having all the added complexity. And yes, as a disclaimer, I know many of the Immunix crew behind AppArmor and have worked with them at Defcon and such. Having used both SELinux and AppArmor I can say there's no comparison in terms of effectiveness. If a security tool it too complex to use it will be used incorrectly and can lead to even worse security problems. I would rather stick with a much simpler approach that still provides all the confinement of MAC but only where I need it.
There isn't actually a license to use each others patents, only an agreement not sue each others customers for any products they sell which might infringe on their patents. They can still sue the hell out of each other, just not the end customers.
The balance of payments are by far in Novell's favor from what I've seen. I don't remember the exact numbers but Microsoft is paying far more than Novell is paying them for the patent agreement. It isn't costing Novell anything to add the patent agreement, in fact, they're making a lot of money from Microsoft by doing it. It still seems like a weird deal but Microsoft is the one paying Novell not the other way around.
I've been on the beta the entire time and I have to say that I'm very happy with what they've done. Yes, I work quite a bit with Novell so I'm biased but having tried to support desktop Linux deployments using other solutions has been miserable. The amount of time and money that's gone into making SLED 10 enterprise ready is impressive. They even have an intro video with clips for all the major pieces of the desktop for helping new users (similar to the Windows XP new user intro) so that it's as easy as possible for new users to get up and running. The gnome menu interface is very slick with the beagle integration and the end result is a very clean desktop. For anyone who is interested in trying it out you can get it from Novell (you have to fill out a survey first). I highly recommend just giving it a try to at least see what Novell's been up to.
I've only used v2 so far but I use it pretty extensively. It actually has a conflict bin so that if there is some type of conflict it wil prompt you for what to do. I haven't had one in a long time so I don't remember exactly how it behaves but it won't just overwrite everything. It additionally had basic versioning support so that you can specify on the server side how many versions of a file to keep. This comes in pretty handy when a user gets a virus that wipes out their data as you can roll back whatever they had in ifolder to a previous version.
I couldn't agree more. For anyone who hasn't tried out AppArmor I highly recommend giving it a try with the distro of your choice or trying OpenSUSE as all of the newer SUSE products (SLES/NLD 9 sp3+, OpenSUSE 10+, OES sp2+) have it integrated with a stupid simple YAST interface for using it. I'm definitely biased as I've been friends with the Immunix crew for quite some time and work closely with Novell but having used a variety of MAC products (Argus Pitbull, SELinux, and AppArmor) I can say that AppArmor is the only tool that doesn't require weeks to configure. People who say MAC is difficult just haven't tried AppArmor yet. It's really quite easy to get a very high level of security by profiling the few applications of concern (anything running as root, anything that talks on the network, user apps like Firefox, Evolution, Kmail, Konqueror, GAIM, etc....).
We actually use ZLM at my workplace and maintain and patch numerous RHEL systems. While ZLM7 does require SLES, it would probably be pretty difficult for them to support installing it on anything else as there is so much involved with the product (eDirectory, Extend, etc...). It's really only one server you're talking about anyway and a single SLES license doesn't cost much at all. The new version also offers so many more features such as imaging, policy distribution, arbitrary remote execution, replication, and more that it doesn't even compare to the old version. I'm not sure why you couldn't get the agent to work under RHEL but if you need any help feel free to send a message.
It is unfortunate that the security features of Windows are almost never used properly but they've gone to great lengths to cultivate a user community that cares only about features and not about security. It's kind of like Intel hyping up their MHz myth and then getting killed when their latest and greatest processors don't have an insane clockspeed but have a decent pipeline. Proper priviledge seperation is difficult to do under any OS so lets hope that people take the time to do it right under Linux/BSD/Whatever and don't go for what's easiest for an out of the box setup.
Sure you can, I'm running firefox right now in an AppArmor environment. Setting up SELinux is quite a bit more difficult but not impossible. I have to admit that I'm an AppArmor fanboy but the capabilities it gives you make hardening applications dirt easy. It comes with SUSE 10 but I don't believe it's turned on by default. My firefox profile only allows it to execute certain viewer applications and only access certain parts of the filesystem, i.e. firefox can't read anything in /etc. I have evolution setup the same way. You should have a look at it, I think you'll find that MAC really isn't that hard at all once you have the right tools to manage things.
What we have in the Linux and BSD world at least are very good Mandatory Access Control systems that help mitigate some of this risk. In the Linux world you can use SELinux (shudder) or use something even easier, AppArmor. If you properly profile an application to determine what it should and should not do you'll be in much better shape when new exploits like this come out. It won't save you from everything since they can still get access to anything the program could legitimately access in the first place but it's much more efficient than setting up sandboxes for everything like chroot and much more secure.
We've been using Groupwise for a long time now and it's been a solid platform for us. Version 7 also natively supports pretty much all the functionality of the native Windows client with Evolution as well which is a big draw for us since we don't use Windows for our desktops. I haven't had a chance to try it out yet but I've been waiting for native calendar access for some time from Evolution to Groupwise.
Novell's eDirectory satsifies all of those requirements. It installs as an rpm (everyone else will have to alien it to a deb or whatever you like). The ldap schema is completely hidden unless you want to extend it in which case you can use either a web frontent (iManager) or a java app (ConsoleOne). The same two tools will let you manage everything you would ever need to touch on it as well as manage just about every other Novell application. Both tools work fine under the browser/os of your choice as well. If you're using SUSE the PAM setup takes about 2 minutes using YaST. Otherwise, you just have to create and /etc/ldap.conf file and modify whatever services you want to authenticate via ldap under /etc/pam.d/. If you want it even eaiser you can setup the entire thing from the web interface with very advanced ACLs for who can access what server which will setup pam_nam automatically for you.
I've used OpenLDAP a number of times and while it works well in smaller environments, the ability of eDirectory to scale out to millions of objects and transparently replicate bidrectionally with no setup required makes it quite a bit more useful. It's not OSS, but they practically give it away so you usually never even have to pay for it.
Forcing the smtp server at the network level would work great if all your workstations are on a local network, but if you're managing users worldwide roaming around with laptops it's not really an option. Anyway, with the security policies for application/desktop configuration, you can choose whether you're setting defaults for a user that are locked (they can't change them) or unlocked (they can). A read only config file would also work but it's not that convenient to have to manage several dozen config files in /etc/skel and then have to script out changes to every user's account anytime you want to force a change on everyone. With Zen you can have as many different groups of users as you want and each group (or even machine if you want) can have a separate set of policies applied to it, minimum list of software packages to have installed, etc.... All policy is group based so if I have a group of office workers who only need OpenOffice and Firefox and shouldn't be able to make changes to their preferences I can put them in a separate group from my power users who I can trust not to set their incoming imap server to something non-existant and then complain to the helpdesk. You would never use Zenworks to harden a single machine, you would use is to manage at least several hundred out to several hundred thousand. You're absolutely right about it being overkill for just a few machines.
Unfortunately, the current version of Zenworks Linux Management really is just Red Carpet Enterprise with a little more polish. The next version which is due out in a few months if I'm not mistaken is worlds appart and is almost on par with the feature set currently available for Windows. Everything you could want is built in. I don't think there will really be a desktop and server line as Linux is Linux. The remote access via VNC and application security policies (Firefox must have x as it's home page, evolution can't change the smtp server, etc....) are more desktop oriented but the end result is the same. You have one tool to perform all your system management if you're a Linux shop.
Yes, version 7 is quite an improvement over what is essentially Red Carpet Enterprise. If they can integrate AppArmor security policies into it there really won't be any need for any other tools. The difference in the web interface alone is enough to make an admin cry. Just out of curiousity, you're not the same gentleman from Novell whose business cards actually read "Evil Zen Scientist" are you?