PRTG – ADM Events überwachen

Im einem der letzten Beiträge habe ich ein Powershell Modul vorgestellt, mit welchem man Daten vom Citrix ADM abgreifen kann.

Basierend auf diesem Modul habe ich bei uns einen PRTG Custom Sensor erstellt, welcher die Events aus dem ADM ausliest:

Dazu müssen erst einmal die Parameter von PRTG sowie das Modul selbst eingelesen und eine Verbindung zur Appliance hergestellt werden:

# Get parameter from PRTG
param (
[string]$server,
[string]$domain,
[string]$username,
[string]$password
)

# Import ADM PS module
$CustomSensors="C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\"
Import-Module $CustomSensors\PRTGCustomCitrixADM.psm1

# Create the ADM session
$ADMHost = "https://"+$server
$ADMSession = Connect-ADM -ADMHost $ADMHost -CredUser $username -CredPW $password

Damit dies funktioniert, muss der entsprechende Benutzer von PRTG auf dem ADM Leserechte haben. Weiter gehe ich nicht auf jede Zeile ein, dies kann im Script selbst nachgelesen werden. Hier beschreibe ich vor allem die wichtigsten Punkte, wie das auslesen der Events:

# Get the events from the ADM
$ActiveEvents = Invoke-ADMNitro -ADMSession $ADMSession -OperationMethod GET -ResourceType active_event
# Create the variable only with the active events content
$ActiveEvents2 = $ActiveEvents | Select-Object active_event

Es sollen im PRTG nicht alle ADM Meldungen gleich einen Alarm auslösen, daher habe ich div. Arrays für Ausschlüsse vorbereitet, welche bei Bedarf genutzt werden können:

# Prepare a device_entity_name exlusion list for PRTG outputs
# Add each device in quota with a comma (except the last line)
$DeviceExcludeList = $null
$DeviceExcludeList = @(
    "entity1",
    "entity.domain.pit"
)

# Prepare a failureobj exlusion list for PRTG outputs
# Add each failure object in quota with a comma (except the last line)
$FailureObjectExcludeList = $null
$FailureObjectExcludeList = @(
    "object1",
    "object2"
)

# Prepare a message exlusion list for PRTG outputs
# Add each message in quota with a comma (except the last line)
$MessageExcludeList = $null
$MessageExcludeList = @(
    "192.168.99.99"
)

Da auch vServer und Services vom ADC welche wieder hochkommen einen „Critical Event“ darstellen, habe ich diese beim Aufbereiten ausgeklammert:

    If ($Event.severity -eq "Critical"){
        # Filter out 'entityup' messages from critical state
        If ($Event.category -ne "entityup"){
            $RetState = $returnStateCritical
            $Events += [PSCustomObject]@{Severity=$Event.severity;SourceIP=$Event.source;SourceHost=$Event.hostname;Category=$Event.category;Entity=$Event.device_entity_name;State=[Int64]$RetState}
            $RetCritical = $RetCritical + 1
        }
    }

Innerhalb der „Major Events“ werden im ersten Schritt die vorher definierten Ausschlüsse gegengeprüft und mittels Variable $DeviceAlarm die weitere Verarbeitung bestätigt oder gestoppt:

        # Filter out known entities, failure objects etc. from major state
        # Set variable $DeviceAlarm, if the device isn't filtered
        
        $DeviceAlarm = $null
        
        ForEach ($ExcludedDevice in $DeviceExcludeList) {
            $Entity = $Event.device_entity_name
            If ($DeviceAlarm -or ($DeviceAlarm -eq $null)) {
                If ($Entity -notlike "*$ExcludedDevice*") {
                    $DeviceAlarm = $true
                }
                Else{
                    $DeviceAlarm = $false
                }
            }
        }
        
        If ($DeviceAlarm){
            ForEach ($ExcludedFO in $FailureObjectExcludeList) {
                $Entity = $Event.failureobj
                If ($DeviceAlarm -or ($DeviceAlarm -eq $null)) {
                    If ($Entity -notlike "*$ExcludedFO*") {
                        $DeviceAlarm = $true
                    }
                    Else{
                        $DeviceAlarm = $false
                    }
                }
            }
        }
        
        If ($DeviceAlarm){
            ForEach ($ExcludedMessage in $MessageExcludeList) {
                $Entity = $Event.message
                If ($DeviceAlarm -or ($DeviceAlarm -eq $null)) {
                    If ($Entity -notlike "*$ExcludedMessage*") {
                        $DeviceAlarm = $true
                    }
                    Else{
                        $DeviceAlarm = $false
                    }
                }
            }
        }

Falls ein „Major Event“ nicht durch einen Ausschluss gefiltert wurde, wird die Eventliste entsprechend aufbereitet. In diesem Schritt werden Meldungen von Services („svc“ im Namen) oder Service Groups („svg“ im Namen) zu einer Warnung herunter gestuft. Dies weil definiert wurde, dass im PRTG erst ein Alarm erscheint, wenn der komplette vServer und nicht ’nur‘ ein Service DOWN ist:

        # If device isn't excluded, add to monitoring array
        # Services (svc) or service groups (svg) returns a warning instead an alarm
        If ($DeviceAlarm){
            If (($Event.device_entity_name -like "*svc*") -or ($Event.device_entity_name -like "*svg*")) {
                $RetState = $returnStateWarning
                $Events += [PSCustomObject]@{Severity=$Event.severity;SourceIP=$Event.source;SourceHost=$Event.hostname;Category=$Event.category;Entity=$Event.device_entity_name;State=[Int64]$RetState}
                $RetWarning = $RetWarning + 1
           }
            Else {
                $RetState = $returnStateCritical
                $Events += [PSCustomObject]@{Severity=$Event.severity;SourceIP=$Event.source;SourceHost=$Event.hostname;Category=$Event.category;Entity=$Event.device_entity_name;State=[Int64]$RetState}
                $RetMajor = $RetMajor + 1
            }
        }

Im restlichen Skript wurden die einzelnen Daten mit einem vorgegebenen Wert gegen geprüft und die entsprechenden PRTG Ausgaben definiert.

Das Script muss nun in den Custom Sensors Ordner von PRTG gelegt werden und der Sensor kann entsprechend eingerichtet werden:

Parameter gem. Script-Beschreibung, Securitykontext vom Gerät

Das Resultat sieht dann wie folgt aus:

Viel Spass beim Nachbauen :-)




PRTG – Zertifikate mittels ADM überwachen

Im einem der letzten Beiträge habe ich ein Powershell Modul vorgestellt, mit welchem man Daten vom Citrix ADM abgreifen kann.

Basierend auf diesem Modul habe ich bei uns einen PRTG Custom Sensor erstellt, welcher die Ablaufdaten aus der SSL Zertifikatsübersicht ausliest:

Dazu müssen erst einmal die Parameter von PRTG sowie das Modul selbst eingelesen und eine Verbindung zur Appliance hergestellt werden:

# Get parameter from PRTG
param (
[string]$server,
[string]$domain,
[string]$username,
[string]$password
)

# Import ADM PS module
$CustomSensors="C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\"
Import-Module $CustomSensors\PRTGCustomCitrixADM.psm1

# Create the ADM session
$ADMHost = "https://"+$server
$ADMSession = Connect-ADM -ADMHost $ADMHost -CredUser $username -CredPW $password

Damit dies funktioniert, muss der entsprechende Benutzer von PRTG auf dem ADM Leserechte haben. Weiter gehe ich nicht auf jede Zeile ein, dies kann im Script selbst nachgelesen werden. Hier beschreibe ich vor allem die wichtigsten Punkte, wie das auslesen der Zertifikate:

# Get the certificates from the ADM
Invoke-ADMNitro -ADMSession $ADMSession -OperationMethod GET -ResourceType ns_ssl_certkey
$ActiveCerts = Invoke-ADMNitro -ADMSession $ADMSession -OperationMethod GET -ResourceType ns_ssl_certkey

Das Ablaufdatum konnte nicht einfach so verwendet werden, daher musste ich mittels einer Funktion dieses erst in einen String umwandeln und dann entsprechend sortiert wieder zurück geben:

# Function ConvertTo-DateTime
# Converts the dates from the certificates to a standardized format
Function ConvertTo-DateTime([string] $datetime) {
    # Removes double spaces
    $datetime2 = $datetime -replace '\s+',' '
    # Create an array and use the space as separator
    $arr = $datetime2 -split ' '
    # Reorder and create a readable date
    $validdate = $arr[3] +"-"+ $arr[0] +"-"+ $arr[1] +" "+ $arr[2]
    # Return the value
    return $validdate
}

Nun konnte ich jedes Zertifikat einzeln in ein Array schreiben mit den entsprechenden Common Names und Ablaufdaten:

# Create array with all the certification information
ForEach ($Cert in $ActiveCerts2.ns_ssl_certkey){
    
    $CertSubject = ($Cert.subject -split "," | ConvertFrom-StringData).CN
    $CertIssuer = ($Cert.issuer -split "," | ConvertFrom-StringData).CN
    $CertValidTo = ConvertTo-DateTime $Cert.valid_to
    # For troubleshooting
    #Write-Host $CertValidTo
    $Certs += [PSCustomObject]@{Host=$Cert.hostname;Subject=$CertSubject;Status=$Cert.status;Expiredate=$CertValidTo;IssuerCA=$CertIssuer}

}

Im restlichen Skript wurden die einzelnen Daten mit einem vorgegebenen Wert gegen geprüft und die entsprechenden PRTG Ausgaben definiert.

Das Script muss nun in den Custom Sensors Ordner von PRTG gelegt werden und der Sensor kann entsprechend eingerichtet werden:

Parameter gem. Script-Beschreibung, Securitykontext vom Gerät
Als primären Channel die bald ablaufenden Zertifikate, Intervall 12h und sofortiger DOWN Status auswählen

