In Version ScriptRunner 2018R1 dreht sich alles um dynamische PowerShell Abfragen. Mit dieser Version wird die vierte Generation der erfolgreichen Management-Plattform für PowerShell veröffentlicht. Der konsequente Ausbau mit diesen Funktionen unterstreicht die führende Rolle von ScriptRunner zur Automation und Delegation mit PowerShell.
PowerShell Script Policies mit dynamischen Abfragen
Im Fokus der Entwicklungsarbeiten standen die Funktionen und der Ausbau des Regelwerkes zur kontrollierten Ausführung von Scripten. Mit dynamischen Abfragen ergeben sich neue Möglichkeiten für die erweiterte Interaktivität in delegierten Aktionen. So können Administratoren und Helpdesk innerhalb der automatisch erzeugten Weboberfläche nun nicht nur Formulare befüllen, sondern in diesen bereits dynamische Abfragen und Auswahllisten nutzen.
Die Abfragen ermöglichen dynamische Eingaben für einen Parameter per selektierter Vorauswahl. So muss der Anwender den Parameterwert für das Script, z.B. den SamAccountName eines Benutzers, nicht mehr kennen und manuell eingeben, sondern kann den Anwender bequem aus einer Liste auswählen. Der Unterschied zu den bereits unterstützen Validate Sets besteht in der Dynamik der Auswahlliste.
Abfragen können an verschiedene Quellen gerichtet werden:
- Active Directory-Objekte, einschließlich trusted und non-trusted Domains
- Abfrage-Scripte mit voller Script-Flexibilität
- Dynamisch sich ändernde oder statische Dateien
- Statische Listen
Eine Abfrage liefert immer zwei Ergebnisse, eine Liste mit Anzeigewerten und eine Liste mit den zugehörigen Parameterwerten. Der Anzeigewert dient der Verständlichkeit der Auswahl in der Darstellung beim Anwender. Der Parameterwert wird zur Laufzeit an eine Script-Variable übergeben. Beide Werte können identisch sein. Wird kein Anzeigewert erzeugt, wird automatisch der Parameterwert angezeigt.
Abb. 1 – Schema einer dynamischen Powershell-Abfrage
Die oben dargestellte Abfrage liefert die Anzeige- und Parameterwerte für alle OU im Active Directory mit Übereinstimmung der Sucheingabe „user“. Mit Auswahl des Anzeigewertes „Users | Deutschland“ wird der Script-Variablen $OUPath als Parameterwert der Distinguished Name der OU übergeben.
Besonders interessant für die täglichen Anwendungsfälle sind kaskadierte Abfragen. Hierbei werden mehrere Abfragen logisch hintereinander geschaltet. Die Abfragequellen können dabei gemischt verwendet werden. Bei kaskadierten Abfragen geht der Parameterwert der vorangegangenen Abfrage als Eingabegröße in die aktuelle Abfrage ein. Er steuert somit das Abfrageverhalten selbst.
Abb. 2 – Arbeitsweise von kaskadierten PowerShell Abfragen
Die dargestellte Kaskade ermittelt in der ersten Abfrage den Distinguished Name einer ausgewählten OU im Active Directory, hier für Germany/Customer/ASR/LOCAL, und verwendet diesen zur Steuerung der zweiten Abfrage. Diese zweite Abfrage ermittelt alle Gruppen in der ausgewählten OU. Das Ergebnis liefert bei der Auswahl der Gruppe den zugehörigen SAMAccountName, hier „G-GRP-012“. Dieser wird an die Script-Variable $Group sowie die dritte Abfrage übergeben. Die dritte und letzte Abfrage löst nun die Gruppe komplett in seine Mitglieder auf. Die Auswahl eines Mitgliedes übergibt den SAMAccountName des Benutzers, hier „G001“, als Parameterwert an die Script-Variable $User.
Mit einer solchen Anfragen-Kaskade könnte beispielsweise ein PowerShell Script zum Entfernen eines Benutzers aus einer bestimmten Gruppe parametrisiert werden. Der wesentliche Vorteil liegt dabei in der generischen Wiederverwendbarkeit der Abfragen und des Scripts für unterschiedlichste OUs, Gruppen und Benutzer ohne, dass Änderungen am Script selbst nötig wären. In Verbindung mit verschieden vorkonfigurierten ScriptRunner-Aktionen lassen sich so sehr einfach Subadministrations-Szenarien für bestimmte OUs umsetzen.
Es könnten ebenfalls für Rechteänderungen die Benutzer oder Verzeichnisse, Datenbanken, virtuelle Maschinen u.v.a.m. automatisch abgefragt und die Ergebnisse dem Anwender zur Auswahl gestellt werden. Im Helpdesk kann so ein AD-Anwender über seinen UPN, E-Mail-Adresse oder andere Eigenschaften gezielt ermittelt und sein SAMAccountName automatisch als Parameter an das Script übergeben werden.
Konfiguration dynamischer Abfragen für PowerShell
Das sehr einfache Erstellen von Abfragen und deren Einbindung in das Regelwerk zur Scriptausführung, den ScriptRunner Aktionen, war ein Hauptaugenmerk bei der Entwicklung von ScriptRunner 2018. Am auffälligsten treten die Abfragen im erweiterten Hauptmenü in Erscheinung. Dort kann man mit dem Menüpunkt „New+“ sofort aus einer Liste die gewünschte Quelle für eine Abfrage auswählen.
Abb. 3 – Erstellen einer Query durch Auswahl der Quelle
Je nach Quelle der Abfrage sind Einstellungen für deren Ausführung möglich.
Dabei gibt es unterschiedliche Möglichkeiten der Liste mit den Anzeigewerten für den Anwender:
- Anzeige der Werte als einfaches Dropdown-Menü
- Anzeige der Werte als einfaches Dropdown-Menü mit Mehrfachauswahl, sofern die Script-Variable den Datentyp String-Array besitzt
Anzeige der Werte als Dropdown-Menü mit einem multifunktionalen Suchfeld. Es können Buchstaben, Silben oder Wörter in das Suchfeld VOR der Abfrage eingegeben werden, um die angezeigte Ergebnismenge zu begrenzen. NACH der Abfrage dient das Suchfeld direkt zum Filtern in der Ergebnismenge der Abfrage.
Abb. 4 – Darstellung der Abfrageergebnisse in der Delegate App
Zusätzlich unterscheiden sich die Abfragen durch ihren Cache-Mechanismus:
- Abfragen in Echtzeit werden direkt zur Laufzeit an die Quelle gerichtet; das ist insbesondere bei kaskadierten Abfragen notwendig
- Abfragen mit zeitgesteuertem Cache, z.B. für sich regelmäßig verändernde Dateien oder Abfragen ohne Echtzeit-Anforderungen
- Abfragen mit automatischem Cache-Algorithmus; hierbei wird die Abfrage im Kontext des Aktualitätsgrades automatisch im Hintergrund vom ScriptRunner Host ausgeführt
Abb. 5 – Einstellungsoptionen für die Abfragen
Die Konfiguration der eigentlichen Abfrage hängt von den Möglichkeiten der Quelle ab. Exemplarisch soll hier die Abfrage von Gruppen aus dem Active Directory vorgestellt werden. Die Abfrage von Objekten aus dem Active Directory erfolgt über LDAP. Um die Abfrage effektiv durchführen zu können ist die Parametrisierung der Abfrage sinnvoll. Folgende Parameter helfen dabei:
- Domäne, in welcher nach der Gruppe gesucht werden soll
- Einschränkung auf den Objekttyp „Gruppe“
- Einschränkung auf den Typ der Gruppe; Sicherheitsgruppe oder Verteilergruppe
- Einschränkung auf einen Teilbaum des Active Directory
- Erforderlicher Parameterwert, der ermittelt werden soll
Angaben zur Darstellung des jeweiligen Anzeigewertes
Abb. 6 – Konfiguration einer Abfrage von Gruppen aus dem Active Directory
In obiger Abbildung wurden folgende Einstellungen für die Abfrage von Gruppen vorgenommen.
- gesucht wird in der Domäne, in welcher auch ScriptRunner residiert
- gesucht wird ausschließlich nach Sicherheitsgruppen ohne weitere Attribut-Filter; die Verwendung von Attributfiltern wird im nächsten Abschnitt vorgestellt
- gesucht wird in der gesamten Domäne; die Suche wird nur dann auf einen Teilbereich eingeschränkt, wenn in einer Aktion eine übergeordnete Abfrage eine andere SearchBase einsteuert; die SearchBase kann auch direkt z.B. durch Eingabe von „OU=Customer,DC=asr,DC=local“ eingeschränkt werden
- als Parameterwert wird das Attribut „SAMAccountName“ verwendet
- als Anzeigewert im Dropdown-Menü wird das Attribut „cn“, also der Common Name verwendet
Die Zuordnung der Abfragen zu einer Scriptausführung erfolgt über das Regelwerk für die ScriptRunner Aktion. In dieser wird u.a. festgelegt auf welchen Systemen das Script ausgeführt werden darf, wer berechtigt ist eine Aktion zu starten usw. Zentraler Teil einer Aktion ist die mögliche Vorbelegung von Script-Variablen. Dadurch können mit dem gleichen Script unterschiedlich voreingestellte Aktionen erstellt werden.
Durch die Zuweisung von Abfragen zu Script-Variablen in ScriptRunner Aktionen lassen sich nun voll dynamische Anwendungsfälle abbilden. Die Zuweisung erfolgt jeweils für einzelne Variablen.
Abb. 7 – Zuweisung von Abfragen zu Script-Variablen in einer Aktion
Die Script-Variable $OUPath dient ausschließlich zur Steuerung der zweiten Abfrage von Gruppen aus dem Active Directory. Dieser Script-Variablen wurde eine Abfrage an eine statische Liste mit Einträgen zugewiesen.
Der Script-Variablen $Group wurde die Abfrage „Group list from AD root …“ zugewiesen und gleichzeitig die Variable $OUPath als Eingabewert aus der ersten Abfrage zugeordnet usw. Hierdurch wird die SearchBase auf die zuvor ausgewählte OU eingegrenzt.
Komplexe Abfragen im Active Directory
Besonders interessant in der Anwendung sind Konfigurationen mit spezifischen Abfrageeinstellungen. So können weitere Filter eingestellt oder direkt LDAP Abfragen erstellt werden.
Abb. 8 – Spezifische Abfrage von Anwendern der Abteilung Marketing
In der obigen Abbildung werden Anwender abgefragt, welche sich in der OU Customer befinden und welche das AD Attribut [department] = „Marketing“ erfüllen. Die Anzeige wurde so eingestellt, dass nicht nur die Namen der Anwender, sondern auch deren E-Mail-Adresse und deren Lokation (sofern belegt) angezeigt wird.
Sinnvoll kann an dieser Stelle für eine Abfrage auf Gruppen beispielsweise ein Filter auf das AD Attribut [cn] sein, um auf alle Gruppen mit „Admin“ im Namen zu filtern.
Ein Testmodus für die Abfrage dient der schnellen Verifikation der konfigurierten Abfrage.
Abb. 9 – Ergebnis des Testlaufes einer AD-Abfrage mit Angabe der Laufzeit.
Die komplexe Abfrage aller Benutzerkonten unterhalb einer OU, bei denen bei der nächsten Anmeldung das Passwort zu ändern ist, kann mit einer direkten LDAP-Abfrage umgesetzt werden.
Abb. 10 – Komplexe Abfrage mit LDAP
Abfragen per PowerShell-Script
Die volle Flexibilität von Abfragen wird mit Abfrage-Scripten erreicht, da sich beliebige Abfragen per PowerShell umsetzen lassen. Je nach gewählter Option kann festgelegt werden, wo die Abfrage ausgeführt werden soll:
- Lokale Ausführung auf dem ScriptRunner Host
- Entfernte Ausführung immer auf dem gleichen System. Damit lassen sich bspw. SQL-Datenbanken abfragen, egal auf welchem System das eigentliche Script dann ausgeführt wird.
- Entfernte Ausführung immer auf dem System, auf dem auch das eigentliche Script ausgeführt werden soll. Auf diese Weise lassen sich mit einer einzigen Query zur Laufzeit unterschiedliche Virtualisierungs-Hosts nach aktiven VMs abfragen.
Die nachfolgende Abbildung zeigt eine generische Abfrage von Exchange Datenbanken.
Fig. 11 – Querying Exchange Databases
Auch Abfragen per Script können in einer Kaskade verwendet werden. Im nachfolgenden Beispiel kann ein auszuwählender Workflow auf einer zuvor ausgewählten Liste in SharePoint Online gestartet werden. Durch die generische Gestaltung der Scripte und der Abfragen können nun Aktionen für verschiedene SharePoint Sites mit den gleichen Abfragen und mit dem gleichen Workflow-Script gestaltet werden.
Das erste Abfrage-Script fragt eine SharePoint-Site auf SharePoint-Listen mit Workflows ab. Das Script hat zwei Variablen, $SiteURL und $userCredential. Beide werden über die Voreinstellungen der Aktion eingesteuert. Die zweite Abfrage erzeugt eine Auswahl an Workflows für die zuvor ausgewählte Sharepoint-Liste. Das Script für die Abfrage hat einen zusätzlichen Parameter $listTitle, um die Abfrage der Workflow für die zuvor ausgewählte Sharepoint-Liste zu steuern.
Abb. 12 – Kaskadierte Abfragen per PowerShell-Scripten
-
Mit der Delegation dieser Aktion wäre nun ein Helpdesk oder eine ausgewählte Gruppe von Endanwendern in der Lage, eine entsprechende SharePoint-Liste auszuwählen und deren Aktualisierung zu starten. Die Ausführung der PowerShell Scripte auf SharePoint Online unterliegt weiterhin komplett den Richtlinien von ScriptRunner. Die Trennung der Anwenderrechte zum Starten des Workflows und die dafür notwendigen administrativen Rechte für die Ausführung der Abfrage- und Funktionsscripte sorgt für höchstmögliche Reproduzierbarkeit und Sicherheit.
Fazit
Helpdesk und Administratoren profitieren mit den Abfragen von sehr mächtigen Funktionen gleichermaßen:
- Hoher Grad an Interaktivität
- Dynamisierte Parametereingaben durch gezielte Abfragen
- Vielfältige, granulare Einstellmöglichkeiten für Abfragen
- Einmal konfigurierte Abfragen können in verschiedenen Aktionen gleichermaßen angewendet werden, wie beispielsweise die Anwender- und Gruppenabfragen.
- Einfache Suche und Auswahl zur Laufzeit in der Browseroberfläche
- Reduktion von PowerShell Code durch kaskadierte Abfragemöglichkeiten
- hohe Sicherheit durch PowerShell Script Policies in ScriptRunner
Unterstützung von implizitem PowerShell Remoting
Die Möglichkeiten zur Ausführung von PowerShell wurde nun für weitere Szenarien ausgebaut. Mit der Möglichkeit zum impliziten Remoting stehen nun in ScriptRunner alle Möglichkeiten zur Verfügung, welche sich mit Import-PSSession auf der Kommandozeile bieten. Diese Option ist insbesondere, aber nicht ausschließlich, für den Einsatz von ScriptRunner mit Microsoft Exchange sehr interessant. Beim Einsatz dieser Option verhält sich ScriptRunner gleichartig zur Exchange Management Shell. Eine Rekonfiguration der PowerShell-Einstellungen am Exchange Server entfällt damit zukünftig. Zudem können die in die Session importierten Kommandos begrenzt werden.
Abb. 13 – PowerShell Remoting Session Settings
Azure AD 2.0 Support in Office 365
ScriptRunner unterstützt direkt die Office 365 Service Endpoints für Directory, Exchange Online, SharePoint Online und Skype4Business Online. Die Plattform übernimmt dabei die komplette Steuerung der PowerShell-Kommunikation mit Office 365. Mit der Unterstützung von Azure AD 2.0 stehen nun sowohl die Funktionen von MS online als auch der neusten Version von Microsofts Azure AD uneingeschränkt zur Verfügung.
Unterstützung für Edge-Browser
Neben der Unterstützung für Internet Explorer 11, Google Chrome, Firefox und Opera wird mit der neuen Version auch Microsofts neuer Browser Edge unterstützt. Sowohl die Web App für die Administratoren als auch die Delegate App für den Service Desk können nun auch Edge verwenden. Die Java-Script-basierten Windows Apps stehen weiterhin als Option zur Verfügung.
Security Einstellungen nun im Setup verfügbar
Bisher waren einige Sicherheitseinstellungen am ScriptRunner Web Service manuell zu konfigurieren. Ab der Version 2018 können diese Einstellungen mit dem Setup vorgenommen werden, sofern gültige Zertifikate auf dem ScriptRunner Host vorhanden sind. Zusätzlich wurde das PowerShell Cmdlet „Set-ASRUri“ um diese Einstellungen erweitert.
ScriptRunner kostenlos testen
Wir stellen Ihnen ScriptRunner als 30-Tage Testinstallation gerne kostenlos zur Verfügung oder geben Ihnen eine kurze Produkt-Demo. Mehr Informationen finden Sie hier.
Zusammenhängende Posts
Über den Autor:
Frank Kresse ist Head of Product und CEO von ScriptRunner. Als Erfinder der Automatisierungs- und Delegationslösung für PowerShell berät er Kunden zu Use-Case-Szenarien und entwickelt Lösungen für die Automatisierung und die Digitalisierung ihrer Prozesse. Außerdem ist er an Technologie-Start-ups beteiligt.