Office 365 PowerShell – 5. del

V prejšnjih člankih iz te serije sem pisal o upravljanju storitev O365 s pomočjo PowerShella (denimo o upravljanju SharePoint in SharePoint Online). Velikokrat pa pri svojem delu potrebujemo tudi skripte za posamezno storitev, ki se mora izvajati po urniku. V tem primeru se nam takoj poraja vprašanje, kako lahko varno shranimo gesla za administrativne račune in zaganjamo skripte s pomočjo »Task Schedulerja«.

Pri shranjevanju gesel za PowerShell skripte imamo na voljo kar nekaj načinov. V tem članku bom skušal prikazati, kateri so slabi in kateri so primerni za produkcijsko uporabo.

1. način: poverilnice v skripti

Prvi način, ki ga bom prikazal, je način, ki se ga moramo izogibati. V članku je samo zato, ker želim prikazati slabo prakso pisanja skript z uporabo uporabniškega imena in gesla, ki sta »zapečena« v skripti.

#Not cool
$user="user@contoso.com"
$pass=ConvertTo-SecureString -AsPlainText -Force 'Pa$$w0rd'
$credentials=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $userName, $Password

Connect-MsolService -Credential $credentials

V tem primeru vidimo, da v skripti naredimo nov PS Credential objekt iz podatkov, ki jih beremo direktno iz skripte. To ima lahko zelo velike posledice, saj lahko vsak, ki ima dostop do skripte, prebere poverilnice in potencialno to zlorabi.

2. način: poverilnice v kriptirani datoteki

V drugem primeru bom predstavil način, kako lahko geslo varno shranimo v kriptirani datoteki. S tem načinom si lahko zagotovimo to, da lahko samo uporabniški račun, ki je ustvaril kriptirano datoteko z geslom, geslo tudi dekriptira.

# Create-EncryptedCredentialFile
$credentials = Get-Credential

$filename = "C:\temp\CliXml.xml"
$credentials | Export-CliXml -Path $filename

$xml=Import-Clixml -Path $filename
$xml.UserName
$xml.Password

$credentials=New-Object -TypeName System.Management.Automation.PSCredential `
-ArgumentList $xml.UserName, $xml.Password 

Connect-MsolService -Credential $credentials

Za ustvarjanje kriptirane datoteke je najbolj pomembna vrstica:

$credentials | Export-CliXml -Path $filename

Ta vrstica kode zapiše »credentials« objekt v izbrano datoteko:

Iz slike lahko razberemo, da je uporabniško ime napisano v obliki »clear text«, medtem, ko je geslo že kriptirano. Kriptiranje gesla se v tem primeru izvede s pomočjo Windows Data Protection API (DAPI) metod. Prednost, ali pa v nekaterih primerih tudi slabost te metode je, da lahko samo uporabnik, ki je geslo kriptiral, nato geslo tudi dekriptira.

3. način: uporaba Windows Credential Managerja

3. metoda, ki je pravzaprav zelo podoba načinu 2, je uporaba Windows Credential Managerja. Credential Manager prav tako uporablja DAPI za kriptiranje gesel, vendar pa v tem primeru ne potrebujemo datoteke, kjer bi imeli shranjena gesla. Za uporabo Windows Credential Managerja v PowerShell okolju si moramo najprej namestiti dodatek za PowerShell, ki ga lahko dobimo na spletni strani PowerShell Gallery:

PowerShell Gallery | CredentialManager 2.0

https://www.powershellgallery.com/packages/CredentialManager/2.0

Namestitev lahko izvedemo tudi v PowerShell okolju z ukazom:

Install-Module -name credentialmanager

Naslednji korak je, da v Credential Manager zapiše poverilnice. To izvedemo z ukazi:

$credentials=Get-Credential
New-StoredCredential -Credentials $credentials -Target PikaOktober

Za uporabo poverilnic v skripti pa moramo seveda poverilnice tudi pridobiti iz Credential Managerja. To lahko zelo preprosto izvedemo s pomočjo ukaza:

$managedCred = Get-StoredCredential -Target PikaOktober
Connect-msolService -Credential $managedCred

V Windows Credential Managerju lahko nato seveda tudi preverimo ali naš zapis obstaja.

Iz slike lahko vidimo, da nam je skripta res ustvarila nov zapis in nato lahko kadarkoli uporabimo poverilnice v naših skriptah, brez da bi morali ponovno vpisovati uporabniško ime in geslo. Poleg tega pa je seveda to zelo dober način, da poverilnice uporabimo v skriptah po urniku na varen način, saj so tako poverilnice zaščitene s Windows DAPI.

S tem člankom, se je tudi zaključila serija o O365 PowerShell. V primeru, da imate kakršnakoli vprašanja, me seveda kontaktirajte (podatki v podpisu).