Making SSO a reality in mixed-OS enterprises involves niggling details, compromises, and add-ons or third-party solutions. Does Windows 2000 help?

Single Sign-On Promises

Making SSO a reality in mixed-OS enterprises involves niggling details, compromises, and add-ons or third-party solutions. Does Windows 2000 help?

• By Roberta Bragg
• May 01, 2000

Ever since Biblical people built that infamous tower stretching toward Heaven only to have God cast it down, we’ve been doomed to a babbling cacophony of voices. We’ve been promised that the fruits of every new spiritual, philosophical, governmental, mechanical, industrial, and technological advance will bring us the ability to fully communicate, speculate, commiserate, and cohabit with our fellow hominoids in one big happy family.

Shoot, I can’t even communicate with my teenager, and we’re going to have worldwide conversations? That’s like promising “one user, one account, one password” in the enterprise.

Or isn’t that just what we’re being promised by the current darling of geekdom—“single sign-on” or SSO? Microsoft claims SSO in its Windows 2000 network. Novell promises it with Novell Directory Services for NT. Kerberos defines authentication interoperability for Unix systems. Everyone’s singing this tune, but where’s the three-part harmony?

What’s the fuss? Maybe you don’t want your Linux server slumming with NT or your Novell accounts able to access the mainframe. Why not stick your head in the sand while the tsunami approaches?

You think you have it tough remembering multiple passwords and accounts?! Pity the poor security administrator. If you have multiple accounts and you leave the company, how can I be sure I’ve eliminated all of your accounts from every system? Now I’ve got more security holes than Bill Clinton’s testimony. Your attempts at logging into NT with your NetWare password have just generated 25 password failure audits, which I have to recognize as your forgetfulness and not as an attack on your account. Forget your passwords often? Last night I found 55 passwords taped to the bottoms of 18 keyboards. Guess you’ve got too many to remember, huh?

OK, you get the point. A little coordination could go a long way here. That’s what SSO is supposed to give you. It’s the first step to easy interoperability. In a strict, Windows-only network with perhaps fewer than 40,000 users, you can have it. One account, one password. Add a few iMacs? Give them an authentication module and load Services for Macintosh and you’re still OK. Then it gets complicated. Let’s look at what features and promises are available to make SSO a reality in mixed-OS enterprises.

Give a Little, Get a Little

SSO doesn’t mean all your problems with disparate networks are over. Even a single-OS enterprise has problems with that (Come on, show me your colors: Big Blue, everything red, Red Hats waving, or the Microsoft rainbow family…) Living in an SSO world doesn’t mean you have everything. In the single-OS enterprise, there are still plenty of problems matching the parts. In the SSO world, you still have to figure out how to share files, and programmers are going to have to implement middleware to make applications cross-OS-functional.

Everyone’s got an SSO initiative these days, including Microsoft, Unix, and IBM (which has had one for a long time). It’s just that when your family’s that big, it’s hard to get them all to play well together, let alone invite anyone else in for tea. If you listen to any of these good folks, they’ll tell you they’ve got the problem solved. If your systems are predominately one or the other, then perhaps you’ll agree.

So what’s SSO? Simply put, it’s just what the network administrator and the frustrated user ordered. With SSO, you have one user account and one password. You log on once in the morning and go anywhere in the enterprise you want (well, anywhere you’re allowed to go). That allowance, however, is now by policy, not by techno-inability. Notice I said anywhere you’re “allowed” to go. SSO doesn’t mean my applications and file systems work the same way, or that there’s any structure in place to translate permissions or allow applications to communicate across disparate systems.
SSO simply means you don’t have to have multiple accounts and passwords. This is a good thing. It’s convenient for users, and once he or she understands the principles and implementation, it’s better for the administrator. It’s the first step on the stairway to the new enterprise order.

Halt! Who Goes There?

Like the soldier approaching the sentry, we must prove who we are every time we access resources on the network. Authentication is the process we go through. It’s the challenge we answer when we enter our user ID and password in the morning to prove to the system that we are who we say we are. Authentication, by definition, doesn’t grant us any rights, permissions, or resource access; it just identifies us to the OS. Remember that. To understand SSO—to understand interoperability features in new and old OSs, applications, and networks—you’re going to have to separate “I am who I am,” which is authentication, from “I have the right to do a backup, read a file, enter data, and print payroll checks,” which is authorization. These two principals of security are often confused.

“Stupid Microsoft. It keeps asking me for my name and password,” Treny says. “And I keep entering it and I still can’t get my email. I logged on using that name and password, so it has to be right.” Like Treny, we tend to forget that until you get an access-denied message, you usually don’t realize that this sort of check isn’t done only at the morning logon, but happens all day long. Each new resource I look at checks to see if I have the rights to access it; if it finds me lacking, it may ask me for new credentials. Other resources, such as email servers, may ask for another logon. In Treny’s case, her son had pointed her email client to his mail server. It was looking for his account and password, not hers. (The things I put up with.)

Status Report

OK, the promise of SSO is not that everything works well together, but that we’ve accomplished the first step. Can I move as easily across disparate platforms as I can across homogenous ones? In true SSO, I log on once and forget about it. Changes from one host to another are transparent to me as a user. Each new OS I need to touch can use that initial logon information to determine if I’m allowed into the system. What happens after that is the province of the subsequent system. Another component of true SSO is the ability to easily manage user accounts across disparate systems. I need to be able to have some way of controlling password changes and user additions and deletions that’s efficient, reliable, and secure.

So from the perspective of users of Microsoft products, what’s the current status of SSO? Here’s what’s in place and how it’s supposed to work.

There are six main players in our enterprise today: Windows, Unix, Novell, Macintosh, IBM mid-range (AS/400), and mainframe systems. These are the ones most of us have to deal with. Can I have SSO if I have all of these today? Maybe. There are various ways that password integration can occur, and there are different ways you can implement it. Some of your success depends on the products you choose, your abilities as an administrator, and your acceptance of a few hiccups along the way.

Here are some of the choices you have today.

Choose a Common Authentication Algorithm

Windows systems (3.x, 9x, NT, and Win2K) share the LAN Manager (LM) network authentication system. NTLM and NTLM version 2 were developed for NT, but weren’t backported to the other OSs until now. In a Win2K network with Active Directory, the Active Directory Client for Windows 98 will retrofit the client OS so that it can use NTLMv2. Microsoft Services for Unix also has a telnet server that supports NTLM authentication. Unfortunately, you must use the Microsoft telnet server, which is available only for NT and Win2K.

Choose a Standard Authentication Algorithm

Win2K uses Kerberos for network authentication. Kerberos is a standard system (see RFC 1510, available at www.ietf.org/rfc/rfc1510.txt) used for many years in the Unix world. Since it’s standard, not proprietary, it offers the possibility of interoperability with other Kerberos-based systems. For more information, see “Kerberos Interoperability.”

Purchase a Method to Synchronize Passwords

If you have a mixed Novell and Microsoft infrastructure, you’ve experienced their attempts at integrating with each other. Each offers a way to share files with the other. From the Microsoft side, you can use Directory Services Manager for NetWare (DSMN) to copy NetWare user accounts to NT Server 4.0 Directory Services or Win2K Active Directory. Changes are propagated back to the NetWare server. DSMN also provides dsmchk.exe, a utility to verify that password changes have been propagated to all NetWare servers.

Microsoft Services for UNIX (SFU), used with either NT 4.0 or Win2K, can be set up to handle secured or unsecured password synchronization. Networked Unix computers are organized into security groups called password synchronization pods. Unsecured methods send passwords in the clear across the network and use the Unix rlogin daemon. A secured model requires placing an SFU component—the single sign-on daemon (SSOD)—on the Unix system. An encrypted channel (3DES) is used to send passwords to each Unix server. In a Network Information Services (NIS) domain structure, Windows sends password changes (see Figure 1) to the SFU Password Synchronization Daemon running on the NIS domain master. The NIS domain master propagates password changes to its clients. (NIS is a namespace administration system for Unix systems. It’s used to organize Unix computers into a central administrative model. Different flavors of Unix implement their own versions of this. Each Unix computer or NIS domain master must have the Password Synchronization Daemon installed. Currently, versions exist for HP-UX, SunOS, and Digital Unix. Source code is available should you wish to write your own.)

Figure 1. Synchronizing passwords securely through Microsoft Services for UNIX (SFU) involves five steps: 1) the user feeds information to the NT PDC; 2) NT sends changes to the SFU password daemon; 3) the SFU daemon on each server in the password synchronization pod is updated; 4) the SFU daemon also updates the Network Information Services (NIS) domain master; 5) the NIS domain master updates other hosts in the NIS pod.

Proginet’s SecurPass (www.proginet.com) extends the SNA Server gateway single sign-on to provide password synchronization with IBM host security applications (ACF2, RACF, and TopSecret). Password synchronization is two-way. A Proginet SecurPass detects password changes and supplies them to other SecurPass platforms. Suspended or deleted host accounts will also be propagated to NT. In addition, SecurPass Password Harmonization (oh, I hear the music) makes sure your NT password choice follows the mainframe-established rules. You can change your password in NT or on the mainframe through your emulator. SNA Server provides the host connectivity.

