Enterprise FreeBSD: Managing Desktops and Users through Directory Services

vanessa

vanessa

Initially talking about roaming profiles alternatives for FreeBSD clients over here I decided to start a new discussion about the usage of FreeBSD as a client OS in an enterprise environment. The reason for the separate thread is that on one hand I don't want to shift the topic of the previous discussion and on the other hand this question deserves its own discussion because of its significance for the acceptance of the OS.

So here comes first an overview of the best practices for managing Windows and Apple clients. There are numerous discussions out there about what the best/right approach is. Generally, they run down to the following solutions (please note that for simplicity I am talking about Windows and OS X clients only! FreeBSD/Linux come later):

Open Directory instead of Active Directory
When using Open Directory for serving Windows Clients instead of Active Directory, one has to use the Samba 3 package which comes with OS X Server. Some disadvantages: tedious setup and support, old Samba version, limited AD functionality. What you have, is in fact Samba, and not Open Directory serving PCs ... You could put Samba on every BSD/Linux box with the same effect. There is no solution (I am aware of) besides Samba, which can extend an OD schema in order to offer some or full AD support to Windows clients. The trick with Active Directory is the proprietary SMB protocol - not the schema itself.

Active Directory instead of Open Directory
Most advices go in the opposite direction - serving OS X clients through AD on a Windows Server. The point here is that AD offers the most complete (or bloated, depending on the personal opinion) functionality for Windows clients. There are 3 approaches:
  • either expanding the AD schema to support Open Directory, or
  • by augmenting AD with an OD server, or
  • with the Magic Triangle method.
Please google for the explanations - two good articles could be found here and here. Please note that this solution doesn't employ Apple's Active Directory plug-in, but the AD server tries to mimic an OD server instead.

Using plain Samba instead of AD/OD
Samba 4 finally offers an almost complete implementation of Active Directory thanks to the European Commission, which compelled Microsoft to provide full information about the SMB protocol and the internals of AD. You could install Samba 4 on a FreeBSD or Linux server and extend the schema to support Open Directory and Mac Clients. Is this the end of Microsoft's hegemony in business installations?

No! Those of us running mainly FreeBSD or OS X with a couple of Windows boxes would gladly use Samba as the main or only Directory Service in a heterogeneous environment. For the rest of the world - all the companies with dozens or hundreds of Windows-only clients - some additional Windows Server licenses make no difference in price and even less in usability. Don't forget that most of their system administrators speak Windowish only.

Using the Apple Active Directory plugin
* cited from here
"Apple's OS X directory service support is built around LDAP and includes a plug-in architecture. The company provides a small set of plug-ins that enable support for Open Directory, Active Directory, and generic LDAP services. The big advantage for enterprises, however, is that this approach allows third parties to create additional plug-ins that offer greater capabilities than what Apple includes with each OS X release.

Apple's Active Directory plug-in has steadily updated since it was introduced five OS X generations ago, with the most notable improvement in OS X Lion being support for DFS browsing. That said, Apple's Active Directory support has its limitations, as it is primarily aimed at providing authentication and, on its own, offers almost no client management capabilities."
Click to expand...

Using third-party software
Thursby ADmitMac, Centrify DirectControl or Likewise Enterprise all offer a Mac-to-AD integration by providing their own plug-ins for Macs willing to obey an AD server. There are two excellent overviews here and here. In my opinion this is the best and most complete solution for paying enterprises which need to manage Macs and Windows PCs through a single directory service.

What about managing FreeBSD or Linux clients? Well, give me a coffee break, I'll post some thoughts about this later.
 
Now I would like to come to FreeBSD and its place in a directory service. It is not intended to be a how-to but rather a starting point for a discussion.

Let's imagine we have a network of 40 Windows PCs, 15 iMacs and 20 FreeBSD desktops with KDE. Which directory would you choose to manage them? I guess Active Directory. Why? Because it's got group policy! And there is nothing comparable for FreeBSD or Linux. Well, there is FreeIPA for Linux, but this is only on the server side. In order to apply something to a client machine, it must be able to receive and use it (like the Windows registry).

