After installing the Full Text Search component on our SQL Server 2012 instance running on Windows Server 2008 R2, we encountered three distinct but related authentication problems:

• SPN registration failures in the Windows Event Log
• Job ownership validation failures for domain accounts
• Network resource access denied for the virtual service account

The key error message we're seeing indicates Kerberos authentication challenges:

Event ID: 26014
The SQL Server Network Interface library could not register the 
Service Principal Name (SPN) [ MSSQLSvc/FooComputer.FooDomain.com:1433 ] 
for the SQL Server service. Windows return code: 0xffffffff, state: 63.

To verify the current SPN registration status:

setspn -L MSSQLSvc/FooComputer.FooDomain.com

For manual SPN registration (requires Domain Admin privileges):

setspn -A MSSQLSvc/FooComputer.FooDomain.com:1433 MyDomain\SQLServerComputerName$
setspn -A MSSQLSvc/FooComputer:1433 MyDomain\SQLServerComputerName$

The job failure error (Error 15404) suggests the SQL Server service account cannot validate domain credentials. For temporary workarounds:

-- Change job owner to sa
USE msdb
GO
EXEC dbo.sp_update_job @job_name = 'YourJobName', @owner_login_name = 'sa'
GO

For a more permanent solution, we need to configure proper service account permissions:

-- Grant the SQL Server service account necessary AD permissions
-- This requires domain administrator privileges
-- Add the computer account to "Windows Authorization Access Group" in AD
-- Or grant "Read all properties" permission to the computer account

The virtual account (NT SERVICE\MSSQLSERVER) cannot authenticate across the network. The proper solution involves:

1. Setting up a domain service account
2. Configuring constrained delegation
3. Granting explicit permissions

For shared folder access, you'll need to:

-- 1. Create a domain service account (e.g., MyDomain\SQLService)
-- 2. Grant this account permissions to the network share
-- 3. Change SQL Server service to run under this account
-- 4. Configure SPNs for the new account
-- 5. Enable constrained delegation if accessing other services

Here's the complete remediation script for changing the service account:

-- Step 1: Change service account (run in PowerShell as admin)
$service = Get-WmiObject -Class Win32_Service -Filter "Name='MSSQLSERVER'"
$service.Change($null, $null, $null, $null, $null, $null, "MyDomain\SQLService", "Password123", $null, $null, $null)

-- Step 2: Register SPNs for new account
setspn -A MSSQLSvc/FooComputer.FooDomain.com:1433 MyDomain\SQLService
setspn -A MSSQLSvc/FooComputer:1433 MyDomain\SQLService

-- Step 3: Grant necessary permissions in AD
dsacls "CN=SQLService,CN=Users,DC=MyDomain,DC=com" /G "MyDomain\SQLServerComputerName$:RP"

To confirm the changes worked:

-- Check service account
Get-WmiObject -Class Win32_Service -Filter "Name='MSSQLSERVER'" | Select-Object Name, StartName

-- Test Kerberos authentication
klist get MSSQLSvc/FooComputer.FooDomain.com:1433

-- Verify network access
EXEC master..xp_cmdshell 'dir \\FooComputer\FooFolder\'

---

When using the virtual account NT Service\MSSQLSERVER in Windows Server 2008 R2 with SQL Server 2012, we encountered three distinct but related authentication issues after installing the Full Text Search component. This virtual account, while convenient for standalone installations, presents unique challenges in domain environments.

The most fundamental issue appeared in the Application logs:

The SQL Server Network Interface library could not register the
Service Principal Name (SPN) [ MSSQLSvc/FooComputer.FooDomain.com:1433 ]
for the SQL Server service. Windows return code: 0xffffffff, state:
63. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos.

Virtual accounts cannot register SPNs because they don't exist in Active Directory. To resolve this:

-- First check existing SPNs
SETSPN -L FooComputer.FooDomain.com

-- Manually register the SPN using domain admin credentials
SETSPN -A MSSQLSvc/FooComputer.FooDomain.com:1433 Domain\SQLServiceAccount
SETSPN -A MSSQLSvc/FooComputer:1433 Domain\SQLServiceAccount

SQL Agent jobs owned by domain users began failing with error 15404:

The job failed. Unable to determine if the owner (MyDomain\FooUser)
of job JOBNAME has server access (reason: Could not obtain information
about Windows NT group/user 'MyDomain\FooUser', error code 0x6e.

This occurs because virtual accounts cannot query Active Directory for user information. Solutions include:

1. Change job owners to SQL logins (like sa)
2. Switch to a domain service account with proper AD permissions
3. Grant "Access this computer from the network" right to the computer account

The virtual account's inability to access network resources manifests when attempting operations like:

DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\\FooComputer\FooFolder\' + Char(34)
EXEC master..xp_cmdshell @CopyCommand

While granting permissions to the computer account (DOMAIN\SQLServer$) helps in some scenarios, for reliable network access you should:

-- 1. Create a proxy account for xp_cmdshell
USE master
GO
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\NetworkAccessUser', 'Password123'
GO

-- 2. Enable advanced options and xp_cmdshell
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE

For production environments, I recommend this approach:

-- Step 1: Create a dedicated domain service account
-- (Minimum permissions: "Log on as a service" and "Perform volume maintenance tasks")

-- Step 2: Change SQL Server service account
SQLServerManager12.msc → Right-click SQL Server service → Properties → Log On → 
Change to "This account" and enter DOMAIN\SQLServiceAccount

-- Step 3: Register SPNs (as shown above)

-- Step 4: Configure constrained delegation if needed
Active Directory Users and Computers → Computer account → Delegation → 
"Trust this computer for delegation to specified services" → Add SQL Server SPN

Remember to restart SQL Server services after making these changes and test connectivity thoroughly.