Das Resultat sieht dann wie folgt aus:

Viel Spass beim Nachbauen :-)




PRTG – Citrix ADM für zentrale ADC Überwachung nutzen

Es ist schon ein paar Tage her, da habe ich über PRTG Custom Sensoren für ADC geschrieben. Diese haben bisher mehr oder weniger gut in unserer Umgebung funktioniert. Für mich zeigten sich dabei jedoch mit der Zeit folgende Nachteile:

  • Jeder ADC, jedes ADC HA Paar muss im PRTG konfiguriert werden
  • Ist ein LB/CS vServer im DOWN Status, bleibt der PRTG Sensor rot, bis der vServer entweder wieder UP oder manuell deaktiviert ist (reaktivieren nicht vergessen)
  • Die Sensoren lieferten teils falsche/unvollständige Daten

Da wir sowieso eine ADM Appliance im Einsatz haben, suchte ich nach Möglichkeiten diese als Datenquelle anzusteuern. Mein erster Ansatz mit SNMP Traps scheiterte an der Tatsache, das PRTG dies nur einmalig als Alarm anzeigt und im nächsten Intervall wieder auf Status grün wechselt, falls nicht ein weiterer Trap gesendet wurde. Diese Option war daher für uns unbrauchbar.

Nach ein paar Recherchen bin ich auf ein Powershell Modul von Kenny Baldwin gestossen, welches mittels Nitro REST eine ADM Appliance mit div. Befehlen ansteuern kann. Das Original kann man auf GitHub herunterladen.

Das Modul hat ursprünglich vorgesehen, dass bei Benutzung die Anmeldedaten manuell eingegeben werden sollen. Für die Nutzung mit PRTG habe ich daher diesen Teil ein wenig angepasst, so dass die Daten aus dem PRTG Sensor übernommen werden können:

    param (
    [Parameter(Mandatory = $true)]
    [string]$ADMHost,
    [Parameter(Mandatory = $true)]
    [string]$CredUser,
    [Parameter(Mandatory = $true)]
    [string]$CredPW,
    [Parameter(Mandatory = $false)]
    [int]$Timeout = 900
    )

Nun kann das Modul zusammen mit den späteren Custom Sensoren im PRTG Custom Sensor Ordner gespeichert und ggf. verteilt werden.




Citrix Hypervisor – Snapshots für bestimmte VMs verwalten

Als ich am Backup-Skript tüftelte kam mir noch so ein Gedanke: „warum aus dem einen vollen Skript nicht noch zwei einzelne machen, welche man z.B. bei Produktupdates nutzen kann?“

So sind am gleichen Abend noch zwei weitere Skripte entstanden:

Dieses kann man nutzen um bei einer Gruppe von VMs basierend auf dessen Tag z.B. „Citrix“ Snapshots zu erstellen. Die VMs müssen lediglich vorher mit Tags versehen worden sein:

Nach dem Erstellen der Snapshot können die Arbeiten getätigt werden, z.B. Updates aller Citrix Virtual and Desktop Komponenten. Wenn die Arbeiten erfolgreich erledigt wurden, können die Snapshot mit folgendem Skript wieder entfernt werden:

Achtung: im Gegensatz zum Backup-Skript werden hier stur alle Snapshots bei VMs mit definiertem Tag gelöscht, ohne den Zeitstempel des Erstellens zu beachten.




Citrix Hypervisor (XenServer) Backup Skript

Guten morgen allerseits
Da man wegen der aktuellen ausserordentlichen Lage (Corona-Virus) kann man kaum was machen, da habe ich mir mal ein wenig Gedanken gemacht, wie ich meine kleine Testumgebung einfach sichern kann.
Im geschäftlichen Umfeld gibt es div. Backup-Anbieter. Für meine Testumgebung wollte ich dafür jedoch kein Geld ausgeben und wollte auf Basis eines älteren Artikels ein komplettes Skript bauen und bin dabei auf was gestossen, was ich bisher immer ignoriert hatte…



Seit längerem hat Citrix ein SDK Kit in welchem auch ein PowerShell Modul für den Citrix Hypervisor mit dabei ist. Auf Basis des Blogartikels habe ich mich dann mal ans Werk gemacht.

Die Idee war ein Skript zu basteln welches folgendes macht (Ähnlichkeiten mit bekannten Backup Lösungen sind gewollt):
– Snapshot von definierten VMs
– erstellte Snapshots exportieren
– Snapshots wieder löschen

Als erstes muss das SDK auf einer definiertem definierten Windows Rechner installiert werden. Die Anleitung dazu ist im Download enthalten, daher gehe ich darauf nicht ein.

Wie in anderen Skripts wollte ich als erstes einen kompletten Block erstellen, in welchem erst einmal die verschiedenen Variablen definiert werden:

