SQL Server 2008 «Недопустимый ИД пользователя» на стороне сервера (ошибка 18456, уровень серьезности: 14, состояние: 5) - PullRequest
Новая
       21

SQL Server 2008 «Недопустимый ИД пользователя» на стороне сервера (ошибка 18456, уровень серьезности: 14, состояние: 5)

1 голос
/ 04 декабря 2010

ошибка

Администраторы базы данных сообщают об ошибке Microsoft SQL Server 2008 на стороне сервера «Неверный логин» (ошибка 18456, уровень серьезности: 14, состояние: 5).

Примеры ошибок из журнала сервера: 

Dec 1 2010 10:12AM - Login failed for user '{Active Directory Name #1}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #1}]
Dec 1 2010 10:44AM - Login failed for user '{Active Directory Name #2}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #2}]
Dec 1 2010 2:03PM - Login failed for user '{Active Directory Name #3}'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #3}]
Dec 1 2010 4:18PM - Login failed for user 'Admin'. Reason: Could not find a login matching the name provided. [CLIENT: {IP Address #1}]

{Имя Active Directory} совпадает с их именем для входа без домена. Например, полное имя будет {домен} \ {имя Active Directory}.

Ошибка для пользователя «Администратор» происходит с того же IP-адреса, что и {Имя Active Directory # 1}, пользователя, разрабатывающего код Microsoft Access Visual Basic для приложений (VBA); Я подозреваю, что это связано с необходимостью настроить его минимальное использование VBA с правильной строкой подключения для проверки подлинности Windows, даже если он получает доступ к данным только через канал DSN ODBC.

Окружающая среда

База данных Microsoft Access 2003 (веб-интерфейс), содержащая ODBC-файл DSN-ссылки на таблицы в базе данных Microsoft SQL Server 2008 (бэкэнд), доступной только для чтения.

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

Конечные пользователи входят в свои ПК с учетными записями Active Directory, открывают базу данных внешнего интерфейса, а затем используют Microsoft Access Query Designer для создания отчетов, используя ссылки на таблицы в базе данных внутреннего интерфейса. База данных внешнего интерфейса не использует Microsoft Access Jet Security (насколько мне известно - нет запроса на вход в систему).

База данных внешнего интерфейса сообщает об отсутствии (видимых) ошибок и дает ожидаемые результаты.

DSN-содержимое файла ODBC 

[ODBC]
DRIVER=SQL Server
Trusted_Connection=Yes
StatsLogFile={path}
StatsLog_On=Yes
DATABASE={dbname}
APP=Microsoft Data Access Components
Description={general description}
SERVER={server name}

Почему ссылки Файлового DSN будут работать без ошибок, но при этом генерируется ошибка неверного входа в систему на стороне сервера? Спасибо.

Ответы [ 2 ]

1 голос
/ 04 декабря 2010

Есть ли вероятность того, что конечные пользователи видят кэшированные данные?SQL Server настроен для разрешения удаленных подключений?Учетные записи AD настроены как учетные записи, а также как уполномоченные пользователи в соответствующей базе данных?При тестировании соединения ODBC через менеджер ODBC вы получаете успешное соединение?Успешная проверка соединения выдает ошибку?Находятся ли внутренняя база данных и внешнее приложение в одном домене?Если нет, существует ли настройка доверия домена?(Если нет, то вам, скорее всего, придется использовать логины SQL и AD)

Это все типы вещей, которые я обычно выполняю, чтобы попытаться устранить проблему такого типа.

0 голосов
/ 15 ноября 2011

Источником проблемы является недокументированное (?) Ограничение Microsoft Access в 255 символов в строке подключения ODBC.

Каждая таблица Microsoft Access, связанная с ODBC, была создана с файлом DSN, содержащим строку«Trusted_Connection = Да».

Предположительно, это говорит Microsoft Access об использовании аутентификации Windows.

Однако, при двойной проверке одной из таблиц, связанных с ODBC, я заметил, что текст «Trusted_Connection = Yes» выходит за пределы первых 255символы текста.Я вижу, что это там, используя VBA Immediate Window и запуская команду

print CurrentDb.TableDefs ("{table}"). Connect

, но при этом печатается только 271 символ, а не полныйстрока.Однако последние 10 символов:

Trusted_Co

Повторное связывание таблиц с файлом DSN, содержащим строку Trusted_Connection = Yes в первых 255 символах, решило проблему.

Спасибо.

...