Seit DSM-Version 2015.1 ist es ja möglich, das System ohne clientseitige Konten zu betreiben – der Service-Installer kann im Kontext des LocalSystem-Accounts ausgeführt werden und auch der Zugriff auf das Depot für das Staging der Pakete kann in Active Directory Umgebungen mit dem Computerkonto erfolgen. Somit sind in der Konfigurationsdatenbank nur noch die Credentials von Management Point Konten gespeichert, die aber durch die asynchrone Verschlüsselung wirksam geschützt sind.

Trotzdem ist es immer wieder erforderlich, Setup-Programme oder andere Aktionen im Rahmen von DSM-Scripts in einem definierten Benutzerkontext auszuführen, um Zugriff auf Netzwerkressourcen wie Back-End Systeme, Datenbanken, Fileserver oder ähnliches zu haben. Hierfür wird in aller Regel innerhalb der eScripts der Befehl RunAsEx verwendet und dort der Benutzername und das zugehörige Kennwort angegeben.

Dieser Ansatz bringt jedoch unter mehreren Gesichtspunkten Nachteile mit sich...

Bei Verwendung dieser Methode werden sowohl Benutzername als auch das Kennwort eines Domänenkontos hartkodiert im eScript gespeichert. Sollte also die Anforderung bestehen, dass das Kennwort dieses Benutzerkontos einmal geändert werden muss, so müssen auch alle Scripts angepasst werden, in denen das Konto verwendet wird.

Ein weiterer und sicherlich unter Security-Aspekten gravierenderer Nachteil ist, dass die Credentials im Dateisystem abgelegt werden, auf das in der Regel alle Benutzer zumindest lesenden Zugriff haben. Zwar wird das Kennwort verschlüsselt abgespeichert, trotzdem können aber natürlich auch Benutzer mit unlauteren Absichten auf die Scriptdatei zugreifen und versuchen, das Kennwort über Brute-Force-Angriffe oder anderen Methoden zu knacken.

Da es sich um ein Kennwort handelt, das auf Client-Seite entschlüsselt werden muss, kann hier die hochsichere asynchrone Verschlüsselung der Management Point Kennwörter konzeptbedingt nicht zum Einsatz kommen. Synchrone Verschlüsselungsverfahren sind jedoch stets einfacher angreifbar, auch wenn mittlerweile in DSM ein deutlich besserer Verschlüsselungsalgorithmus zum Einsatz kommt wie noch in früheren Versionen...

In einem Kunden-Szenario haben wir daher vor kurzem einen Lösungsansatz gesucht, wie die Anforderung, Prozesse unter definierten Benutzerkonten auszuführen, sicherer abgebildet werden kann. Ein Ergebnis dieses Workshops möchte ich hier kurz beschreiben, auch weil ich davon ausgehe, dass diese Möglichkeit auch erfahrenen DSM-Administratoren bisher nicht bekannt ist – zumindest mir war sie das vorher nicht.

Wenn ein definierter Username und Kennwort zwingend benötigt werden, dann müssen diese irgendwo abgelegt und an das System übergeben werden, damit DSM einen Prozess unter diesen Credentials erzeugen kann. Die Idee war daher, die Werte nicht innerhalb der Scriptdatei zu speichern, sondern die vertraulichen Daten innerhalb der DSM-Datenbank abzulegen, die ja deutlich besser vor "neugierigen Augen" geschützt werden kann, als das Dateisystem der DSM-Depots mit den Paketen.

Um benutzerdefinierte Daten in der DSM-Datenbank zu speichern, bietet sich die Verwendung von Schema-Erweiterungen oder Installationsparametern an. Da es sich im vorliegenden Fall ja explizit um Parameter handelt, die für die Ausführung eines Pakets benötigt werden, haben wir uns für Installationsparameter entschieden. Es wurden also zwei Installationsparameter definiert, einer für den Benutzername (als normaler Text-Parameter) und einer als Kennwort-Parameter, der den Inhalt verschlüsselt in der Datenbank speichert.

Es wurden bewusst keine Vorgabewerte für beide Parameter eingetragen. Da auch die Eigenschaft "Wert darf leer sein" nicht eingeschaltet wurde, müssen die Werte dieser Parameter bei der Zuweisung des entsprechenden Pakets im Rahmen des Policy-Assistenten zwingend angegeben werden.

Das eigentliche Problem war nun, wie die Werte der Installationparameter an den RunAsEx-Befehl übergeben werden können.

Zunächst hatte ich einfach versucht, im Feld "Benutzername" im Abschnitt "Folgendes Konto verwenden" den Installationparameter "Username" und im Feld "Kennwort" den Installationparameter "Password" einzutragen.

Da DSM Variablen und Installationsparameter automatisch vorschlägt, sobald man das Prozentzeichen eintippt und die Auswahl aus dieser Liste erfolgte (sodass Tippfehler ausgeschlossen werden konnten), schlugen Tests mit diesem Vorgehen aber reproduzierbar mit einem "falscher Username oder Kennwort" Fehler fehl.

Die zweite Idee war, die Werte der Installationsparameter auf der Kommandozeile, also im Feld "Parameter" des RunAsEx-Befehls an das auszuführende Executable zu übergeben. Da es sich um ein PowerShell-Script handelte, hätte man innerhalb des Scripts auf die Kommandozeilen-Parameter zugreifen und die erforderlichen Aktionen impersonifiziert ausführen können.

Dies wurde jedoch verworfen, weil es über den Windows Task Manager ja problemlos möglich ist, sich die Kommandozeile eines Prozesses anzeigen zu lassen. In dieser wären dann Username und Kennwort im Klartext zu lesen gewesen – ein inakzeptables Sicherheitsloch. Außerdem ist dieser Ansatz ungeeignet, wenn Executables von Drittherstellern ausgeführt werden müssen, die die Angabe von Credentials auf der Kommandozeile nicht unterstützen.

Schließlich half uns der Ivanti-Support schnell und unbürokratisch aus der Klemme (an dieser Stelle mal ganz offiziell ein herzliches Dankeschön an Manuel und Kollegen!) indem er mir "den Trick" verriet, wie man einen Installationsparameter im Kennwort-Feld des RunAsEx-Befehls referenzieren kann: Es ist dazu notwendig, in die Experten-Ansicht der Packaging Workbench zu wechseln. Dort kann der verschlüsselte Kennwort-String mit dem Namen des Installationsparameters überschrieben werden:

Nach dem Speichern und dem Wechsel zurück in die Standardansicht des Script-Editors, ist dann auch zu sehen, dass der Befehl nun sowohl für den Benutzer als auch für dessen Kennwort den Wert des Installationsparameters verwendet.

Nachdem diese Änderungen vorgenommen worden waren, belegten die Tests, dass nun die Prozesse mit dem über die Installationsparameter spezifierten Anmeldeinformationen erzeugt wurden und die Anforderung war erfüllt.