Windows nt challenge response что это

То, что в последние годы проблемы безопасности протокола NTLM обсуждаются реже, чем раньше, выходят новые версии Microsoft Windows и внедряются новые протоколы аутентификации, не означает что проблемы исчезли. Эта статья — попытка собрать в одном месте информацию о различных недостатках NTLM, возможных атаках и о том, как следует учитывать архитектуру NTLM при проектировании и администрировании корпоративных сетей.

Конфигурирование локальных учетных записей

Дважды щелкните на записи нужного пользователя, чтобы открыть диалоговое окно Properties, где вы можете сконфигурировать настройки этого пользователя. Как можно видеть из рис. 12.7, по сравнению с опциями доменных пользовательских учетных записей опции для локального пользователя содержат намного меньше вкладок.

Чтобы сделать локального пользователя членом группы, щелкните на вкладке Member Of (Член групп) диалогового окна Properties этого пользователя. По умолчанию все локальные пользователи являются членами группы Users. Щелкните на кнопке Add, если вы хотите включить этого пользователя в дополнительные группы. Введите имя группы, если вы знаете его, или щелкните на кнопке Advanced и щелкните на кнопке Find Now (Найти), чтобы выполнить поиск в списке групп (см. рис. 12.8).

Напомним, что при работе с локальными пользователями ваши настройки ограничены локальным компьютером; например, если вы хотите сделать локального пользователя членом группы, то в списке групп будут присутствовать только локальные группы.

Локальный пользователь имеет профиль, и вы можете конфигурировать этот профиль во вкладке Profile диалогового окна Properties для этого пользователя. Как и в случае доменных пользователей, профиль содержит домашнюю папку и скрипт входа. (Профили для доменных пользователей рассматриваются ниже в разделе «Профили пользователей»; см. также раздел этой лекции «Домашние папки».)

Каждый пользователь, который выполняет вход на компьютер Windows Server 2003, имеет папку My Documents (Мои документы), и она также действует обычно как домашняя папка, если этот пользователь работает локально. Но вы можете использовать опции вкладки Profile, чтобы задать другую локальную домашнюю папку.

Внимание. Вкладка Profile содержит опцию для отображения буквы накопителя на сетевой разделяемый ресурс, но она не действует, когда пользователь выполняет вход на локальный компьютер, поскольку это опция только для доменного профиля пользователя.

Вы можете также назначать скрипт входа, но это нетипично для локального входа, поскольку вы можете создать пакетный (batch) файл и загрузить его в папку Startup (Автозагрузка) меню All Programs.

Обзор процесса входа

Windows Server 2003 запрашивает во время входа Username (Пользовательское имя) и Password (Пароль), и пользователь выбирает между локальным компьютером и доменом в раскрывающемся списке Log On To (Вход в).

Локальный вход

Если пользователь указывает имя локального компьютера в раскрывающемся списке Log On To, то Windows Server 2003 проверяет наличие допустимой соответствующей учетной записи в локальной базе данных безопасности. Вход выполняется успешно, если указанная учетная запись найдена и введенный пользователем пароль соответствует паролю этой учетной записи.

Вход в домен

Если пользователь выбирает в раскрывающемся списке какой-либо домен, то Windows Server 2003 использует Active Directory для обработки запроса входа. Служба Net Logon отправляет запрос DNS-имени серверам DNS для поиска ближайшего контроллера домена (DC). Конкретный запрос DNS содержит следующие характеристики:

• тип запроса: SRV (служебная ресурсная запись);
• имя запроса: ldap._tcp.имядомена.

Примечание. В данном случае предполагается, что вход инициируется на компьютере, работающем под управлением Windows Server 2003, Windows XP/2000 или более ранней версии Windows с установленным клиентом Active Directory. Если вход инициируется на компьютере, работающем под управлением более ранней версии Windows без установленного клиента Active Directory, то DC не может выполнить проверку в Active Directory и процесс аутентификации проходит по-другому.

Например, если пользователь пытается выполнить вход в домен ivenseast.com, то Windows Server 2003 отправляет запрос DNS-имени типа SRV, чтобы найти имя ldap.tcp .ivenseast.com. Сервер DNS отправляет в ответ DNS-имена ближайших контроллеров домена ivenseast.com вместе с их IP-адресами.

Используя эти IP-адреса, Windows Server 2003 пытается установить контакт с каждым из DC, которые считаются достаточно близкими, чтобы определить, функционирует ли этот DC. Первый ответивший DC используется для процесса входа. Служба Net Logon кэширует затем информацию этого DC, чтобы не повторять тот же процесс поиска при будущих запросах с этого компьютера.

DC ищет в Active Directory информацию о пользовательской учетной записи, с помощью которой пользователь хочет выполнить вход. Если эта учетная запись и пароль указаны верно и настройки безопасности позволяют выполнять вход с данного компьютера с помощью этой учетной записи, то DC санкционирует вход.

Вход в доверяемые домены

При наличии доверительного отношения доверяющий домен доверяет пользователям и группам из доверяемого домена. Это позволяет пользователям выполнять вход в доверяющем домене. Если пользователь выполняет вход в доверяющий домен, то он указывает домен, где находится его пользовательская учетная запись. Windows Server 2003 санкционирует вход, если учетная запись и доверительные отношения между доменами позволяют это сделать.

Удаленный вход

Служба дистанционного доступа RAS (Remote Access Service) позволяет пользователю выполнять вход в домен с помощью дистанционного соединения по учетной записи коммутируемого (dial-up) доступа или с помощью выделенного соединения глобальной сети (WAN). Удаленный вход осуществляется почти так же, как и локальный вход или вход в локальном домене. Запрос входа передается через сервер RAS контроллеру указанного в учетной записи домена, который аутентифицирует запрос и передает серверу RAS информацию, разрешающую или запрещающую вход. Подробнее о службе RAS см. в
«Служба RRAS (Routing and Remote Access Service)»
.

Аутентификация

Аутентификация является основой безопасности систем, подтверждая опознавательные данные пользователей, которые хотят выполнить вход в домен и получить доступ к сетевым ресурсам. Windows Server 2003 позволяет выполнять один вход для доступа ко всем сетевым ресурсам, и это означает, что пользователь может выполнить вход в домен и затем аутентифицироваться на любом компьютере в этом домене.