Open Universal Software’s Universal Password, combined with Microsoft SNA Server, provides password synchronization support for AS/400 to NT connectivity. Learn more at www.universal.com.

White papers are available at www.microsoft.com/sna. More information on SNA Server follows.

Create Translating Gateways

A variety of gateways exist, including Gateway Services for NetWare, SNA Server, and Services for Macintosh.

Gateway and Client Services for NetWare

Gateway Services for NetWare allows the Windows client to access Novell servers. Client Services, installed on the NT client, provides access without the Server gateway. Neither sidesteps the authentication process. Duplicate accounts are maintained on the Novell and Windows servers. A gateway account on the server can provide access for multiple users without Novell accounts. Clients using the client service must have their own account on the NetWare server.

Host Integration

SNA Server provides a gateway from NT/Win2K to mainframe, AS/400, and Unix hosts. SNA Server 4.0 provides single sign-on. A user can be authenticated by NT and have his or her account mapped to multiple hosts. This service doesn’t include automatic password synchronization. Both users and administrators can perform manual synchronization using the security configuration tool udconfig. For more information on this process, see “Host Security Integration.”

Host Security Integration with SNA Server Host Account Cache. A database that maps host user IDs and passwords to Windows user names and passwords. This is installed on the domain controller where the SNA servers are installed. Host Account Synchronization Service sends notices of changes in Windows accounts to host, or host to Windows if a third-party interface to the host security databases is used. This must be installed on the SNA Server. Windows NT Account Synchronization Service synchronizes passwords between multiple NT domains in a multiple master domain arrangement and with the password synchronization services supplied by third parties. Host Security Domain defines different security domains that will share a common user database and would include NT, host, and SNA Servers. With or without third-party password synchronization services, the user can log on once to the SNA server, and the SNA server can autolog the user into the host application. Microsoft SNA Server can provide different host logons as necessary, so users don’t have to remember multiple host passwords. Another advantage to using SNA Server is that 3270 and 5250 emulator host logons typically pass passwords across the network in the clear. If the emulator is configured to use SNA Server, the logon can occur at the SNA server; no clear text password need travel across your network if you then secure the SNA Server-to-host connection with a channel attachment, use a dedicated token ring LAN connection, or use the client-to-server encryption feature of SNA Server 4.0. SNA Server can help to coordinate many dissimilar systems (see Figure 2), including IBM Advanced 36, System/36, System/38, AS/400, and mainframe systems, Unix systems, and the entire Windows family. Figure 2. Passwords in domain A are synchronized with the mainframe using SNA Server and SecurPass. —Roberta Bragg

Authenticating with Macintosh

The usual choice for providing authentication for Mac computers on your network is to install Services for Macintosh and place User Authentication Modules (UAM) on the Mac. UAM allows encryption of passwords similar to the Windows client and increases the possible password length to 14 characters. In addition, use of the UAM allows Windows to notify Mac users that their passwords have expired.

Develop a Public Key Infrastructure Using a Trusted Root

It’s funny how a groundswell of public initiative and private greed can create something that the giants of our industry can’t. IBM, the Open Source initiative, and now Microsoft have been promising interoperability for a long time, if you do it their way. Each one, sitting in a world of its own making, attempting to determine our fates, bemoaning the complexities and wanting to be “the” one to bring us a solution, has missed an opportunity and is now scrambling. They forgot a basic premise of business: It’s not the technology, stupid; it’s getting the work done.

I’m talking about the ease with which we now buy and sell goods on the Internet. Talk about your penultimate interoperability. No merchant on the Web cares if I’m logging in to a site from an iMac, a PC, an RS/6000, or a mainframe. No browser gives a twit if the Web server is sitting on OpenBSD, Win2K, OS/390, or Mac OS9. If my credit card will accept their charges, I’m in, baby.

Sure, it’s not SSO for the user—just yet. In fact, I’m collecting a whole lot of new identification these days. The Web servers get it though; they buy a certificate and voila! Their authentication credentials are in our account databases.

The goo that allows us to shop and others to sell is a reliance on public key infrastructure. What makes it work? Every Web site that wants to participate obtains a server certificate from a third-party certificate authority such as VeriSign (www.verisign.com) or Thawte (www.thawte.com), recently bought by VeriSign. That certificate allows the merchant and you to participate in a public-key, private-key cryptographic session when you want to exchange money for goods over the Internet. The merchant retains the private key, and the public key is incorporated in the certificate. When you visit the merchant, you obtain a copy of the certificate and use the public key to secure communication. This is an example of authenticating the server—you want to know with whom you’re dealing. It works because the other guy’s server’s certificate was certified by a root authority that we trust (such as VeriSign). You didn’t give your permission to accept this authority? When you use your browser, it can check the authority of the merchant’s certificate by looking in its certificate store. Every browser comes with one. To look at your certificates in Internet Explorer go to View | Internet Options | Content | Certificates. This brings you to Certificate Manager. Don’t change anything!

