NetWorker: SQL-sikkerhedskopieringsfejl i dæmonloggen "Kan ikke læse anmodning fra '<clientname>' om en GSS-godkendelsesstatusopdatering"

NMM/SQL-sikkerhedskopier har fejl i serverens dæmonlog på:
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.

Klientdæmonen har fejl:
nsrexecd NSR notice 06/28/16 17:19:42.763849 Encountered BSAFE SSL error: The SSL read operation did not complete

Hvis den køres i debug 1- eller 2-tilstand, kan følgende fejl ses med efterligningen på NW-serveren:
 
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

Godkendelsen mislykkes på grund af ikke at kunne åbne den oprettede pipe og falder tilbage til svag godkendelse:
 
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
 

Problemer med brugerrepræsentation opstår, når SQL-agenten sqlagent.exe Kører som en brugerkonto, der på grund af sikkerhedskrav ikke er en lokal administratorkonto.
NW-sikkerhedskopien udløses ved hjælp af en SQL-proxykonto (med repræsentation), der heller ikke er en lokal administratorkonto.
 

Der er fundet følgende løsninger på dette problem:

• Fjern stærk godkendelse (nsrauth) fra SQL-værterne, så de bruger oldauth i stedet.
• Gør SQLAGENT-brugerkontoen til lokal administrator på SQL-værten (og genstart SQL Server-tjenesten) 
• Start jobbet fra Windows Opgavestyring
• Start jobbene manuelt fra kommandolinjen