Hallo,
ich würde gerne mit einer Pipeline über Powershell onPrem AD Objekte anlegen.
Gibt es hier irgendwie die Möglichkeit Credentials für die Rechte im onPrem AD zentral abzulegen am besten nicht im Klartext?
Im Klartext könnte ich das in den Pipeline Variablen tun, aber vielleicht gibt es hier ja schon eine bessere Lösung.
Gruß
Thomas
Hallo Thomas,
hier ein paar Ideen die mir zu diesem Thema gekommen sind:
Option 1) Dem Computerobjekt des MMS Servers im AD entsprechende Rechte erteilen. Damit müssten Sie keine Credentials ablegen, da der Server sich selbst authentifizieren kann. Zu beachten dabei ist allerdings, dass nicht nur der MMS, sondern alle Dienste auf dem Server dieses Recht erhalten und entsprechend mit Vorsicht zu agieren ist.
Option 2) Ein SecureString als globale Variable im MMS speichern und in den Skripts ein Credential Objekt daraus bauen. Ist mit etwas mehr Aufwand verbunden, limitiert aber den Zugriff auf den MMS.
Option 3) Nutzung eines externen Secretstores wie Azure KeyVault (cloud), Hashicorp Vault (onprem) o.ä. Auf genaueres gehe ich hier Aufgrund der Komplexität nicht ein.
Eingebaute Funktionalitäten haben wir aktuell nicht, aber ich hoffe einer der Optionen oben konnte Ihnen eine entsprechende Idee geben.
Option 4) Ablage eines verschlüsselten Datensatzes auf dem MMS Servers und auslesen über das Skript.
Sowohl für Option 2 als auch 4 gibt es hier eine ganz gute Anleitung: How To Save and Read Sensitive Data with PowerShell – Microsoft Certified Professional Magazine Online (mcpmag.com)
Danke für die Antworten, das hat in der normalen Powershell schon mal funktioniert, rufe ich das Powershellscript allerdings im System context auf, was die Pipeline ja tut, dann bekomme ich ein Access denied. Mein Code sieht wie folgt aus.
[CmdletBinding()]
Param (
$ADGroup,
$ADUser,
$ADPwd
)
$encryptedPassword = $ADPwd | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PSCredential($ADUser, $encryptedPassword)
Start-Process powershell -Credential $credential
Im Parameter adUser übergebe ich einen ADUser und im Parameter adpwd das Passwort als systemsecret.
Ich vermute Sie stoßen hier auf eine Limitierung von SecureString.
Sofern nicht näher spezifiziert, verwendet SecureString DPAPI zum Verschlüsseln, allerdings im Benutzerkontext. Wenn das Skript nun unter SYSTEM läuft, kann der String nicht korrekt entschlüsselt werden.
Sollte dies zutreffen, stehen zwei Optionen zur Verfügung:
Verschlüsseln Sie die Daten als System. Hierzu können Sie beispielsweise PsExec verwenden, um eine PowerShell als SYSTEM zu öffnen.
Nutzen Sie den „-Key/-SecureKey“ Schalter von ConvertTo-SecureString. Damit wechselt der Verschlüsslungsmodus auf AES. Solange Sie den Schlüssel vorliegen haben, können Sie die Daten überall auslesen. Der Zugriff auf den Schlüssel sollte am Besten nur durch die Pipeline möglich sein, beispielsweise durch eine Datei mit entsprechenden Berechtigungen.
Danke für die Antworten, leider funktionieren beide Ansätze nicht. Wenn ich es richtig recherchiert habe ist das eine Einschränkung des System Users.
Hallo Thomas,
ich habe gerade nochmal verifiziert, dass Methode 1) funktioniert.
Dazu habe einen SecureString in einer System Powershell erstellt (via PSEXEC), als globale Variable gespeichert und in der Pipeline daraus ein PSCredential Objekt erstellt. Dieses konnte ich erfolgreich nutzen, um Get-AdUser aufzurufen.
Hier ein Beispiel zur Nutzung:
Hallo Julian,
danke für die Infos. Ich habe es jetzt mit deiner Anleitung auch hinbekommen.
