FTS Security Issue

Hi,
FTS will not populate the catalogs. 0 Items.
I have a new installation W2003 with SQL2K Sp3.
The SQL Server is running with a high security configuration.
All the SQL services are running under an account Domain\SQLService which is a plain old user in the domain and on the SQL Server box.
The local system account was chosen during installation. I changed to the domain user via the Enterprise Manager after the fact. SQL Server and SQL Agent run fine. BUILTIN\Administrators has been removed.
I saw a post that said changing the service account from one account and back to the original should fix the problem. It did not. I see "Login failed for NT AUTHORITY\SYSTEM" in the SQL Error Log when I try to build the catalog. I checked the account th
at is running MS Search in the Services dialog and it is still Local System. When I changed accounts on SQL Server, I changed it to myself a local admin and then back to the Domain\SQLService account. I tried changing the MS Search account via the Service
s dialog to Domain\SQLService account and now it will not start. Domain\SQLService has full control on the FTDATA directory. Any other directories or registery keys that perhaps Domain\SQLService needs access to, but is not being set?
Thanks,
Norman
Follow up...
Here are some messages from the event log:
12:14:21 PMSearch Service 7052The Search service has loaded project <SQLServer SQL0002000005>.
12:14:19 PMIndexer 7070The Search service has added project <SQL0002000005>.
12:14:19 PMIndexer 7071The Search service has removed project <SQL0002000005>.
12:14:19 PMIndexer 7042Project <SQLServer SQL0002000005> has been shut down as requested by user.
12:14:05 PMIndexer 7045The catalog was not propagated, because no new files were detected for the project <SQLServer SQL0002000005>.
12:14:05 PMGatherer 3018The end of crawl for project <SQLServer SQL0002000005> has been detected. The Gatherer successfully processed 0 documents totaling 0K. It failed to filter 1 documents. 0 URLs could not be reached or were denied access.
12:14:05 PMGatherer 3024The crawl for project <SQLServer SQL0002000005> could not be started, because no crawl seeds could be accessed. Fix the errors and try the crawl again.
12:14:05 PMGatherer 3036The crawl seed <MSSQL75://SQLServer/37fa4c37> in project <SQLServer SQL0002000005> cannot be accessed. Error: 800700e9 - No process is on the other end of the pipe. .
12:14:04 PMGatherer 3019The crawl on project <SQLServer SQL0002000005> has started.
|||Norman,
The MSSearch service requires that either the BUILTIN\Administrators login
be present or that [NT Authority\System] localsystem login have the below
rights and this is why you are seeing ("Login failed for NT
AUTHORITY\SYSTEM" ) after removing the BUILTIN\Administrators login:
exec sp_grantlogin N'NT Authority\System'
exec sp_defaultdb N'NT Authority\System', N'master'
exec sp_defaultlanguage N'NT Authority\System','us_english'
exec sp_addsrvrolemember N'NT Authority\System', sysadmin
See also KB article Q263712 "INF: How To Prevent Windows NT Administrators
From Administering a Clustered SQL Server"
at http://support.microsoft.com/default...;EN-US;q263712 for more
info.
Regards,
John
"Norman" <anonymous@.discussions.microsoft.com> wrote in message
news:C6CE845A-0975-4801-8B0B-5B02D848F336@.microsoft.com...
> Follow up...
> Here are some messages from the event log:
> 12:14:21 PM Search Service 7052 The Search service has loaded project
<SQLServer SQL0002000005>.
> 12:14:19 PM Indexer 7070 The Search service has added project
<SQL0002000005>.
> 12:14:19 PM Indexer 7071 The Search service has removed project
<SQL0002000005>.
> 12:14:19 PM Indexer 7042 Project <SQLServer SQL0002000005> has been shut
down as requested by user.
> 12:14:05 PM Indexer 7045 The catalog was not propagated, because no new
files were detected for the project <SQLServer SQL0002000005>.
> 12:14:05 PM Gatherer 3018 The end of crawl for project <SQLServer
SQL0002000005> has been detected. The Gatherer successfully processed 0
documents totaling 0K. It failed to filter 1 documents. 0 URLs could not be
reached or were denied access.
> 12:14:05 PM Gatherer 3024 The crawl for project <SQLServer SQL0002000005>
could not be started, because no crawl seeds could be accessed. Fix the
errors and try the crawl again.
> 12:14:05 PM Gatherer 3036 The crawl seed <MSSQL75://SQLServer/37fa4c37> in
project <SQLServer SQL0002000005> cannot be accessed. Error: 800700e9 - No
process is on the other end of the pipe. .
> 12:14:04 PM Gatherer 3019 The crawl on project <SQLServer SQL0002000005>
has started.
>
|||John,
No kudos to Microsoft for the high level security requiements for MS Search and not providing a KB with a work around for highly secure environments.
FYI:
Even though I found posts that indicate the contrary, the MS Search service remains Local System Account regardless of which account you put in the the SQL Service or SQL Agent at installation or after the fact via the Enterprise Manager. I tried it on se
veral SQL Server installations on W2K and W2003.
My compromise solution was to create a domain account specifically for the MS Search service and make it local admin and sa in the SQL Server. This seems to function correctly for all the test I have tried. The SQL Server service is then still locked down
as long as there are no holes to exploit via the FTS queries. (I won't hold my breath)
Norman
|||Norman,
Unfortunately, I'd have to agree with you. FYI, the "Microsoft Search"
(mssearch.exe) service should ALWAYS be started and running under the
"system" or LocalSystem account as that how it is currently designed in SQL
Server 2000. However, for SQL Server 2005 (Yukon) this has changed and the
new MSSearch service, will be able to run under the same service account as
the MSSQLServer service.
If I was in the SQL MVP program, I'd be glad to volunteer and write such a
KB article, but alas I'm not *yet* in that program...
Regards,
John
"Norman" <anonymous@.discussions.microsoft.com> wrote in message
news:F954B2E0-FCDA-4692-8F80-D10DB1F5F701@.microsoft.com...
> John,
> No kudos to Microsoft for the high level security requiements for MS
Search and not providing a KB with a work around for highly secure
environments.
> FYI:
> Even though I found posts that indicate the contrary, the MS Search
service remains Local System Account regardless of which account you put in
the the SQL Service or SQL Agent at installation or after the fact via the
Enterprise Manager. I tried it on several SQL Server installations on W2K
and W2003.
> My compromise solution was to create a domain account specifically for the
MS Search service and make it local admin and sa in the SQL Server. This
seems to function correctly for all the test I have tried. The SQL Server
service is then still locked down as long as there are no holes to exploit
via the FTS queries. (I won't hold my breath)
> Norman