"Accesso negato" durante la connessione di SSMS a Integration Services


17

Ricevo il seguente errore quando tento di connettere SSMS a Integration Services utilizzando il nome di rete di un cluster SQL Server specifico:

La connessione al servizio Integration Services sul computer "FooDB" non è riuscita con il seguente errore: "Accesso negato".

Questo errore si verifica quando il computer non è stato configurato per consentire connessioni remote tramite DCOM o l'utente dispone dell'autorizzazione per accedere al servizio SQL Server Integration Services tramite DCOM.

Questo è un problema di routine con una soluzione ben documentata. Ad esempio, vedi le soluzioni qui e qui .

Tuttavia, ho provato tutte le soluzioni che conosco e il problema persiste.

Più in dettaglio, ho fatto quanto segue:

  • Verificare che gli utenti che si connettono dispongano delle autorizzazioni DCOM elencate negli articoli collegati in precedenza su MsDtsServer100:

    1. Autorizzazioni di avvio e attivazione: consenti avvio locale, consenti avvio remoto, attivazione locale, attivazione remota

    2. Autorizzazioni di accesso: consentire l'accesso locale, consentire l'accesso remoto

    3. Autorizzazione alla configurazione: consenti lettura

  • Confermato con uno sniffer di pacchetti che tutto il traffico relativo alla connessione arriva correttamente attraverso il firewall. L'ultimo pacchetto mostrato prima della demolizione della connessione TCP è una risposta dal server contenente il codice di stato di Windows per "accesso negato" all'interno di un'intestazione MSRPC.

  • È stato verificato l'aggiunta degli utenti al gruppo "Utenti COM distribuiti" e / o al gruppo degli amministratori locali, quindi il riavvio dei server. Ciò ha consentito agli utenti di connettersi a SSIS da SSMS utilizzando i nomi dei nodi locali (FooDBN1, FooDBN2), ma ottengono comunque un errore di "accesso negato" durante la connessione al nome della rete del cluster (FooDB), che è ciò a cui sono abituati all'utilizzo e a ciò che funziona sui nostri altri cluster.

Inoltre, non ho trovato l'alterazione dell'appartenenza a questi gruppi necessaria su altri cluster.

Sugli altri cluster che ho controllato, posso connettere SSMS a SSIS usando il nome del cluster senza alcuna configurazione non predefinita.

Mi rendo conto che questo potrebbe essere più appropriato per ServerFault e sono d'accordo con la migrazione della domanda, se necessario, ma è anche un problema di SQL Server e penso che gli utenti qui potrebbero avere maggiori probabilità di averlo affrontato prima.

Dettagli della piattaforma:

  • Windows Server 2008 R2 SP1
  • SQL Server 2008 R2 SP2
  • Cluster attivo-passivo a 2 nodi con una singola istanza di SQL Server

Qualcuno potrebbe suggerire cosa dovrei guardare qui accanto?

Aggiornamento : questo misteriosamente ha iniziato a funzionare oggi, ma solo per i membri del gruppo degli amministratori locali. Nulla è cambiato per quanto posso dire.


1
Se stai usando il gruppo Amministratori, potresti essere morso dal mascheramento dei privilegi UAC. Prova a creare un nuovo gruppo o a concedere autorizzazioni per singoli utenti direttamente sull'applicazione SSIS DCOM.
db2

Se si dispone di un cluster, gli utenti dovrebbero connettersi all'alias del cluster, non a singoli computer. È il caso?
Stoleg,

Sì, dovrebbero usare il nome del cluster, non il nome del singolo nodo. Tuttavia, per qualche motivo, l'errore si verifica solo quando si utilizza il nome del cluster.
James L

Non abbiamo UAC abilitato sui client o sul server, ma proverò a concedere le autorizzazioni DCOM ai singoli utenti anziché ai gruppi e vedere se questo fa la differenza. Attualmente il problema non ha alcun senso per me.
James L

OK, ora questo ha semplicemente incominciato a funzionare per tutti coloro che dovrebbero avere accesso in base alle autorizzazioni che avevo concesso settimane fa. Non ho idea del perché questo abbia iniziato a funzionare solo negli ultimi giorni. Quindi il problema sembra risolto, ma non ho idea del perché sia ​​iniziato o del perché si sia fermato. La mia ipotesi è che è correlato a cambiamenti senza preavviso di criteri di gruppo.
James L,

Risposte:


9

Colpo lungo forse, ma vale la pena controllare il file

\ Programmi \ Microsoft SQL Server \ 100 \ DTS \ Binn \ MsDtsSrvr.ini

o l'equivalente sulla tua configurazione. Potrebbe essere necessario modificarlo manualmente con il nome dell'istanza. Altrimenti le connessioni SSIS potrebbero cercare un msdb di un'istanza SQL predefinita che non esiste.


1
Grazie, ma l'ho già impostato. È stato votato perché vale la pena menzionarlo.
James L

0

Il problema ha a che fare con le autorizzazioni sul server sottostante e non su SSIS o MSDB. Abbiamo avuto lo stesso problema. L'aggiunta temporanea dell'account AD dell'utente al gruppo degli amministratori locali ha risolto questo problema per noi. L'aggiunta del proprio account AD a PowerUser o Utenti no; tuttavia, sono certo che avremmo potuto trovare ciò che mancava nella politica di sicurezza locale per realizzarlo.


L'aggiunta all'account locale ha funzionato anche per me, puoi suggerirmi quale potrebbe essere la ragione probabile. Poiché questa non potrebbe essere la migliore pratica
Saurabh Sinha,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.