Using pGINA to Authenticate Users in Microsoft Windows Environments
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article describes the use of pGINA, which simplifies the authentication of Microsoft Windows users in an environment that includes Window, Linux, and UNIX® systems. The objectives of this article are to provide you with a basic understanding of how authentication in a Windows environment works, and how pGINA can be used to provide an alternative authentication mechanism in a heterogeneous environment. This article provides recommendations for when pGINA should be used, and when it might not be a good idea to use.
This article is intended for technical people who are interested in directory services and the integration of Microsoft Windows into a heterogeneous environment.
The following sections define the problem, offer a solution to the problem, and provide a case study as an example of a successful deployment of the solution:
"The Problem" on page 2
"The Solution" on page 5
"VCSU – A Case Study" on page 10
The Problem
There are a number of problems to consider when setting up a unified authentication scheme in a UNIX-based computing environment that includes Microsoft Windows.
Windows simply doesn't play nice. When authentication is used in a Windows environment, Windows, by default, wants to use its own authentication mechanism and it doesn't provide the ability to easily use other authentication mechanisms. Because Windows makes it difficult to use other authentication mechanisms, users often don't make an effort to use a method that might be more secure and make overall administration easier.
Windows support is another problem. Support for 95/98/Me is ending. Support for Windows 95 ended in 2000 and paid extended support ended in 2001. Windows 98 support ended in 2002 with paid extended support ending in 2006, and Windows Me support ended in 2003 with paid extended support until 2006.
Microsoft has also announced that they will stop supporting Windows NT. Security and hot fix support for Windows NT is available through 2004. Any other support is available only with a custom support contract.
For a number of reasons, not the least of which is price and Microsoft's licensing policies, many institutions are now looking to utilize other operating systems in the data center. Many institutions are moving to UNIX/Linux.
All of these issues pose problems for system administrator's ability to have a single unified authentication mechanism.
Typical Authentication Architecture
Typically, data centers implement Windows using the default Windows authentication services. This means they implement either a standalone authentication architecture or they implement one based upon Active Directory. If they have a heterogeneous environment and have UNIX servers as well as Windows servers, they may end up with two entirely separate authentication mechanisms—one for UNIX and one for Windows (FIGURE 1). This presents problems for administration because two separate services must be maintained. Therefore, when a user needs to be added, the administrator must add the user in both directories.
At best, they will set up both an LDAP directory for UNIX and an Active Directory server for Windows, and then use some form of synchronization software between the two (for example, Sun Java™ System Identity Synchronization for Windows). This solves some of the problems, but there are still two authentication services as well as an additional component that must be maintained.
)
FIGURE 1
Typical Authentication Architecture
Ideal Authentication Architecture
The ideal authentication architecture is to maintain a single authentication directory and have both UNIX and Windows clients authenticate to it.
This is where Windows starts to fall down: the standard Windows Authentication mechanism doesn't allow for this.
Using the ideal authentication architecture (FIGURE 2), UNIX and Windows clients talk directly to the UNIX authentication service, bypassing the use of Active Directory. But how do you get there?
)
FIGURE 2 Ideal
Authentication Solution