Archive for June, 2008

"How I Lost 1180 Seconds" or "Putting S.DS Code on a Diet" – Part 1

Sunday, June 15th, 2008

(Note: this is the first of a 4 part post).

In previous posts, I raved about .NET’s System.DirectoryServices (S.DS) — its library for accessing LDAP directories. In this post, I’ll go over how I sped up a particular bit of S.DS code in dramatic fashion.

S.DS, like any code, needs to be used and studied for a while before you really become adept at understanding how best to use it. If used in poor fashion, it can result in very slow code.

In my case, the slow code arose from my desire to properly layer various components of our software. Although n-tier design (where, most often, n=3) is associated with database processing the fundamental concept can be used on just about any software. The general idea behind tiered design is to isolate components from the details of other components “above” or “below” them in hierarchy. In database software, n-tier design suggests that all database access (connecting to the database, executing SQL statements) be performed in the data layer and that no other layer be aware of how the data is stored in the database. This allows you to change a database schema, for example, and to only have to change the one layer.

Atop the database layer, a business rules layer is often present. This layer contains the main program logic. In a banking application for example, it’s the layer that knows that a transfer between accounts involves a transacted withdrawal from one account and deposit to another.

Finally, the user interface layer displays information to the user and allows the user to initiate actions.

In my S.DS application, I use a similar layering. Only the data layer knows how Likewise stores information in AD. The data layer exposes higher-level UserInfo, GroupInfo and CellInfo objects that are manipulated by the business-rules layer. Finally, the user-interface layer is the code that interacts with our MMC snapins or with our own Likewise Console.

This layering initially resulted in some very slow code during a very common use case. When the user brings up the Likewise Settings property page for an AD organizational unit (OU) — in Microsoft’s Active Directory Users and Computers (ADUC) snapin — we display a list of all of the users and groups that are “enabled” for Unix access by the computers joined to that OU. At the lowest level, this operation starts with an AD search performed by the S.DS DirectorySearcher class. At the UI level, the data is displayed in a ListView.

When we encountered an OU with a large number of users and groups (around 10,000), my original implementation of this code took 20 minutes (1200 seconds) to display the information. By the time I finished redesigning and optimizing, I had this time down to less than 20 seconds.

I’ll explain how I accomplished this in my next post.

Do That Sudo Voodoo That You Do

Saturday, June 14th, 2008

In the Implementing Effective Access Control webinar that I did a few days ago, I spent a little time talking about sudo. It’s a pretty cool utility that, I think, is vastly underutilized. With some care, sudo can be the basis for a powerful role-based access control (RBAC) system on Linux.

Sudo is a Linux/UNIX/Mac OS X utility that reduces the need to run as root. Rather than logging in with the root account in order to access priviliged commands and restricted files, you log in with your personal (non-administrative) account and then invoke the sudo program whenever you want to perform an operation that requires root priviliges.

For example, to restart the network, instead of logging in as root and running:

/etc/init.d/network restart

You would log in with your personal account and run:

sudo /etc/init.d/network restart

The sudo command runs the privileged command for you after first consulting its configuration file, /etc/sudoers, to verify that you’re allowed to run the command.

In addition to minimizing the need to share the root password, sudo is also valuable because it performs logging. The command above would result in a log entry being written that identified who (your personal account) performed what operation (the network restart).

While we find that our customers are familiar with sudo, we find that many of them don’t use it. The problem with sudo is that, to use it, you need to carefully design a correspoding /etc/sudoer configuration file. Clearly, you don’t want everyone to be able to perform every privileged operation. You want to design a set of roles, for example:

  • System administrator
  • Database administrator
  • Storage administrator
  • Developer
  • Help desk assistant
  • End user

And then you want to determine what privileged commands will be available to each of these roles. Finally, you need to assign roles to your users.

Adding individual users to /etc/sudoer can be painful. If new employees are being hired and fired frequently, it’s inconvenient to have to push out new versions of this file to all the machines in your network. Although /etc/sudoer allows the referencing of user groups instead individual users, without a centralized authentication system, identifying groups in sudo is no more convenient that identifying individual users. Each time an employee is hired or fired, you’ll need to push out a new /etc/groups file to all of your systems.

This is where our software comes us. Likewise allows Linux/UNIX/Mac OS X machines to authenticate users with the Active Directory credentials. We allow these non-Windows machines to be joined to AD and to perform Kerberos/LDAP based authentication against AD without any local account.

With Likewise, adding/removing employees from AD groups is all done at the central LDAP repository; no file needs to be updated on each participating Linux/UNIX/Mac OS X machine. Additionally, Likewise extends the Microsoft group policy architecture to these non-Windows systems and provides a GP setting for sudo. We can use group policy to distribute sudo configuration files automatically.

The combination of Likewise software and sudo makes it much, much, easier to eliminate the use of privileged accounts by relying on sudo as controlled by AD group memberships.