You can set up your own PKI with Windows NT Certificate Server (available for free in the NT Option Pack) or with Win2K Certificate Services (an installation option). You can accept a root certificate from another authority or become your own. If you’re your own root authority, I wouldn’t try to sell goods over the Internet to consumers; they won’t have your root certificate in their browsers. Managing your root authority is a good framework for setting up a public key infrastructure in your enterprise or for trading with business partners who are willing to trust you.

Herein lies much promise for SSO.

Use one Directory Structure

Win2K Active Directory offers another approach to interoperability. In this approach, since all users are in the directory, you truly have one account and one password. In a Microsoft world, you’ve eliminated the 40,000-user account barrier and can have single sign-on in your Microsoft enterprise. If other directories can be merged and manipulated with Active Directory, then we can have true SSO. Instead of integrating OSs to get SSI, we’ll integrate directories into one large mega-directory and make a new creature: the SSO hub.

At this point, with Win2K, we have part of the picture—we can synchronize with NDS.

Directory Synchronization Services for NetWare 5

First, we have password synchronization; now we have directory synchronization. First, we can update passwords on a disparate system; now we can update all sorts of information about users, printers, servers, services, and so forth.

Microsoft Win2K Directory Synchronization Services (MSDSS) allows two-way data synchronization between AD and NDS and one-way synchronization with NetWare 3.x binderies. Password synchronization is one-way, AD to NDS.

Use ADSI

Active Directory Service Interfaces provides a consistent, open set of interfaces for integrating multiple directory services. Using Perl, REX, VBScript, or C++ you can create your own interfaces with NDS. First, you must install Gateway and Client Services for NetWare. Read “Using ADSI with NDS Providers” in MSDN or find it online at http://msdn.microsoft.com/ isapi/msdnlib.idc?theURL=/library/psdk/adsi/ds2prggd_7mgj.htm.  

ADSI is also used to integrate Microsoft Exchange Server 5.5 directories with Win2K. Exchange 2000 will be integrated with the AD and won’t have a separate directory store.

Kerberos Interoperability The Windows 2000 implementation of Kerberos has stirred up hope and a host of new antagonism from “the other guys.” Kerberos is a standard, so you ought to be able to integrate Win2K with other Kerberos systems and have a single authentication system to manage. Microsoft being what it is, the Kerberos community is quick to jump all over any real or perceived variance from “the standard” (the interpretation of the RFC that they themselves have implemented). What’s the truth here? A recent white paper sums up what Win2K offers in the way of interoperability; you can find it at www.microsoft.com/security. In a nutshell, here’s how Kerberos integration is supposed to work: MIT Kerberos-based clients and hosts can use a Win2K Server Kerberos KDC (Kerberos Distribution Center—the user and password database) for authentication. DES-CBC-MD5 or DES-CBC-CRC encryption types can be used. Win2K Professional clients can be configured to use a Kerberos realm for authentication. That’s right: single sign-on to the Win2K Professional client and to the Kerberos realm. Command-line tools to configure Win2K Professional are on the installation CD. Cross-platform hierarchical Kerberos realm support isn’t included; however, you can set up a trust relationship between Win2K domains and Kerberos realms. The trust won’t be transitive, but it can be configured. Accounts for the MIT Kerberos clients and hosts are configured in AD. Services instance accounts can be placed in AD for services running on Unix systems. Trusted MIT Kerberos realm accounts are mapped to local account identities in the AD. There’s interoperability between the Win2K Kerberos Security Support Provider, which is its implementation of the Kerberos GSS API (RFC-1964) and an MIT Kerberos implementation of the GSS API. Figure 3. In a properly integrated Unix realm and Windows 2000 domain, Win2K Pro and Unix clients can access services that exist in both. Users log on once, using either a Win2K or Unix ID and password. —Roberta Bragg

And the Answer Is…

How dissimilar is your network? What’s your budget for add-ons and administrative support? What’s your background in the technologies I’ve discussed? Ideally, SSO should reduce administrator involvement in the issue of authentication. However, there’s going to be a learning curve and a time when it seems you’d be better off glossing over the multiple password issue.

One thing’s for sure: We’re a lot closer to true, enterprise-class SSO than we’ve been before. Does that mean the tower is about to be knocked over again?