Failed to get data for authentication windows value
Debug Windows authentication errors
When using Windows authentication as a security mechanism, the Security Support Provider Interface (SSPI) handles security processes. When security errors occur at the SSPI layer, they are surfaced by Windows Communication Foundation (WCF). This topic provides a framework and set of questions to help diagnose the errors.
For an overview of the Kerberos protocol, see Kerberos Explained; for an overview of SSPI, see SSPI.
For Windows authentication, WCF typically uses the Negotiate Security Support Provider (SSP), which performs Kerberos mutual authentication between the client and service. If the Kerberos protocol is not available, by default WCF falls back to NT LAN Manager (NTLM). However, you can configure WCF to use only the Kerberos protocol (and to throw an exception if Kerberos is not available). You can also configure WCF to use restricted forms of the Kerberos protocol.
Debugging Methodology
The basic method is as follows:
Determine whether you are using Windows authentication. If you are using any other scheme, this topic does not apply.
If you are sure you are using Windows authentication, determine whether your WCF configuration uses Kerberos direct or Negotiate.
Once you have determined whether your configuration is using the Kerberos protocol or NTLM, you can understand error messages in the correct context.
Availability of the Kerberos Protocol and NTLM
The Kerberos SSP requires a domain controller to act as the Kerberos Key Distribution Center (KDC). The Kerberos protocol is available only when both the client and service are using domain identities. In other account combinations, NTLM is used, as summarized in the following table.
The table headers show possible account types used by the server. The left column shows possible account types used by the client.
| Local User | Local System | Domain User | Domain Machine | |
|---|---|---|---|---|
| Local User | NTLM | NTLM | NTLM | NTLM |
| Local System | Anonymous NTLM | Anonymous NTLM | Anonymous NTLM | Anonymous NTLM |
| Domain User | NTLM | NTLM | Kerberos | Kerberos |
| Domain Machine | NTLM | NTLM | Kerberos | Kerberos |
Specifically, the four account types include:
Local System: The built-in account SYSTEM on a machine that is not joined to a domain.
The service credential is captured when the Open method of the ServiceHost class is called. The client credential is read whenever the client sends a message.
Common Windows Authentication Problems
This section discusses some common Windows authentication problems and possible remedies.
Kerberos Protocol
SPN/UPN Problems with the Kerberos Protocol
When using Windows authentication, and the Kerberos protocol is used or negotiated by SSPI, the URL the client endpoint uses must include the fully qualified domain name of the service’s host inside the service URL. This assumes that the account under which the service is running has access to the machine (default) service principal name (SPN) key that is created when the computer is added to the Active Directory domain, which is most commonly done by running the service under the Network Service account. If the service does not have access to the machine SPN key, you must supply the correct SPN or user principal name (UPN) of the account under which the service is running in the client’s endpoint identity. For more information about how WCF works with SPN and UPN, see Service Identity and Authentication.
In load-balancing scenarios, such as Web farms or Web gardens, a common practice is to define a unique account for each application, assign an SPN to that account, and ensure that all of the application’s services run in that account.
To obtain an SPN for your service’s account, you need to be an Active Directory domain administrator. For more information, see Kerberos Technical Supplement for Windows.
Kerberos Protocol Direct Requires the Service to Run Under a Domain Machine Account
To remedy, run the service using a Domain Machine account, such as Network Service, on a domain joined machine.
Delegation Requires Credential Negotiation
To use the Kerberos authentication protocol with delegation, you must implement the Kerberos protocol with credential negotiation (sometimes called «multi-leg» or «multi-step» Kerberos). If you implement Kerberos authentication without credential negotiation (sometimes called «one-shot» or «single-leg» Kerberos), an exception will be thrown.
To implement Kerberos with credential negotiation, do the following steps:
Require SSPI negotiation:
Require the SSPI negotiation to use Kerberos by disallowing the use of NTLM:
Do this in code, with the following statement: ChannelFactory.Credentials.Windows.AllowNtlm = false
NTLM Protocol
Negotiate SSP Falls Back to NTLM, but NTLM Is Disabled
The following shows how to disable fallback to NTLM.
NTLM Logon Fails
The client credentials are not valid on the service. Check that the user name and password are correctly set and correspond to an account that is known to the computer where the service is running. NTLM uses the specified credentials to log on to the service’s computer. While the credentials may be valid on the computer where the client is running, this logon will fail if the credentials are not valid on the service’s computer.
Anonymous NTLM Logon Occurs, but Anonymous Logons Are Disabled by Default
The following client code attempts to enable anonymous logons (note that the default property is Identification ).
The following service code changes the default to enable anonymous logons by the server.
For more information about impersonation, see Delegation and Impersonation.
Alternatively, the client is running as a Windows service, using the built-in account SYSTEM.
Other Problems
Client Credentials Are Not Set Correctly
Windows authentication uses the WindowsClientCredential instance returned by the ClientCredentials property of the ClientBase class, not the UserNamePasswordClientCredential. The following shows an incorrect example.
The following shows the correct example.
SSPI Is Not Available
The following operating systems do not support Windows authentication when used as a server: Windows XP Home Edition, Windows XP Media Center Edition, and Windows Vista Home editions.
Developing and Deploying with Different Identities
If you develop your application on one machine, and deploy on another, and use different account types to authenticate on each machine, you may experience different behavior. For example, suppose you develop your application on a Windows XP Pro machine using the SSPI Negotiated authentication mode. If you use a local user account to authenticate with, then NTLM protocol will be used. Once the application is developed, you deploy the service to a Windows Server 2003 machine where it runs under a domain account. At this point, the client will not be able to authenticate the service because it will be using Kerberos and a domain controller.
Failed to get data for authentication windows value
Вопрос
I am running SQL Server 2008 SP1. My windows event log is filling up with the error «Login failed for user ». Reason: an attempt to login using SQL authentication failed. Server is configured for Windows authentication only.» This server is definitely configured for mixed mode authentication. The service has been restarted and yet this error keeps popping up every 40 seconds or so. What am I missing?
Ответы
Thanks to everyone who responded. Turns out there was an application running on the server that was failing to log in. This application wasn’t actively being used by anyone and after I turned off the services associated with the application, the error stopped.
Все ответы
Can we test a single connection using SQL authentication and If still persist, you have to double check that credential if it is still trying to connect SQ Server and identify if it is hitting the same DB on the same server or other DBs since I do think this errors is related to other DBs
Kindly work out it and please let know me your feedback
Shehap (DB Consultant/DB Architect) Think More deeply of DB Stress Stabilities
Please identigy the login that you are getting the issue. Most prob its becuase of SPN (or) Kerbros authentication issue from AD level. Please check with your AD engineers.
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue 🙂
Can you please go back and check if the server has definitely been configured for sql and windows autentication mode(mixed mode) in the server properties—>security tab. If not make it sql and windows authentication and restart sql.
My windows event log is filling up with the error «Login failed for user ». Reason: an attempt to login using SQL authentication failed.
1,First can you please check what is the Authentication mode set for the SQL server Database engine?
2.Any database has been dropped and associated login is trying to connect from the application?
3.Can you paste the errorlog completely because the each login failed will have severity and state.. hence can you please paste the error log here.
Here is the complete error log:
Event Type: Failure Audit
Event Source: MSSQL$EPM
Event Category: Logon
Event ID: 18456
Date: 7/3/2012
Time: 5:39:52 AM
User: N/A
Computer: TETTNANG
Description:
Login failed for user ». Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: 10.28.0.117]
As far as I know, no databases have been dropped and the database engine is definitely set to mixed mode authentication.
Отключение NTLM аутентификации в домене Windows
NTLM (NT LAN Manager) – это довольно старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим особенности процесс отключения протокола NTLMv1 и NTLMv2, и перехода на Kerberos в домене Active Directory.
Основные проблема NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA, который может извлечь различными утилитами (типа mimikatz) и использовать хэш для дальнейших атак, отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.
Часть этих недостатков исправлена в более новой версии NTLMv2, который использует более криптостойкие алгоритмы шифрования и позволяет предотвратить популярные атаки на NTLM. Начиная с Windows 7 / Windows Server 2008 R2 использование NTLMv1 и LM для авторизации по умолчанию выключено.
Переключаемся на использование NTLMv2
Если вы задумались полностью отказаться от NTLM в своем домене, сначала нужно убедиться, что у вас не используется его более уязвимая версия- NTLMv1. Вероятно в вашей сети имеется ряд устаревших устройств или служб, которые все еще используют аутентификацию NTLMv1 вместо NTLMv2 (или Kerberos). Поэтому прежде, чем прибегнуть к его полному отключению прочитайте раздел этой статьи по аудиту событий авторизации с помощью NTLM.
В первую очередь администратору домена нужно убедиться, что в его сети запрещено использовать NTLM или LM для авторизации, т.к. в некоторых случаях атакующий может с помощью специальных запросов получить ответ на NTLM/LM запрос.
Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).
В настройках политики есть 6 опций:
Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.
Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.
Также вы можете отключить NTLMv1 через реестр. Для этого в ветке
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».
Не забудьте применить эту политику для контроллеров домена.
Если вы убедились, что у вас не используется NTLMv1, вы можете пойти дальше и попытаться отказаться от NTLMv2. NTLMv2 хотя и более защищенный протокол аутентификации, но все равно существенно проигрывает Kerberos в плане безопасности (хотя уязвимостей в NTLMv2 намного меньше, чем в первой версии протокола, все-таки существуют возможности перехвата и повторного использования данных, и отсутствует взаимная аутентификации).
Главная риск отключения NTLM – возможное использование в домене устаревших или некорректно настроенных приложений, которые все еще могут использовать проверку подлинности NTLM, и для перехода на Kerberos их придется обновлять или настраивать особым образом.
Аудит событий NTLM аутентификации в домене
Перед полным отключением NTLM в домене и переходе на Kerberos желательно убедиться, что в домене не осталось приложений, которые требуют и используют NTLM авторизацию.
Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.
Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.
Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.
Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.
Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:
После того, как вы нашли пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для работы Kerberos авторизации (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.
Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.
Полное отключение NTLM в домене Active Directory
Чтобы проверить, как будет работать аутентификация в различных приложениях в домене без использования NTLM, вы можете добавить учетные записи необходимых пользователей в доменную группу
Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.
Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.
В этой политике доступно 5 опций:
Failed to get data for authentication windows value
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
I am running SQL Server 2008 SP1. My windows event log is filling up with the error «Login failed for user ». Reason: an attempt to login using SQL authentication failed. Server is configured for Windows authentication only.» This server is definitely configured for mixed mode authentication. The service has been restarted and yet this error keeps popping up every 40 seconds or so. What am I missing?
Answers
Thanks to everyone who responded. Turns out there was an application running on the server that was failing to log in. This application wasn’t actively being used by anyone and after I turned off the services associated with the application, the error stopped.
All replies
Can we test a single connection using SQL authentication and If still persist, you have to double check that credential if it is still trying to connect SQ Server and identify if it is hitting the same DB on the same server or other DBs since I do think this errors is related to other DBs
Kindly work out it and please let know me your feedback
Shehap (DB Consultant/DB Architect) Think More deeply of DB Stress Stabilities
Please identigy the login that you are getting the issue. Most prob its becuase of SPN (or) Kerbros authentication issue from AD level. Please check with your AD engineers.
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue 🙂
Can you please go back and check if the server has definitely been configured for sql and windows autentication mode(mixed mode) in the server properties—>security tab. If not make it sql and windows authentication and restart sql.
My windows event log is filling up with the error «Login failed for user ». Reason: an attempt to login using SQL authentication failed.
1,First can you please check what is the Authentication mode set for the SQL server Database engine?
2.Any database has been dropped and associated login is trying to connect from the application?
3.Can you paste the errorlog completely because the each login failed will have severity and state.. hence can you please paste the error log here.
Here is the complete error log:
Event Type: Failure Audit
Event Source: MSSQL$EPM
Event Category: Logon
Event ID: 18456
Date: 7/3/2012
Time: 5:39:52 AM
User: N/A
Computer: TETTNANG
Description:
Login failed for user ». Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: 10.28.0.117]
As far as I know, no databases have been dropped and the database engine is definitely set to mixed mode authentication.
Устранение неполадок при соединении с ядром СУБД SQL Server. Troubleshoot connecting to the SQL Server Database Engine
В этой статье описаны методы поиска и устранения неполадок, при которых не удается подключиться к экземпляру ядра СУБД SQL Server на отдельном сервере. This article lists troubleshooting techniques to use when you can’t connect to an instance of the SQL Server Database Engine on a single server.
Для других сценариев см. такие материалы: For other scenarios, see:
Эти инструкции не входят в процедуры решения наиболее вероятных проблем, так как, скорее всего, вы уже пробовали выполнить эти процедуры. These steps aren’t in the order of the most likely problems which you probably already tried. Сначала указываются шаги по устранению базовых ошибок, а затем рассматриваются более сложные вопросы. These steps are in order of the most basic problems to more complex problems. При выполнении этих действий предполагается, что вы подключаетесь к экземпляру SQL Server с другого компьютера по протоколу TCP/IP, так как этот вариант является наиболее распространенным. These steps assume that you’re connecting to SQL Server instance from another computer by using the TCP/IP protocol, which is the most common situation.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.
Эта ошибка обычно означает, что клиенту не удается найти экземпляр SQL Server. This error usually means that the client can’t find the SQL Server instance. Обычно это происходит при наличии хотя бы одной из следующих проблем: This normally happens when at least one of the following problems exists:
Интерактивную страницу по устранению неполадок можно найти на сайте службы технической поддержки Microsoft Microsoft на странице Solving Connectivity errors to SQL Server (Устранение ошибок подключения к SQL Server). An interactive troubleshooting page is available from Microsoft Microsoft Customer Support Services at Solving Connectivity errors to SQL Server.
Ошибки, не описанные в статье Not included
Получение имени экземпляра из диспетчера конфигурации Get instance name from Configuration Manger
На сервере, на котором размещен экземпляр SQL Server, проверьте имя экземпляра. On the server that hosts the SQL Server instance, verify the instance name. Используйте диспетчер конфигурации SQL Server. Use SQL Server Configuration Manager.
Диспетчер конфигурации автоматически устанавливается на компьютер при установке SQL Server. Configuration Manager is automatically installed on the computer when SQL Server is installed. Инструкции по запуску диспетчера конфигурации могут незначительно отличаться в зависимости от версии SQL Server и Windows. Instructions on starting Configuration Manager vary slightly by version of SQL Server and Windows. Подробные сведения об определенных версиях см. в статье Диспетчер конфигурации SQL Server. For version-specific details, see SQL Server Configuration Manager.)
Войдите на компьютер, на котором размещен экземпляр SQL Server. Sign in to the computer hosting the instance of SQL Server.
Запустите диспетчер конфигурации SQL Server. Start SQL Server Configuration Manager.
На левой панели выберите Службы SQL Server. In the left pane, select SQL Server Services.
На правой панели проверьте имя экземпляра ядра СУБД. In the right pane, verify the name of the instance of the database engine.
Проверить, выполняется ли экземпляр, позволяет значок около экземпляра SQL Server в диспетчере конфигурации. To verify that the instance is running, in Configuration Manager look at the symbol by the SQL Server instance.
Если экземпляр остановлен, щелкните его правой кнопкой мыши и выберите команду Запустить. If the instance is stopped, right-click the instance and then click Start. Экземпляр будет запущен, и красный квадрат поменяется на зеленую стрелку. The server instance starts, and the indicator becomes a green arrow.
Чтобы подключиться к именованному экземпляру, нужно запустить службу обозревателя SQL Server. To connect to a named instance, SQL Server Browser service must be running. В диспетчере конфигурации найдите службу Обозреватель SQL Server и проверьте, запущена ли она. In Configuration Manager, locate SQL Server Browser service and verify that it’s running. Если она не работает, запустите ее. If it’sn’t running, start it. Служба обозревателя SQL Server не требуется для экземпляров по умолчанию. SQL Server Browser service isn’t required for default instances.
Экземпляр SQL Server по умолчанию не требует службы «Обозреватель SQL Server». A default instance of SQL Server doesn’t require SQL Server Browser service.
Тестирование локального подключения Testing a local connection
Перед устранением неполадки, связанной с подключением с другого компьютера, нужно проверить возможность подключения из клиентского приложения, установленного локально на компьютере, на котором запущен SQL Server. Before troubleshooting a connection problem from another computer, first test your ability to connect from a client application installed locally on the computer that is running SQL Server. Локальное подключение позволяет избежать проблем, связанных с сетями и брандмауэрами. Connecting locally avoids issues with networks and firewalls.
Войдите на компьютер, на котором установлен SQL Server, с помощью имени входа с разрешением на доступ к SQL Server. Sign in to the computer where SQL Server is installed, using a login that has permission to access SQL Server. (Во время установки для SQL Server требуется задать по меньшей мере одно имя входа в качестве администратора SQL Server. (During installation, SQL Server requires at least one login to be specified as a SQL Server Administrator. Если администратор неизвестен, см. сведения в статье Подключение к SQL Server в случае, если доступ системных администраторов заблокирован.) If you don’t know an administrator, see Connect to SQL Server When System Administrators Are Locked Out.)
На начальной странице введите SQL Server Management Studio. В более старых версиях Windows в меню «Пуск» выберите Все программы, Microsoft SQL Server, а затем щелкните SQL Server Management Studio. On the Start page, type SQL Server Management Studio, or on older versions of Windows on the Start menu, point to All Programs, point to Microsoft SQL Server, and then click SQL Server Management Studio.
В диалоговом окне Соединение с сервером в списке Тип сервера выберите Ядро СУБД. In the Connect to Server dialog box, in the Server type box, select Database Engine. В поле Проверка подлинности выберите Проверка подлинности Windows. In the Authentication box, select Windows Authentication. В поле Имя сервера задайте один из следующих типов подключения: In the Server name box, type one of the following connection types:
| Подключение к Connecting to | Тип Type | Пример Example |
|---|---|---|
| Экземпляр по умолчанию Default instance | ACCNT27 | |
| Именованный экземпляр Named Instance | ACCNT27\PAYROLL |
При подключении к SQL Server из клиентского приложения на том же компьютере используется протокол общей памяти. When connecting to a SQL Server from a client application on the same computer, the shared memory protocol is used. Общая память — это тип локального именованного канала, поэтому иногда возникают ошибки, связанные с каналами. Shared memory is a type of local named pipe, so sometimes errors regarding pipes are encountered.
Если на этом этапе происходит ошибка, ее необходимо устранить перед продолжением работы. If you receive an error at this point, you need have to resolve it before proceeding. Существует целый ряд потенциальных проблем. There are many possible things that could be a problem. Имя входа может не иметь разрешений для подключения. Your login might not be authorized to connect. Может отсутствовать база данных по умолчанию. Your default database might be missing.
В некоторых сообщениях об ошибках, передаваемых клиенту, намеренно не приведены достаточные сведения для устранения неполадок. Some error messages passed to the client intentionally don’t give enough information to troubleshoot the problem. Это связано с обеспечением безопасности, так как в этом случае злоумышленник не может получить данные о SQL Server. This is a security feature to avoid providing an attacker with information about SQL Server. Чтобы просмотреть полные сведения об ошибке, обратитесь к журналу ошибок SQL Server. To view the complete information about the error, look in the SQL Server error log. Там вы найдете все подробности. The details are provided there.
Если соединение устанавливается с помощью общей памяти, проверьте его с использованием TCP. If you can connect using shared memory, test connecting using TCP. Вы можете принудительно задать TCP-подключение, указав tcp: перед именем. You can force a TCP connection by specifying tcp: before the name. Пример: For example:
| Подключение к Connecting to: | Тип: Type: | Пример Example: |
|---|---|---|
| Экземпляр по умолчанию Default instance | tcp: | tcp:ACCNT27 |
| Именованный экземпляр Named Instance | tcp: | tcp:ACCNT27\PAYROLL |
Если соединение устанавливается с помощью общей памяти, но не TCP, необходимо устранить проблему с TCP. If you can connect with shared memory but not TCP, then you must fix the TCP problem. Скорее всего, проблема в том, что TCP-протокол отключен. The most likely issue is that TCP isn’t enabled. Сведения о включении TCP см. в разделе Включение протоколов выше. To enable TCP, See the Enable protocols steps above.
Если вы хотите установить соединение с использованием учетной записи, отличной от учетной записи администратора, после соединения с правами администратора повторите попытку, используя имя входа для проверки подлинности Windows или имя входа для проверки подлинности SQL Server, которое использует клиентское приложение. If your goal is to connect with an account other than an administrator account, once you can connect as an administrator, try the connection again using the Windows Authentication login or the SQL Server Authentication login that the client application is using.
Получение IP-адреса сервера Get the IP address of the server
Получите IP-адрес компьютера, на котором размещен экземпляр SQL Server. Get the IP Address of the computer hosting the instance of SQL Server.
Получение данных о номере TCP-порта для экземпляра SQL Server Get the SQL Server instance TCP port
В большинстве случаев соединение с ядром СУБД SQL Server с другого компьютера устанавливается по протоколу TCP. In most cases, you connect to the Database Engine from another computer using the TCP protocol.
Включение протоколов Enable protocols
В некоторых установках SQL Server соединение с компонентом Database Engine с другого компьютера по умолчанию отключено, если администратор не включил его с помощью диспетчера конфигурации. In some installations of SQL Server, connecting to the Database Engine from another computer isn’t enabled unless an administrator uses Configuration Manager to enable it. Чтобы разрешить соединения с других компьютеров, нужно выполнить указанные ниже действия. To enable connections from another computer:
Тестирование подключения TCP/IP Testing TCP/IP connectivity
В меню «Пуск» щелкните Выполнить. On the Start menu, click Run. В окне Выполнить введите cmd, а затем нажмите кнопку ОК. In the Run window type cmd, and then click OK.
В окне командной строки введите ping и IP-адрес компьютера, на котором запущен SQL Server. In the command prompt window, type ping and then the IP address of the computer that is running SQL Server. Пример: For example:
Открытие порта в брандмауэре Open a port in the firewall
По умолчанию брандмауэр Windows включен и блокирует подключения с других компьютеров. By default, the Windows firewall is turned on and blocks the connections from another computer. Чтобы подключиться с использованием протокола TCP/IP с другого компьютера, на компьютере SQL Server необходимо настроить брандмауэр для разрешения подключений к TCP-порту, используемому компонентом Database Engine. To connect using TCP/IP from another computer, on the SQL Server computer you must configure the firewall to allow connections to the TCP port used by the Database Engine. Экземпляр по умолчанию прослушивает по умолчанию TCP-порт 1433. The default instance is listening on TCP port 1433, by default. Если запущены именованные экземпляры или вы изменили значение по умолчанию, TCP-порт SQL Server SQL Server может прослушивать другой порт. If you have named instances or if you changed the default instance port, the SQL Server SQL Server TCP port may be listening on another port. См. раздел Получение данных о номере TCP-порта для экземпляра SQL Server. See Get the SQL Server instance TCP port.
При подключении к именованному экземпляру или порту, отличному от TCP-порта 1433, необходимо также открыть UDP-порт 1434 для службы обозревателя SQL Server. If you’re connecting to a named instance or a port other than TCP port 1433, you must also open the UDP port 1434 for the SQL Server Browser service. Пошаговые инструкции по открытию портов в брандмауэре Windows см. в статье Настройка брандмауэра Windows для доступа к компоненту Database Engine. For step-by-step instruction on opening a port in the Windows firewall, see Configure a Windows Firewall for Database Engine Access.
Проверка подключения Test the connection
После того как появилась возможность соединения с использованием TCP на том же компьютере, нужно проверить подключение с клиентского компьютера. Once you can connect using TCP on the same computer, it’s time to try connecting from the client computer. Теоретически можно использовать любое клиентское приложение, но чтобы избежать дополнительных сложностей, установите средства управления SQL Server на клиентском компьютере и попытайтесь запустить среду SQL Server Management Studio. You could theoretically use any client application, but to avoid additional complexity, install the SQL Server Management tools on the client and make the attempt using SQL Server Management Studio.
Обе эти проблемы связаны со службой обозревателя SQL Server, которая предоставляет клиенту номер порта. Both of these problems are related to the SQL Server Browser service, which provides the port number to the client. Далее приводятся возможные решения. The solutions are: