Hallo alle miteinander,
endlich habe ich mir mal wieder die Zeit genommen ein klein wenig zu schreiben. Heute geht es um mein erstes kleines Azure Data Studio Notebook, welches ich erstellt habe.
Großartig erklären, was es mit dem Notebook im ADS auf sich hat, brauche ich an der Stelle nicht. Ich bin so frei und verweise einfach auf den Blog Post vom Björn Peters aus Hamburg. Björn hatte schon vor langer Zeit Notebooks für sich entdeckt.
Das Schöne ist, dass so ein Jupyter Notebook im ADS nicht nur SQL-Kernel beherrscht, wo Ihr T-SQL Skripte und deren Ergebnisse zusammenfassen könnt. Es ist auch ein Powershell-Kernel mit an Bord.
Und daher ist mein 1. Notebook ist ein Powershell Notebook geworden. Ok, dazu kommt noch die Inspiration durch Rob Sewell ( t | b ), der extrem viel mit Notebooks macht und Jess Pomfret (t | b) durch den Artikel die morgendliche Checkliste in ein ADS Notebook zu packen. Besten Dank an der Stelle nochmal.
Doch wie bin ich überhaupt dazu gekommen, so ein Notebook zu erstellen? Nun, in meiner Rolle als DBA habe ich dann und wann auch mal mit Kerberos Themen zu tun. Das klassische Beispiel ist: Ein Anwender greift von seinem Rechner auf einen Server mit SQL-Server Reporting Services zu. Die Reports verweisen mit der Datenquelle auf einen MS SQL Datenbankserver. Dabei ist die Datenquelle so konfiguriert, dass die Windows Anmeldeinformation des Anwenders genutzt werden soll. Also haben wir den „klassischen“ Doppel Hopp (Double-Hop). Damit so etwas in einem Netzwerk mit Active Directory ordentlich funktioniert, brauchen wir sauber registrierte Service Principal Names, ein oder mehrere Servicekonten, welche auf den oder die SPNs die Anmeldeinformationen weiterreichen können, usw.
An und für sich ist so ein Setup relativ simpel. Aber wenn man, so wie ich, noch die Anforderung erhält, dass auch ein DNS-Alias mit konfiguriert werden soll und man die diversen Dienste (SQL Server, Analysis Services…) unter dedizierten Dienstekonten betreibt, dann muss man doch immer wieder überlegen, was wo wie konfiguriert werden muss. Im weiteren Verlauf dieses Artikels halte ich alles relativ einfach. Im Notebook selbst sieht man dann schon, wie flexibel man das alles einsetzen kann.
Also kurz meine eigentliche Aufgabe (etwas kondensiert) erläutert: für eine Webapplikation wurden spezifische Aliase im DNS angefragt, um etwas mehr Flexibilität zu haben bei etwaigen Umzügen etc. pp. Also so etwas wie SQL-MYAPP-DB-P. DOMAIN.LOCAL und SQL-MYAPP-AS-P. DOMAIN.LOCAL für eine Verbindungszeichenfolge zum Datenbankserver und einmal für die Analysis Services (ok, ist derzeit der gleiche Server, aber ggf. wird der Dienst ja mal umgezogen).
Der erste Teil meines Notebooks macht genau das, ein oder mehrere Aliase für einen Server im DNS registrieren. Ich habe direkt mehrere Zellen erstellt, um auch die Anforderung abzudecken, dass man ggf. verschiedene Aliase anlegen möchte für Produktion, Test oder Entwicklung. Kommt aber immer auf die jeweilige Umgebung und Namenskonvention an. Your mileage may vary wie man so schön sagt.
| #'CNAME/Alias erstellen | |
| #''''''''''''''''''''''''' | |
| # install-module dnsserver | |
| <# Reminder | |
| https://docs.microsoft.com/en-us/powershell/module/dnsserver/?view=win10-ps | |
| DnsServer Module can be obtained either by installing DNS Server role or adding the DNS Server Tools part of Remote Server Administration Tools (RSAT) feature. | |
| #> | |
| $domain = 'domain.local' | |
| $AliasName = 'SQL-MyApp.domain.local' | |
| $targetServer = 'MyTgtServer' | |
| $target = $targetServer + '.' + $domain | |
| $target | |
| $DNSSrv = 'MyDNS.Domain.local' | |
| Add-DnsServerResourceRecordCName –Name $AliasName –HostNameAlias $target –ZoneName $domain –Verbose –ComputerName $DNSSrv –WhatIf |
Mit einem Alias ist es jedoch nicht getan, denn man braucht als nächstes auch passende ServicePrincipalNames für die jeweiligen Dienstekonten. Das Konto, unter dem der SQL-Server Dienst betrieben wird, braucht also zum Beispiel den Eintrag MSSQLSvc/SQL-MYAPP-DB-P. DOMAIN.LOCAL
Der eigentliche Befehl, um einen SPN Eintrag zu tätigen ist dabei nur ein Einzeiler. Aber wenn man das Ganze öfter wiederverwenden oder so ein Notebook vielleicht auch als Dokumentation nutzen will, dann nutzt man halt diverse Variablen. Ich bin, was das angeht, auch eher so der PowerShell Spaghetticode Schreiber, wie ihr seht:
| #SPN SETZEN DB Service | |
| $MeinServiceKto = "MyServiceAccount" | |
| #Variablen fuer Alias, Environment, Dienst | |
| $AliasApp = "MyApp" | |
| $TargetEnv = "P" | |
| $Svc = "MSSQLSvc" | |
| $domain = 'domain.local' | |
| $MeinServiceKonto = $MeinServiceKto + $TargetEnv | |
| $MeinServiceKonto | |
| $DBSPNs2Add = @() | |
| $DBSPNs2Add += $svc+ '/SQL-'+$AliasApp+'-DB-'+$Targetenv+'.'+$domain+':1433' #still a bit static | |
| $DBSPNs2Add += $svc+ '/SQL-'+$AliasApp+'-DB-'+$Targetenv+'.'+$domain #still a bit static | |
| $DBSPNs2Add | |
| $mySvcAcc = Get-ADServiceAccount –Identity $MeinServiceKonto | |
| $mySvcAcc.DistinguishedName | |
| #SPN hinzufügen | |
| Set-ADObject –Identity $mySvcAcc –Add @{"ServicePrincipalName"=$DBSPNs2Add} –Verbose –WhatIf |
Und dann kommt der letzte Teil, wo man eventuell auf die Hilfe der Kollegen angewiesen ist. Ihr müsst ja wissen welches das oder die Konten sind, welche(s) am Ende die Anmeldeinformationen weiterreichen soll(en). In meinem Fall war es z.B. das Konto eines Application Pools in den Internet Information Services.
Da im vorangegangenen Code Block ja die Variable $DBSPNs2Add ja die benötigte Info enthält, nutze ich diese einfach weiter in meinem Skript bzw. in meinem Notebook.
| $Account = "MyNormalSvcAccount" | |
| $mySvcAcc = Get-ADUser –Identity $Account | |
| Set-ADObject –Identity $mySvcAcc –Add @{"msDS-AllowedToDelegateTo"=$DBSPNs2Add } –Verbose |
Das komplette Notebook findet Ihr auf GitHub:
Ihr könnt es Euch hier aber auch einfach einmal angucken:
Am Ende des Notebooks habe ich auch wieder mehr als eine Code Zelle. Je nachdem, ob man für ein normales Dienstkonto, ein (group)ManagedServiceAccount oder ein Computerkonto die Delegierung setzen möchte.
Vielen Dank fürs Lesen.