# Define Variables
$Xenhost = "192.168.199.210"
$XenUser = "root"
$XenPW = "PITPassword"
$BkpDate = Get-Date -Format yyyyMMdd-HHmm
$BkpStart = (Get-Date).AddHours(-1) # Subtract one hour for the system time / check with summer time
$BkpTag = "Backup"
$ExportPath = "S:\VM-Backups"

Die ersten drei definieren den Zugriff auf die Citrix Hypervisor Umgebung.
Mit dem $BkpDate lesen wir Datum/Zeit aus und generieren daraus einen Teil des späteren Snapshot Namens.
Das $BkpStart definiert den Start des Skriptes. Dieses nutzen wir später um nur Snapshots zu löschen, welche nach dem Skriptsstart erstellt wurden. Im Test musste ich noch eine Stunde abziehen, da die Systemzeit anscheinend UTC hat.
Die Variable $BkpTag definiert, auf welchen VM Tag geachtet werden muss.
Der $ExportPath definiert, wohin die Snapshots exportiert werden sollen.

Im zweiten Block wird die Verbindung zum Pool hergestellt. Hier habe ich die Vorlage aus dem Block fast 1:1 übernommen. Lediglich die Meldungen wurden ein wenig ergänzt:

# Connect to Citrix Hypervisor
# Try the defined host otherwise change to new PoolMaster
# --- Base scriptlet from pastebin.com ---

Try {
    $Session = Connect-XenServer -Url https://$Xenhost -UserName $XenUser -Password $XenPW -NoWarnCertificates -SetDefaultSession
    Write-Host -ForegroundColor DarkGreen "Successful connected to $Xenhost"
    }
    Catch [XenAPI.Failure]
        {
        [string]$PoolMaster = $_.Exception.ErrorDescription[1]  
        Write-Host -ForegroundColor Red "$($Pools.$Pool) is slave, Master was identified as $PoolMaster, trying to connect"
        $Pools.Pool = $PoolMaster
        $Session = Connect-XenServer -url "http://$PoolMaster" -UserName $XenUser -Password $XenPW -NoWarnCertificates -SetDefaultSession
        Write-Host -ForegroundColor DarkGreen "Successful connected to $PoolMaster"
       }

Im dritten Block erstellen wir eine Liste aller VMs, die den vorher definierten Tag aufweisen. Damit dies funktioniert, muss den VMs der Tag zugewiesen worden sein:

# Enumerate all VMs
# --- Base scriptlet from pastebin.com ---
# Added selection of "Backup" Tag

$BkpVMs = Get-XenVM | Where {$_.is_a_template -eq $False -and $_.is_a_snapshot -eq $False -and $_.domid -ne 0 -and $_.tags -contains $BkpTag}

Im vierten Block wird für jede gefundene VM ein Snapshot erstellt. Damit die Snapshots auseinander gehalten werden können, wird ein Name aus dem VM Namen und dem $BkpDate gebildet.

# Create Snapshot of each found VM
# --- Base scriptlet from pastebin.com ---
# Loop added and define the snapshot name based on VM name and date/time of backup start

$BkpVMs | ForEach-Object {
    $VMName = $_.name_label
    $VMUuid = $_.uuid
    $Snapshotname = "$VMName - $BkpDate"
    Write-Host -ForegroundColor Gray "Snapshot with name $Snapshotname for VM $VMName (UUID $VMUuid ) will be created"
    Invoke-XenVM -Uuid $VMUuid -XenAction Snapshot -NewName $Snapshotname
    }

Im fünften Block wird eine Liste aller Snapshots erstellt, welche den Tag aufweisen und die nach dem Skriptstart ($BkpStart) erstellt wurden.

# Enumerate all Snapshots
# --- Base scriptlet from pastebin.com ---
# Only snapshots of VMs with the "Backup" tag and snapshots newer the start time

$BkpVMs2 = Get-XenVM |  Where {$_.is_a_snapshot -eq $True -and $_.tags -contains $BkpTag -and $_.snapshot_time -gt $BkpStart}

Im sechsten Block werden alle gefundenen Snapshots ans definierte Ziel ($ExportPath) exportiert.

# Export the enumerated Snapshots
# --- Base scriptlet from pastebin.com ---

$BkpVMs2 | ForEach {
    $Snapshotname2 = $_.name_label
    $SnapshotUuid2 = $_.uuid
    $ExportFile = "$Exportpath\$Snapshotname2.xva"
    Write-Host -ForegroundColor DarkCyan "Snapshot with name $Snapshotname2 will be exported to $ExportFile"
    Export-XenVm -Uuid $SnapshotUuid2 -XenHost $Xenhost -path "$ExportFile"
    }

Im siebten und letzten Block werden alle gefundenen Snapshots wieder gelöscht.

# Delete snapshot of each VM which was created before
# --- Base scriptlet from pastebin.com ---
# Loop added to remove all snapshots created before

$BkpVMs2 | ForEach-Object {
    $Snapshotname3 = $_.name_label
    Write-Host -ForegroundColor DarkYellow "Snapshot with name $Snapshotname3 will be deleted"
    Remove-XenVM -Name $Snapshotname3
    }

