Hey, what are you doing about metadirectory services? What do you mean, "huh?" Just because your organization isn't a Fortune 100 company doesn't mean that it can't benefit from a metadirectory service, and chances are, a metadirectory service such as Microsoft Identity Integration Server (MIIS) 2003 is in your future.
What is MIIS? It's Microsoft's entry in the field of products called metadirectory services. Metadirectory services help manage and synchronize multiple directory services. If that's still not clear, let's back up a bit further and ask "What exactly are directory services?"
Put simply, every secure application and OS need some kind of database of users, some way of authenticating the users, and some way of proving that they're who they say they are. Take Windows NT 4.0's SAM file, for example. It's basically nothing more than a list of user names and passwords. You try to log on by entering your user name and password, and NT looks in the SAM to verify that what you entered matches a user name/password pair. Now let's restate that in directory service terms. The SAM file is a directory. A directory is simply a database of users, passwords, and other data, depending on the particular directory. For example, NT's SAM contains user objects, computer objects, group objects, and trust relationships. An Active Directory (AD) database also contains objects for Group Policy, organizational units (OUs), and many other items. Like other databases, it has no value unless you can query it, which in this case you'd need to do to log on, to change a password, create or delete a user account, or perform similar activities. Every copy of Windows Server 2003, Windows XP, Windows 2000, and NT contains an entire database engine and query language, and when an application needs to know who you are, it uses that database engine and query language. Therefore, you could say that NT and later versions of Windows "provide logon services." Or, to use another phrase, NT contains a directory service. Yes, even simple old Windows NT 3.1 contained a directory service.
You almost certainly know of other things that could be called directory services. There's AD, of course. Or you might recall Novell Netware 3.x's Bindery file (a SAM-like database) or the more complex NetWare Directory Services (NDS) that succeeded it. Banyan, the networking company that Microsoft hired Windows honcho Jim Allchin from, had a nice directory service called StreetTalk. Sun Microsystems has Solaris, and its cousin, the Linux family, has a bunch of directory services including an old UNIX standard called Network Information Services (NIS), which is actually integrated into Windows 2003 R2 domain controllers (DCs). The IBM, Univac, RCA, and Digital mainframes that I've worked on over the years all kept lists of user names and passwords, so they had directory services as well, albeit simple ones.
But directory services aren't just for OSs. Many application programs have them as well. For example, Lotus Notes keeps its own list of user names and passwords, as did Microsoft Exchange Server 5.5, 5.0, and 4.0 (Exchange 2000 and later rely on AD, which is why you can't run a modern Exchange server on a system without AD.)
So what's the big deal with directory services? The fact that they're directory services--plural--not directory service. Virtually every organization has more than one directory service, and that makes for trouble. For example, I have a very small company but still have, believe it or not, four directory services. First, there's my AD domain. Then I have an email server called MailEnable that doesn't integrate well into AD, so it keeps its own list of users and passwords. I also use a tool called WorkgroupShare to share my Microsoft Outlook Contacts and Calendar with my assistant; it does integrate with AD for logons, but I've found that a bit troublesome to make work, so I've opted to configure it to maintain its own list of users and passwords. Finally, I have a Web server directly connected to the Internet that I prefer not to make a domain member for security reasons, so it has a SAM of its own. Thus, in my small enterprise, my assistant and I need four different user names and passwords: one for the AD, one for MailEnable, one for WorkgroupShare, and one to administer the Web server. Password-changing day is, then, a bit of a chore.
But I have it easy compared with most of my clients. It's not unusual to run across a company with an NDS tree, three different AD forests (for legal reasons), a non-Microsoft VPN that doesn't talk to AD, Lotus Notes, an IBM AS/400 system, and a few secure Web-based applications hosted on a Solaris box. These companies would kill for a tool that keeps track of all of those accounts. So what if we took all those directory services and overlaid them with a piece of software that understood how to create, delete, and modify user accounts on NDS, AD, Notes, SAMs, AS/400, and the like. Such a tool would be a directory service for directory services or a "metadirectory service." Such a tool would let you tell it, "I've got a new guy named Larry, he'll need an NDS, Notes, and AD account but no need for a Solaris account, and give him a password of 'swordfish.'" The metadirectory service would then handle the specifics of creating each of those accounts by essentially pretending that it's a human administrator typing at the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, Netware's administration console or similar service; the various directory services would have no idea that they were being manipulated by a metadirectory service.
Microsoft's metadirectory tool, MIIS, grew out of Microsoft's acquisition of a firm named Zoomit, which sold a metadirectory product named Zoomit VIA. But Zoomit VIA was by no means the first attempt to solve the problem of keeping different directory services marching to the same tune. Other metadirectory services include IBM's Metamerge and Novell's DirXML, and there are many of others. Taken in the broadest manner, there are probably thousands of metadirectory services out there in the form of home-grown sets of batch files and scripts. In fact, that's how the original Zoomit VIA worked--it was mostly a patchwork of scripts. That meant a lot of work for whomever was trying to use it, but it also meant that supporting something previously unsupported (such as MailEnable, in my case) was at least possible if you didn't mind doing some scripting. That's why Microsoft says that MIIS supports AD, Exchange, Notes, Novell, Sun, "and many more." In other words, if you want to extend its power, you can write your own scripts.
MIIS 2003 comes in several flavors. MIIS 2003 Enterprise Edition supports a lot of directory services out of the box or enables you to create scripts and extend it. It runs on top of Windows 2003's Enterprise Edition and costs about $25,000 per processor. However, there's also a free cut-down version of MIIS called the Identity Integration Feature Pack 1a (IIFP) for Microsoft Windows Server Active Directory. It too requires Windows 2003 Enterprise Edition and can only manage one or more ADs, Active Directory Application Mode (ADAM) directories, and Exchange 5.5 directory stores.
Now, that last piece of information is the most interesting, as far as I'm concerned. Given that you can buy a fairly nice car for less than the cost of putting MIIS on one processor, MIIS is clearly intended for none but the loftiest of enterprises. But IIFP ... why make that product free? That's an interesting question, but I'm out of space. Have a wonderful New Year, and join me again in January to see how IIFP might just be one of the neatest--and worst!--things to appear in the Windows world.
