User Authentication and Authorization


User Authentication and Authorization

This section discusses security issues during UNIX to Windows migration, and potential solutions.

In any heterogeneous network ” such as a network migrating to Windows ” users need to work across systems, and the systems themselves need to interoperate . Therefore, a migration project needs to take into account the differences between the UNIX and Windows security models.

Migration planners need to resolve these security questions:

  • Do users require two sets of user names and passwords, one for UNIX and one for Windows?

  • How do users keep their passwords synchronized?

  • Do administrators need to manage two user databases?

  • How do administrators manage user security on shared resources, such as network file systems?

The greater the need for interoperability during the migration, the more important these questions become. This section presents information about Windows and UNIX security and how to integrate them. This information determines which of the security questions must be addressed in a particular migration project, and how to address them.

Chapter 2, Windows and UNIX Compared, describes and compares the UNIX and Windows security models. Security models for both operating systems require:

  • Authentication to verify the user s identity.

  • Authorization to control access to resources and to limit what a user can do.

This section describes how UNIX handles authentication and authorization, how Windows handles them, and how to integrate UNIX and Windows security.

Authentication and Authorization in UNIX

UNIX security relies on user credentials and file permissions. (For more information, see Chapter 2, Windows and UNIX Compared. )

In UNIX, user credentials consist of two unique identifiers for each user: a user identifier (UID) and a group identifier (GID). These identifiers apply to every UNIX process. UIDs and GIDs are integers assigned by the administrator. They are not guaranteed to be unique across a network.

Users are listed in the /etc/passwd file. This file contains a single line of text for each user. The line has fields for the user name , user ID, password, home directory, default shell, and so on. The password is encrypted; the administrator cannot read it.

Groups are listed in the /etc/group file, which lists the names of the users in each group as well as the groups themselves.

UNIX assigns permissions to every file, directory, and device. The permissions are for the user (owner of the file), for the group, or for everyone else.

When a process seeks access to a file, UNIX uses the UID and GID of the process to select which permissions to apply to that process.

To authenticate a user at logon, UNIX uses techniques such as username/password pair, Kerberos V4/V5, and proprietary schemes. After logon, every process a user creates has the same UID and GID, and thus has the access rights of the user referenced by the UID.

To secure stations , some UNIX installations also use a host.equiv or .rhosts file containing host information based on the host name and IP address. These files define the set of trusted hosts , users, and host-user pairs that certain UNIX processes use to verify access. For example, rlogin (remote logon) and rsh (remote shell) bypass the normal logon and password security mechanisms of /etc/passwd or Network Information Service (NIS). The /etc/hosts.equiv file contains trusted hosts and/or trusted host-user pairs.

The UNIX user database can be centralized for a network of UNIX computers using NIS. NIS maps the /etc/passwd and /etc/group files to a central database held on the NIS servers. All other aspects of UNIX security continue to work in the same manner, but use UIDs and GIDs from the NIS server rather than local files.

Authentication and Authorization in Windows

Windows security relies on user credentials and object permissions. (For more information, see Chapter 2, Windows and UNIX Compared. )

When a user logs on to a Windows-based computer or domain, Windows authenticates and then identifies the user by using a unique security identifier (SID).

Windows objects (including files and directories) have a security descriptor (SD) associated with them. The information in the security descriptor includes the owner of the object and a discretionary access control list (DACL). The DACL in Windows allows a much greater range of permissions than UNIX does, and those permissions can be assigned more selectively than those provided by UNIX.

Integrating UNIX and Windows Security

Figure 6.1 on the next page illustrates the differences between the UNIX and Windows security models. Although the differences in this example focus on NIS and Active Directory domains, the differences are identical for UNIX- and Windows-based computers that are not part of a security domain.

click to expand
Figure 6.1: UNIX and Windows security model differences

Table 6.1 summarizes the differences illustrated in Figure 6.1.

Table 6.1: Security Model Differences

Security Feature

 

UNIX

Windows

User names

     
 

Length

Typically 8 characters

20 characters

 

Case sensitive

Yes

No

 

Can be same as group names?

Yes

No

User identifier

 

UID 0-65353

SID unique

POSIX groups

 

Yes

Yes, but not default

File permissions

 

Simple bit mode
rwxrwxrwx

Complex Access

Network user database

 

NIS

Active Directory

These differences raise a number of interoperability issues:

  • Mapping UNIX-style user names to Windows-style user names.

  • Mapping UIDs to SIDs and SIDs to UIDs to control access to resources such as files.

  • Converting incompatible file and resource permissions.

  • Centralizing the management of UNIX and Windows users.