Dieses simple Skript ist eine einfache Variante um schnell eine Sicherung einer Testumgebung zu erhalten. Dieses soll keinesfalls ein Ersatz von professionellen Lösungen sein!

Nun viel Spass beim Nachbauen :-)




Citrix ADC SSL Bewertung optimieren – Stand Februar 2020

Im ursprünglichen Artikel bin ich auf die Basis-Schritte eingegangen, wie man bei Qualys die SSL Bewertung auf einen guten Stand bringen kann.

Da die Test-Routinen jeweils an die neusten Erkenntnisse angepasst werden, waren meine Bewertungen auf ein B gesunken, was für mich nicht hinnehmbar war. Hier möchte ich euch die Schritte beschreiben, wie ich wieder auf eine A+ Bewertung gekommen bin.



Der erste Schritt ist relativ einfach. Durch die aktivierten TLS 1.0 und TLS 1.1 wurde die Bewertung automatisch auf ein B heruntergestuft. Dazu kann man diese im virtuellen Server einfach in den SSL Parametern deaktivieren. Im gleichen Atemzug habe ich auch bereits TLS 1.3 aktiviert.

set ssl vserver nsgw-vsrv-gateway.domain.pit -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED

Der nächste Schritt beinhaltet die Anpassung der Cipher Suites. Bei Qualys findet man einen direkten Link mit der Auflistung passender Algorithmen. Nebst dem bestehenden TLS 1.2 habe ich auch gleich diese für TLS 1.3 hinzugefügt.
Man kann einerseits die bestehende Gruppe anpassen oder wie ich eine neue Gruppe erstellen:

add ssl cipher CIPHER-PIT-AEAD
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 1
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 2
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256 -cipherPriority 3
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384 -cipherPriority 4
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 5
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 6
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 7
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 8
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 9
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 10

Anschliessend muss man nur noch auf dem vServer die alte Cipher Gruppe entfernen und die neue hinzufügen um in der Bewertung ein A+ zu sehen:

unbind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT
bind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT-AEAD

Zu guter Letzt müssen sämtliche Applikationen getestet werden, ob auch alle mit den verschärften Algorithmen umgehen können.

Viel Spass beim Nachbau :-)




SMTP Relay mit ACL auf Citrix ADC konfigurieren

Vor knapp zwei Jahren erstellte ich hier einen Artikel, wie man grundsätzlich einen SMTP Relay mit NetScaler konfigurieren kann (hier). Im Rahmen einer Datacenter Migration kam das Thema ACL für diesen Relay auf. Im genannten Artikel wurde sauber beschrieben, wie man den Exchange auf den ADC als Quelle konfigurieren kann. Wie kann man nun aber die Quellen seitens Loadbalancer einschränken?



Wer schon mit dem ADC gearbeitet hat weiss, dass dieser Access Control List (ACL) als Funktion bietet, jedoch ist die Konfiguration dieser eher statisch als dynamisch. Ich arbeite jedoch in einem Umfeld, in welchem die zugelassenen Server immer wieder mal ändern können (bei über 1000 Servern kein Wunder). Daher habe ich ein wenig Recherchiert und bin auf einen Lösungsansatz mittels Responder Policies gestossen, welchen ich hier dokumentiere.

Als erstes muss das Loadbalancing für den SMTP Relay konfiguriert werden. Ich nehme dazu als Basis den letzten Artikel und schmücke diesen mit ein wenig mehr Backend-Servern aus:

add server pitex01 192.168.100.31
add server pitex02 192.168.100.32
add service svc-smtp-pitex01 pitex01 TCP 25
add service svc-smtp-pitex02 pitex02 TCP 25
add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType SOURCEIP -timeout 10 -netprofile NP-192.168.100.12
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex02

Nun bauen wir unsere Responder Policy. Damit die Pflege der Quell IPs ein wenig einfacher ist, nutzen wir dazu die sogenannten Data Sets (ähnlich wie Pattern Sets, jedoch für Daten wie IP Adressen) und verweisen in unserer Policy darauf. Als Aktion nehmen wir die vordefinierten „RESET“ Aktion.

add policy dataset DS_MailRelay ipv4
bind policy dataset DS_MailRelay 192.168.100.21 -index 1
bind policy dataset DS_MailRelay 192.168.100.22 -index 2
add responder policy rs_pol_ACLMailRelay "CLIENT.IP.SRC.TYPECAST_TEXT_T.CONTAINS_ANY(\"DS_MailRelay\").NOT" RESET

Schlussendlich müssen wir nur doch die neu erstellte Policy dem SMTP Relay Loadbalancer zuweisen und ab sofort nimmt dieser nur noch Anfragen von IPs an, welche im Data Set „DS_MailRelay“ definiert sind.

bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -policyName rs_pol_ACLMailRelay -priority 100 -gotoPriorityExpression END -type REQUEST



PRTG – Failover Cluster mit Citrix ADC

