Microsoft Company October 10, 1997
Introduction
Delegation!
ACLS, NTLM, and other definitions
Basic Authentication
Impersonation
Ordinary verification scene
Control verification method, and why care
Do you need a "safety dialog" problem
Safety based on ASP code
Hacker with your site
Windows NT Challenge / Response (Challenge / Response)
Conclude
Introduction
If you are a developer using Microsoft® Internet Information Server (IIS, Internet Information Server) 3.0, understanding how IIS uses authentication and impersonation technology to control your Web server security. When I support the team in Microsoft Internet developers, I found that one quarter of the question we handled was related to the topic of Permissions. Further, if the developer has more understanding of the authentication of the authentication, most of these issues can be avoided. Verification is just a simple process of determining user identity. WINDOWS NT® can control the resources that the user can access will then control the resources that the user can access. Verification and security are prone to confusion when not with special technical color. Accurate understanding of how IIS controls security will help you create a more energetic site and avoid common, time-time issues.
This article explains Windows NT security about IIS, so you can effectively solve problems related to security. Our content includes three verification forms, their differences, several access control methods for your web server key areas, as well as important but universal misunderstandings "concept. For any Web site that uses IIS to establish a data delegate driven, you must understand the authorization. Understanding how Windows NT handles different users will save you the time that is expensive and even a week.
ACLS, NTLM, and other definitions
Before starting, we first define some common terms:
Access Control Tables (Acls, Access Control Lists) Each ACL is an access control entry list, and the access control portal specifies the access and audit information used by Windows NT on the NTFS (New Technology File System) hard disk. Windows NT determines that users who have been granted access to specific resources (files and folders) permissions by accessing ACLs, and permissions that users can get, including read, write, and execution. Right-click on file or folder resources, select Properties, and click the PERMISSIONS button for the Securities page to view the ACLs of the resource. Windows NT Dioss / Response (Challenge / Response) This is a Windows NT verification process. An inter-request / response occurs when accessing any resource stored in another Windows NT computer (such as a shared resource on one server) is accessed over the network. The convention / response can also be verified by IIS to verify when the user browsing the web site. NTLM This is the Windows NT used in the convention / response verification mechanism. NTLM represents Windows NT Lan Manager because it develops and uses Microsoft Lan Manager, Microsoft's earliest network products. SAM SAM (Security Account Manager) is a database that stores user and group account information. The password is not included in the SAM, but it stores the password hash table (described later). SAM is stored in the HKEY_LOCAL_MACHINE / SAM and HKEY_LOCAL_MACHINE / SAM and HKEY_LOCAL_MACHINE / SAM of the registry. Don't be surprised that SAM is often the main goal of hackers. Impersonation
In different cases, IIS will disappear as different users. The processing of all operations on the Windows NT computer is running on a valid Windows NT account. When a program or handle (similar to IIS) represents a user run, it can be said to be in the security context of the user (Security Context). The use of security context is to enable access to files and resources to file and resources that cannot exceed the access rights obtained when the user runs a process locally. When IIS represents a user, it is said that it plays the user.
IIS design processes the web request as an automated service. To achieve this, IIS needs to run in a valid user security context. IIS needs to respond to two requests: anonymous request and authentication request. In an anonymous request, IIS does not know anything about the user. In the verification request, IIS can accurately understand users requested resources. Because the anonymous requests and verification requests do not have a dialog or other identifier for the user, the use of how to use is not always discovered. However, what kind of way of developers should always know how to use it, this is necessary. IIS playing account, as well as a greater range, to IIS processing power, mainly depends on the type of request used.
Anonymous request
This type does not require any information from the user. By default, when the browser issues a web request to a page, IIS first tries to not perform user authentication processing requests. To do this, IIS will play a specific Windows NT account-IUSR_MACHINENAME (IUSR_MACHINENAME's MachineName is an IIS host computer name). This account is created when installing IIS. If the IIS plays the requested resource when you play an IUSR_MACHINENAME account, the web page will be able to access anonymous user. The password of the IUSR_MACHINENAME account and the password entered in the Internet Service Manager (Internet Service Manager) are a common problem that occurs when anonymous access. When IIS tries to play an IUSR_MACHINENAME account, it will submit a password entered by anonymous login text box for a Windows NT server. If the password is incorrect, IIS will not be able to use the IUSR_MACHINENAME account. Once anonymous access fails, IIS will verify all users. Because the verification process has not prompted, the verification of the site may fail, but the reason is often not obvious. I have already told many Web site administrators who have encountered strange security issues because their site verifies each user, but they don't know this. If your page accesses other resources such as databases or client components (such as DLLs), the type of authentication will be very different.
Verify request
It is necessary to confirm confirmation to user identity. When IIS cannot use the IUSR_MACHINENAME account, IIS will attempt and then act as a user to determine if the user can access the requested resources. IIS can use two methods to perform user authentication: in-case / response verification and basic verification. These methods are discussed later in this article. Validated web access is usually best suited for a company's intranet or its internal contained workgroup. However, even if this is still considered some restrictions.
Control verification method, and why care
The IIS Service Manager tool is the main place for configuring IIS for WWW, FTP, and Gopher services. Do not need to know too much detail on the options for the WWW Properties dialog, we only need to care for several critical items. By default, anonymity and interpretation / response verification is selected in the password verification option group. The third method is basic verification and will be explained later. Let's take a few ways to access your web server.
"Allow Anonymous" option box If you select Allow Anonymous, IIS will try access to the requested resources by playing an anonymous login account (default to iUSR_MACHINENAME). When the IUSR_MACHINENAME account is automatically created, it is assigned a random password and is added to the guests group and give guest permissions. Select or deselect Allow anonymous is the best way to allow and disable anonymous access to the entire web server. When deselects Allow anonymous, only users with valid, verifiable (using basic verification or challenge / response verification) Windows NT accounts can be served. Using this way IIS is usually only available for groups or membership settings, which is important to verify that all users accessing your site is important. Changing the Permissions of the File and Folders NTFS Level Permissions are supported in IIS, so separate permission settings for files and folders can be accessed on a smaller particle size. A common way to control access is as follows: You can be placed in a folder by the page viewed by everyone, and restrictions can only be placed to another folder by the page of the site administrator. Right-click the folder that restrictions, then select Properties / Securities / Permissions. Because our goal is to ensure that IIS cannot use the IUSR_MACHINENAME account anonymous access to restricted folders, you should delete the Everyone group and the IUSR_MACHINENAME account from the access list. Place the file in two different folders to ensure that the permission mode of maintaining two groups is used, which is more prone to maintenance than one file. Safety based on ASP code
With ASP code, you can achieve more special security features (this is more interesting than the features just described). For example, some annoying users will mess up your site. Since their IP address can be obtained by the server activity log, you can use the following code to prohibit this address access:
<% If request.servervariables ("remote_addr") = "200.200.157.4" THEN
Response.buffer = TRUE
Response.status = ("401 unauthorized")
Response.end
END IF%>
There are many variables within the Active Server Page to provide information about sending requests, as well as information about IIS itself. (To get a detailed list of server variables, see the Active Server Pages online help.) For example, the logon_user command returns a space for anonymous users for verifying the user returns to Domain / UserName. Then you can check the specific users using the server-side code and or direct them to other pages. I have seen some companies use this technology to refuse competitors outside their Web site.
Windows NT Challenge / Response (Challenge / Response)
The Windows NT challenge / response is the safest way to determine the person who sends a request. The challenge / response process is all those who use IIS must be mastered. (We are actually carried around the DELGATION process, but there is an entrusted manner after challenge / respond.)
Now explains a completely different technique: "Hash (HASH)"
The Windows NT challenge / response verification process does not send passwords over the network because the password may be intercepted and deciphered. Windows NT uses an irreversible algorithm similar to a meat grinder. After entering the content, you get a hash content. Windows NT generates a 16-byte (128-bit) hash value using the Internet standard MD4 hash algorithm. (In theory) It is impossible to use a hash value and algorithm to retrieve the encryption process in mathematics. That is, the password is used as a "private key". Only those who have the key can produce a specific hash value. The Windows NT domain controller has a database stored by the user's hash value generated by the user password, but does not store the user password. (Note that the password and the separation of the has no way to reduce the possibility of hacker attacks, as sometimes the aquary value can also be used as the equivalent of the password.) IIS and challenge / response verification process
If the following conditions are met, IIS will use challenge / response verification:
If the "Allow Anonymous" option of the Internet Service Manager's WWW Properties dialog is not selected, the IUSR account does not have enough license to access the requested resource, or execute code prohibiting access. Select Windows NT Challenge / Response Browser in the Internet Service Manager Send Request in Challenge / Response Validation Method (Internet Explorer support challenge / response verification) in the current browser
When we say that IIS tries to verify the user, IIS is very simple. It sends a "HTTP 401 Access Denied" message to the browser, and the list of validation methods it accepts. It's very similar to the bodyguards of a senior club. III will say: "You can't get what you want without identifying yourself. By The Way, I accept the folloading methods of identification. (Nothing to confirm your identity, you can't get What you need. In addition, I support the following verification methods). The two authentication methods accepted by IIS are challenge / responding verification and basic verification. Which way to use depends on the selection in the IIS's Internet Service Manager WWW Properties dialog box. If both authentication methods are enabled, the Internet Explorer will definitely use challenge / response verification, and basic verification is used for other browsers.
Figure 1 shows how to perform Windows challenge / response verification without seeing the user password without seeing the user password.
Figure 1. Windows NT Challenge / Response Verification Process
Reasons for using random hash challenge information
Increase the additional step of encrypting the challenge information using the password hash value, rather than transmitting a simple hash value to the domain, allowing the column value to be used as a password as a password. Because the challenge requires a user password hash value to generate a new hash value, it confirms that the user has at least the user hash value (and may have a user password). All of these do not have to transfer passwords through the wires. In essence, the password becomes a private key and the random value has become a changing public key.
Delegation!
Entrusted is most of the information missing from Windows NT security and IIS authentication, even if it is critical to the security Web server environment to consider, or the person who is easy to hope that the Web server can run. When the IIS web server plays a user who uses challenge / response authentication, the IIS server does not have a user's password or password aquary value. IIS only saw the encryption of the domain controller. This is likely to encounter this when using an ASP page to access another Windows NT computer (such as a remote database server). The remote server sends challenge information to IIS to verify the user you play, and IIS cannot be verified because the user hash value is not encrypted with the challenge information sent to it, so it cannot be verified. Thus remote servers are disabled, and your database-driven web page will fail. This is a limit for the Windows NT 4.0 (and previous version) security model, not IIS. With Windows NT challenge / respond to verification, a process that rely on the play will not be able to access too many of the Windows NT computers like a text file. If you want to determine when you need to consider the delegation, if you have a user password or have a hash value, please ask yourself. In the policy, you should "Follow the Money". On the commission, you should "Follow the Password"!
This can have a class ratio, the administrative supervisor entrusts a secretary to sign its signature and exercises its duties in other ways. When the user uses challenge / response verification, users cannot entrust IIS to work according to their interests. This special limit may be perfectly resolved after Windows NT 5.0, because the Windows NT integrates the Kerberos authentication system (this system is developed by the ATHENA project for MIT).
Basic Authentication
Most people are afraid to use basic verification, which is caused by the interface facing the user after the basic verification:
After selecting this verification method, the password is transmitted in network without data encryption. Some people who want to endanger your system can intercept user passwords during the verification process using an agreement. Please refer to the online help for details of user verification.
Do you really have to continue?
This news is indeed as bad as it looks like. User Nominal Code uses 64-bit (BASE-64) encoding. Even for a hacker's novice, although they still have to access your network and use a TCP / IP packet detector (TCP / IP Packet-Sniffer intercepting the network protocol package, 64-bit encryption is easy to crack. As a result, hackers may attract your site unless you are a very attractive goal (such as bank).
Most of the web administs I have touched by challenge / respond to verification and basic verification differences, but they are also interchangeable. Basic verification always requires the user to enter the username and password to the user display dialog. The input information is then sent to IIS, IIS uses the username and password to perform a local login command (Log On Locally) command to log in locally on the computer. Because IIS has got the user's password, it can respond to the challenge information of the remote system, so that the issue of the commission. (A user actually located in a web server uses basic validation, and users who use challenge / responding can access the web server over the network). In fact, user permissions "Access this computer from the network" and "Log On Locally" are required, and are also related to the verification methods used. To set these permissions, use the Domain Manager For Domains tool, then select User Rights in the Policy menu. Although there are some defects, there are two kinds of environments or basic verification:
You need to verify users using a non-Internet Explorer browser. For example, Netscape Navigator only understands basic verification. If you have selected challenge / response verification and basic verification, you will definitely use Windows NT challenge / response verification for Internet Explorer, and for Navigator, you will choose Basic verification. If your data is sensitive data, this is a serious problem involving security. Your site verifies the user while your ASP page accesses other Windows NT computers resources. The classic way is to access the database located in the remote Windows NT computer by using the ACTIVEX data object (ActiveX Data Objects) ASP page. To avoid the impact of the commission, ensure that all requested resources are on the computer where IIS itself is located, and if this is unreal, it is basically verified.
Ordinary verification scene
Whenever you use a Windows NT challenge / response to verify an Internet user, you should consider this factor when IIS uses UNIC (Universal Naming Convention, Unified Naming Convention) Path Access to the network or local Windows NT resources. Of course, all local resources can be accessed when the user has the correct NTFS level permission.
UNC path
When the database of code access to an ASP page is used by a file-based data source (such as the Access's .mdb file), and the location is confirmed by a UNC path, there will be a common error. Even if the resource is located locally, using UNC indicates that Windows NT will consider it in other places located in the network. The UNC path is processed by the Windows NT network subsystem. Windows NT has a lot of separation with its components, so that if you gradually enter the network subsystem, you will be outside the network until the Windows components involved. This leads to a confusing, but quite interesting scenarios: IIS computers using challenge / responding verification are accessing local resources using UNC paths. In the effect, it is verified from itself, it is unable to complete the request. To solve this problem, you should use the absolute path on the IIS computer (for example, C: /folder/Resource.ext).
Entrusted, no!
There is also a failure to fail with the commission failure, but actual and commissioned unreasonable is more difficult to determine the failure of security. It happens in a three-level computer level (browser to Windows NT / IIS server to Windows NT remote resources). To determine if the error is delegated, check if the transaction is verified. If so, the problem is almost determined to be delegated. However, if the page is accessed anonymous, the problem may be caused by an anonymous account of the IIS computer. This is easy to happen because the IUSR_MACHINENAME account is created locally. IIS plays an IUSR_MACHINENAME account and tries to access resources on the remote computer. After the challenge information is transmitted, IIS uses the IUSR_MACHINENAME password has a correct encryption of challenge information. However, since the remote information is attempting to verify the password using its local SAM database and the local domain controller, it is impossible to verify this information due to remote Windows NT computers and domain controllers. To avoid this problem, you can try the following method:
Create a replicated IUSR_MACHINENAME account in the remote system and make sure to have the same password. If there is an identical local account on the computer at which the IIS server attempts to access, it does not require the help of a domain controller to verify the submitted hash value. Even if the two accounts are physical separated accounts, if their information matches, verification still occurs. You can be lucky to use this technology because the hash algorithm used by Windows NT will generate the same password aquary value for two identical passwords of different users. In UNIX, there will be no such situation. UNIX introduces a value called "Salt", which has two users having the same password to produce different hash values. When you want the IUSR_MACHINENAME account to access a specific remote resource for your site, it is best to set a copy of the local account. If someone is able to spare an anonymous account password, they can only access the computer where there is a local account in the network. Of course, its disadvantage is that if an anonymous users need to access multiple remote resources, you will face administrators' nightmare, because all accounts and their passwords must be saved synchronously. Set an anonymous login account to domain account. To do this, remove the IUSR_MACHINENAME account from your local IIS computer and create a new account on the domain controller. Then enter the Internet Service Manager's WWW Properties dialog box, enter user information in a domain / username format (for example, BigDomain / Joeuser) in the Username text box. Administrators is the easiest way, but when the account information is jezed, the invasive will get huge access to the network. For some reasons, I have been discussed with a number of network administrators who worried about the IUSR_MACHINENAME account into a hacker attack target. In fact, stealing an anonymous login account name and password will not be easier than the account and password of the CEO, so I prefer this method. SQL Server has a unique ability to achieve non-verified joints with other computers, which can effectively spare to Windows NT security. If security issues are not big problems (small, private intranet is usually very safe), you may want to join the SQL Server through TCP / IP. SQL Server monitors network transfer and reacts directly to TCP / IP requests, and uses this feature that you can still implement a good security configuration using this feature. To use this feature, select TCP / IP Sockets in the Security dialog box when installing SQL.
Do you need a "safety dialog" problem!
Some web developers do not want users to enter names and passwords at each access to their sites. So when is the user needs to prompt a dialog to enter his (her) name and password?
When using Windows NT challenge / response verification, Internet Explorer will automatically and invisiblely send the current user's login name, domain name, and hash value to the web server. Internet Explorer does not need to perform these actions because the challenge information sent to encryption will not bring any security risks. Two things happen at this time: If the information sent by the IIS computer can be verified by the domain controller, the user does not require a visualization prompt to be verified. If IIS has failed to identify the domain name sent by the browser, it will not know where information that needs to be verified. This situation is more common than the intranet user than Intranet users, because users at home are rarely located in one domain (and even if it is domain users, the domain controller may not be accessed by IIS computer). Internet Explorer prompts users to enter new names and passwords. From the effect, "Give me some information that can be used (" If an employee working at home, I try to access a security site He will need to enter his name (in the form of BigDomain / Joeuser) and password to make IIS to get the correct domain information. In this way, the domain name is always necessary in this way when verifying the user of the Internet.
In the basic verification method, the user will prompt a login dialog box. You may guess the reason. What you want to do may endanger your Windows NT account and password. All browsers are clearly pointed out: If you enter the information and press OK, you must know what you are doing. I personally use basic verification in a secure integrated network, but if there is no additional security layer such as Secure Sockets Layer, I will not use basic validation on the Internet. Secure Sockets Layer is called on a special configuration web server using https: // instead of http: //. Users need to clearly explain information submitted with a domain controller.
Hacker with your site
Before I further explain, I need to declare whether it is not committed: Yes, active young hackers will read this article and get inspiration, but I believe me, there are many gratia more than this article better than this article. Make sure your site really safe is to understand where the site's weakness is (no one can know the weakness of the site than hackers). There are several areas on a Web site that may be tried to attack or browsing by hackers. Obviously, the username and password with administrator privileges are best methods in their hand. Getting a user's password aquary value is also as good, because the password hasained value is sometimes used as a "password equivalent". The password hash value is used to answer the challenge by encryption challenge information. This will give intruders "Access to the computer (Access this computer from the network" permission from the network. To be given "Log On Locally" permission, the intruder still needs the actual password.
Some programs have been written in particular to extract and crack the password column value of the Windows NT domain controller SAM database. PWDUMP.EXE and NTCRACK.EXE are all available on the Internet and are used by system administrators and hackers. The PWDUMP.EXE program is used to transfer the user's hash value and account information of the SAM database to a text file. System administrators use PWDUMP in a hybrid environment (such as UNIX and Windows NT coexisting) synchronous passwords between network servers, avoiding different passwords between different operating systems. Hackers perform malicious attacks on a network using PWDUMP and NTCRACK. Hakes usually do not run PWDUMP, because running the program requires administrator-level permissions (and if a hacker already has administrator password, he does not need to run PWDUMP). A hacker that does not have administrator-level visits to the network can create a Trojan-Horse program and send it to an unsubstressed user through E-mail. If the user runs an incidental program in E-mail after logging in with an administrator privilege, the program will quietly copy the SAM database after passing the text file to a hacker with E-mail. (Recently I received an e-mail included: "Click Here". I can let you guess what will happen there.) Even if the hacker gets the PWDUMP output, they still have no password. They use NTCRACK to effectively attack the password hash value table. NTCRACK can search all words from English Dictionary, complicated transformations using numbers and letters case, running in the usual Pentium computer, running millions of words and phrases all possible hash values. It then matches the hash value in the file with the hash value retrieved from PWDUMP, and determines the password generated by the resulting value. Remember even if the MD4 hash algorithm is irreversible, NTCrack is based on a fact: people tend to choose a password that is easy to remember. If NTCRACK has to force attack all possible password aquary values in accordance with the maximum password of Windows NT14 characters (including numbers, symbols, and case), the search process will take billions of years on Pentium 120 computers. (I don't know if someone has calculated the time to take on the Pentium Pro computer, but I want to be safe during a certain short period.) If you want to get more information about security elements, please search on the Internet NTCRACK or PWDUMP content. I personally like to use NTCRACK in my system to ensure that the password list is safe and my user selects a secure password.
Conclude
I hope that now you have a better understanding of the factors that affect the WINDOWS NT security of Web. This topic is the most common use verification and dynamic transmission of the site, and the database drivers. This article discusses the security of the internal basis and commission. The subsequent article will be built on top of these contents and makes a more specific configuration factors and problems. If you have already made a better understanding of IIS to complete your work, you will do better.
Programming.