Windows Server 2003 поддерживает ряд протоколов аутентификации, включая протоколы, предназначенные для входа на защищенные веб-сайты или через коммутируемые (dial-up) соединения. В этом разделе описываются стандартные процессы сетевой интерактивной аутентификации пользователей: Kerberos V5 и NTLM.

Kerberos

Как уже говорилось в
«Безопасность Windows Server 2003»
, в Windows Server 2003 используется по умолчанию протокол аутентификации Kerberos V5. Для входов пользователей Kerberos работает с паролями и смарт-картами, и это основной протокол безопасности для аутентификации в домене. Kerberos используется также для проверки сетевых служб, и эта способность выполнения двойной верификации называется взаимной аутентификацией.

Kerberos выдает так называемые билеты для доступа к сетевым службам, и эти билеты содержат шифрованные данные (включая шифрованный пароль), которые аутентифицируют опознавательные данные пользователя для любой сетевой службы. После того, как пользователь ввел пароль или использовал смарт-карту, остальная часть процесса аутентификации скрыта от пользователя. В
«Безопасность Windows Server 2003»
приводятся сведения по конфигурированию, управлению и устранению проблем аутентификации Kerberos.

NTLM

NTLM — это протокол аутентификации для таких транзакций, в которых хотя бы один компьютер работает под управлением Windows NT 4. Windows Server 2003, как и Windows 2000, поддерживает аутентификацию NTLM. Это не только означает, что компьютеры Windows NT 4 могут аутентифицироваться при доступе к компьютеру Windows Server 2003. Система Windows Server 2003 поддерживает аутентификацию NTLM в обоих направлениях, и поэтому будет использовать NTLM при доступе к какому-либо ресурсу на компьютере, работающем под управлением Windows NT 4. Ниже приводятся некоторые сценарии в вашей сети, требующие поддержки NTLM.

• Компьютер Windows Server 2003/Windows 2000/Windows XP аутентифицируется на контроллере домена Windows NT 4.
• Клиент Workstation Windows NT 4 аутентифицируется на контроллере домена Windows Server 2003/Windows 2000.
• Пользователи домена Windows NT 4 аутентифицируются в домене Windows Server 2003/Windows 2000.
• Клиент Workstation Windows NT 4 аутентифицируется на контроллере домена Windows NT 4.

Протокол NTLM появился в Windows NT, и его называли аутентификацией Windows NT «challenge/response» (вызов-ответ). В дополнение к аутентификации пользователей и паролей NTLM поддерживает шифрование и электронную подпись. Windows NT поддерживает также аутентификацию LAN Manager (LM) для клиентов предыдущих версий Windows (Windows 9x).

Для защиты от частых атак хакеров, пытающихся получить доступ к паролям, Microsoft повысила уровень безопасности NTLM, выпустив NTLM версии 2 (обычно ее называют NTLM 2) в Service Pack 4 для Windows NT 4.

Windows Server 2003 автоматически поддерживает NTLM 2 для компьютеров Windows NT, находящихся в сети. Если у вас еще есть клиенты Windows 9x, установите клиентское ПО Active Directory на этих компьютерах, чтобы они могли аутентифицироваться с помощью NTLM 2.

Клиент Active Directory Dsclient.msi (directory service client — клиент службы каталога) не включен в CD Windows Server 2003. Вы можете загрузить его с веб-сайта Microsoft. Если вы переходите к Windows Server 2003 из Windows 2000, то Dsclient.msi находится на CD Windows 2000 Server в папке ClientsWin9x.

Authentication and Security

For Internet Developers

Scott Stabbert

Internet Developer Support

Microsoft

Introduction

If you are a Web developer working with Microsoft’s Internet Information Server (IIS), it is very important to understand how IIS uses authentication and impersonation to control security on your Web server. While working in the Internet Developer Support team at Microsoft, I found that about 1 in 4 of the issues we dealt with were caused by the umbrella topic we call permissions. Further, most of those issues could have been avoided if the developer simply had a better conceptual understanding of what was happening under the hood. Authentication is simply the process of determining the identity of a user. Once a user has been positively identified, Windows NT can then control what resources that user can access. While not extremely technical, authentication and security can be confusing. Having a solid understanding of how IIS controls security will allow you to be much more successful creating solid sites, and to avoid common time consuming problems.

This article explains Windows NT security as it relates to IIS so that you can effectively troubleshoot nasty security-related problems. We will cover the three forms of authentication, how they differ, several ways of controlling access to key areas on your Web server, and the important but almost universally misunderstood concept of «delegation.» Understanding delegation is mandatory for anyone building a data driven Web site using IIS. Understanding how Windows NT handles different «users» will potentially save you days or weeks of troubleshooting.

ACLs, NTLM, and other definitions

To start with, let’s define some common terms that relate to Windows NT’s security.

 ACLs Access Control Lists. Each ACL is a list of Access Control Entries (ACEs) that specify access and auditing information used by Windows NT on an NTFS-formatted hard drive. Windows NT uses the lists to determine which users have been granted access to specific resources (files and folders), and which rights a user may exercise such as read, write, and execute. The ACLs for a file or folder can be viewed by right-clicking the resource, clicking properties, and clicking the Permissions button on the Securities tab.

 Challenge/Response A Windows NT authentication process. Challenge/response can occur when a user or service (such as IIS) tries to access any resource stored on an NT machine across a network (such as viewing a shared resource on a server). Can be used by IIS to authenticate a user browsing a Web site.

 NTLM Windows NT’s implementation of the challenge/response authentication scheme. NTLM stands for NT LAN Manager because it was developed and originally used in Microsoft LAN Manager, one of Microsoft’s earliest networking products.

 SAM The SAM (Security Account Manager) is a database of user and group account information. The SAM does not contain passwords, but instead stores password hashes (described later). The SAM is stored in the HKEY_LOCAL_MACHINESAM and HKEY_LOCAL_MACHINESecuritySAM registry subtrees. Not surprisingly, the SAM is often the prime target of hackers.

Impersonation

Under different situations IIS pretends to be different users. Remember that all processes operating on a Windows NT machine run under a valid NT account. When a program or process (like IIS) runs on behalf of a user, it is said to be running under the security context of that user. The purpose is to give that process no more access to files and resources than the user would have. When IIS does this, it is said to be impersonating that user.

IIS, obviously, is designed to handle Web requests as an automated service. To do this, IIS still needs to run under some valid user’s security context. There are two kinds of requests that IIS may be required to respond to. First are anonymous requests where we know almost nothing about the user, and second are authenticated requests where we know exactly who is requesting the resource. It’s not always obvious which method is being used since both anonymous and authenticated requests can happen with no dialog boxes or other indications to the user. It is, however, mandatory that we as developers always know which method is being used. What account IIS impersonates, and by extension, what IIS can and can not do depends completely on knowing.

Anonymous Requests — No information is required from the user. By default, when a browser requests a Web page, IIS will first try to fill the request without authenticating the user. To do this, IIS impersonates a special Windows NT account, IUSR_machinename (where machinename is the name of the IIS host computer). This account is created during the install process for IIS. If IIS, impersonating the IUSR_machinename account, can access the requested resource, then the page is served to the anonymous user.

A common problem with anonymous access occurs when the password for the IUSR_machinename account and the password entered in the Internet Service Manager get out of sync. When IIS tries to impersonate the IUSR_machinename account, it submits the password that was entered in the anonymous logon field to Windows NT . If that password is incorrect, IIS is totally prevented from using the account. Since anonymous access failed, IIS attempts to authenticate everyone. The scary part of this is that the authentication can happen silently, so the site begins to fail but the reason isn’t apparent at all. I’ve talked to many Web site administrators who were experiencing bizarre security related problems because their site authenticating all users, and they didn’t even know it. This makes a huge difference if your pages are accessing other resources like databases or server side components (DLLs).

Controlling the Authentication Method, and Why We Care

Allow Anonymous Check Box

Change Permissions on Files and Folders

The NTFS level permissions are respected by IIS, so manipulating individual permissions on files and folders allows better granularity as you control what pages can be accessed by whom. A common scenario would be to have customer pages on a retail site set with the default «Everyone Full Control» permissions, while other pages that allow the prices to be changed could be restricted to administrators. The IUSR_machinename account is of course part of the Everyone group, so you could restrict access several ways. Either remove the Everyone group and possibly add a «Web authors» group for those that need editing rights, or if you have a diverse number of Web authors and you aren’t interested in setting up and maintaining a «Web Authors» group, you could simply exclude the IUSR_machinename account. This method is obviously best for a site that needs some anonymous while still securing other pages.

ASP Code-Based Security

Code-based security is the most fun. Using Active Server Pages (ASP) code, we can implement unique and varied security. For example, say an annoying person is harassing your site. Since the IP address can be pulled from the logs, we could use the following code to deny 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 server variables that can be used under ASP, including the LOGON_USER that will return the domainusername of authenticated users, and a blank for anonymous users. In this case it would be possible to use server side code to check for key individuals and possibly redirect them to different pages depending on their job requirements. I’ve even seen companies used this technique to lock competitors out of their Web sites.

And Now for Something Completely Different: The «Hash»

IIS and the Challenge/Response Authentication Process

IIS will try to use Windows NT challenge/response authentication if the following are true:

• 
  If the “Allow Anonymous” box in the WWW properties of the Internet Service Manager is cleared or the IUSR account doesn’t have sufficient permissions to access the requested resource or code is used to deny access.
• 
  Windows NT Challenge/Response is selected in the Internet Service Manager under WWW properties
• 
  The browser making the request understands challenge/response. Currently Internet Explorer is the only browser that supports NT challenge/response.

When we say that IIS tries to authenticate the user, what it actually does is rather simple. It sends an HTTP 401 Access Denied message back to the browser, with the list of authentication methods it accepts. Another way of looking at this is IIS saying, “You can’t get what you want without identifying yourself. By the way, I accept the following methods of identification.” The two methods of identification are NT Challenge/Response and Basic. Which method is acceptable depends on which WWW properties are checked in the IIS Internet Service Manager dialog box. If both authentication methods are turned on, Internet Explorer will always attempt to use challenge/response, while other browsers will use Basic.

The following table presents a packet’s-eye view of how NT challenge/response authenticates a user without ever seeing their password.

Client Server

Why a Random «Challenge»?

The extra step of encrypting a challenge using a password hash, instead of just passing the simple hash up to the domain, makes it harder for the hash to be intercepted and used as a password. Since the challenge requires the user’s password hash to generate the new hash, it proves the person has at least the user’s hash, but probably the user’s password as well. All this without having the password sent over the wire. In essence, the password becomes a private key and the random value a constantly changing public key.

Delegation!

Delegation is where most people lose the picture on both NT security and IIS authentication, even though delegation is a huge issue for anyone considering a secure Web server environment, or, for that matter, just wanting things to work! When the IIS Web server impersonates a user authenticated using NT challenge/response, IIS does NOT have the user’s password or password hash. IIS only sees the encrypted challenge, which it passes to the domain controller. You are most likely to see this when you have an ASP page that accesses resources on another Windows NT box (such as a database). The second Windows NT box will challenge IIS forcing it to prove that it is truly the impersonated user and IIS will not be able to since it can not encrypt any challenges sent to it with the user’s hash. The second machine will deny access, and your database enabled Web pages fail. This is a limitation in the Windows NT 4.0 (and prior) security model, and not IIS. Using Windows NT challenge/response, there is no way a process impersonating you can access so much as a text file on another Windows NT box.

If you ever want to determine when delegation is an issue, ask yourself if the Web server has the user’s password or hash. In politics you «follow the money». In delegation you «follow the password»!

An analogy for this could be an executive that delegates responsibility to a secretary to sign checks and otherwise act on their behalf. When using NT challenge/response, the user cannot delegate IIS to act fully on their behalf. This particular limitation may well go away with the release of Windows NT 5.0 when NT incorporates the Kerberos authentication system (developed for MIT’s Project Athena).

Basic Authentication

Most people are afraid to use the Basic authentication option because of the screen they are confronted with when activating it:

The authentication option you have selected results in passwords being transmitted over the network without data encryption. Someone attempting to compromise your system security could use a protocol analyzer to examine user passwords during the authentication process. For more detail on user authentication, consult the online help.

Are you sure you want to continue?

The message is as bad as it sounds. The user name and password are Base64 encoded. Base 64 is easily de-coded by even novice hackers, though they would still have to access your network and use a TCP/IP packet sniffer to intercept network packets, so this is not a likely event unless you are an overly attractive target such as a bank.

