Die Azure MFA Erweiterung für den NPS Server von Microsoft bietet einige erweiterte Parameter die Microsoft in der aktuellen Dokumentation auch erwähnt. Jedoch zeigt sich bei der Analyse mit dem Process Monitor das dies bei weitem nicht alle Parameter sind, die die Erweiterung verarbeiten kann.

Die folgende Tabelle ist eine Liste mit allen von mir gefundenen Parametern. Hierbei ist zu beachten das viele davon nicht geändert werden sollten, da dadurch die Erweiterung nicht mehr funktionieren würde. So ist es sicherlich keine gute Idee z.B. die URL für den Azure MFA Service zu ändern.

Ich habe mich die letzten Tage ein wenig mit dem Azure MFA Plugin für den Network Protection Server beschäftigt und bin relativ schnell bei dem(!) Artikel bzgl. NPS, Azure MFA und Netscaler von Christiaan Brinkhoff gelandet. Für meinen Aufbau habe ich mich für eine verkleinerte Variante seiner Anleitung ohne Proxy und komplexe Request Policies entschieden.

NPS Konfiguration

Die Konfiguration des NPS sieht dann wie folgt aus:

• Radius-Clients
  • Mit welcher IP Adresse (NSIP oder SNIP) hängt vom Netscaler ab. (die Logs helfen hier schnell)
  • Vorsicht! der Netscaler kann nur Shared Secrets bis zu 31 Zeichen verarbeiten (Link); der NPS erzeugt jedoch bei einem Klick auf Generate eine Shared Secret mit 64 Zeichen.
• Es braucht nur mindestens eine Connection Request Policy die auf Localhost zeigt
  • hier nehmen wir die Default-Policy
• Zusätzlich wird eine Network Policy wie bei Christiaan beschrieben benötigt die folgendes enthält:
  • Condition: NAS Identifier -> MFA (damit wir auch noch andere Services authentisieren können)
  • MS-CHAPv2
• Die anderen Network Policies können weiter bestehen bleiben solange keine andere Policy vor unserer trifft (NPS arbeitet mit First Match)

[gallery size=“medium” ids=“634,636,635”]

Hallo liebe Leser,

ab sofort tritt dieser Blog unter einem neuen Namen auf.

Cloud Brothers

Die Namensänderung hängt vor allem damit zusammen, das zwei neue Autoren mitschreiben und meine Namenswahl von vor über 15 Jahren nicht mehr ganz passend ist.

Ich begrüße meine zwei lieben Kollegen Christoph Burmeister und Chris Brumm und freue mich auf Ihre tollen Beiträge.

Wer viel mit der PowerShell arbeitet, kommt nicht um Module aus der PS Gallery herum.

Die Module werden von Zeit zur Zeit aktualisiert und das kann dafür sorgen, dass Cmdlets, Funktionen, Aliase, usw. hinzugefügt, bzw. entfernt werden oder so angepasst werden, dass diese anders angesprochen werden müssen.

Mir ist dies vor ein paar Wochen bei dem Module cNtfsAccessControl aufgefallen, nachdem die DSC-Configuration auf einen Fehler hinauslief.

Zum anderen kommt es zu Problemen, wenn mehrere Versionen des gleichen Moduls auf einem Server installiert sind. Es ist zwar von Microsoft unterstützt und das Importieren von Modulen kann auch pro Version geschehen, aber persönlich finde ich diesen Ansatz ehr unsauber, da es in den meisten Fällen zu Verwirrungen führt und z.B. DSC-Configuations Probleme mit verschiedenen Versionen haben.

Beim Arbeiten mit Azure Automation kommt man schnell an den Punkt, dass ein Runbook ein zweites Runbook starten soll. Dabei möchte man meistens auch noch den einen oder anderen Parameter übergeben. Das ist alles kein Problem und schnell und einfach realisiert.

Interessant wird es jedoch wenn komplexere Objekte wie Arrays oder Hashtables übermittelt werden sollen.

Runbook mit Parametern starten

#region Connect to Azure with certificate
try {
    # Get the connection "AzureRunAsConnection "
    $servicePrincipalConnection = Get-AutomationConnection -Name "AzureRunAsConnection"
    Write-Output "Logging in to Azure..."
    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint   $servicePrincipalConnection.CertificateThumbprint | Out-Null
    # Switch Azure subscription
    Write-Output "Switch to Azure SubscriptionId $($servicePrincipalConnection.SubscriptionId)"
    Select-AzureRmSubscription -SubscriptionId $servicePrincipalConnection.SubscriptionId | Out-Null
} catch {
    if (!$servicePrincipalConnection) {
        throw "Connection $connectionName not found."
    } else {
        throw $_.Exception
    }
}
#endregion

#region Start new runbook
$AzureAutomationRunbook = "SuperFunRunbook"
$HybridWorker = "HybridWorkerGroup"

# Set parameters
$AzureRunbookParameter = @{
    "ParameterString" = "Blue Jeans"
    "ParameterArray" = @("BLUE","BLACK")
}
# Start runbook
Get-AzureRmAutomationAccount | Start-AzureRmAutomationRunbook -Parameters $AzureRunbookParameter -Name $AzureAutomationRunbook -RunOn $HybridWorker
#endregion

Im ersten Abschnitt liest das Skript über eine Activity die Informationen der Connection “AzureRunAsConnection” aus. Mittels dieser Informationen und dem, auf dem Hybrid Worker installierten, Zertifikat wird eine Verbindung zu Azure hergestellt und in die korrekte Subscription gewechselt.

Mit Desired State Configuration (DSC) hat Microsoft Sysadmins und DevOps Teams ein Tool an die Hand gegeben um Systemkonfigurationen zu beschreiben und nicht Installationen zu skripten.

Dieser deklarative Ansatz unterscheidet sich stark von dem semi-manuellen oder automatisierten Ansatz den viele Firmen heute noch betreiben. Es wird nicht mehr Codezeile für Codezeile ein SQL Server installiert und konfiguriert, sondern es wird definiert wie der SQL Server, wenn er installiert ist, aussehen soll. Den Rest übernehmen die DSC Ressourcen. Nicht nur wird so eine Dokumentation erstellt, sondern es macht diese Konfiguration reproduzierbar und versionierbar.