„Odmowa dostępu” podczas łączenia SSMS z Integration Services

17

Otrzymuję następujący błąd podczas próby połączenia SSMS z Integration Services przy użyciu nazwy sieciowej określonego klastra SQL Server:

Łączenie z usługą Integration Services na komputerze „FooDB” nie powiodło się z powodu następującego błędu: „Odmowa dostępu”.

Ten błąd występuje, gdy komputer nie został skonfigurowany do zezwalania na połączenia zdalne za pośrednictwem DCOM lub użytkownik ma uprawnienia dostępu do usługi SQL Server Integration Services za pośrednictwem DCOM.

Jest to rutynowy problem z dobrze udokumentowanym rozwiązaniem. Na przykład zobacz rozwiązania tutaj i tutaj .

Jednak wypróbowałem wszystkie znane mi rozwiązania i problem pozostaje.

Bardziej szczegółowo wykonałem następujące czynności:

  • Zweryfikowano, że użytkownicy łączący się mają uprawnienia DCOM wymienione w artykułach połączonych powyżej na MsDtsServer100:

    1. Uprawnienia do uruchamiania i aktywacji: Zezwalaj na lokalne uruchamianie, zezwalaj na zdalne uruchamianie, lokalną aktywację, zdalną aktywację

    2. Uprawnienia dostępu: Zezwól na dostęp lokalny, zezwól na dostęp zdalny

    3. Pozwolenie na konfigurację: Zezwól na odczyt

  • Potwierdzono za pomocą sniffera pakietów, że cały ruch związany z połączeniem pomyślnie przechodzi przez zaporę. Ostatni pakiet pokazany przed zerwaniem połączenia TCP to odpowiedź serwera zawierająca kod stanu systemu Windows dla „odmowy dostępu” w nagłówku MSRPC.

  • Przetestowano dodawanie użytkowników do grupy „Użytkownicy rozproszonego COM” i / lub grupę lokalnych administratorów, a następnie restartowanie serwerów. Umożliwiło to użytkownikom połączenie się z SSIS z SSMS przy użyciu lokalnych nazw węzłów (FooDBN1, FooDBN2), ale nadal pojawia się błąd „odmowa dostępu” podczas łączenia się z nazwą sieci klastra (FooDB), do czego są przyzwyczajeni do korzystania i co działa na naszych innych klastrach.

Nie znalazłem też konieczności zmiany członkostwa w tych grupach w innych klastrach.

W innych klastrach, które sprawdziłem, mogę połączyć SSMS z SSIS przy użyciu nazwy klastra bez konfiguracji innej niż domyślna.

Zdaję sobie sprawę, że może to być bardziej odpowiednie dla ServerFault i jestem w porządku, jeśli pytanie jest migrowane w razie potrzeby, ale jest to również problem z SQL Server i myślę, że użytkownicy tutaj prawdopodobnie byliby w stanie poradzić sobie z tym wcześniej.

Szczegóły platformy:

  • Windows Server 2008 R2 SP1
  • SQL Server 2008 R2 z dodatkiem SP2
  • 2-węzłowy aktywny-pasywny klaster z pojedynczą instancją SQL Server

Czy ktoś mógłby zasugerować, na co powinienem tutaj patrzeć?

Aktualizacja : w tajemniczy sposób właśnie zaczęła działać dzisiaj, ale tylko dla członków lokalnej grupy administratorów. O ile wiem, nic się nie zmieniło.

James L.
źródło
1
Jeśli korzystasz z grupy Administratorzy, możesz zostać ugryziony przez maskowanie uprawnień UAC. Spróbuj utworzyć nową grupę lub udzielić indywidualnych uprawnień użytkownikom bezpośrednio w aplikacji SSIS DCOM.
db2
Jeśli masz klaster, użytkownicy powinni łączyć się z aliasem klastra, a nie z poszczególnymi komputerami. Czy to prawda?
Stoleg
Tak, powinni używać nazwy klastra, a nie nazwy pojedynczego węzła. Jednak z jakiegoś powodu błąd występuje tylko podczas używania nazwy klastra.
James L
Nie mamy włączonego UAC na klientach lub serwerze, ale spróbuję przyznać uprawnienia DCOM pojedynczym użytkownikom zamiast grupom i zobaczę, czy to coś zmieni. Obecnie problem nie ma dla mnie żadnego sensu.
James L
OK, teraz to nieoczekiwanie zaczęło działać dla wszystkich, którzy powinni mieć dostęp na podstawie uprawnień, które nadałem tygodnie temu. Nie mam pojęcia, dlaczego to zaczęło działać w ciągu ostatnich kilku dni. Wygląda na to, że problem został rozwiązany, ale nie mam pojęcia, dlaczego się zaczął i dlaczego przestał działać. Domyślam się, że jest to związane z niezapowiedzianymi zmianami zasad grupy.
James L

Odpowiedzi:

9

Być może dalekie ujęcie, ale warto sprawdzić plik

\ Program Files \ Microsoft SQL Server \ 100 \ DTS \ Binn \ MsDtsSrvr.ini

lub odpowiednik w konfiguracji. Może być konieczne ręczne edytowanie go za pomocą nazwy instancji. W przeciwnym razie połączenia SSIS mogą szukać msdb domyślnej instancji SQL, która nie istnieje.

John Alan
źródło
1
Dzięki, ale już to ustawiłem. Pozytywnie oceniany, ponieważ warto o nim wspomnieć.
James L
0

Problem ma coś wspólnego z uprawnieniami na podstawowym serwerze, a nie SSIS ani MSDB. Mieliśmy ten sam problem. Tymczasowe dodanie konta AD użytkownika do lokalnej grupy administratorów naprawiło to dla nas. Dodanie konta AD do PowerUsers lub użytkowników nie; jestem jednak pewien, że mogliśmy znaleźć to, czego brakowało w lokalnej polityce bezpieczeństwa, aby tak się stało.

PseudoToad
źródło
Dodanie do konta lokalnego również działało dla mnie, czy możesz zasugerować, co może być prawdopodobnym powodem. Ponieważ nie może to być najlepsza praktyka
Saurabh Sinha