Slashdot Mirror
Locking Down Linux Desktops In an Enterprise?
supermehra writes "How do you move 300 desktops, locked down with Windows ADS Group Policies (GPO), over to Ubuntu desktop? We have tried Centrify, Likewise, Gnome Gconf, and the like. Of course, we evaluated SuSe Desktop Enterprise and RedHat Desktop. Samba 4.0 promises the server side, however nothing for desktop lockdown. And while gnome gconf does offer promise, no real tools for remotely managing 300 desktops running gnome + gconf exist. All the options listed above are expensive, in fact so expensive that it's cheaper to leave M$ on! So while we've figured out the Office suite, email client, browser, VPN, drawing tools, and pretty much everything else, there seems to be no reasonable, open source alternative to locking down Linux terminals to comply with company policies. We're not looking for kiosk mode — we're looking for IT policy enforcement across the enterprise. Any ideas ladies & gentlemen?"
Why not use LSTP? That way you only have to worry about whatever image(s) you keep on the server.
so expensive that it's cheaper to leave M$ on!
If you want to be taken seriously, please lern 2 spel currektly. I'm not a Microsoft fan, but it sure is annoying seeing it spelt like that.
if you are talking stand alone desktops then it's not so great. linux doesn't really have anything as good as group polices and active directory, it's part of the reason corperate networks are mostly windows.
If you mod me down, I will become more powerful than you can imagine....
I guess the first question is: what are you trying to accomplish? Are you trying to prevent users from installing additional software locally? Are you trying to insure that particular applications get particular preferences set and users are prevented from changing those settings? What? Just saying "lock down the desktops" doesn't say what you're trying to actually do.
Remember that Unix is, in large part, designed to work correctly without needing to be locked down. Much is controlled simply by the system-wide configuration files. The rest tends to be controlled on the server side, so that users simply can't do unacceptable things regardless of how they configure their local user account.
In linux world, there is yet to be a quick, 3 question and 1 button way to add the computer to a domain and then receive straight away:
- group policies - security and software install
- single password store (with cached passwords for notebooks that go away from the network)
- Patch update policy
The only thing linux does right is work on technologies such as DHCP that were written for OTHER unix O/S'.
Ubuntu is not interested in those things, they're more interested in making stories about koalas and hiding popup boxes.
Gnome is dead, Mono and moonlight took all their brains away.
kde is making a next-gen desktop but have yet to understand why so many IT shops have kept Windows at the office.
This is all depressing. Windoze will never be replaced at the current rate.
Instead of spending $$$ on bondage and discipline, how about treating your users like adult human beings?
Because a number of them will wind up installing aps that put the company at risk?
I'm a consultant - I convert gibberish into cash-flow.
I remember an article about KDE's long term strategy to be just that: an enterprise ready Desktop with fine grained policies, central administration and all the fluff that makes windows enterprise-ready and the de facto standard for the desktop.
IToday, we have a colorful disaster that isn't even as usable as its predecessor. Developers should have focused on the need for an enterprise desktop that could actually make a dent in MS corporate sales. Instead we got useless eye candy.
The fault, of course, lies with the big distributions that pride themselves on providing enterprise ready Linux. Enterprise sans le Desktop. Useless wanking. The requirements for an enterprise ready desktop are out there for anyone to see and it's not just "applications" as everyone usually points out. It's the ability for administrators to create and maintain a usable desktop according to official corporate policies. No more and no less.
locking down Linux terminals to comply with company policies
Sooo, what exactly ARE these company policies?
Ya, NO linux based company would EVER do something like that.
www.redhat.com
What's Ubuntu's LTS support? 5 years? And how long has XP been supported? Right...
Probably because you can't guarantee that the users will ACT like adult human beings.
Any corporate policy that relies on "Let's just hope users don't do bad things" is doomed to fail.
If you need web hosting, you could do worse than here
You think using technology to help enforce an IT policy and respecting your employees are mutually exclusive aims? I strongly disagree.
A small contingent of 'bad apples' can do serious harm if you do not effectively enforce IT policies. It's not possible to guarantee there is no one like this in your company, so you should protect the company and other staff from from them.
Respecting staff won't stop douchebags being douchebags and screwing up your systems.
Finally! Thank you. I can't believe I had to read so many posts on slashdot of all places before someone points out the obvious. I recommend the OP googles "root over NFS." To reiterate, don't try to do Linux the Microsoft way. Also, please disregard all these stupid AC posts about Linux not being ready for the corporate desktop. Unemployed MCSEs are just yanking your chain.
Let us not become the evil that we deplore.
While I _mostly_ agree with this, a nice policy management (configuration management mostly) tool is also essential when dealing with lots of boxes. You want a new setting for all Gnome desktops, simply add it to the policy tool and let it distributed any required config files or run commands to change the setting, etc. This type of thing used to be done with things like: for h in $all_my_hosts; do ssh $h /tweak/some/setting; done
CFEngine and Puppet and friends are a nicer way of doing this. They're "self documenting" in that your write the code and then you can later very easily see when you added some configuration bits, etc...version control your configuration management scripts and you get even better tracking of who did what and when. (A side question: How does one do the version control type stuff in AD?)
While kickstart is great (I use it), it only goes so far. Having a policy manager on top of that (installed and configured in the kickstart) is a beautiful thing!
-Ben
Or, am I missing something?
Yeah managing this for 300+ people in an environment that changes daily without spending your entire IT budget on admins and the sneakernet support staff.
despite our desire to act like open source is the cure for all ills this is the type of problem we need to solve. You MUST lock down some enterprise environments (or have a CEO who is willing to go to jail) and you MUST be able to manage this without breaking the company piggy bank. He's asking for solutions to these two requirements not how to keep ONE person on ONE desktop from doing ONE of the many forbidden things.
And as for the guy/gal who suggested we treat everyone nice and hope they act right. That's fine for your 10 person IT shop...not so much for a multi-billion dollar public company that needs public trust and investment and is governed by a whole mess of federal regulations in numerous national jurisdictions around the world.
Have you ever met a sales person, or watched them try to use a computer? Seriously, watch them try to send a 500MB powerpoint presentation as an e-mail attachment, or ask for tech support on their limewire install, and marvel at the risk to your company.
Err, you can still run interpreted programs on a filesystem mounted noexec:
~$ python myprogram.py
A sufficiently clever user could use an interpreter to write his own dynamic linker and thereby run binaries too.
But I agree: locking down the desktop is the wrong approach. Better is to separate sensitive information from things that aren't sensitive, and have a standard user environment to restore to if the user does manage to mess up his configuration.
You kids still think that what the OP is asking for has anything to do with "preventing users from doing something harmful to the computer".
Get it out of your heads. Many of the things group policy can do has nothing to do with "security" or "preventing users" from doing anything. It has a lot to do with quickly standardizing departments, offices, rooms, or whatever your business structure is.
When you move a computer to a different department you simply drag the computer in AD to the different OU and BAM! That computer now gets everything new with its policies. There's no bringing the computer in to the IT department and reloading its configuration with "Configuration A for Department B".
Want to make a change to how a whole department does things? There's no pushing a script out later on to the whole department. You simply change it in group policy and the entire thing gets taken care of automatically.
You can spend more time focusing on actually getting shit done than fussing around with HOW to solve the problem with roundabout tool sets.
If it's cheaper to stay with a Microsoft-based infrastructure, then stay with that. Creating massive infrastructure-wide group policies that go from desktop to web browser is sort of a windows thing. If you're going to maintain security policies in a linux-based system, you better be prepared to start thinking in Unix- that means remembering that you're using a network-based system, not a locally-oriented system on a network.
If you're setting an IT infrastructure, the costs you're cutting on licensing will probably bite you in either support, security, training, or usability/productivity. There's no such thing as free software, I'm sorry.
Instead of spending $$$ on bondage and discipline, how about treating your users like adult human beings?
THIS is why those tools don't exist. Because every time you ask, some self-righteous idealist responds like this. Unfortunately, those self-righteous idealists are often also the really good programmers who have the ability to create such tools.
Move it to a new department? Change the entry for the machine on the DHCP server. No need to pull it in for retweaking.
Or even plugged in when you make the change.
You can use the whole disk for swap and /tmp. No individual installs. No local copies.
And the user's entire persistent state is on your fileservers, where you control the backup, maintain history (and let the user recover his OWN lost files), etc.
Meanwhile, with nothing persistent on the user's machine there's no info lost if it fries or is stolen, or if you need to upgrade his hardware. Just configure a fresh machine for netboot and replace the MAC address of his workstation with the new machine. Instant gratification.
You also get to update the software on ALL the machines by updating ONE image on the servers.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Unfortunately, few people in the Windows world seem to grasp that LDAP has been around for many years in the *nix world, and has all the functionality you would find in Group Policies when linked into PAM on the client side.
For a couple years, I maintained a company-wide network that supported unified "home" directories and unified login/password capabilities between Windows workstations, Linux workstations, and Solaris servers, all tied back to Fedora Directory Server. It was hell to set up, and sweet to watch in action.
Active Directory and Group Policies aren't bad for simple installations, but really turn into a mess quickly depending on your setup. LDAP and *nix systems that support PAM are a snap to set up, work fairly well and took significantly LESS time to get working properly than the Windows side did.
There's a lot of research that goes into setting up either side of the equation. Linux/Unix has been more ready for the "enterprise" desktop than Windows has, though, and that's a cold hard fact.
In Linux it's done with policies in LDAP that are used to set variables for login scripts. Using standard Linux tools (written 20+ years ago for UNIX systems), the login process can report back what machine, IP address, etc a user is accessing. That coupled with the group structures in LDAP are used to set environment variables that dictate everything a user can access.
If it weren't for the boneheaded point-n-click gui that windows crams down every admins throat, even windows admins would see that their precious AD is just ldap with environment variables modified by scripts.
You talk about converting 300 seats. I converted 2000 to LTSP desktops. All driven by only 33 servers. See here for details: http://www.localnetsolutions.com/press.html
If you are still stuck, my contact info is on the site. I consult.
Unfortunately few people in the *nix world seem to grasp that LDAP is just a protocol (that's the P bit of the acronym). It's just a standard way of accessing directories - which is what Active Directory is (as is OpenLDAP etc etc). LDAP means nothing as a reference to a directory - OpenLDAP might in your case. So what you meant to say was "directories (that are accessible via LDAP) have been around for years". Whether they do everything the particular implemention of Active Directory does is up for question - some may, some may not. It depends on implementation...