Here is why I started this topic under KDE. I think that the desktop environment (on the client) makes the decision for the directory (on the server). For FreeBSD we have KDE and GNOME, but none of them support group policies like Windows. This is why the FreeIPA project is near to useless. What are the alternatives?
  • for KDE this is Kiosk. It is the most 'advanced' free/opensource tool I know of.
  • for GNOME we have Sabayon, although I am not informed of its current development status and capabilities
None of them support a centralised dispatch of policies from a server in the way Windows and Active Directory do. The only solution I am aware of is a commercial one: Likewise Enterprise. Here is a good overview of its functionality.

So my questions for this discussion are:
  1. Are there other free/opensource/commercial solutions which bring group policies to KDE or GNOME?
  2. Are there intensions/plans/desire/need in the FreeBSD community for a development of a centralised dispatching service for KDE group policies on top of a, let's say, plain OpenLDAP directory? Or even a Samba alternative, now when the SMB specs are open.
  3. KDE and GNOME are both GPL, so FreeBSD still lacks a clean-room developed desktop? Any plans for such one?
Hope these are of interest not only to me :)
 
vanessa said:
KDE and GNOME are both GPL, so FreeBSD still lacks a clean-room developed desktop? Any plans for such one?
Click to expand...
There are no plans for anything that comes with FreeBSD by default. There probably never will be. Keep in mind that KDE and GNOME are considered third-party software and as such are not part of the FreeBSD OS.

I understand what you are asking but I think you're asking the wrong people. The FreeBSD OS simply doesn't have a desktop and never will. If you're wondering what KDE or GNOME are planning to implement any directory services you should really ask them. Added bonus, if it does get added to KDE or GNOME it's most likely going to run on both FreeBSD and Linux, killing two birds with one stone.
 
If you come from a Linux background the distinction between ports and the base OS is something to get used to. On Linux everything appears to be part of the "OS".
 
