| Previous | Table of Contents | Next |
Cryptography is also necessary for secure NIS in order for both the client and the server to establish their identities. Otherwise, a hacker may be able to impersonate either the client or the server and cause problems in the network. You’ll learn more about this type of network authentication in Chapter 4, “Traditional Network Security Approaches.” Descriptions of these procedures are not detailed here because one need not purchase any additional software to take advantage of these enhancements; they are part of most standard UNIX distributions. For more details on NIS, consult Stern, 1991. NIS+ is covered in depth in Ramsey, 1994. One final shortcoming of NIS is that it relies on a network protocol that is not usually permitted through firewalls—UDP. Still, in private networks, NIS can be depended on for simplified account administration as the size of the network grows.
The important points to remember from this discussion are as follow:
Microsoft NT is based upon the Mach operating system, which also has its foundations in UNIX. Like the UNIX operating system, NT has entities such as users and groups. Although the internals of NT are not as widely published as those of UNIX, several attacks have been made against the I&A mechanisms of NT. Many books describing NT security contain strong statements praising the integrity of the cryptographic techniques used to hide password values. However, several NT password crackers have been created (L0pht, 1997; Anonymous, 1997).
NT authentication is first addressed from the simple perspective of a user sitting down in front of a single system. When login is understood from this elementary view, a broader authentication approach is considered. The architecture of NT also supports authentication from a central server or domain controller. In other words, passwords and usernames are not necessarily stored on the NT workstation or server that a user is attempting to access.
NT stores user and group information in the NT Registry, which is a general-purpose repository for important system information. Sun put only a limited set of information in NIS databases, but the NT Registry includes nearly all important data for the system. The security access controls on information in the Registry have been widely debated on Internet news groups, and indeed several flaws and recommend improvements can be found in the NTsec mailing archives and on Microsoft’s Web site (www.microsoft.com/security). The physical file corresponding to the registry key for the user and group database is currently found in the %SystemRoot%\winnt\system32\config directory in the file named SAM (Security Account Manager).
Each user in NT is identified by a username and authenticated with a password. The password is hashed using MD4, and the resulting value is stored in the registry. Passwords can be up to 128 characters long. Some interesting subtleties exist regarding different types of groups when a domain controller is used. However, the specifics of NT group administration are not particularly relevant for this discussion.
As in the UNIX environment, the string name associated with a user is not the basis for making access control decisions. The NT equivalent of the user’s UID is the security identifier (SID). Each group also is assigned a SID. When the user or group is added to the system, NT generates a SID using the computer’s name (chosen at installation time), the current system time, and the cumulative time spent by the current thread being used to compute the SID. Technically, it is the thread’s user-mode time, rather than kernel-mode time, that is consulted. In principle, this combination ensures that the SID is unique within a given network.
S-1-5-21-975380050-2111395089-755307947-1000
An example SID is shown here. Don’t worry about all of the fields and their meanings. Think of a SID as a unique number used to identify an individual user or group.
The NT login procedure is controlled by several cooperating components. Winlogon is a process that displays the initial login window and acquires the username and password. The SAM is a set of routines responsible for managing the database of user accounts and for validating user information against its database. The Local Security Authority (LSA) performs the actual user authentication process. Other security tasks are performed by the LSA, such as auditing, but these tasks are not relevant to I&A.
After you enter your username and password, Winlogon passes this information to the LSA, which in turn invokes an authentication routine (called MVS1_0). The SAM database routines are consulted by these authentication threads to determine whether the user exists, and if so, whether the hashed password value matches. If authentication is successful, the LSA constructs your credentials by composing a data structure consisting of your SID and the SIDs of all groups to which you belong.
The LSA then creates a desktop process with these credentials, performs some further initialization such as executing your custom profile, and then returns to a waiting state in anticipation of the next login request. You will now have a graphical desktop from which to interact with the system. Any access requests made by you will be analyzed by the reference monitor based on the SIDs attached to the desktop process. Similarly, any new processes started from the desktop will inherit the credentials assigned to you at login completion.
To be more accurate, the LSA assigns an access token to you at login time. The access token contains the following fields:
The access token is consulted when you try to access objects because it contains your user SID and your group SIDs.
| Previous | Table of Contents | Next |