NetWorker: SQL-säkerhetskopieringsfel i daemonloggen "Det går inte att läsa begäran från '<klientnamn'>' för en statusuppdatering för GSS-autentisering"

NMM/SQL-säkerhetskopieringar har fel i serverns daemonlogg för:
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.

Klientdaemonen har fel:
nsrexecd NSR notice 06/28/16 17:19:42.763849 Encountered BSAFE SSL error: The SSL read operation did not complete

Om du kör i felsökningsläge 1 eller 2 kan följande fel visas med personifieringen på NW-servern:
 
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

Autentiseringen misslyckas på grund av att det inte går att öppna röret som skapats och återgår till svag autentisering:
 
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
 

Problem med användarpersonifiering uppstår när SQL-agenten sqlagent.exe Körs som ett användarkonto som inte är ett lokalt administratörskonto på grund av säkerhetskrav.
NW-säkerhetskopieringen utlöses med hjälp av ett SQL-proxykonto (med personifiering) som inte heller är ett lokalt administratörskonto.
 

Följande lösningar har hittats för det här problemet:

• Ta bort stark autentisering (nsrauth) från SQL-värdarna, så de använder oldauth istället.
• Gör SQLAGENT-användarkontot till lokal administratör på SQL-värden (och starta om SQL Server-tjänsten) 
• Starta jobbet från Schemaläggaren i Windows
• Starta jobben manuellt från kommandoraden