The following sections describe some tools for integrating UNIX and Windows security.

User Account Management and Synchronization

There are three approaches to managing users across UNIX and Windows:

  • Create separate and unrelated accounts for UNIX and Windows.

    This solution is simple, but it requires the most effort for users of both platforms. It complicates cross-system authentication and security permissions. This solution is appropriate when the need for interoperability between UNIX and Windows is limited and brief.

  • Create duplicate, identical accounts on UNIX and Windows.

    Duplication of accounts simplifies interoperability because UNIX and Windows accounts can relate to each other. It also simplifies the conversion of permissions. However, it doubles administration and can result in users having two sets of passwords.

  • Integrate UNIX and Windows account management.

    This long-term solution accommodates a long- term migration project or a target environment that includes both UNIX- and Windows-based servers. In this case, administrators should centralize user management into one place, such as Windows Active Directory. Management from Windows Active Directory is consistent with a migration to the Windows platform. Also, Windows Active Directory is a well-integrated product with built-in management functionality.

Many third-party and Microsoft interoperability products provide UNIX-to-Windows user mapping. For example, Samba provides its own methods of mapping user names. (For more information about Samba, see Samba and Resource and Data Sharing later in this chapter.) Most products provide different methods of mapping user names, which creates a need for additional administration.

Windows Services for UNIX Server for NIS

Windows Services for UNIX includes a Network Information System (NIS) server called Server for NIS. This service uses Windows 2000 Active Directory to implement NIS.

Administrators can use Server for NIS to:

  • Store NIS maps by using Active Directory.

  • Integrate NIS data (such as user data) with corresponding Active Directory objects.

  • Use Windows 2000 “ based servers as NIS servers.

  • Migrate NIS domains to Active Directory.

  • Merge multiple NIS domains.

  • Synchronize passwords. (See Windows Services for UNIX Password Synchronization later in this chapter.)

Figure 6.2 shows the architecture of Server for NIS. Notice that although UNIX slave NIS servers are still usable, the master NIS server now resides on Windows.

click to expand
Figure 6.2: Architecture of server for NIS

Server for NIS is especially useful for large networks that already have NIS and Active Directory. However, administrators need to be aware of how Server for NIS interoperation works:

  • Server for NIS must be installed on a Windows 2000 domain controller. The Windows-based server uses Active Directory to store the NIS information. Normal Active Directory replication is used to propagate the NIS data.

  • The computer running Server for NIS must be the master NIS server. This means that all the other Windows-based and UNIX NIS servers are subordinates .

  • The Active Directory tools on the master computer administer both the NIS and the Active Directory domains.

  • An NIS to Active Directory Migration Wizard assists in moving the existing NIS domain to Active Directory.

For more information about Server for NIS, see the Microsoft white paper, Server for NIS Overview, at http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/deploy/sfu/servnis.asp.

Windows Services for UNIX Password Synchronization

Windows Services for UNIX includes two-way password synchronization between UNIX and Windows.

To synchronize from UNIX to Windows, a single sign on daemon (SSOD) must be running. Windows Services for UNIX supplies precompiled SSODs for popular UNIX versions. For UNIX versions without a precompiled SSOD, Windows Services for UNIX supplies the source to create one.

Password synchronization occurs only between systems that are configured to do so by an administrator. A file on the UNIX side contains a list of computers to notify of password changes. Windows-based tools on the Windows side maintain the list. In addition, administrators can specify which users have password that must be synchronized.

To synchronize passwords for Windows 2000 domain accounts, all domain controllers on the network must be running the synchronization service, and all participating UNIX computers must be running the SSOD. When synchronizing passwords for local user accounts, the service must be installed on all Windows  2000 “ based computers.

Because password synchronization does not use user name mapping, the user names must be exactly the same for both UNIX and Windows. Therefore, user names must conform to the most restrictive definition of length and structure. For example, because Windows user names are not case-sensitive when used on UNIX, all Windows user names must be lowercase.

Samba

Samba is an open -source freeware implementation of the common Internet file system (CIFS). (For more information about Samba, see Resource and Data Sharing later in this chapter.)

Samba is designed to integrate with Windows-based networks. Therefore, it must convert between UNIX and Windows user identities and between UNIX and Windows file permissions. To do so, Samba maps UNIX to Windows and Windows to UNIX users and it converts between UNIX and Windows file security schemes.

In Samba, user names can be different on UNIX and Windows. Thus, Samba provides the flexibility to use UNIX-style user names on UNIX and Windows user names on Windows. This feature comes at the cost of additional administration.




UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net