Bei meinem aktuellen Arbeitgeber steht die Migration in zwei neue Rechenzentren an. Eines der Ziele dieser Migration ist die Erhöhung der Ausfallsicherheit. Dies habe ich zum Anlass genommen mir den PRTG Failover Cluster mit einem vorgeschalteten Citrix ADC einmal anzuschauen.

Die Installation und Konfiguration ist eigentlich recht einfach und das Vorgehen möchte ich in diesem Artikel nochmals erläutern.



PRTG Failover Cluster konfigurieren

Um den Core-Server von PRTG als Failover-Cluster zu konfigurieren gibt es seitens PAESSLER zwei gute Artikel:
Failover Cluster Configuration
Failover Cluster Step by Step

Wenn man sich an diese hält, läuft der Cluster in kürzester Zeit. Was gibt es zu beachten?

  • Der zweite Cluster-Node ist immer Read-Only, d.h. selbst bei einem Ausfall des Master-Servers kann auf dem Failover-Server nur überwacht, jedoch nicht konfiguriert werden.
  • Remote Probes müssen so (um-)konfiguriert werden, dass sie ihre Daten an alle Cluster Nodes senden und nicht nur dem Master.
  • Die Remote Probes werden vom PRTG Cluster selbst konfiguriert. Eine allfällige Registry Anpassung (manuell oder via GPP) wird wieder überschrieben.
  • Remote Probes müssen jeden Cluster Node einzeln erreichen können. Bei einer NAT Konfiguration bedeutet dies ein eigener FQDN und NAT Zugang pro Core Server.
  • Der erste Administrator (prtgadmin) ist autonom pro Node. Um spätere Probleme zu vermeiden sollte das Passwort auf beiden Servern identisch gesetzt und mit der AD Authentifizierung gearbeitet werden.
  • Nur der Master-Server sieht sich selbst noch als „Local Probe“. Auf den Failover-Servern ist nur der „Cluster Probe“ und alle anderen Remote Probe Server ersichtlich.
  • Die Probe Dienste der PRTG Core Server senden ihre Daten nur lokal (127.0.0.1).

In den Cluster Einstellungen sollte man die „Node Namen“ passend setzen und die IP Adressen durch FQDN ersetzen.
Dies macht es einerseits übersichtlicher für alle PRTG Benutzer und andererseits ist man unabhängiger bei einer allfälligen Änderung der IP Adressierung.

Kontrolle in der Registry auf einem Remote Probe Server
Kontrolle im Cluster Status
Cluster-Konfiguration der Remote Probes

Hinweise:
– Man kann zwar im GUI dem Master Server einen DNS Alias setzen, die Remote Probes erhalten jedoch immer den originalen Hostname übermittelt.
– Die Änderung wird sofort an die Remote Probes übermittelt.

Bei einer frischen Installation kann nun die Konfiguration direkt in der Cluster Probe gestartet werden. Wurde ein Solo PRTG Core Server in einen Cluster umgewandelt, so müssen die konfigurierten Gruppen, Geräte und Sensoren vomr „Local Probe“ in den „Cluster Probe“ verschoben werden:

Konfiguration Citrix ADC

Nachdem nun der PRTG Failover Cluster soweit konfiguriert ist, bauen wir nun den Zugriff auf diesen. Ohne ADC würde man nun entweder mittels DNS Round-Robin einen FQDN konfigurieren, wobei man hier nicht steuern kann auf welchem Node man landet, oder man arbeitet mit zwei verschiedenen FQDN, was wiederum nicht Anwenderfreundlich ist.

In diesem Abschnitt wird die Konfiguration eines LB vServer mit Failover Funktion erläutert.

Hierzu werden alle (normalerweise zwei) Cluster Nodes im ADC erfasst:

add server prtgserver1 prtgserver1.domain.pit
add server prtgserver2 prtgserver2.domain.pit

Für jeden Server erstellen wir einen Service. Nach best practice sind die PRTG Server SSL verschlüsselt, somit bauen wir passende Services dazu:

add service svc-https-prtgserver1 prtgserver1 SSL 443
add service svc-https-prtgserver2 prtgserver2 SSL 443

Im Gegensatz zu einem normalen Loadbalancing wird im Failover nicht ein einzelner sondern zwei vServer benötigt, um den zweiten als Backup zu konfigurieren. Dem vServer mit einer IP wird der Service des PRTG Master Servers angefügt. Der zweite vServer (ohne Adressierung) steuert den PRTG Failover Server an. Beide LB vServer benötigen auch das dazu passende SSL Zertifikat:

add lb vserver lb-vsrv-prtg.domain.pit SSL 192.168.200.222 443
add lb vserver lb-vsrv-prtg-backup.domain.pit SSL 0.0.0.0 0

bind lb vserver lb-vsrv-prtg.domain.pit svc-https-prtgserver1
bind lb vserver lb-vsrv-prtg-backup.domain.pit svc-https-prtgserver2