Most Web administrators I’ve talked to know that there are differences between NT challenge/response and Basic, but still treat them as interchangeable. Basic authentication always prompts the user with a dialog box and asks them to type in a user name and password. This information is then sent to IIS, which uses the name and password to execute a log on locally command to the IIS box. Since IIS now has the password of that user, it can answer challenges from remote machines, eliminating the delegation problem. Think of a user authenticated using Basic as actually sitting at the Web server working, where a user authenticated using NT challenge/response as accessing the Web server from a network. In fact, the user rights “access this computer from the network” and “log on locally” are specific user rights that need to be set for users depending on which authentication method is used. To set these rights, use the «User Manager for Domains» tool and select the «user rights» item from the «policies» menu.

Even with its flaws, there are two circumstances where Basic authentication should be used.

• 
  You need to authenticate users using a browser other than Microsoft Internet Explorer. For example, Netscape Navigator only understands Basic authentication. If you have NT challenge/response and Basic authentication selected, Internet Explorer will always use NT challenge/response, and Navigator will choose Basic. If your data is sensitive, this is a serious security concern.
• 
  Your site authenticates users and your ASP pages access resources on other Windows NT machines. The classic situation is an ASP page that uses ADO (ActiveX Data Objects) to access a database on a remote Windows NT machine. To avoid delegation issues, either ensure that all requested resources are located on the IIS machine, or, if that isn’t practical, use Basic authentication.

Common Authentication Scenarios

Whenever an Internet user is authenticated using NT challenge/response, delegation will be an issue when IIS accesses Windows NT resources across a network or local resources using UNC paths. Of course, all local resources can be accessed as long as the user has the correct NTFS level permissions.

UNC Paths

A common delegation-related error occurs when an ASP page is coded to access a database using a file-based data source (such as an Access .mdb file) and the location is specified using a UNC path (for example, \ServerShareresource.ext). Even though the resource is local, specifying a location using UNC makes it look to Windows NT as if it is elsewhere on the network. The Windows NT networking subsystem handles UNC paths. Windows NT is abstracted within its various components enough that if you step into the networking subsystem, as far as the other Windows components are concerned, you are out on the network. This leads to the confusing, but rather amusing scenario where an IIS machine that has authenticated a user using challenge response, and is trying to access a local resource using UNC, will demand authentication from itself, and is unable to fulfill the request. To resolve this problem, use absolute paths on the IIS machine (for example, “C:folderresource.ext”).

Delegation, NOT!

There is a subtle security-related failure that mimics delegation failure, but is not related to delegation at all. In both these cases, you will see a three machine hop that fails (browser to NT/IIS to NT/remote resource). To troubleshoot this, check if this is an authenticated or non-authenticated transaction. If authenticated, the problem is almost certainly delegation failure. However, if the page is accessed anonymously, the problem is likely caused by the anonymous logon account being local to the IIS machine. This can easily happen because the IUSR_machinename account is of course created locally. IIS impersonates IUSR_machinename, and attempts to access a resource on the remote machine. The challenge is passed, and IIS correctly encrypts the challenge using the IUSR_machinename’s password hash. However, the remote Windows NT machine takes the password hash and tries to validate it using its local SAM database and the local domain controller. Neither the remote Windows NT machine nor the domain controller have ever heard of this account and, therefore, can’t validate the information.

1. 
   Duplicate the IUSR_machinename account as a local account on the remote machine making sure the user passwords are the same. If an identical local account exists on the machine with the desired resources, that machine can validate the submitted hash without the aid of a domain controller. Even though the two accounts are physically separate accounts, if their information matches, validation can occur. One of the technical reasons you can get away with this technique is because Windows NT’s hashing algorithm is such that two identical passwords from different users will generate the same password hash. Under UNIX, this isn’t the case. UNIX introduces a value referred to as «salt» such that two users with the same password will generate different hash values. Setting up a duplicate local account is best when you want the IUSR_machinename account to only have access to specific remote resources on your net. If someone is able to compromise the password for the anonymous account, they will only have access to those computers on the network where the local account exists. The drawback is of course that if the anonymous account needs access to multiple remote resources, now you have an administration nightmare as all the accounts and their passwords must be kept in sync.
2. 
   Make the anonymous logon account a domain account. To do this, remove the IUSR_machinename account from the local IIS machine, and create a new account on the domain controller. From the WWW properties dialog box of the Internet Service Manager, enter the Username field information in the format DomainUsername (for example, BigDomainJoeUser). This method is the easiest to administer, but in the event that the account information is compromised, an intruder would have greater access to the network. For some reason, I’ve talked with a lot of network administrators who are concerned about the IUSR_machinename account being a target of hackers. It is actually no easier to steal the anonymous logon account name and password then the CEO’s, so my preference for ease of administration is the domain route.
3. 
   SQL Server has the unique ability to allow an unauthenticated connection from another machine, effectively bypassing Windows NT’s security. If security isn’t a big concern (local company intranets are usually pretty safe environments), you may want to make the process of connecting to SQL server much easier by using TCP/IP sockets. SQL server will monitor the network traffic and respond directly to TCP/IP requests, taking Windows NT out of the loop. SQL has it’s own security layer, so it is very possible to use this option and still implement a decent security configuration. To enable this option, select TCP/IP sockets in the Security dialog box when running SQL setup.

To “Security Dialog” or Not to “Security Dialog”? That is the Question!

Some Web developers do not want their users to have to type in a name and password each time they view the site. So when will users be prompted with a dialog box to enter their name and password?

When using NT challenge/response, Internet Explorer automatically and invisibly sends the logon name, domain name and hash of the currently logged on user to the Web server. Internet Explorer does this without asking because sending the encrypted challenge doesn’t present any real security risk. From there, two things can happen:

• 
  If the IIS machine sends information that can be appropriately validated by the domain controller, the user will be authenticated without a visible prompt.
• 
  If the domain name sent by the browser isn’t recognized by IIS, then IIS will have no idea where to send the information for validation. This is more common for Internet users than intranet users, since a person sitting at home is rarely on a domain. Even if they are, their domain controller probably isn’t accessible by the IIS machine. Internet Explorer prompts the user to enter a new name and password, in effect saying, “Give me some information that I can use.” If an employee working at home were trying to access a secured site, they would need to enter their name in the form “bigdomainJoeUser” and their password in the password field so that IIS will get the correct domain information. Explicitly stating the domain name in this manner is almost always mandatory authenticating users across the Internet.

