Integrating Windows and Unix Accounts
Vintela eases integration by replacing NIS with AD.
Microsoft’s Services for Unix 3.5 (SFU 3.5) helps bridge the gap between
Windows and Unix/Linux by “fooling” Unix/Linux systems into thinking they’re
just another NIS server. SFU can also perform account and password synchronization
between AD and existing NIS databases. In order to work, users on Unix/Linux
clients authenticate to a NIS server (either a real Unix/Linux one or
a Windows domain controller masquerading as one), and users on Windows
clients authenticate to an AD DC. Account and password synchronization
between AD and NIS happens behind the scenes, thanks to SFU 3.5. This
works well if you already have existing NIS and AD under one roof.
However, in both of these scenarios, there’s a fundamental problem—there are still two account databases to maintain: AD and NIS.
Vintela VAS reduces the number of account databases to just one: AD. This is an ideal way to handle new Unix/Linux installations because you can position AD as the “go-to place” for Windows and Unix/Linux authentication.
To accomplish this feat, VAS doesn’t need to load any services or other running software within AD. VAS simply leverages the AD schema to allow an association between existing AD groups or users to Unix/Linux group IDs and user IDs. The best news of all? If the schema’s been extended with SFU 3.5, you’ve already done all the modifications you need to do to AD.
Last, to assist in administration, simply load the Active Directory Users
and Computers snap-in extensions, and voila! You’re in business. The Active
Directory Users and Computers snap-in, shown in the figure, demonstrates
how each User and Group object has a new tab to correlate to Unix/Linux
properties. You can use these new tabs to “Unix-enable” a user and/or
|IT can correlate users and
groups to Unix properties with VAS. (Click image to view larger version.)
Once the information’s in place, the normal Unix/Linux user and group permissions take over. Alas, there is one more piece of the puzzle needed for the magic to work. In order for Unix/Linux clients to authenticate to AD, they have to have their own VAS client piece installed. That way, once users log on to Unix/Linux, AD is queried, a standard Kerberos ticket is issued, and both Windows and Unix/Linux security is utilized. Now, no matter where users try to gain access, the native Windows or Unix/Linux security will keep them honest.
The VAS client piece is available for multiple varieties of AIX, HP-UX, Solaris and Linux. Installation of the VAS client on my Red Hat test machine took about 15 seconds. It should be noted that this installation needs to occur for every Unix/Linux machine you want to participate in AD.
Once installed, I did what any normal Windows client would do in order to play in the AD sandbox: I joined the domain. This is done via the Unix/Linux command line vastool join. Computer accounts appear in AD like other computer accounts.
What’s especially noteworthy about the VAS client for Unix/Linux is that it actually utilizes the AD you hand-
crafted to its fullest advantage. The user and group account information for VAS is stored in Global Catalog servers. This is good, and if you need to log on across domains, it’s quicker. Even better, the VAS client is AD site-aware. In other words, it doesn’t just pick any random DC to authenticate to—it picks one close to the client. Nice touch.
The only problem I had with VAS was the way it handled the refresh of new user accounts. Specifically, if I “Unix-enabled” an existing AD user, then logged out of Linux, I couldn’t immediately utilize that user for logon. Instead, I had to wait 10 minutes for the local VAS client to refresh the list of Unix-enabled users from AD. Only then were they available from the “Happy GNOME” pick list of available users.
At press time, Vintela released VAS 2.4. Increased support for AD group types and nested groups are a welcome addition. Other new features are more nuts and bolts. Specifically, the Kerberos implementation was enhanced to support TCP failover should the ticket get too big to be handled by UDP. Additional support to help excise NIS is in there too — with a way to perform local NIS lookup, which, in reality, redirects those requests to AD servers.
In all, the Vintela Authentication Service is solid and easy to install
and use. If you need a “one-stop-shop” way to handle AD and Unix/Linux
account management, give it a test drive.
Jeremy Moskowitz, a Group Policy MVP, is the Chief Propeller-Head for Moskowitz, Inc. and GPanswers.com. He is one of less than a dozen Microsoft MVPs in Group Policy. Since becoming one of the world's first MCSEs, he has performed Active Directory and Group Policy planning and implementations for some of the nation’s largest organizations. His latest books are Group Policy Fundamentals, Security, and Troubleshooting and Creating the Secure Managed Desktop: Group Policy, SoftGrid, and Microsoft Deployment and Management Tools.