I would summarize the differences like this: In FreeBSD the desktop environments are considered third party software as noted above and the OS itself does not provide any special support for getting a particular third party software package working on FreeBSD. If it can be made to work on FreeBSD, good. If it can't be then it's not the responsibility of FreeBSD developers to "fix" the OS to get third party software package working (unless there's a bug that causes FreeBSD to do something that clearly violates standards and expected behaviour and there for breaks the 3rd party software).


On most Linux distributions there's no division between the base OS and third party software. Much of what is in part of the OS that would be part of the base system in FreeBSD is subject to changes, many times in uncontrolled fashion, to tailor the OS to accommodate the latest changes in most popular applications, web browsers and desktop environment for example.
 
Despite being a FreeBSD newbie, I make this distinction. However the base system might be extended at some point of time, doesn't it?

And I do realise, that coding a desktop from scratch is really a huge project. On the other hand, when seeing the difficulties and time needed for porting GNOME 3 from Linux to FreeBSD, a clean and straight approach doesn't seem so weird.
 
vanessa said:
Despite being a FreeBSD newbie, I make this distinction. However the base system might be extended at some point of time, doesn't it?
Click to expand...
Absolutely. Just look at the differences between 9.x and the upcoming 10.0.

But for the things you are suggesting I don't think the base OS is the right place to do it.
 
OK, so let's drop question number 3 or mark it answered and look at the other two. Are there any suggestions?
 
The only one I could think of that uses anything resembling policy groups is polkit (formerly known as PolicyKit). At least GNOME has it already implemented, I'm not sure about KDE.

And when it comes to the base OS I think a good LDAP client integration would be nice. You need to install third party software to get it working. I'm fine with that but tools like passwd(1) only support NIS and Kerberos besides the local accounts. Everything on top of LDAP for KDE, GNOME or whatever else shouldn't interfere with the standard LDAP authentication that's in use now.
 
vanessa said:
Let's imagine we have a network of 40 Windows PCs, 15 iMacs and 20 FreeBSD desktops with KDE. Which directory would you choose to manage them? I guess Active Directory. Why? Because it's got group policy! And there is nothing comparable for FreeBSD or Linux.
Click to expand...

Pretty much. Also, AD can be supported by a vast, vast army of Microsoft support technicians (and desipte a large quantity of muppets, some know their stuff), many commercial Windows applications expect it and it has been battle tested over 10+ years.

In terms of path of least resistance/trouble, making non-windows machines work with AD is probably easier than re-creating an AD clone and replicating all of the AD functionality for Windows.
 
SirDice said:
The only one I could think of that uses anything resembling policy groups is polkit (formerly known as PolicyKit). At least GNOME has it already implemented, I'm not sure about KDE.
Click to expand...

Can Polkit be used for saving the user's preferred screensaver for example? Or to lock down a user preventing the execution of particular programs? I don't think so ... From what I know and read it is an SUDO rights management tool, nothing more. Don't know if it could be extended to do something more.

throAU said:
In terms of path of least resistance/trouble, making non-windows machines work with AD is probably easier than re-creating an AD clone and replicating all of the AD functionality for Windows.
Click to expand...

I agree with you. So the "perfect" combination would be KDE and/or GNOME pulling their newly created group policies from an AD server, be it Windows or Samba. No need to make use of all and every AD client feature, but the most important ones.

Also, in place of the file-based Windows registry, a local LDAP server or a file-based database could be used as the local storage. This database, however, should be developed with the base FreeBSD system as it can be used without GUI for f.i. authentication or ACL storage.

How about a plugin-able registry-like database in the base system which can be extended by KDE or GNOME or any other app for its respective needs?
 
I think a big thing missing from the Unix world in terms of user management (and someone will no doubt correct me if I'm wrong here) is nested ACLs.

If you want to implement role based access control, you pretty much need them (yes, sure, in theory maybe you could flatten out the groups to a single level, but management would be even more of a nightmare).

E.g., with RBAC on Windows (Active Directory)

Joe is a department head and wants access to the HR folder, but the HR staff need full read/write.

I would create/modify ACLs for something like

  • HR_FOLDER_RO - ACL assigned READ-ONLY access to the folder. ACL Members: ROLE_DEPT-HEAD
  • HR_FOLDER_RW - ACL assigned READ-WRITE access to the folder. ACL Members: ROLE_HR_OFFICER
  • ROLE_DEPT-HEAD - ACL containing users who need to perform this job description. This ACL is included in various other ACLs including stuff like say, DEPT_BUDGET_RW, HR_FOLDER_RO
  • ROLE_HR-OFFICER - ACL containing users who need to perform this job description. This ACL is included in various other ACLs including stuff like say, HR_FOLDER_RW

Yes, this looks like a bit more work to set up, but... this lends itself to assigning and removing roles to people rather than putting them in a million different security groups and then trying to retroactively figure out what to add and remove when they take on or lose responsibilities.

You just figure out the permissions for a role ONCE and make minor adjustments both to the role (as new resources like folders and equipment are added) and the people it applies to as required. I.e., it's a little short term initial pain for far less pain in maintenance.

Trying to do this 2 layer thing with Unix groups just doesn't work. Unless I'm missing something?

The filesystem does ACLs, but authentication on Unix doesn't unless you use something like LDAP somehow?

e.g., I can't for example create a group for HR_STAFF, and then have that HR_STAFF group a member of a hundred other groups for particular securables on a Unix box. I'd need to add the user to all hundred groups directly... every time I add a user. To remove the equivalent permissions when they move to a different department, but keep one of their other existing roles? Nightmare. Start over.
 
Well, as you said, LDAP helps here a lot. Actually I don't even discuss a solution without LDAP. The problem is that it is not enough. Even if LDAP does the authentication in a fine grained manner and serves all possible stuff like a real database, a normal UNIX box can not make much use of it.

You described a normal user rights management scenario. Now add to it the need to lock down a group of users and allow access to just a couple of programs whereas others may not be run. I am even not speaking of cooler stuff like saving user sessions (running programs or size/position of open windows) to the server. All these do need a local caching database which synchronises with the server.

With two replicating LDAP servers this could be also achieved with no big effort. The problem is that UNIX OSs can't make use of the information. KDE's Kiosk goes in the right direction but is still far, far away from a complete solution. Really pity ...
 
I believe you may be able to lock down file execution rights by using ACLs on the filesystem, and removing the user's execute permission.

No, this won't be in a policy type way like active directory's group policy, but presumably you could do it with a cron job, some shell scripting, a list of files and setfacl.
 
Yes, as I thought: program yourself a FreeBSD "registry" and join an AD/Samba would be probably the best solution. Or use a commercial fix ...
 
You must log in or register to reply here.
Back
Top