Under Basic authentication, the user will always be prompted with a logon dialog box. You can probably guess why. We are about to do something that could compromise your Windows NT account name and password. All browsers figure that if you are willing to fill in the information and click OK, then you must know what you are doing. I personally don’t have a problem using Basic authentication on a secure corporate network, but I will not use it over the Internet without an additional layer of security such as Secure Sockets Layer (SSL is invoked on a specially configured Web server that uses HTTPS:// instead of HTTP://). Once again, the user will need to explicitly state the domain. IIS still needs to verify the submitted information with some domain controller.

Hackers and Your Site

Before I get into this, it seems I always need to offer a disclaimer. Yes, an aspiring young hacker could read this and get ideas, but believe me, there are much better sources for hackers than this article. The best way to really secure your site is to know where the weak points are, and no one knows where the weak points are better than hackers. There are several key areas that a hacker may try and attack or exploit on a Web site. Obviously getting their hands on a username and password with administrative privileges is the biggest coup. Getting a user’s password hash is almost as good because a password hash can be used in some cases as a «password equivalent.» The password hash could be used to answer challenges by encrypting the challenge. Doing this can grant an intruder «access this computer from the network» rights. To be granted a «log on locally» right, though, they still need the actual password.

Several programs have been written specifically to extract password hashes from a Windows NT domain controller’s SAM database, and crack the passwords. PWDump.exe and NTCrack.exe are both free on the Internet, and are used by both system administrators and hackers. System administrators will use PWDump to synchronize the password lists between network servers in a mixed environment such as UNIX and Windows NT so users don’t need different passwords for the different Network operating systems. Hackers will use PWDump and NTCrack to execute a brute-force attack against a network. Here is how it works. PWDump.exe is a program written to dump the SAM database of user hashes and account information to a text file. An administrator must run PWDump, so hackers usually wouldn’t run the program themselves. If they already had an administrator’s password, they would have enough. A hacker without administrative access to a network could construct a Trojan horse program that could be sent in e-mail to an unsuspecting user. If the user, while logged on with administrative rights, ran the attachment in e-mail, the program could silently dump the SAM database and e-mail the text file to the hacker. (I received mail recently with an attachment that said «click here.» I’ll give you one guess what the chances are of my clicking on an unknown e-mail attachment; exactly zero). Once a hacker has the output of PWDump, they still don’t have any passwords. Remember that the MD4 hashing algorithm theoretically cannot be reversed. NTCrack is the program of choice for brute force attacks against a list of password hashes. NTCrack can take all the words in the English language, as well as play sophisticated games for variations with numbers and case sensitivity, and in several hours on an average Pentium machine, generate all the possible hashes for about a million words and phrases. It then just matches the hashes on file with the hashes retrieved from PWDump, and looks to see which password generated that hash. NTCrack is only useful because users tend to choose passwords that are easy to remember. If NTCrack had to brute force attack all the possible password hashes for Windows NT’s maximum password length of 14 characters (including numbers, symbols, and case sensitivity), the search it would take several thousand million years using a Pentium 120. (I don’t know if anyone has calculated how long it would take on a Pentium Pro, but I think we’re safe for a little while.) If you would like more information on security issues, search the Internet for NTCrack or PWDump. I personally enjoy using NTCrack on my own system to ensure that the password list is secure and that my users are choosing good passwords.

Final Word

I hope you now have a better idea of Windows NT security issues that affect Web site development. This subject comes up the most frequently on sites that use authentication and deliver dynamic database driven content. In this article I’ve tried to look at just the underlying foundations of security and delegation. Future articles will begin to build on this understanding, and discuss more specific configuration issues and problems. If you have a good understanding of what IIS is doing to get its job done, you’ll be much more able to get your job done.

Happy programming!

Scott Stabbert

The LM and NTLM (v1 and v2) challenge/response processes are nearly identical, which is to be expected since the NTLM Security Support Provider (SSP) is responsible for implementing the LAN Manager, NTLMv1, NTLMv2, and NTLMv2 Session protocols.

Here’s what the process looks like:

1. Client sends a login request to the server. This is also known as a Type 1 message and contains a list of features supported by the client and requested of the server.
2. Server respondes with a Type 2 message, which contains the agreed-upon features and a random string (the challenge)¹.
3. Client responds with a Type 3 message, containing its response to the challenge and, in the case of NTLMv2, a little something extra.
4. Server processes the response (in a domain environment, the server will send the username, challenge, and response to a DC to do this work), using its copy of the user’s hash as the key, and compares the result with the challenge. If they match, the client is authenticated.

So why do we go through all this trouble with the challenge and response? Why can’t the client just send its hashed credentials for the server to compare with its own local copy and be done with it?

The reason for all of this challenge/response business is that Windows hashes are password equivalent. In both NTLM and Kerberos, it is the user’s hash that acts as the input into the process. The only thing an attacker needs to authenticate as a user is access to their NT hash. This is known as a pass-the-hash attack.

NTLM uses challenge/response as a way to prevent the user’s hash from being sent over the network where it can get stolen. Rather, the hash is used to encrypt a challenge, which is then sent as proof that the client has access to the user’s credentials (the hash). The server will then encrypt the challenge it sent with its own copy of the user’s hash and compare the two results. If they match, the client is authenticated.

So how does the response actually get made?

LM & NTLMv1 Response

In a welcome bit of simplicity, LM and NTLM both follow nearly the same process for creating a response. The only difference is the input hash format used as a key for the DES encryption algorithm.

Here’s a closer look at the encryption process:

1
2
3

Response = DES(<HASH>[0-6], challenge) +
           DES(<HASH>[7-13], challenge) +
           DES((<HASH>[14-15] + 5 * NULL), challenge)

If LM is enabled, the response will contain both the LM response (24 bytes) and the NTLMv1 response (24 bytes). If LM is not enabled, you’ll just get the NTLMv1 part. Fair enough.

LMv2 & NTLMv2 Response

You knew v2 wasn’t going to get simpler, right?

LMv2 Response

The LM response is created for systems that don’t understand NTLMv2 and are expecting to see a 24-byte response value in both the LM and NT positions. The HMAC-MD5 hash is 128 bits (16 bytes) long which, when combined with the 8-byte client challenge, results in a 24 byte value. Coincidentally (or not?) the size of the old school LM response.

1
2
3

NTLMv2 Hash   = HMAC-MD5(NT Hash, uppercase(username) + target)
LMv2 Goodies  = HMAC-MD5(NTLMv2 Hash, challenge + 8-byte client nonce)
LMv2 Response = LMv2 Goodies + 8-byte client nonce

NTLMv2 Response

The NTLMv2 response is the default version of NTLM for pretty much every computer running Vista or greater. If you’re dealing with NTLM today, it’s probably NTLMv2.

Here’s how an NTLMv2 response is created:

1. The username is converted to uppercase and concatenated with either the (case-sensitive) target domain name or server name².
2. The username/target string is smashed into an HMAC-MD5 function, using the NT hash as the key. This gives us the 16-byte NTLMv2 hash.
3. The blob is created³.
4. The server’s challenge is concatenated with the blob, and then smashed into another HMAC-MD5 function, this time using the NTLMv2 hash as the key, resulting in a 16-byte output, which I’ll be calling the Goodies.
5. The Goodies are concatenated with the blob to form the NTLMv2 response.

1
2
3

NTLMv2 Hash     = HMAC-MD5(NT Hash, uppercase(username) + target)
NTLMv2 Goodies  = HMAC-MD5(NTLMv2 Hash, challenge + blob)
NTLMv2 Response = NTLMv2 Goodies + blob

The data contained in the blob is of variable length, which means that the response will also be of variable length.

NTLM2 Session Response (No V!)

Do you have serious security concerns about precomputed dictionary attacks, but can’t implement NTLMv2? Read on, dear reader, read on.

We’re going to start this one with the LM response:

1. Client creates an 8-byte nonce and null pads it to 24 bytes to form the LM response.

1

LM Response = 8-byte client nonce + 16 * NULL

Now on to the NTLM2 bit:

1. Combine the 8-byte client nonce with the server challenge to create a session key.
2. Squish the session key through MD5.
3. Truncate the 16 bytes of hashed session key down to 8. This is the NTLM2 session hash.
4. Null pad the 16-byte NT hash to 21 bytes, then split that into three 7-byte blocks.
5. Using each of the 7-byte blocks as the key, DES-encrypt the NTLM2 session hash.
6. Concatenate the three resulting ciphertext bits into a 24-byte response.

1
2
3
4
5

NTLM2 Session Key = 8-byte client nonce + 16-byte server challenge
NTLM2 Session Hash = (MD5(NTLM2 Session Key))[0-7]
NTLM2 Response = DES(NTLM2 Session Hash[0-6], NTLM2 Session Hash) +
                 DES(NTLM2 Session Hash[7-13], NTLM2 Session Hash) +
                 DES((NTLM2 Session Hash[14-15] + 5 * NULL), NTLM2 Session Hash)

ELI5

The deeper down you go with NTLM the more complicated it gets, but from a 5-year-old’s perspective it’s quite simple. Both the client and the server have access to the hash of the user account you’re using to authenticate. If they didn’t, you wouldn’t be able to authenticate at all which makes for as short blog post.

So you want to connect to the server but we’re going to do this in a such a way that we’re not sending your password-equivalente NT hash across the network where it could be burgled.

You contact the server and say «hi» and in return the server provides you with a random string. You encrypt this random string with either DES (LM & NTLMv1) or HMAC-MD5 (NTLMv2), using your NT password hash as the key, and then send it back to the server.

Since the server (or DC) also has access to your hash, it encrypts the challenge with that hash and compares its result to the one sent by the client. If it’s a match, the client is authenticated.

Resources

• NTLM Challenge Response is 100% Broken (Yes, this is still relevant
• NT LAN Manager
• The Most Misunderstood Windows Security Setting of All Time
• The NTLM Authentication Protocol and Security Support Provider

Администрирование

MMC — Microsoft Management Console

•  
  •  
    •  
      A) Нажмите конпки stop, start или pause в меню панели инструментов.
      B) Нажмите правой кнопкой мыши на нужном сервисе и нажмите Start, Stop или pause.

  Свойства наследуются по всей
  иерархии сайта (Site, Directory и Files), если только в индивидуальный
  свойствах явно не указан другой набор свойств. Например, установки
  сайта (Site settings)будут унаследованы каталогами и файлами в пределах
  этого сайта.

  Web site operator имеет ограниченный
  набор администраторских полномочий на конкретном сайте. Он может только
  менять установки сайта, но не установки IIS. Web site operator может
  быть назначен сайту через свойства сайта (закладка Operators).

  При помощи MMC можно останавливать, запускать и ставить на паузу различные службы.

  Что бы остановить, запустить или поставить на паузу службу, сделайте одно из следующих действий:

Для того, что бы удаленно администрировать IIS, в адресе необходимо указать порт, например : http://www.cramsession.com:6967/iisadmin/

.

Аутентификация

Возможные способы аутентификации :

•  
  • Allow Anonymous — любой пользователь может получить доступ к вашему сайту.
  • Basic — Для доступа требуется имя пользователя и пароль.
  • Windows NT Challenge/Response — Используется проверка прав пользователя через User Manager for Domains.
  • SSL Client Certificate — Сертификат, установленный на системе клиента, используется для аутентификации.

Если права пользователя меняются в то
время, когда загружен IIS, необходимо либо подождать 15 минут, пока
изменения вступят в силу, либо перезапустить соответствующую службу для
немедленного внесения изменений.

От пользователей Web аутентификация требуется только когда:

•  
  • Анонимный доступ запрещен.
  • Анонимному пользователю запрещен доступ к данному ресурсу.

Когда используется метод аутентификации
challenge/response, браузер, не поддерживающий этот метод (не
MS-браузен ) выведет на экран сообщение Access is Denied

.

Если браузер поддерживает только basic authentication, не отключайте ее в IIS, в противном случае сайт будет недоступен.

В IIS доступ на чтение позволяет пользователям читать или скачивать файлы.

Для доступа к каталогам, которые
находятся на разделе NTFS на удаленном сервера, вам необходимо указать
имя пользователя и пароль.

Что бы не передавать имя
пользователя и пароль по сети, используйте метод challenge/response в
WWW и используйте только анонимные подключения в службе FTP.

Виртуальные каталоги, расположенные на удаленном компьютере, для доступа к ним требуют учетной записи пользователя NT.

Если IIS установлен на server1,
а виртуальный каталог располагается на server2, и две системы не входят
в один NT домен, вы должны добавить одинаковую учетную запись
пользователя на server1 и на server2.

Клиентские сертификаты могут быть назначены на учетные записи NT.

Разрешения NTFS и IIS:

•  
  • Содержание сайта = Read
  • Программы = Read и Execute
  • Базы данных = Read и Write

Что бы исключить доступ анонимного пользователя к конкретным директориям:

•  
  • Уберите все разрешения NTFS у группы guest
  • Присвойте пользователю IUSR_ComputerName право no access

Если в FTP используются только
анонимные подключения, задействуйте оба свойста — Allow Anonymous
Connections и Allow Only Anonymous Connections в разделе Security
Accounts свойств сайта FTP.

WWW

Есть два пути как пользователь может получить доступ к виртуальному каталогу:

•  
  • Ссылки.
  • Написать alias в URL.

Пробелы в именах виртуальных каталогов вызовут проблемы у старых браузеров.

Если вы не указали адрес IP виртуального сервера к виртуальному каталогу, он будет виден всеми виртуальными серверами.

Когда реплицируете ваш web сайт
на несколько серверов, используйте одинаковое имя для любого сайта.
Создайте отдельные записи с именем web сервера как alias.

Пользователь по умолчанию должен иметь право logon local для получения доступа к WWW страницам вашего сервера.

Для улучшения загрузки web страниц, увеличьте время HTTP keep alive.

Виртуальные каталоги на другом сервере:

•  
  • Создайте каталог общего доступа на удаленном сервере
  • Используйте путь UNC к удаленному серверу и каталогу общего доступа
  • Введите имя пользователя и пароль для соединения
  • Удаленный сервер должен быть в том же домене, или добавьте имя пользователя с правами доступа в обоих доменах.

Для каждого виртуального сервера может быть создан только один домашний каталог (home directory).

Каталог скриптов в виртуальном домашнем каталоге управляет скриптами для этого виртуального домашнего каталога.

Общий каталог скриптов не назначенный на виртуальный домашний каталог может управлять скриптами для всех виртуальных серверов.

Виртуальные каталоги различаются именами alias. Alias привязан к виртуальному каталгу в закладке каталог (directory tab).

Если вы удалите виртуальный
каталог IISadmin на сервере, который вы администрируете, вы не сможете
использовать HTML администратора.

FTP

Для использования аннотаций каталогов:

•  
  • Поместите AnnotateDirectories REG_DWORD=1 в реестр.
  • Создайте ~ftpsvc~.ckm в каждом каталоге.

Некоторые броузеры не могут моддерживать управлени более чем одной линии в FTP приветственном сообщении, и получают ошибку 404.

Изменение Порта TCP через FTP Site
Properties потребует изменение клиентам их настроек software FTP для
TCP портa для правильного подключения.

Типы листиногов каталогов FTP:

•  
  • DOS — дата, время, размер, имя
  • UNIX — разрешения, владелец, группа, размер, дата, время, имя

Порты

Если вы изменяете номер порта, клиенты должны указать измененный номер порта для доступа к ресурсу.

ISAPI/CGI/Perl

Разрешение на Исполнение (Execute) необходимы для ISAPI и CGI приложений.

Разрешение на Чтение (Read) необязательно для ISAPI и CGI приложений.

Разрешения NTFS Читать (Read) и Писать (write) необходимы для ISAPI/CGI на разделах NTFS.

Для возможности серверу запускать CGI приложения, добавьте запись для типа приложения в реестр.

CGI приложения не могут быть запущены если использовалась аутентификация challenge/response.

CGI необходим новый процесс для каждого исполнения.

ISAPI фильтры используются для настройки процесса авторизации, доступа или процесса входа пользователя (logging).

Perl необходимо установленного command interpreter на IIS сервере.

MIME

MIME (Multipurpose Internet Mail Extensions) — Содержит список расширений и их ассоциаций с приложениями.

Установки MIME существуют в metabase. Metabase подобна реестру, но используется исключительно для хранения установок IIS.

Назначения MIME существуют с MMC
— Свойства Web Site, под закладкой HTTP Headers. Вы должны остановить и
перезапустить web сайт для вступления в силу изменений MIME.

Добавьте тип MIME для разрешения
обработки файлов с другими расширениями. Например, добавьте тип MIME
для разрешения фaйлов *.WEB быть обработанными как файлы *.HTML.

SSL — Secure Sockets Layer

Страницы SSL влияют на загрузку CPU и дольше загружаются сами.

URL SSL начинаются с https:// вместо http://.

Используйте Key Manager для запроса и импорта сертификатов безопасности.

Если две компании используют один и тот же IIS сервер, вам нужно два SSL сертификата.

Вы можете указать IP адрес и номер порта для применения сертификата когда импортируете в KEYMGR.

Вы можете применить SSL сертификат на виртуальный сервер, на котором не установлен IIS, указывая его адрес IP.

Процедуры для получения и внедрения SSL сертификата:

1. Сгенерируйте файл ключевой пары (key pair) и файл запроса (request).
2. Запросите сертификат у authority.
3. Установите сертификат.
4. Активизируйте SSL на сайте/директории.

Коды Ошибок

Регистрация (Logging)

Регистрация может быть реализована только для желательных служб, не для страниц, файлов и т.д.

Регистрация Текстового файла имеет минимальные воздействия на производительность.

Регистрация на базу данных SQL требует больше ресурсов.

Вы можете определить счетчик посещений для страницы из файла регистрации.

Только один файл журнала (log file) может быть создан для всех WWW виртуальных серверов.

Вы можете наблюдать за регистрациями пользователей Анонимов (Anonymous) через файл регистрации.

• CONVLOG.EXE —
  Используется для преобразования IP адресов в DNS имена, и для
  преобразования файлов журана web в формат NCSA Common Log File.

Настройка Производительности

Вы можете органичить пропускную
способность для IIS кликнув по limit bandwidth. Эти ограничения
доступны для WWW служб (особенно для транспортировщиков файлов *.HTML),
чтобы больше пропускной способности оставалось для других служб.

Пропускная способность может быть ограничена индивидуально для каждого сайта.

ASP приложения, CGI скрипты и базы данных загружают CPU, по сравнению со стандартными .HTML и FTP транспортировщиками файлов.

Пропускную способность можно подсчитать добавляя 4 бита к каждому 12 биту на каждый байт:

•  
  • т.e. 56,000 байт займут 56k*12 для передачи.

Модернизируйте сетевую архитектуру (100 BaseT, FDDI) если сетевая утилизация больше 60%.

IIS/SQL

.IDC файлы содержат имена и
расположение .HTX файлов, ODBC имя источника (DSN), SQL утверждения и
ID пользователя и его пароль (оба опцыональны).

.Коммуникация IDC требует 32-битовых драйверов ODBC.

