2015-06-03 4 views
0

После того, как в следующем месяце появились данные о завершении срока службы Windows 2003, я переношу устаревшее приложение в Windows 2008. Все это произошло неожиданно гладко, за исключением нашего подключения к Услуги индексирования.Не удалось выполнить запрос к службам индексирования с помощью пользователя проверки подлинности SQL

У нас есть два сервера, сервер БД, работающий под управлением SQL 2008 и веб-сервер. Наше веб-приложение позволяет пользователям искать хранилище документов. Вот процесс:

  1. Типы пользователей в запросе к веб-приложению
  2. Веб-приложение отправляет запрос на сервер базы данных
  3. Запрос ссылается на веб-приложения в качестве связанного сервера базы данных и загружает извлекаемые пути в временная таблица
  4. сервер баз данных объединяет эти пути против другой таблицы на сервере SQL
  5. сервер базы данных передает результаты обратно в веб-приложение
  6. веб Applicati on показывает результаты для пользователя.

Веб-приложение входит в с помощью проверки подлинности SQL на сервер БД, чтобы выполнить запрос, но он терпит неудачу с этой ошибкой:

An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".

отображается Та же ошибка при попытке выполнить запрос, если вошли в систему под именем этого пользователя на сервере БД через SSMS, но с некоторой дополнительной информации:

OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Invalid catalog name 'MYCATALOG'. SQLSTATE=42000 ".

Msg 7399, Level 16, State 1, Line 1

The OLE DB provider "MSIDXS" for linked server "Filesystem" reported an error.

Access denied.

Msg 7321, Level 16, State 2, Line 1

An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".

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

OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Unspecified error".

OLE DB provider "MSIDXS" for linked server "Filesystem" returned message "Invalid catalog name 'MYCATALOG'. SQLSTATE=42000 ".

Msg 7321, Level 16, State 2, Line 1 An error occurred while preparing the query "SELECT PATH FROM "10.0.1.89".MyCatalog..SCOPE('DEEP TRAVERSAL OF "C:\Documents"') WHERE (FREETEXT(Contents, 'introduction')) OR (FREETEXT(FileName, 'introduction'))" for execution against OLE DB provider "MSIDXS" for linked server "Filesystem".

Я создал связанный сервер с этот запрос, который появляется, чтобы соответствовать конфигурации прежней системы:

EXEC sp_addlinkedserver FileSystem, 'Index Server', 'MSIDXS', 'Web'; 
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname = N'FileSystem', @locallogin = NULL, @useself = N'False', @rmtuser = N'CatalogUser', @rmtpassword = N'xxx'; 

Я создал пользователя на веб-сервере с именем CatalogUser, и я установил свой пароль, чтобы быть таким же, как выше запроса.

Однако, когда я подключаюсь к проверке подлинности Windows, эта информация игнорируется, и вместо этого используются данные проверки подлинности Windows. Если я изменю пароль на что-либо, запрос все равно будет успешным.

Я попытался включить CatalogUser для входа в систему как служебную учетную запись, и это не повлияло.

Эти две машины не входят в домен, но ни одна из двух машин Windows 2003 не работает, и это работает совершенно нормально.

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

Информации об этой проблеме в Интернете не так много, по-видимому, из-за возраста программного обеспечения, поэтому, по крайней мере, мы можем начать создавать базу знаний здесь. Я задаюсь вопросом, есть ли у большего количества людей проблемы с этим программным обеспечением, а конец жизни на горизонте.

ответ

0

Теперь я решил эту проблему. Я не знал этого, но когда вы запускаете программу под NT AUTHORITY\LOCAL SYSTEM, она будет аутентифицироваться по сети как анонимный пользователь.

Чтобы решить эту проблему, я создал нового пользователя SqlServer как на веб-сервере, так и на сервере БД с тем же паролем. Затем я сконфигурировал экземпляр SQL Server для работы под этим новым пользователем и начал правильно аутентифицироваться.

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