Oczywiście muszę to zrobić używając użytkownika, który jest już w AD i ma dostęp do serwera, ale jak to zrobić bez logowania się do niego używając mojego konta AAD i robienia tego ręcznie?
Cześć wszystkim!
Mam już powoli dość azure SQL i jego "integracji" z AAD...
Sytuacja:
Chcę sobie zautomatyzować tworzenie bazy danych na serverze Azure SQL i dodać do bazy użytkowników z AAD. Używam hosted agent w Azure Dev Ops, a tam taska co się zowie AzureSQL task. Chcę tam dodać dwie grupy z AD do dwóch różnych ról. Oczywiście muszę to zrobić używając użytkownika, który jest już w AD i ma dostęp do serwera, ale jak to zrobić bez logowania się do niego używając mojego konta AAD i robienia tego ręcznie? Nie mogę odnaleźć jak to sensownie zrobić używając Managed Identity, które zresztą musi być dodane z poziomu SQL używając konta AAD, czyli koło się zamyka (chyba, że czegoś nie rozumiem).
Nie wiem czy problemem nie jest sam task w Azure DevOps, albowiem widziałem kilka wątków w necie, że są spore problemy z AAD i taskami SQL właśnie (). Swoją drogą testowaliśmy konto, które ma tam dostęp (jest dodane do grupy AAD ustawionej jako Active Directory ADmin na serwerze i dostajemy ten sam błąd) używając trybu logowania Active Directory Password i dostajemy nic nie mówiący błąd:
"One or more errors occurred.Check out how to troubleshoot failures at " https://aka.ms/sqlazuredeployreadme#troubleshooting-
Włączenie system.debug niewiele wyjaśnia, dostaję wyjątek, który mówi tyle co sam błąd powyżej:
"Error Message : System.Management.Automation.ActionPreferenceStopException: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: One or more errors occurred."
Jeśli chodzi o samo AD, to jestem w pewien sposób ograniczony, bo projekt jest dla dużego korpo - Mają wewnętrzne systemy na nim oparte, jest dobrze chronione, nie mam do niego bezpośredniego dostępu, a jedynie korzystam z tego, co jest zsyncowane do AAD z on-prem. Nad samymi użytkownikami z AAD nie mam kontroli ale ich widzę, to samo z grupami (jedno i drugie jednostronnie syncowane do AAD z on-prem). Mogę przypisywać grupy i użytkowników do zasobów, przeszukiwać AD, tworzyć app registrations itd. Nie mogę natomiast tworzyć i modyfikować użytkowników ani grup, wiec Tworzenie apki, czy Managed identity nic mi nie da, bo nie będę ich mógł dodać do grup.
Dodam jedynie, że zalogowanie kontem AD przez SSM przebiega normalnie, nie jest to też kwestia firewalla - SQL login w tasku DevOps również działa normalnie.
Co robić, jak żyć?
Z góry dzięki za pomoc!
Replies
A jak byś się podłączył server admin, którego konfigurowałeś jak stawiałeś SQL Server na którym stoi Twoja DB?
SQL authentication działa normalnie problem jest właśnie przy logowaniu z Agenta poprzez konto AD. Problem w tym, że po zalogowaniu SA nie mogę dodać żadnego użytkownika z AD, bo muszę być zalogowany userem AD :D
Dokładnie tak, w DevOps podczas budowy bazy zapisz w keyvault albo przekaż login i pass server admina do kolejnego taska (Powershell) i w nim zrób ustawianie użytkowników, dodawanie ról itp.
Masz rację: Users that are not based on an Azure AD account (including the server administrator account) cannot create Azure AD-based users, because they do not have permission to validate proposed database users with the Azure AD.
Hmm... To może na chwilę przypisać usera który odpala task w DevOps jako admin sqla, zrobić co trzeba i go zdjąć z bycia adminem sqla?
no wlasnie problemem tutaj jest hosted agent w Azure Dev Ops, gdyby nie to, to SSMS, PowerShell czy cokolwiek innego by działało. Ale jak rozumiem w gre wchodzi tylko hosted agent w Azure Dev Ops,
A czemu hosted agent ma być problemem? Powershell powinien działać wszędzie 🤔
Rafałowi pewnie chodzi o to, że na self hosted bym sobie wjechał AAD integrated gdybym miał skonfigurowanego agenta samodzielnie a tak używam AD password jako trybu logowania i prawdopodobnie Azure SQL sobie z tym nie radzi.
Dodanie tego usera bezpośrednio jako admina servera SQL obfituje tym samym błędem
No to jeżeli Powershell jest opcją akceptowalną, to nie powinienes miec zadnego problemu z tym, zeby wykonac Invoke-SqlCmd w kontekscie usera AAD. Jedym ale jest MFA, gdzie wymagany jest user, ale to wtedy przez automation account, przy czym wcześniej trzeba by go bylo dodać do userów.
Trochę nie rozumiem tej części odpowiedzi: "Jedym ale jest MFA, gdzie wymagany jest user, ale to wtedy przez automation account."
Ale dzięki, spróbuję zalogować się powershellem i odpalić skrypt
bo jezeli masz MFA to nie odpalisz zadnego skryptu automatycznie bez dodatkowego potwierdzenia tozsamosci (np wpisanie kodu lub przesuniecie suwaka w telefonie), zawsze odpalajac musisz to zrobic. a nie mając go mozesz to zautomatyzowac, zeby skrypt wykonywał się bez Twojego udziału.
user nie ma MFA z tego co mi wiadomo - konto miało posłużyć automatyzacji
Niestety chyba nie wyjdzie z tym userem: https://feedback.azure.com/forums/908035-sql-server/suggestions/37517965-add-aad-auth-to-invoke-sqlcmd
to pozostaje automation - tam tworzysz connection uzywajac AppID, TenantID, Thumbprint i SubID. Ja u siebie tak się łączę. Ponieważ AA jest obiektem utworzonym w AAD powinno sie udać, choć nigdy nie robiłem tego.
Ok, czyli mam zrobić app registration, żeby za jego pomocą połączyć się poprzez automation account?
Tak bym spróbował zrobić, aczkolwiek nigdy nie dodawałem userów AAD przez AA, ale patrząc na problem - może zadziałać.
U nas robimy to przy pomocy Azure Automation (tfu, tfu) i Invoke-Sqlcmd Kontem lokalnym względem SQL Servera, dlatego Service Principal nie jest potrzebne.
Ale jest też bardziej prawilna opcja do wyboru, https://docs.microsoft.com/en-us/azure/connectors/connectors-create-api-sqlazure
Stanisław Henry Bugalski dzięki, rowniez sprawdzę!
Stanisław Henry Bugalski tworzyć logic app, aby dodawała użytkownika? A kto utworzy tę logic app?
Janet Mitchell pipeline ;)