bind ssl vserver lb-vsrv-prtg.domain.pit -certkeyName wildcard.domain.pit
bind ssl vserver lb-vsrv-prtg-backup.domain.pit -certkeyName wildcard.domain.pit

set lb vserver lb-vsrv-prtg.domain.pit -backupVServer lb-vsrv-prtg-backup.domain.pit

Dem Service Monitoring habe ich am meisten Zeit gewidmet. Die PRTG Server bieten eine Status-Seite (/api/public/testlogin.htm), welche jedoch bereits bei einem Problem mit dem Mailserver ein „NOTOK“ zurück meldet.
Nur diese Status-Seite alleine konnte ich also nicht nutzen. Daher baute ich ein Monitoring basierend auf dieser plus zusätzlichen zwei Standard-Monitoren (TCP und HTTP). Da sich der TCP-Default Monitor nicht anfügen lässt wenn bereits ein anderer Monitor in Benutzung ist, habe ich einen eigenen erstellt.
Wegen der Benutzung von HTTPS muss dem HTTP Monitor der Response Code 302 hinzugefügt werden.

add lb monitor mon-prtg-TCP TCP
add lb monitor mon-prtg-http HTTP -respCode 200 302 -httpRequest "HEAD /" -secure YES

Das Monitoring der Status-Seite bat mir ein erstes Mal die Nutzung des „Reverse“ Monitorings. Würde man nämlich nur die Antwort „OK“ prüfen, so wäre der Monitor auch bei einem „NOTOK“ zufrieden, da „OK“ ein Bestandteil der Antwort ist. Daher prüfen wir auf ein „NOTOK“ und geben mit dem Monitor grünes Licht, falls diese Antwort nicht vorhanden ist – Reverse eben. ;-)

add lb monitor MON-PRTG-Core-Status HTTP-ECV -send "GET /api/public/testlogin.htm" -recv NOTOK -reverse YES -secure YES

Zu guter Letzt müssen die neu gebauten Monitore in den Services konfiguriert werden. Dazu fügen wir pro Service die drei hinzu und definieren den Monitoring Schwellwert 2. So bleibt der Service verfügbar, solange zwei Monitore grünes Licht geben:

bind service svc-https-prtgserver1 -monitorName mon-prtg-http
bind service svc-https-prtgserver1 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver1 -monitorName mon-prtg-Core-Status
bind service svc-https-prtgserver2 -monitorName mon-prtg-http
bind service svc-https-prtgserver2 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver2 -monitorName mon-prtg-Core-Status

set service svc-https-prtgserver1 -monThreshold 2
set service svc-https-prtgserver2 -monThreshold 2

Mit dieser Konfiguration kann nun ein Benutzer über eine FQDN (z.B. prtgcluster.domain.pit) auf die PRTG Oberfläche zugreifen. Der LB vServer vom ADC schaltet erst auf den Failover Server um, sobald der Master Server nicht mehr verfügbar ist (z.B. Neustart). Ist der Master Server wieder online, schaltet der ADC wieder auf diesen zurück.

Viel Spass beim Nachbauen. :-)




PRTG – Citrix ADC überwachen

Citrix bietet zur Überwachung und Konfiguration von Citrix ADC (ehem. NetScaler) das Citrix Application Delivery Management (ehem. NetScaler MAS). Wie kann man nun aber die ADC Appliances im PRTG überwachen? Diese Frage haben sich schon einige gestellt und nebst kostenpflichtigen Plugins von www.prtgplugins.com gibt es weitere Open Source Optionen.

Eine mögliche Lösung habe ich bei Jason McKenry gefunden. Er hat basierend auf dem NetScaler PowerShell Modul passende Skripte erstellt, mit welchen aktuell folgendes überwacht werden kann:

  • Appliance Performance (CPU, PE CPU, Disk, RAM und Durchsatz)
  • Status aller vServer (LB, AAA, VPN und CS)
  • Status aller LB vServer
  • Ablaufdaten aller Zertifikate
  • ungespeicherte Konfigurationen

Sein Blog-Artikel erklärt die komplette Konfiguration in Englisch. Ich möchte in diesem Artikel einerseits die Vorgehensweise auf Deutsch erläutern und andererseits noch ein paar Ergänzungen anbringen.



Als Basis dient nun jedoch der Blog-Artikel von Jason:

Quelle: https://itrandomness.com/2018/01/monitoring-netscaler-with-prtg/

Als erstes lädt man die passenden Skripte herunter. Dieser sind entweder auf GitHub (manchmal aktualisiert) oder am Ende des Artikels zu finden.

Nun muss das NetScaler Module installiert werden. Hierbei gibt es folgendes zu beachten:

  • Ein aktuelles Windows Management Framework sollte installiert sein (muss manuell gemacht werden, nicht über die Microsoft Updates).
  • PRTG arbeitet mit der 32-bit Version von PowerShell. Somit müssen alle Befehle in der (x86) Version ausgeführt werden.
  • Das NetScaler Module muss auf allen Probe Server installiert werden, welche den Custom Sensor ausführen sollen.

