Delegazione di Kerberos per SQL Insert bulk (accesso negato)

Ho un problema quando provo a mettere in massa l'inserimento in SQL nella seguente situazione:

  • Studio di gestione in esecuzione su workstation A
  • SQL in esecuzione sul server B
  • Caricare file da caricamento di massa da server C

Quando provo sempre e caricare in massa, ottengo l'errore

Cannot bulk load because the file <filename> could not be opened. Operating system error code 5(Access is denied.). 

Ora sono consapevole che abbiamo un problema a doppio hop e che abbiamo bisogno di risolvere la delegazione. Le SPN sono state configurate per SQL come segue (SQL è in esecuzione su una port diversa). SQL è in esecuzione come utente di dominio e le SPN sono in quel conto.

 command: setspn -l domain\sqluser result: MSSQLSvc/WIN-D04V1IOTESN MSSQLSvc/WIN-D04V1IOTESN.domain.local MSSQLSvc/win-d04v1iotesn.domain.local:55037 MSSQLSvc/WIN-D04V1IOTESN:55037 

Ho anche impostato una delegazione dall'account utente SQL al file server per Cif e HOST, ma senza alcun risultato.

Ho triggersto la logging di Kerberos e vedo il seguente evento nel visualizzatore events:

  A Kerberos Error Message was received: on logon session Client Time: Server Time: 14:44:10.0000 8/9/2011 Z Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP Extended Error: Client Realm: Client Name: Server Realm: domain.LOCAL Server Name: krbtgt/domain.LOCAL Target Name: krbtgt/domain.LOCAL@domain.LOCAL Error Text: File: 9 Line: efb Error Data is in record data. 

Così, tutti i pensieri su quello che mi manca qui? Ho avuto questo tipo di delegazione che lavora prima ma sempre con SQL sulla port predefinita, che potrebbe avere un impatto?

Modifica

Ora vedo anche questo errore Kerbors accanto al primo:

 A Kerberos Error Message was received: on logon session Client Time: Server Time: 15:4:10.0000 8/9/2011 Z Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP Extended Error: Client Realm: Client Name: Server Realm: domain.LOCAL Server Name: krbtgt/domain.LOCAL Target Name: krbtgt/domain.LOCAL@domain.LOCAL Error Text: File: 9 Line: efb Error Data is in record data. 

3 Solutions collect form web for “Delegazione di Kerberos per SQL Insert bulk (accesso negato)”

Dai commenti, stai collegando a SQL utilizzando un login di dominio in modo che SQL sta cercando di rappresentarti quando si connette alla condivisione di file. Se la delegazione non è stata impostata per questo per il tuo account di dominio, allora non riesce.

Quando si esegue il process memorizzato collegato come SQL login SQL tenterà di utilizzare l'account del servizio di dominio in cui è in esecuzione, per cui si dice che è già impostata la delegazione.

Se si collega la window di query utilizzando l'account di servizio di dominio SQL è in esecuzione in quanto dovrebbe funzionare da quando la delegazione è già configurata. Impostare una fiducia di delegazione al file server per il proprio account di dominio e dovrebbe iniziare a lavorare.

Lo sguardo di SPN è corretto per SQL Server. Le SPN corrette sono registrate per il file server?

L'altra cosa che può confondere l'authentication kerberos a SQL Server è problemi DNS. Ho letto da qualche parte che il client sql eseguirà una ricerca DNS inversa nell'indirizzo del server e usa quel nome per formare la SPN.

So che hai già fatto molti di questi passaggi, ma questo dovrebbe essere tutto quello che devi fare.
Assicurarsi che la risoluzione DNS funzioni correttamente sia per il server SQL che per il file server.
Registrare SPN per SQL Server. Assicurarsi che non ci siano duplicati SPN. setspn in SQL 2008 può fare questo controllo per te.
Registrare SPN per il file server. Assicurarsi che non ci siano duplicati.
Abilita "trusted for delegation" nell'account di servizio di SQL Server.
Verifica anche che il tuo account non sia contrassegnato come non delagatable. (è una parola?)

Se non è ansible farlo funzionare allora è ansible impostare un process di agente SQL a un inserimento di massa. Quindi verrà eseguito sotto l'account configurato per eseguire il process.

La mancanza di un tempo del cliente nel tuo messaggio di errore mi rende sospetta. L'authentication Kerberos non funziona se il tempo sul client e l'ora sul server sono troppo diversi. (Non sono mai stato sicuro di cosa sia davvero "troppo diverso". So che un minuto può farlo perché abbiamo avuto questo problema (di nuovo) ieri con un nuovo server.)

Quando l'authentication kerberos non riesce, SSMS probabilmente ancora si collega, ma si riprenderà silenziosamente utilizzando l'authentication NTLM.

È ansible forzare i kerberos, modificando le impostazioni di connessione e le stringhe, in modo che una connessione non riesca duro se authentication kerberos, ma c'è un modo più semplice per vedere se si è connessi con kerberos. Per accertarsi di essere connessi utilizzando l'authentication Kerberos, collegarsi normalmente tramite SSMS e eseguirlo in una window di query SSMS:

select auth_scheme da master.sys.dm_exec_connections where session_id = @@ spid

Dovresti vedere "KERBEROS". Se non lo fai, probabilmente vedrai "NTLM" e saprai che qualcosa è sbagliato.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.