Jaa

Windows / Linux Integration -- Making sense in the enterprise

  • Artikkeli

By Jeremy Moskowitz © 4-5-2005 Jeremy Moskowitz

Windows History

Windows has a rich history of being easy to use -- when working with other Windows systems. However, what many administrators often miss is Windows’ ability to interoperate with other non-Windows systems, like Linux.

And, in integrating with non-Windows systems, administrators can gain the benefits of both Windows and the non-Windows systems. This can produce an overall lower cost to run IT services and provide better benefits to the end-user.

Integration Challenges

One challenge that faces administrators is the centralization of account information. Many organizations are standardizing on Active Directory as their “go to” place for centralized account storage.

However, this leaves many non-Windows systems to still have their own unique directories. When there are unique directories in the enterprise, this means three major problems:

• Administration isn’t centralized: Administrators are often running around to various systems. For instance, if someone’s name changes (say, due to marriage) the administrator must hunt down each and every directory the user is in
• Costs are increased: This running around to different systems to change passwords costs money. This is time which is not well spent.
• Passwords are not synchronized: If the administrator misses one directory, that user will most certainly be prompted for alternate credentials on the missed system. This causes pain for the user and certainly a call to the help desk.

Many users are using Linux to get some aspect of their job done. For instance, a specialized engineering or CAD application might only be available on the Linux platform. In those circumstances, should the user be forced to remember a different username and password?

Or, wouldn’t it be better to integrate the Linux account information into what we already have? Indeed, providing unified account storage which permits the user to log on to both Windows and Linux with the same set of credentials is ideal. 

One action which can be performed to help alleviate this predicament is to have unified account database. That database, is Active Directory.

Leveraging Windows

Of course, out of the box, Active Directory knows how to handle Windows account information. By using Active Directory Users and Computers, administrators have lots of potential fields to populate with user information, such as First and Last name, home directory, profile and the like

However, Active Directory out of the box, doesn’t have the ability to store Unix user, group and computer account information. Active Directory, out of the box, simply doesn’t have placeholders for Linux account attributes. Specifically, the two main things we need to teach Active Directory about are Unix UserID (UIDs) and Group IDs (GIDs).

But, additionally, beyond that, Active Directory also need to be taught about a location for Linux home directories, which Login Shell any particular user should use and a whole lot more.

In short, Active Directory needs to be taught how to embrace Unix user, group and computer account information. And, to do that, we’ll need to extend Active Directory to embrace Unix / Linux account objects.

There easiest way to have Active Directory be the unified source for account information is Microsoft’s via free Services for Unix 3.5 installation from Microsoft available at www.microsoft.com/sfu.

But before we take one of these steps, let’s take just a moment to understand what SFU 3.5 does to help you get started in overcoming your integration challenges.

Understanding SFU 3.5

Services for Unix (SFU) 3.5 allows Windows to embrace all sorts of Unix-like functionality. As described, one key component allows Active Directory to embrace Unix / Linux account information. However, let’s take a moment to get a better understanding of just what SFU 3.5 has to offer as an overall integration package.

Server for NIS
This component allows a Windows 2000 or Windows 2003 Domain Controller to pretend to be a Master NIS server. It can also pretend to be a Slave NIS server, but only to other Domain Controllers with the NIS Server components running -- not Unix NIS Master servers. Using this component, you can get rid of all your Unix NIS servers, and centralize NIS account information in Active Directory. Why is this good? We’ll examine this in the next section.

Password Synchronization
This suite of tools helps keep collections of Windows and Linux computers up-to-date with password changes on either platform.

NFS Client, Server, Gateway and Client for PCNFS, and User Name Mapping
A suite of tools which run on a Domain Controller which allow a Windows user to transparently view files contained within Unix / Linux NFS shares.

Base Utilities
If you’re already familiar with the Unix / Linux set of commands, (ie: ls, cat, grep, and more) this is the perfect addition.

Telnet Server and Telnet Client
Telnet Server is actually already built in to both Windows 2000 and Windows 2003. However, by loading this software upon a Windows 2000 machine, you’ll have a more enhanced version. SFU installs both a Telnet Server and Client that operate in both stream and console mode (useful if your Unix application requires it.)

Interix and Interix SDK
Interix is a POSIX-compliant subsystem; this means that some (yes, only some) applications already compiled for Unix / Linux systems will run unaltered on Windows. The Interix SDK helps with libraries for programmers to help convert existing Unix / Linux applications to run on Windows with Interix.

Exploring Active Directory as a NIS Server
Again, SFU 3.5 can extend an Active Directory Domain Controller to respond as if it were a UNIX NIS server. Why would you ever want to do this? There are a slew of reasons why you might consider this seemingly strange combination.

• Your Unix clients remain untouched (as they think they’re still talking to a UNIX NIS server). Though, they do need to rebind to the Active Directory / NIS server.

• Active Directory replication does the hard work of (securely) replicating user accounts around. The "NIS Master" role can be played by all Active Directory  servers as a result of the multimaster replication capabilities of Active Directory, eliminating a single-point-of-failure inherent to NIS.

• Active Directory replication is far more robust, and far more bandwidth-friendly, than traditional NIS map propagation.

• User provisioning for both Windows and Linux clients would now be through one unified tool: Active Directory Users and Computers. You could argue that this lowers costs and simplifies workflow.

In short, this is a low-risk solution to save some money, increasing robustness, have a unified tool (Active Directory Users and Computers) and have some quality-of-service improvements.

Beyond NIS Emulation

It might sound like a good idea to leverage this “Active Directory as a NIS server” as a stepping stone to get all your Unix accounts directly into Active Directory. An alternate, and likely better long-term solution is a migration from Unix/ Linux NIS to Active Directory.

One excellent reference is Microsoft’s document entitled “Solution Guide for Windows Security and Directory Services for UNIX” at http://go.microsoft.com/fwlink/?LinkID=23115.

Additionally, there are some commercial options which will help you leave NIS behind and go straight to Active Directory:

• Vintela’s VAS product (also discussed later) has a set of tools to help convert NIS tables directly to Active Directory. Check out http://www.vintela.com

• Centrify (at www.centrify.com) also has tools to help you convert NIS to Active Directory.

Final Thoughts

Microsoft’s Services for Unix 3.5 is an extensive tool to help you get started on your Windows / Linux integration path. However, there is so much more to Windows / Linux integration which is not specifically part of Services for Unix. For instance, printing integration, email integration, and core network services integration are all hugely important to help lower your overall costs of doing IT business.

For more information on all the avenues of Windows / Linux integration, including step-by-step proactive guidance, be sure to check out www.WinLinAnswers.com and the upcoming “Windows / Linux Integration Handbook” being published this September by SYBEX.

By Jeremy Moskowitz
Moskowitz-inc.com
WinLinAnswers.com

Portions of this excerpt were taken from Windows and Linux Integration Handbook (c) 2005, SYBEX, Inc.
Used by permission.
All rights reserved.

Comments

  • Anonymous
    January 01, 2003
    Jeremy Moskowitz, the author of "Windows / Linux Integration Handbook" due for publication around...
  • Anonymous
    September 08, 2006
    There is a Problem in upgrading a win2003 AD-server to a Win2003 AD-Server. I thougth, that we should integrate
    first a secound win2003-AD-Server(enterprise) an upgrade after that the old win2003-AD-Server Standard to enterprise, too.
    But nothing will function. He recognice allways the schema as unknown an will not work!
    What is the Error?
    Doesn't the Win2003 Server (enterprise) support the SFU3.5???
    what is wrong ???