Strangely enough, there’s no equivalent functionality in Windows. The closest thing to sudo is the ability to runas another user (impersonation). At the shell level, you can right click on an application icon and invoke the Run As… menu item. You can then specify the credentials for an administrator and run an application to which you might not normally have access. With this technique, however, you still need to know the credentials for an administrative account.

At least one third-party implementation of sudo for Windows has been written (this one).

Access Control and Controlling Complexity

Friday, June 13th, 2008

A few days ago, I prepared a Powerpoint presentation and a demo script for a Webinar. The topic under consideration was Implementing Effective Access Control.

The first thing I did was to look for a good definition of “Access Control.” As usual, Wikipedia did the trick, “Access control is the ability to permit or deny the use of a particular resource by a particular entity.” Pretty straightforward.

After defining the term, I demonstrated several different ways that our product (Likewise) provides to implement access controls. I came up with 4 different mechanisms and I know I skipped at least a couple of variations! Likewise lets you implement access controls by placing restrictions on a user account, by manipulating Cells (groups of computers), through access control lists on resources and by using group policy. There are other ways, too, based on setting ACLs on computers and by directly editing configuration files.

On one hand, we can brag about the power of our software. We’ve got enough mechanisms that we can satisfy anyone. Some customers don’t want to use group policy for non-Windows computers; fine, they can use Cell-based mechanisms. Others want a simple Cell architecture and no GP; fine, they use account restrictions or they can set configuration files manually.

On the other hand, when you step back and note the plethora of access control mechanisms, it’s hard not to think that all this should be easier to accomplish.

The real art in software development is providing power while maintaining usability. “Powerful, yet easy to use” has become such an oft-repeated mantra that it has lost all marketing value. Too many programs have promised such but failed to achieve one of the goals (or both!).

Although Apple has a well-earned reputation for delivering capable-yet-usable products, let me mention a couple of others: cars and cameras.

When I look at the dashboard of my car (one with, admittedly, more doodads than most) I note over 100 different buttons that I can press. Controls for windows, wipers, lights, radio, climate, GPS, traction control, locks, cruise control, turn indicators, telephone, parking radar, heat seaters, rear shade, etc. My car has a button that controls whether my door mirrors stick out, pull in or move in and out automatically. If I include “soft” buttons on the touchscreen GPS device, there’s probably more like 200-300 buttons.

In spite of the complexity, it took me less than one hour to learn 95% of the car’s functionality (I still don’t know how to set Address book entries without a Bluetooth phone).

I had a similar experience when I checked out the Canon 40D and Rebel XSi, recently. I was able to flip through the various exposure modes, figure out how to squeeze off multiple shots, and how to perform several other basic camera features. I dutifully noted the “CF” button on the back, but didn’t press it.

Why is that cameras and cars are easier to manipulate than spreadsheets and word processors? You can argue that the latter offer more features, but I think that 200-300 car features is probably comparable to the number of features I use in office products.

I think the key difference is whether or not people have a good existing mental model of how something is supposed to operate. I know, for example, that pretty much any non-American car is going to turn headlights on and off with some stick on the left side of the steering wheel. I’m probably going to pull it back and forth to activate the high beams. I know that there’s going to be an AM/FM band selector for the radio and that there’s going to be a button (probably, with a red triangle on it) that controls the emergency flashers. Every once in a while, I’ll rent an American car and I’ll have to hunt for a headlight know on the dashboard, to the left of the wheel. Every once in a while, too, I talk to someone old enough to remember the metal “pushbutton” on the floor that controlled the high beams on American cars until about 1970.

I knew how to operate the Canon cameras because I already own a Canon camera. Canon is smart enough to minimize UI differences between cameras. They’re also smart enough to exploit common standards or practices. The exposure mode knob is pretty standard on most cameras (with settings for “P”, “M”, “Av” and “Tv” and a bunch of icons). The “CF” button though is not. “CF” stands for “Custom Function”. This is where Canon “hides” about 25 functions that only advanced (or anally retentive) users need to access.

Cameras are a great example of the need to balance power and complexity. The Canon 40D is a formidable instrument. It provides tremendous flexibility over shutter speed, aperture control, flash synchronization, mirror lockup, picture resolution, etc. Either that or you can just put it on “P” and press the shutter.

“Software”, broadly, has no such well-defined model for how it should operate. There are some standard paradigms (for example: establish a selection and then perform an operation on it), but beyond the basics, there is too much variation between applications. For a while, we could count on “File”, “Edit”, “View” and “Help” menus but now Microsoft has gone and messed that up, too. After months of using the new version of Office, I’m still playing “find where they’ve gone and hidden my favorite operation.”

My only excuse when preparing my talk was that, at least, we only make matters a little more complicated. For the most part, the access control mechanisms that we provide are ones with which our customers should already be familiar (on Windows computers). We extend these mechanisms to work with UNIX, Linux and Mac OS X computers adding “only one” new one: the Cell concept. Here, too, we associate Cells with AD organizational units rather than inventing a parallel administration entity.

By the way, if you want to watch the recorded Webinar, you can see it here.