At Likewise, we’ve just recently announced the “Fall Edition” of our software. If you haven’t done so already, you shouldn stop now and read Krishna’s post on the topic.

I know, it’s a long post but, hey, we’ve got a lot to talk about in this release! There’s LWIS (a German pun on “Elvis”), there’s the new event system, the Likewise Administrator’s Console and support for the Mac Workgroup Manager. Each of these warrants its own post, elaborating its features. In this post, however, I’m going to write about something that Krishna mentions only in passing: the new underlying architecture. While LWIS (the new Likewise authentication engine) is the most clear manifestation of this new architecture, it’s impact to the current and future products is much more significant.

Before I get into the details of the new architecture, let me describe the fundamental elements of authentication and why we decided to redesign our product.

Fundamentally, authentication against Active Directory does not seem like a difficult problem. AD supports the Kerberos security protocol. To logon to AD, first you need to “join” the computer to AD and then you need to send some Kerberos packets to get a user “TGT”. This TGT, later, lets you get “service tickets” for other systems allowing single sign-on. After a user is logged on (to a UNIX, Linux or Mac computer), you then need to implement a series of nsswitch library functions to perform name-to-ID mapping. Implementing these functions usually involves performing a series of LDAP transactions in order to look up information in AD.

So far, the problem doesn’t seem very complicated. Indeed, years ago, someone wrote pam_kerberos and a set of nsswitch libraries to do exactly this. Alas, this simple-minded approach turns out to be difficult and inadequate. Joining a computer to AD involves creating a computer account (and Kerberos principal). Doing this “by hand” involves steps on both Windows and non-Windows computers and copying keytabs around. Additionally, AD doesn’t like plain old LDAP calls – it wants them to be secure and encrypted. Doing this with SSL encryption involves certificate distribution and other messy details. Beyond this, there are the issues of “offline-mode”, site affinity, domain controller selection, automatic machine password changes, Kerberos ticket refreshes, dynamic DNS updates and a host of other problems. Oh, there’s Group Policy, too. Hey, if it was easy, Likewise would not be in business.

The authentication engines in Likewise 3.0 through 4.1 were based on Samba source code. Samba has been in the Windows interoperability business for years and has solved many of the problems mentioned above. Likewise employs several Samba developers and has been a major contributor of features and bug fixes for several years.

With 5.0, we decided to rewrite the authentication engine to remove our dependency on Samba. Why? Because we wanted to develop an architecture that would serve our needs for the next 5-10 yeas. Our interests in the Identity Management business go significantly beyond authentication and group policy. We need a flexible, modern, architecture that suited our technical and business purposes. Let’s consider the elements of the new architecture.

First, 5.0 is based on a formal RPC (remote procedure call) architecture. In order to join a computer to Active Directory and to perform a series of other operations efficiently, the Likewise agent performs RPC calls rather than LDAP calls. These RPC calls are described using a formal IDL (interface definition language) and translated by a compiler into a set of stubs that handle marshaling of the RPC calls. In 5.0, we’ve defined an IDL language and an IDL compiler that is Microsoft compatible. We can take IDL files designed for Windows and generate stubs that work on non-Windows systems.

Second, because Windows systems accept RPC calls using TCP or named-pipe protocols, we’ve implemented RPC transport layers that support both of these protocols.

Needless to say, the RPC calls support authentication and signing/sealing with Kerberos protocols. Additionally, however, because we’ve implemented a local provider for LWIS, we also support authenticated, secure, calls between UNIX, Linux and Mac computers (or, for that matter, between non-Windows and Windows systems using local credentials instead of AD credentials).

Only Likewise 5.0 is based on a formal RPC architecture and only Likewise provides this architecture as open source to others who want to build on it.

There’s another reason why we’ve implemented 5.0 in this fashion: it’s how Microsoft does it. Krishna, several of our developers and I are all ex-Microsoft folk. When you’re trying to talk to Microsoft systems, doing ala Microsoft makes a lot of sense to us. Note, too, that LWIS (like lsass, its Windows equivalent) is thread-based. Samba was originally developed at a time when threads were not consistently implemented across UNIXy operating systems and, often, performed poorly or were not reliable. Likewise has developed thread-support libraries to deal with inconsistencies (for example, exception handling) between OS thread packages. The result is that LWIS is highly scalable, easy to understand, and easy to debug.

When we developed the new event log system in 5.0, we also exploited the new RPC architecture. As with most Windows APIs, the event log API is remotable. By calling our API, you can read or write from/to an event log on another computer just as easily as you can to the local computer. The RPC mechanism takes care of the remoting, authentication and securing of the call. It will be trivial for us to write an archiving event log collector without having to worry about clear-text UDP messages or about a custom security mechanism (problems encountered by syslog-based solutions).

Implicit in the previous paragraph, by the way, is that we’ve implemented our RPC mechanism on both the client and server side. Implementing server-side RPC will allow us to implement future functionality that requires centralized management consoles to call managed computers.

There are many other things “in the works” that will build atop our new architecture. Some of these will be appearing soon and some will take a little longer for us to complete. As I like to say, however, “in the startup world, there are only two times: now and six-months from now.” Beyond that, it’s anybody’s guess.