Authentication Security | Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit

The best security system is only as safe as its authentication scheme. Although many secure applications exist, users can jeopardize efforts to secure applications by using generic passwords such as 1234, not using any passwords at all, or writing passwords and leaving them in places where they can easily be discovered. Remedies such as password dictionary check or minimum password lengths are available to safeguard potentially unsecured applications; however, not all application security problems can be solved programmatically. Assuming that steps will be taken to exclude reckless password behavior on the part of users, in this section we take a look at the security process of authentication, which involves identifying and validating users, and potentially revalidating users as an ongoing process.

Windows NT Authentication

Windows NT users are authenticated by the MSV1_0 Authentication Package that corresponds to MSV1_0.DLL in Windows NT's <systemroot>\SYSTEM32 directory. Conceptually, MSV1_0 is split into two halves. The top half is responsible for receiving the logon request and determining whether the request is to the local or remote Windows NT computer. If the request is local, MSV1_0 passes the logon information to the bottom half of MSV1_0. The bottom half of MSV1_0 in turn authenticates the user by referencing the local security database. However, if the logon request is to a remote Windows NT computer, the top half of MSV1_0 passes the logon information to the local computer's Netlogon service. The Netlogon service in turn passes the logon information to the remote Windows NT computer's bottom half of MSV1_0. When the Netlogon services of two computers communicate, challenge/response occurs. Challenge/response doesn't occur with local logons. The request is answered and returned to the top half of the local Windows NT computer's MSV1_0 through the respective Netlogon services.

NOTE
We focus mainly on network authentication as it relates to Windows NT LAN Manager (NTLM) security over the network via challenge/response. However, MSV1_0 also supports interactive logons, service logons, and network logons. All forms of logon through the MSV1_0 Authentication Package pass the name of the domain containing the user account, the name of the user account, and some function of the user password. These various types of logon differ in the way the password is represented. For interactive logons and service logons, the client logging on is physically on the computer running the top half of the MSV1_0 Authentication Package. In this case, the clear (unencrypted) text password is sent into the top half of the MSV1_0 Authentication Package. The top half of the MSV Authentication Package converts the clear text password to both a LAN Manager password and a Windows NT password before sending it on to either the Netlogon service or the lower half. The lower half queries the passwords from the Security Account Manager (SAM) and compares the passwords to ensure they are identical.

The following steps are an example of how a user might log on locally or remotely to a Windows NT system:

Press CTRL+ALT+DEL to display the Windows NT Security logon dialog box. Pressing this key combination before logging on protects against Trojan Horse-type programs that impersonate the operating system and manipulate users into disclosing their username and password.

Provide a username and password to enable the logon process to call the Local Security Authority (LSA).

The Local Security Authority runs the MSV1_0 Authentication Package.

The authentication package checks the user accounts database to see whether the account is local. If it is, the username and password are verified against those held in the user accounts database. If it is not, the requested logon is forwarded to the Windows NT Netlogon service. The Netlogon service on the local computer communicates with the Netlogon service of the remote Windows NT system (in this example, a domain controller). Here, the upper half of MSV1_0 on the local computer communicates with the lower half of MSV1_0 on the remote computer, initiating a challenge/response.

When the account is validated either locally or remotely, the SAM (which owns the user accounts database) returns the user's security ID (SID) and the security IDs of any global groups to which the user belongs.

The authentication package creates a logon session and then passes the logon session and the security IDs associated with the user to the Local Security Authority.

If the logon is rejected, the logon session is deleted, and an error is returned to the logon process.

If the logon is accepted, an access token is created, containing the user's security ID and the security IDs of the Everyone group and any other groups to which the user belongs. It also contains user rights assigned to the collective security IDs. This access token is returned to the logon process with a Success status.

The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thus creating a subject for the user account.

For an interactive Windows NT session, the Win32 subsystem starts a shell process (that is, starts the desktop) for the user.

After the validation process, the user's shell process is given an access token. For Windows NT 4.0, the token is associated with Explorer.exe. The information in this access token is a reflection of anything the user does or by any process that runs on the user's behalf.

Kerberos Authentication

Kerberos authentication was developed within the think tanks of MIT. It is a ticket-, session-, and trust-based authentication scheme. The Kerberos Authentication included in Windows 2000 is based on Kerberos v5. When compared with the Windows NT domain strategy, the Kerberos authentication protocol provides the following benefits:

Faster server authentication performance during initial connection establishment The application server doesn't have to connect to the domain controller to authenticate the client, so applications servers can scale better when handling a large number of client requests.

Delegation of authentication for multi-tier client/server applications and architectures When a client connects to a server, the server impersonates the client on that system. But if the server needs to make a network connection to another network server to complete the client transaction, the Kerberos protocol allows delegation of authentication for the first server to connect on behalf of the client to another server. The delegation also allows the second server to impersonate the client.

NOTE
Applications that use process access permissions can take advantage of additional security providers on Microsoft Windows 2000 and can use delegate-level impersonation and cloaking to affect the security credentials used during method calls. Delegate-level impersonation is established by the client process and allows a server to impersonate the client and to pass the client's credentials to remote computers. Previously, servers could impersonate the client only to access local resources. Cloaking is used to hide an intermediate server's identity from a destination server. For example, if Client A calls Server B, which then calls Server C on Client A's behalf, and Server B has cloaking enabled, Client A's identity will be used for calls to Server C.

Transitive trust relationships for inter-domain authentication Users can authenticate to domains anywhere in the domain tree because each domain's authentication services trust the tickets issued by other authentication services in the tree. Transitive trust simplifies domain management for large networks with multiple domains.

Authentication between heterogeneous systems (even Internet-based systems) Users can validate once and access many different systems on different operating system platforms. For example, Windows 2000 security can be utilized between Windows 2000 and UNIX or mainframe environments, provided the correct Microsoft COM libraries are being utilized on the UNIX or mainframe systems. Users don't have to be running Windows 2000 to be authenticated by a Windows 2000/Kerberos domain.

NOTE
The transition from the NTLM authentication used in Windows NT 4.0 to Kerberos domain authentication can be very smooth. Windows 2000 services support client or server connection using either security protocol. The transition from enterprise-based services using Kerberos authentication to Internet-based services using public-key authentication (discussed later in this chapter) is mostly transparent to the user.

Web-Based Authentication

Almost every Web browser on the market supports a basic form of authentication that involves sending a username and password in clear text over the Internet or an intranet. Unfortunately, this basic authentication allows this information to be stolen by others. Because organizations need to provide secure access to information on their networks and servers, user authentication is an important aspect of a Web server. In addition to the security provided by Windows NT, Microsoft Internet Information Server (IIS) 4.0 includes additional security features that Windows NT uses to correctly identify users, determine their level of access, and create a secure Internet connection.

In this section, we first describe the IIS 4.0 authentication technology. Then we discuss Microsoft's Secure Channel technology, which is used to protect networked data from prying eyes when communicating in Internet or intranet environments after users have been authenticated.

Windows NT Challenge/Response Support

IIS 4.0 provides support for the Windows NT challenge/response authentication, which uses a cryptographic technique to authenticate the password. The actual password is never sent across the network, so it cannot be captured by an unauthenticated source. Challenge/response is supported by Microsoft Internet Explorer 2.0 and later versions.

When Windows NT challenge/response authentication is enabled, the user's Internet Explorer browser proves its knowledge of the password through a cryptographic exchange with the Web server. If the authentication exchange succeeds in identifying the user, the user is not prompted for account information. However, if the authentication exchange initially fails to identify the user, Internet Explorer prompts the user for a Windows NT account username and password, which it processes using the same Windows NT challenge/response method. Internet Explorer continues to prompt the user until the user enters a valid username and password or closes the prompt dialog box.

NOTE
Windows NT challenge/response authentication takes precedence over basic authentication. If the user's Web browser supports both authentication methods, it chooses Windows NT challenge/response authentication.

Cookies

Web applications can use simple cookie mechanisms to track and identify users. Cookies are small files sent from the server to the user's computer, where they are stored locally. These identification cookies typically contain a globally unique identifier (GUID) that can be requested and queried by a Web server. Although cookies provide a simple means of identifying users, they should not be used when the information being accessed is considered confidential or private. A cookie can be intercepted in transit, or even copied from a user's computer, and anyone can then use it to represent himself or herself as the cookie's user. Although the concept of stealing cookies is similar to that of stealing logon usernames and passwords, cookies are technically much easier to "borrow."

Digital Certificates

Digital certificates give users a secure method of logging onto a Web site without having to remember logon usernames and passwords. IIS supports the use of X.509 certificates for access control. Certificates verify identity in much the same way as driver's licenses or corporate identification cards do. They are issued by a trusted certificate authority, either a department within an organization or a public company such as VeriSign or Entrust. How rigorously IIS checks identities or credentials when issuing a certificate depends upon the level of security—or trust—required for the information or application being accessed.

Certificate-based client authentication requires a protocol that can handle certificates at both the client end and the server end, as well as the appropriate requests and replies.

Server Certificates

Unique digital identifications, called server certificates, form the basis of a Web server's Secure Sockets Layer (SSL) security features. Server certificates, obtained from a trusted, third-party organization, provide a way for users to authenticate the identity of a Web site. The server certificate contains detailed identification information, such as the name of the organization affiliated with the server content, the name of the organization that issued the certificate, and a unique identification file called a public key. This information helps to assure users about the authenticity of Web server content and the integrity of the secured HTTP connection. The public key, along with another privately held key, form the SSL key pair. A Web server utilizes the key pair to negotiate a secure TCP/IP connection with the user's Web browser. (Although the key pair serves a vital role in establishing a secure link, the key pair is not directly used for data encryption.)

Client Certificates

With SSL, a Web server can also authenticate users by checking the contents of their client certificates. These encrypted files are similar to conventional forms of identification such as driver's licenses or passports. A typical client certificate contains detailed identification information about a user and the organization that issued the certificate. Each user enters a password when signing his or her certificate, and this password is required every time the certificate is activated for use. As with a driver's license, mere possession of a certificate does not constitute proof of ownership. Only the owner of the certificate should know the password because it is the key to verifying access.

Certificate Mapping

This method maps the client certificate to the Windows NT server user account and requires a copy of the certificate. The Web server has a client certificate-mapping feature that authenticates users who log on with client certificates, without requiring the use of basic or Windows NT challenge/response authentication. A certificate mapping relates the contents of the user's client certificate to a corresponding Windows NT account, which is a file that defines the rights and access policies of the user. After a mapping is created and enabled for a particular user, each time that user logs on with his or her client certificate, the Web server automatically connects, or maps, that user to the appropriate Windows NT account.

This approach is ideal when the Web site issues its own certificates using a certificate server, such as Microsoft Certificate Server, which is included in the Windows NT 4.0 Option Pack.

Wildcard Mapping

When using wildcard mapping, the IIS server doesn't need to possess the client certificate, but instead authenticates the user based on information stored in the certificate, such as "SubjectName." IIS 4.0 also includes a Microsoft ActiveX component that automates the wildcard mapping using an Active Server Page (ASP). For example, a business could set up an ASP page that asks users whether they want to map their certificate to their Windows NT Server user account. If a user chooses to do so, the information in the certificate is mapped to the appropriate Windows NT Server user account.

IIS 4.0 can authenticate users who log on with a client certificate by creating mappings that relate the information contained in the certificate to a Windows NT user account. Using the Web server's certificate mapping feature, IIS 4.0 can either map a specific user's client certificate to an account (a one-to-one mapping), or map multiple certificates to an account. To map multiple certificates, wildcard-matching rules must be defined that create a mapping by verifying only whether a certificate contains certain items of information. For example, to map all users who log on with client certificates issued by a particular organization, a wildcard-matching rule could be defined that automatically maps any certificate issued by that organization to a single user account, rather than creating a separate mapping for each client certificate.

Programmatic Use of Certificates

Client authentication in IIS 4.0 goes beyond pure authentication and access control. Information in the certificate is exposed to both ASP and Internet Information Server Application Programming Interface (ISAPI) applications. As a result, developers try to create custom ASP and ISAPI applications that can serve personalized content, control access, or query databases based on the information fields in the client certificate. Developers can use client certificate authentication, along with SSL encryption, to implement a very tamper-resistant method for verifying user identity.

Microsoft Certificate Server

Internet Information Server 4.0 Option Pack contains certificate management features available through Microsoft Certificate Server, and standard cryptographic API functions available through Microsoft's CryptoAPI, which we discuss later in this chapter. Certificate Server has the following features:

Accepts standard PKCS #10 certificate requests.

Issues X-509 version 1 and version 3 certificates in PKCS#7 format.

Issues SSL client and server certificates.

Issues Secure Multipurpose Internet Mail Extensions (S/MIME) certificates.

Issues Secure Electronic Transactions (SET)-compliant certificates.

Supports open interfaces that enable writing of modules to support custom formats.

SQL Server Authentication

In this section, we discuss the various types of security available with Microsoft SQL Server, including standard security, integrated security, and mixed security.

Standard Security

Standard security uses SQL Server's own logon validation process for all connections. Connections validated by SQL Server are referred to as non-trusted connections. Standard security is useful in network environments with a variety of clients, some of which may not support trusted connections, which we discuss below. Also, standard security provides backward compatibility for older versions of SQL Server.

Integrated Security

Integrated security allows SQL Server to use Windows NT authentication mechanisms to validate SQL Server logons for all connections. Connections validated by Windows NT Server and accepted by SQL Server are referred to as trusted connections. Only trusted connections are allowed. Integrated security should be used in network environments where all clients support trusted connections. The clients of SQL Server in a three-tier application are MTS components.

NOTE
With Windows NT 4.0, MTS components must be authenticated by a domain controller. Authentication of a component by a domain controller over the network adds extra traffic and therefore extra expense. With Windows 2000, Kerberos helps hold down traffic by carrying information that allows direct component authentication without taking a trip to the domain controller.

When the SQL Server logon security mode is set to integrated, an MTS component's login is validated as follows:

To access SQL Server, a component first obtains a valid Windows NT user account. MTS components use the Windows NT user account specified in the component's MTS package's Identity property. When the user account is in a domain, the username and password are validated by the domain controller's security accounts database when the MTS package executable launches via LAN Manager security. However, if the user account is located in a workgroup, the username and password are validated by the local security accounts database.

The component connects to SQL Server, and SQL Server looks in the syslogins table for a mapping to a SQL Server logon ID. This mapping is created as part of the configuration process based on whether a logon exists, a logon does not exist, or neither a logon nor a default logon exists. If the logon exists, the component is logged onto SQL Server with the privileges associated with that logon ID. If the logon does not exist, the component is logged onto SQL Server using the default SQL Server logon ID, which is usually a guest account. However, if the component's account has administrator privileges on Windows NT, the user will also have administrator privileges within SQL. Finally, if the logon does not exist and there is no default logon ID, the component is denied access to SQL Server.

Once the logon process is complete, access to individual SQL Server tables is managed through permissions granted within an SQL Server database.

Mixed Security

When mixed security is used, SQL Server validates logon requests using either integrated or standard security methods. Both trusted connections (as used by integrated security) and non-trusted connections (as used by standard security) are supported. Mixed security is useful in network environments that have a mixed client base. For those clients that support trusted connections, Windows NT validates logons. For clients that support only non-trusted connections, SQL Server validates logons.

When a server's login security mode is set to mixed, a component's logon is validated as follows:

When a component attempts to log onto the server over a trusted connection, SQL Server examines the logon name. If this logon name matches the component's network username, or if the logon name is blank or contains spaces, SQL Server uses the Windows NT integrated logon rules (as for integrated security).

If the requested logon name is any other value, the component must supply the correct SQL Server password, and SQL Server uses its own logon validation process (as for standard security). If the logon attempt is not over a trusted connection, the component must supply the correct logon ID and password to establish the connection, and SQL Server uses its own logon validation process (standard security).

NOTE
Integrated or mixed security is recommended for enterprise solutions using Windows NT Server, MTS, and SQL Server. Integrated security makes management of logons easier because accounts can be administrated from one source in Windows NT. Also, developers can avoid coding logon IDs and passwords into their components or placing them in ODBC DSNs. Any logon changes under standard security forces components to be recompiled or ODBC DSNs to be tracked down and updated.

Using SQL Authentication with Objects

As we've said, SQL Server requires a logon ID and password. We'll now demonstrate how a component can implement such a security measure.

A component supplies its logon either through the ConnectionString property of the ADO Connection object, or as a Connection String parameter to the Open method of the Connection or Recordset objects. If a component supplies a logon ID and password, the component connects using standard security. If the component does not supply a logon ID and password, the component connects using integrated security, and within MTS, the component's package identity is used as the logon.

If the connection is through an OLE DB provider, the provider must be notified that integrated security is to be used. The logon ID or password should not be provided, but instead the Trusted_Connection attribute should be set as shown in the following code:

 Dim conn as ADODB.Connection  Set conn = New ADODB.Connection  conn.Provider = "SQLOLEDB"  conn.ConnectionSTring= "Data Source=MYSERVER;' & _   "Initial Catalog=Pubs;Trusted_Connection=Yes"  conn.Open