NetWorker: SQL-back-upfouten in daemon-logboek "Kan verzoek van '<clientname>' voor een update van de GSS-authenticatiestatus niet lezen"

NMM/SQL-back-ups bevatten fouten in het daemon-logboek van de server van:
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.

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

Als deze wordt uitgevoerd in debug 1- of 2-modus, zijn de volgende fouten te zien met de imitatie op de 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

De verificatie mislukt omdat de gemaakte pijp niet kan worden geopend en valt terug op zwakke verificatie:
 
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
 

Problemen met gebruikersimitatie treden op wanneer de SQL-agent sqlagent.exe Wordt uitgevoerd als een gebruikersaccount dat vanwege beveiligingsvereisten geen lokaal beheerdersaccount is.
De NW-back-up wordt geactiveerd met behulp van een SQL-proxyaccount (met imitatie) dat ook geen lokaal beheerdersaccount is.
 

De volgende oplossingen zijn gevonden voor dit probleem:

• Sterke verificatie verwijderen (nsrauth) van de SQL-hosts, zodat ze oldauth in plaats van.
• Maak het SQLAGENT-gebruikersaccount lokale beheerder op de SQL-host (en start de SQL Server-service opnieuw) 
• Start de taak vanuit de Windows Taakplanner
• Start de taken handmatig vanaf de opdrachtregel