Uruchamianie pakietu SSIS należącego do użytkownika domeny z SQL Server działającego na koncie usługi lokalnej


10

Chcę uruchomić pakiet SSIS zawierający zadania Transfer SQL Server Objects. Zaangażowane serwery znajdują się w tej samej domenie, ale usługi SQL Server działają na lokalnych kontach usług. Więc środowisko wygląda następująco:

Domena

Serwer 1

  • SQL Server działający na koncie lokalnym
  • W systemie plików: pakiet SSIS
  • W SQL Server Agent: zadanie

Serwer 2

  • SQL Server działający na koncie lokalnym

Aby móc zalogować się na oba serwery, utworzyłem konto domeny, które będzie używane jako konto usługi. Kiedy korzystam z tego konta domeny, aby zalogować się do serwera 1, a następnie uruchomić pakiet z systemu plików, każdy krok kończy się powodzeniem. Jednak gdy próbuję dodać zadanie do programu SQL Server, napotykam jeden z następujących problemów:

Sytuacja 1. Właściciel pracy: konto lokalne; uruchom SSIS krok jako serwer proxy do konta domeny . Gdy ustawię właściciela zadania na konto lokalne, ale uruchomię zadanie jako serwer proxy do konta domeny, samo zadanie zostanie pomyślnie wykonane, ale pakiet zgłasza błędy, takie jak

Wykonanie nie powiodło się z następującym błędem: „Katalog„ LocalApplicationData ”nie istnieje.”.

Ten błąd można naprawić, tworząc login z uprawnieniami administratora dla użytkownika domeny na serwerze 1, ale oczywiście nie jest to pożądane rozwiązanie. Dodanie konta do jednej z grup agentów / grup DTS programu SQL Server również nie działa.

Sytuacja 2. Właściciel zadania: konto domeny; uruchom SSIS krok jako serwer proxy do konta domeny . Gdy ustawię zarówno właściciela zadania, jak i opcję „Uruchom jako użytkownik” dla kroku do konta domeny, zadanie w ogóle się nie uruchomi z następującym błędem:

Nie można ustalić, czy właściciel (domena \ użytkownik domeny) zadania Job namema dostęp do serwera (powód: Nie można uzyskać informacji o grupie systemu Windows NT / użytkownik „domena \ użytkownik domeny”, kod błędu 0x5. [SQLSTATE 42000] (Błąd 15404)) .

Uważam, że ostatnim błędem jest to, że SQL Server działa na koncie lokalnym i nie może sprawdzić, które konta domeny praw mają.

Jaki jest właściwy sposób na uruchomienie zadania? Sytuacja 2 wydaje mi się czystsza, ale wydaje się niemożliwa, ponieważ SQL Server działa na koncie lokalnym. Sytuacja 1 też by działała, ale przyznanie praw administracyjnych użytkownika domeny na moim SQL Server nie nastąpi.


AKTUALIZACJA:

@JonSeigel i @ Mr.Brownstone:

Wydaje się prawdopodobne, że problem ten wynika z braku uprawnień. Błąd dotyczy jednak nieistnienia „LocalApplicationData” - jednego z folderów generowanych dla każdego konta. Zalogowałem się już na serwerze przy użyciu poświadczeń, na podstawie których działa pakiet (tworząc katalog profilu) i wypróbowałem kilka kombinacji uprawnień do katalogu profilu. Nawet gdy ręcznie udzielam prawie wszystkich uprawnień w tym konkretnym katalogu, pojawia się błąd wymieniony powyżej.

Podczas dalszych badań natknąłem się na wątek na forum pod adresem http://www.sqlservercentral.com/Forums/Topic391332-148-1.aspx#bm391441, który jest dość podobny - jednak bez rozwiązania.


Czy istnieje powód, dla którego nie korzystasz z konta domeny dla usług SQL?
Eric Higgins,

Tak, ale nie wiem z jakiego powodu (chyba coś z cyklu DTAP i domena nie jest wszędzie dostępna). W każdym razie jest to dane środowisko, którego nie wolno mi zmieniać.
vstrien

Sytuacja nr 1 wydaje się być odpowiedzią. Myślę, że komunikat o błędzie pojawia się w pakiecie. Innymi słowy, pakiet jest wykonywany, ale zadanie w nim zawarte wymaga więcej uprawnień niż konto usługi zostało przyznane. Być może nie będzie konieczne przyznanie konta uprawnień na poziomie administratora, aby się powiodło (zamiast tego udzielić uprawnień granularnych lub zmienić proces, aby nie potrzebował uprawnień).
Jon Seigel

Czy możesz dodać loginy SQL (uwierzytelnianie SQL) do zdalnego serwera SQL (serwer 2)? Jeśli masz tę opcję, możesz użyć logowania SQL w połączeniu SSIS używanym jako miejsce docelowe. Oznacza to, że będziesz musiał użyć hasła do zaszyfrowania paczki, ale to rozwiąże twój problem.
Roi Gavish,

@Justicator: Może w ostateczności. Ale gdy tylko możliwe są logowanie do domeny, wolę nie używać uwierzytelniania SQL.
vstrien

Odpowiedzi:


5

Moim osobistym zdaniem jest taka opcja nr 1. Ale nie widzę potrzeby, abyś musiał przyznać lokalnemu administratorowi konto domeny. Wydaje mi się, że wymaga dostępu do niektórych folderów i plików, więc użytkownik domeny może uzyskać dostęp tylko do zasobów niezbędnych do pomyślnego uruchomienia pakietu. Można tego dokonać w oknie dialogowym właściwości pliku / folderu i wybrać kartę zabezpieczeń - nie powinno być potrzeby ustawiania go dla każdego pliku i folderu, ponieważ można ustawić uprawnienia do katalogu nadrzędnego i ustawić je tak, aby przesłoniły właściwości potomne.

Mam nadzieję, że to Ci pomoże.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.