Wenn alles rund läuft reichen folgende Befehle:

Set-ExecutionPolicy Unrestricted
Install-Module -Name NetScaler -scope AllUsers

Ich hatte auf meinem System das Problem, dass kein passender Provider gefunden wurde. Bei der Fehleranalyse stellte ich fest, dass im System kein Paket-Provider registriert war. Mit folgenden Befehlen kann dies korrigiert werden:

Install-PackageProvider Nuget –Force
Install-Module –Name PowerShellGet –Force

Damit wir die Appliances abfragen können, benötigen wir einen lokalen Benutzer auf jeder Appliance. Dieser benötigt nur Read-Only Rechte:

add system user svcprtg PASSWORD -externalAuth DISABLED
bind system user svcprtg read-only 100

Nun müssen die Sensor Dateien in die entsprechenden Ordner kopiert werden.

Die .ps1 Dateien kommen in den Ordner „Custom SensorsEXEXML“ (Standard: %programfiles(x86)%PRTG Network MonitorCustom SensorsEXEXML).

Die .ovl Dateien kommen in den Ordner „lookupscustom“ (Standard: %programfiles(x86)%PRTG Network Monitorlookupscustom).

Anschliessend müssen die Dateien (lookups) im PRTG neu geladen werden. Der Menüpunkt ist unter PRTG > Setup > Administrative Tools zu finden:

Bevor die Sensoren eingerichtet werden können, muss der neu erstellte Benutzer konfiguriert werden. Entweder gilt dieser nur für die ADC Appliances oder es ist eine Überlegung wert, den Benutzer für alle Linux/UNIX Server zu verwenden:

Linux Benutzer im PRTG konfigurieren

Nun können die fünf Sensoren (einer pro PowerShell Skript) eingerichtet werden. Diese werden als EXE/Script Advanced hinzugefügt. Der Name kann frei vergeben werden. Folgende Parameter müssen mitgegeben werden:

%host %linuxuser %linuxpassword

Hier ein paar Beispiele:

Performance Übersicht
Gültigkeit der SSL Zertifikate
Status LB vServer

Falls seitens ADC vServer hinzugefügt oder entfernt werden, so muss der Sensor neu eingerichtet werden. Die Channels können dies nicht automatisch abgleichen.

Viel Spass beim Nachbauen. :-)




SMTP Relay mit Exchange 2016 und NetScaler einrichten

Ich bin mich wieder frisch am Einarbeiten in das Thema Exchange.

Das Grundsetup mit Exchange 2016 habe ich recht schnell hingekriegt und auch den externen Zugang via NetScaler war dank eines Skriptes von meinem Kollegen einfach hergestellt. Nun wollte ich jedoch noch für div. Dienste einen einfachen internen SMTP Relay Server erstellen.

Eine erste Anleitung dazu fand ich dann relativ schnell bei Paul Cunningham (Link).

Leider funktionierte dies nicht ganz so im Web GUI. Der Grund lag einfach gesagt an einem Bug von Microsoft und die Lösung war Powershell. Die Anleitung dazu fand ich dann bei Jeff Guillet (Link).

Nun funktionierte mein SMTP Relay zwar wenn ich den Exchange Server direkt ansteuerte, jedoch nicht via NetScaler. Und dies wollte ich dann auch noch lösen:

Die Ursache warum ich via die bereits eingerichtete NetScaler Konfiguration den SMTP Relay nicht ansteuern konnte war mir recht schnell klar. Der Exchange Server unterscheidet die Empfangskonnektoren jeweils anhand der Quell-IP und via NetScaler ist dies immer die SNIP.

Was musste nun getan werden?

Dem Exchange Server müssen verschiedene Quellen vorgegaukelt werden. Im NetScaler kann dies mittels einer weiteren SNIP eingerichtet werden. Wichtig hierbei ist jedoch, dass die jeweiligen SNIP Adressen den richtigen vServern mittels Net Profiles zugewiesen werden, da ansonsten die Appliance mittels Round Robin die SNIP wechselt.

Schritt 1 – Erstellen einer weiteren SNIP und Konfiguration der Net Profiles:

add ns ip 192.168.100.12 255.255.255.0 -vServer DISABLED -gui DISABLED
add netProfile NP-192.168.100.11 -srcIP 192.168.100.11
add netProfile NP-192.168.100.12 -srcIP 192.168.100.12

Schritt 2 – Erstellen eines weiteren LB vServers für den SMTP Relay:

add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType NONE
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01

Schritt 3 – Net Profiles den LB vServern korrekt zuweisen:

set lb vserver lb-vsrv-mail.domain.pit-SMTP -netprofile NP-192.168.100.11
set lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -netprofile NP-192.168.100.12

Schritt 4 – Empfangskonnektor für SMTP mit neuer SNIP konfigurieren:

Und nun viel Spass beim Nachbauen :-)

Quellen: The EXPTA {blog}exchangeserverpro.com

Skript: NS-ExSMTPRelay