NetWorker: SQL backup errors in daemon log "Unable to read request from '<clientname>' for a GSS authentication status update"

NMM/SQL backups have errors in the server's daemon log of:
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.

The client daemon has errors:
nsrexecd NSR notice 06/28/16 17:19:42.763849 Encountered BSAFE SSL error: The SSL read operation did not complete

If run in debug 1 or 2 mode, the following errors can be seen with the impersonation on the NW server:
 
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

The authentication is failing due to not being able to open the pipe created, and falls back to weak authentication:
 
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
 

User impersonation issues occur when the SQL agent sqlagent.exe runs as a user account that is not a local admin account due to security requirements.
The NW backup is triggered using a SQL proxy account (with impersonation) that is also not a local admin account.
 

The following workarounds have been found to this issue:

• Remove strong authentication (nsrauth) from the SQL hosts so they use oldauth instead.
• Make the SQLAGENT user account local administrator on the SQL host (and restart SQL Server service) 
• Start the job from the Windows Task Scheduler
• Start the jobs manually from the command line