NetWorker: Errores de respaldo de SQL en el registro del demonio "No se puede leer la solicitud de '<clientname>' para una actualización del estado de autenticación de GSS"

Los respaldos de NMM/SQL tienen errores en el registro del demonio del servidor de los siguientes elementos:
nsrexecd NSR critical Unable to authenticate user USERNAME: Unable to read request from 'CLIENTNAME' for a GSS authentication status update: Connection reset by peer. Consult CLIENTNAME s daemon log for additional information.

El demonio de cliente tiene errores:
nsrexecd NSR notice 06/28/16 17:19:42.763849 Encountered BSAFE SSL error: The SSL read operation did not complete

Si se ejecuta en modo de depuración 1 o 2, se pueden ver los siguientes errores con la suplantación en el servidor NW:
 
nsrexecd NSR critical Unable to authenticate user USERBANE/CLIENTNAME@DOMAINNAME: Unable to read request from 'CLIENTNAME' for a GSS authentication status update: Connection reset by peer. Consult CLIENTNAME's daemon log for additional information

La autenticación falla debido a que no se puede abrir la canalización creada y recurre a una autenticación débil:
 
06/30/16 12:54:11.244790 DEBUG: the pipe name -> \\CLIENTNAME\pipe\nsridentity2ce0
06/30/16 12:54:11.244790 DEBUG: failed to open pipe
06/30/16 12:54:11.416677 RPC Authentication: error in LookupAccountSid: No mapping between account names and security IDs was done. (Win32 error 0x534)
06/30/16 12:54:11.432303 An unexpected error occured in file: rpc/lib/gsslgtov1.c, line: 2756, message = "Could not open file"
101036:save: Falling back to a weaker RPC authentication flavor since GSS authentication failed: Authentication error; why = GSS-API context problem
06/30/16 12:54:11.432303 Setting DNS cache TTLs to 1800 secs for positive lookups and 1800 secs for negative lookups
79355:save: Could not get session key from CLIENTNAME for GSS authentication with NW_SERVERNAME: Authentication error; why = GSS-API context problem
 

Los problemas de suplantación de usuario se producen cuando el agente de SQL sqlagent.exe Se ejecuta como una cuenta de usuario que no es una cuenta de administrador local debido a requisitos de seguridad.
El respaldo de NW se activa mediante una cuenta de proxy de SQL (con suplantación de identidad) que tampoco es una cuenta de administrador local.
 

Se encontraron las siguientes soluciones alternativas para este problema:

• Eliminar la autenticación reforzada (nsrauth) de los hosts de SQL para que usen oldauth en su lugar.
• Haga que la cuenta de usuario de SQLAGENT sea administrador local en el host de SQL (y reinicie el servicio SQL Server) 
• Inicie el trabajo desde el programador de tareas de Windows
• Inicie los trabajos manualmente desde la línea de comandos