Файл .HTX это шаблон HTML, используемый для отображения запрошенных данных SQL.

Измениение транспортоного
протооокола между SQL и IIS серверами (на разных машинах) остановит
хакеров от доступа к SQL через TCP/IP.

Три файла необходимы для соединения между IIS и SQL:

•  
  • .IDC
  • .HTX
  • HTTPODBC.DLL

Если IIS и SQL сервера расположены в
разных доменах, необходимо установить доверительные отношения между
доменами или учетная запись IUSR_WEB должна быть добавлена в SQL домен.

Специальная однопользовательская лицензия (на SQL Сервер) необходима для разрешения неограниченного доступа к Интернет.

Если включена аутентификация
challenge на IIS, это остановить регитсрацию на удаленном SQL сервере.
Вам нужно установить основную (basic) аутентификацию или установить SQL
сервер на тотже сервер, что и IIS.

Index Сервер

Файлы index занимают по совокуности 40%

Index Сервер может искать ОДИН каталог на каждый запрос.

Есть два пути наблюдать за производительностью Index Сервера:

•  
  • Performance Monitor
  • .IDA script

Вы можете сделать слитие (merge) Index
Сервера более частым, делая принудительное слитие с web
административной станицой, или сокращением максимального цисла
постоянных indexes в реестре, уменьшив MaxIndexesValue.

.IDQ эквивалетны .IDC файлам и
используются как фалы помощи при запросе преобразования от WWW. Они
содержат вводимую пользователем HTML форму. Они содержат следующую
информацию:

•  
  • Scope запроса
  • Ограничения Запроса (Query restrictions)
  • Запрос самого себя (Query itself)
  • Имя .HTX файлов

Избегайте нессответствущих hits добавляя шумовые слова (noise words) в WINNTSYSTEM32NOISE.ENU.

Избегайте нежелательных hits в Index
Сервера, создавая отдельные каталоги на каждый виртуальный каталог с
различным содержанием, и сопоставляя отдельные каталоги с
соотвествующими виртуальными серверами.

Имейте отдельные каталоги в установках IS Я знаяю, что документ там, но мой запрос не возвращает этого.

Запросы Index Сервера с нулевыми результатами занимают слишком много времени CPU.

Три шага процессов фильтрации для Index Сервера:

•  
  • Фильтрация Содержания (Content filtering) — Извлекает текст из файла.
  • Разрыв Слова (Word breaking) — Идентифицирует слова в пределах символьного потока.
  • Нормализация (Normalizing) — Удаляет преобразование букв в прописные, пунктуацию, и шумовые слова.

Типы index:

•  
  • Списки Слова (Word lists) — Слова, извлеченные из документа в память во время когда документ фильтруется.
  • Индексы Тени
    (Shadow indexes) — Постоянные (сохраненные на диск, а не в память) —
    созданные слиянием списков слов и другими индексами тени.
  • Главный Индеск
    (Master index) — Постоянный, сильно сжатый; содержит данные индексов
    для большого числа документов, созданных главным слиянием (master
    merge). Слитые индексы тени и текущий главный индекс могут иметь много
    индексов в каталоге.

Подсети (Subnetting)

ODBC Коды Ошибок

Microsoft OLE DB Provider for
ODBC Drivers error «80004005» [Microsoft] [ODBC Microsoft Access
Driver] The Microsoft Jet database engine cannot open file «(unknown)».
It is already opened exclusively by another user, or you need
permission to view its data.

Причина — учетная запись (обычно IUSR) не имеет необходимых разрешений. Проверьте Разрешения NTFS и Share.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005» [Microsoft] [ODBC Microsoft Access 97
Driver] Couldn’t use «(unknown)»; file already in use.

Причина — База данных не может быть блокирована правильно для большого количества пользователей.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005»[Microsoft] [ODBC Driver Manager] Data
source not found and no defaultdriver specified.

Причина — Файл GLOBAL.ASA не
правильно выполняется. Проверьте, что этот файл находится в папке
Application Root для IIS, и что пользователи имеют разрешение Execute
на эту папку.

Microsoft OLE DB Provider for
ODBC Drivers error ‘80004005’ [Microsoft][ODBCAccess 97 ODBC driver
Driver] General error Unable to open registry key’DriverId’.

Причина — Эта ошибка возникает
при чтении значения из реестра. Проверьте разрешения на ключ реестра
используя Редактор Реестра (Regedt32.exe). Вам также понадобится для
использования Windows NT Монитор Реестра (Registry Monitor) для
проверки попыток неудачно прочесть реестр.

Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’ [Microsoft][ODBCDriver Manager] Data source name not ??

Причина — Это появляется в связи
с проблемой какое ПО установлено или удалено с компьютера. Если
основные файлы ODBC становятся несинхронизированными (они должны иметь
одинаковую версию) вы можете увидеть эту ошибку.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005»[Microsoft] [ODBC Microsoft SQL Driver]
[dbnmpntw] ConnectionOpen (create file)

Причина — IIS будет использовать (по умолчанию) учетную запись Windows NT названную IUSR_Имя компьютера.
Эта учетная запись локальна для Web сервера, но по существу неизвестна
для любого компьютера в сети. Когда IIS, оперируя контекстом
безопасности учетной записи IUSR, пытается получить доступ к любому
ресурсу на удаленном компьютере, удаленный компьютер пытается утвердить
используемую учетную запись. Так как учетная запись IUSR — локальная и
не известна для удаленного компьютера, в доступе отказано.

Microsoft OLE DB Provider for ODBC Drivers error «800004005»[Microsoft] [ODBC Microsoft SQL Driver] Logon Failed

Причина — SQL Сервер запретил
доступ учетной записи, пытающейся получить доступ на SQL сервер.
Проверьте что пароли учетных записей SQL и NT совпадают, и что
подключение IIS к SQL серверу назначено на правильное имя пользователя.

Microsoft OLE DB Provider for
ODBC Drivers error ‘80004005’ [Microsoft][ODBC SQL Server Driver][SQL
Server] Login failed- User: Reason: Not defined as a valid user of a
trusted SQL Server connection.

Причина — Встроенная Защита
включена в SQL Enterprise Manager, а учетная запись Windows NT не была
назначена на учетную запись SQL. — Попытайтесь изменить SQL на
использование Standard Security. Если используете IIS 4.0, выключите
«Синхронизация Пароля (Password Synchronization)» для этого проекта.