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?
Prediction Number 1 for the year 2000: The
next killer app is going to be one that will
automatically manage all my Internet logons
and allow me to have single sign-on on the Internet.
Know of one? Or want more details? Write me
at [email protected].
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
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
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.)
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
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
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
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.”
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
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
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
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.
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
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.
|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
- 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.
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?