5

Использование Sql Studio Express (на компьютере с Windows 7-64) для подключения к трем различным серверам Sql Server 2005 с использованием аутентификации Sql Server, я получаю сообщение об ошибке: 1846, состояние: 8. Согласно http://blogs.msdn.com/b/sql_protocols/archive/2006/02/21/536201.aspx, это должно быть несоответствие пароля.

Тем не менее, когда я использую те же имена пользователей и пароли из SQLCMD и из клиентов на основе jdbc, таких как Squirrel, он прекрасно работает для подключения ко всем трем серверам. Я также могу войти в них с компьютера XP с Sql Studio Express, используя те же имена пользователей и пароли. И, конечно же, я четыре раза проверил все обычные вещи, такие как моя блокировка заглавных букв не включена, я не настроен на альтернативной языковой клавиатуре, я действительно набираю одну и ту же вещь в обоих случаях и т.д.

В любом случае, почему я могу получить ошибку несоответствия пароля, если пароль правильный? Может ли это быть как-то связано с различными версиями MDAC на машинах, и если так, есть ли способ вернуть Windows 7 обратно к более старой версии MDAC?

|источник

4 ответа4

3

Я бы попробовал следующие вещи в таком порядке:

Прежде всего я бы попробовал этот IP-адрес 10.19.190.x с именем экземпляра: 10.19.190.x\instance_name, также по имени сервера. Я подозреваю, что это может быть проблема протокола (подробнее об этом ниже), и это может изменить способ подключения.

Во-вторых, это может быть просто ошибка, но поскольку некоторые из них вырезали и вставляли, это может быть просто скрытый персонаж. Я видел эту работу для нескольких человек в сообщениях: после ввода пароля переместите курсор назад к началу поля входа в систему и нажмите Enter / Connect. Вы копируете и вставляете pw?

Есть ли какие-либо программные брандмауэры на пути? Временно отключите их, так как могут использоваться дополнительные порты, которые заблокированы.

Мне также было интересно, если один (SQLCMD vs. Studio) подключается через TCP/IP, а другой по именованным каналам, вызывая сбой безопасности для одного. Я хотел бы проверить диспетчер конфигурации SQL (не Management Studio), чтобы убедиться, что все протоколы включены, и посмотреть, что установлено в качестве предпочтительного протокола. Включите NamedPipes и TCP и установите для "Общая память" значение "включено". Я подозреваю, что это сильно. Ознакомьтесь с этим документом:http://groups.google.com/group/microsoft.public.inetserver.iis.security/browse_thread/thread/68c216b10e7fa70/69aacf4a582ec20c%2369aacf4a582ec20c?pli=1.

Попробуйте снять флажок принудительной политики паролей в свойствах пользователя sa. Я тоже это сильно подозреваю.

Попробуйте запустить эту команду из командной строки:

rundll32.exe keymgr.dll, KRShowKeyMgr

Если есть какие-либо записи, связанные с SQL, удалите их. Попробуйте вручную добавить учетные данные для SQL. Я видел кое-что о Vista (так что я бы предположил, что и Windows 7 тоже) удалял определенные маркеры безопасности, и я мог видеть, что это обходили в командной строке.

Я также попытался бы сбросить пароль sa в SQL и сразу же изменить его. Затем, если учетная запись sa используется для запуска SQL Server, измените пароль в любых службах, связанных с SQL Server, и перезапустите их (я пытаюсь синхронизировать их для соответствия). С этим связаны следующие команды:

    exec sp_password @new = 'sqlpassword', @loginame = 'sa'
    alter login sa
    with password = 'sqlpassword' unlock,
    check_policy = off,
    check_expiration = off

Кроме того, вы рассматривали настройку аудита входа в систему?

http://msdn.microsoft.com/en-us/library/ms175850.aspx

Если ничего из этого не работает, было бы очень полезно увидеть формат, который вы используете для имени сервера, чтобы войти в SLQ Manager, и строку SQLCMD, которую вы используете. Конечно, измените что-нибудь конкретное, кроме имени пользователя "sa". Еще один вопрос: одна среда сервера SQL или несколько?

Я нашел кое-что из этого здесь, но прополз, чтобы найти только то, что, по моему мнению, может иметь отношение к делу: http://blogs.msdn.com/b/sql_protocols/archive/2006/02/21/536201.aspx?PageIndex= 7 # комментарии

|источник
0

Долгий путь, но вы можете проверить, не верный ли пароль, кэшированный Windows.

От доступа к сохраненным именам пользователей и паролям с помощью rundll32.exe :

Апплет «Сохраненные имена пользователей и пароли» позволяет назначать имена пользователей и пароли для использования при аутентификации для служб в доменах, отличных от того, в котором вы в настоящий момент вошли.

Обычный способ запуска этого апплета может быть трудно найти быстро, поэтому вот способ запустить его с помощью ярлыка на рабочем столе с помощью программы rundll32.exe:

Нажмите START - RUN и введите следующее (затем нажмите ENTER):

rundll32.exe keymgr.dll, KRShowKeyMgr

После этого вы должны выйти, а затем снова войти.

|источник
0

Вы можете попытаться взять установочный носитель SQL Server и установить соответствующую SQL Management Studio на компьютер с Windows 7 и посмотреть, будет ли это работать лучше.

|источник
0

Попробуйте использовать командную строку для сброса утерянного пароля. Я использовал его, чтобы успешно сбросить утерянный пароль на SQL Server 2000/2005.

  1. Откройте командную строку (Пуск -> Выполнить -> cmd)

  2. Введите следующие команды и нажмите Enter после каждой строки:

    Osql –S yourservername –E
EXEC sp_password NULL, 'yourpassword', 'sa'
GO
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .