Połącz się z SQL Server z uwierzytelnianiem systemu Windows w innej domenie

Próbuję połączyć się ze zdalnym programem SQL Server w sieci VPN w innej domenie. Kiedy wprowadzam nazwę serwera na serwerze SQL i wybieram dodatkowe parametry połączenia, aby dodać dodatkowe rzeczy potrzebne mojej szkole:

Integrated Security=SSPI; User ID=DOMAIN\username; Password=Password

Otrzymuję następujący błąd:

Logowanie nie powiodło się. Login pochodzi z niezaufanej domeny i nie można go używać z uwierzytelnianiem systemu Windows.

sql-server authentication logins

— fxuser
źródło

Jedynym problemem związanym z rozwiązaniem Windows Credential Manager jest to, że jeśli masz wiele obsługiwanych baz danych, musisz mieć wpis dla każdego z nich i aktualizować je przy każdej aktualizacji haseł domeny. Dla niektórych osób może to być co 30 - 60 dni.

— smehaffie,

Ten post jest nieco powiązany.

— RBT

@ smehaffie możesz łatwo używać skryptów i polecenia „cmdkey / add”, aby zachować swoje hasła - aktualizuje się również.

— Mister Magoo,

Odpowiedzi:

Próbujesz przekazać poświadczenia systemu Windows zwykłym tekstem z ciągu połączenia aplikacji. To po prostu nie działa uwierzytelnianie systemu Windows i w dużej mierze jest to sprzeczne z celem.

Nie możesz też po prostu stworzyć tej samej nazwy użytkownika z tym samym hasłem we własnej domenie i oczekiwać, że zadziała to magicznie. Nazwa domeny jest nadal częścią sprawdzania poprawności - komputer musi być częścią domeny lub domena, w której znajduje się komputer, musi być zaufana przez domenę szkoły.

Jedyne obejście, jakie znam, dotyczy SSMS i taka jest runas /netonlysztuczka opisana w tej odpowiedzi . Powoduje to oszukanie systemu Windows do uruchamiania SSMS jako określonego przez Ciebie loginu, a nie własnego (nie jest to coś, co można ustawić w oknie dialogowym Właściwości połączenia SSMS, chodzi o to, jak uruchomić SSMS z wiersza polecenia lub skrótu):

runas /netonly /user:domain\username "C:\path_to\ssms.exe"

Spowoduje to monit o podanie hasła w domenie zdalnej. Będzie to wyglądać tak jak to jest przy użyciu lokalnych poświadczeń systemu Windows, ale nie jest .

Możliwe, że będzie również działać z Visual Studio, ale tak naprawdę nie wiem.

Twoje opcje to:

niech uniwersytet pozwoli ci przyłączyć się do twojego komputera w domenie
poproś uniwersytet o dodanie Twojej domeny jako domeny zaufanej
mieć pole skoku w sieci VPN, które umożliwia RDP i używanie narzędzi łączących się bezpośrednio z maszyną SQL Server
używać uwierzytelniania SQL
wypróbuj runas /netonlysztuczkę z Visual Studio
po prostu użyj runas /netonlysztuczki z SSMS

— Aaron Bertrand
źródło

runasSprawa ma pracować z Visual Studio.

— Daniel Hutmacher

Czy istnieje sposób naśladowania tego zachowania bez wiersza polecenia?

— Gilles Lesire,

@Gilles, możesz utworzyć plik wsadowy i kliknąć dwukrotnie plik wsadowy, lub możesz użyć tego ciągu i utworzyć skrót

— Aaron Bertrand

102

Jest inny sposób, którego teraz używam zamiast runas /netonlymetody.

Możesz dodać poświadczenia do swojego profilu w systemie Windows za pomocą Menedżera poświadczeń znajdującego się w panelu sterowania systemu Windows.

Otwórz Credential Manager
Kliknij „Dodaj poświadczenie systemu Windows”
Wypełnij pole „adres internetowy lub sieciowy” nazwą i numerem portu instancji SQL, dla której chcesz przechowywać poświadczenia.

Przykład: UniServer:1433(1433 jest domyślnym portem, możesz potrzebować innego portu, szczególnie jeśli łączysz się z nazwaną instancją)
Wypełnij „Nazwę użytkownika” (nie zapomnij dołączyć domeny np. MYDOMAIN\MYUSER)
Wypełnij „Hasło”
Kliknij OK

Jeśli masz poprawną nazwę serwera, port i dane logowania, powinieneś być teraz w stanie korzystać z uwierzytelniania systemu Windows z większości narzędzi klienckich, SSMS, Excel, cokolwiek. Wszystkie wykorzystają zapisane poświadczenia.

Wskazówka: Czasami trzeba użyć nazwy FQN dla serwera podczas dodawania poświadczeń. np UniServer.UniDomain.org:1433. wszystko zależy od specyfiki sieci.

Oto krótkie demo metody: http://youtu.be/WiVBPsqB9b4

Jest to zrzut ekranu, w którym próbuję (i nie udaje mi się) połączyć z serwerem SQL Server uruchomionym na maszynie wirtualnej z mojego pulpitu, a następnie dodać wymagane poświadczenia i spróbować ponownie - z powodzeniem.

Wskazówka: użyj polecenia „cmdkey / add”, aby utworzyć skrypt i zaktualizować zapisane poświadczenia.

— Pan Magoo
źródło

Ciekawy! Wydaje się, że zależy to od tego, co myśli twój komputer klienta, a nie od tego, jak może się on nazywać. Umieściłem wymyślony wpis („verysillytest.mwardm”) w moim pliku hosta dla adresu IP (jak to robią ci, którzy uzyskują dostęp spoza domen) i ustawiłem poświadczenie w nazwie „verysillytest.mwardm: 1433 ”. Następnie mogę połączyć się szczęśliwie (z małej aplikacji o nazwie Query Express) przy użyciu nazwy hosta lub adresu IP.

— mwardm

@mwardm tak, dlatego zalecam użycie polecenia ping lub nslookup, ponieważ poda ono nazwę dokładnie tak, jak trzeba jej użyć, w tym specyfikę wielkich / małych liter.

— Mister Magoo,

Ach, cóż „ping -a” nic mi nie dało, a nslookup nie (natychmiast) działał, ponieważ nie korzystałem z serwerów DNS domeny. Nie martw się, właściwie wolę elastyczność po prostu znać adres IP (i login) i mieć możliwość stworzenia własnego imienia!

— mwardm

Wspaniale, działa! Zastanawiam się - czy tak powinno działać, czy jest to błąd, czy błąd projektu po stronie SQL Servera? Microsoft lub ludzie z firmy Microsoft reklamują wszędzie, że musisz mieć maszynę podłączoną do domeny, w przeciwnym razie nie ma sposobu, aby połączyć się z SQL Server, który jest skonfigurowany tak, aby akceptował tylko poświadczenia domeny.

— Dawid Ferenczy Rogožan

BTW, powiedziałbym, że ta odpowiedź powinna być oznaczona jako zaakceptowana, ponieważ wydaje się, że jest to prawdziwe rozwiązanie, a druga odpowiedź bardziej przypomina obejście.

— Dawid Ferenczy Rogožan