Zuerst einmal muss ich loswerden, dass mich Ubuntu langsam richtig aufregt. Ich rate davon ab sowas als Produktivserver zu nutzen. Da gibt es meiner Meinung nach bessere Alternativen, wie Debian oder CentOS, die weitaus stabiler laufen.
Attachments können wie folgt hinzugefügt und entfernt werden:
$Message.Attachments.Add("C:\test.txt")
$Message.Attachments.Add("C:\test.txt")
# Über Index entfernen
$Message.Attachments.RemoveAt("0")
$Message.Attachments.RemoveAt("1")
Header können mit folgendem Befehl hinzugefügt werden:
$Message.Headers.Add("X-Test-Header","Daten")
Anonymes Senden
Mit folgender einfachen Funktion kann man über Powershell emails anonym, also ohne Benutzeraccount, an einen Mailserver senden. Bitte vorher die Empfänger, das From und den Mailserver anpassen.
Das Script baut eine anonyme Verbindung mit dem Mailserver auf. Der Mailserver benötigt hierzu also einen EmpfangsConnector (MS Exchange), der anonyme Verbindungen von dem Host erlaubt, auf dem das Script ausgeführt wird.
Man kann mit der WinSCP Assembly über PowerShell ganz einfach SFTP-Uploads durchführen. WinSCP hat dazu eine gute Doku, die auch zeigt, wie man die Assembly als COM Objekt nutzt und wie man Ressourcen zu einem .NET Projekt hinzufügt und in eine temporäre Datei entpackt:
Wichtig ist, dass die Logs auch verfügbar sind, wenn man sie braucht. Das geht entweder über die Retention Policy pro Server und Log oder über eine SIEM-Lösung (Security Information and Event Management). Ein SIEM-Client schickt dabei alle relevanten Logs an einen zentralen Server. Ähnlich wie bei Remote Syslog. Ein SIEM kann normalerweise auch Syslogs direkt empfangen und verarbeiten.
Retention Policy
Um hier alle Logs nach einer Vorgabe zu konfigurieren, sollte man die Retention Policy per PowerShell Script ausrollen. Anleitung hierfür folgt.
In diesem Artikel wird die Authentifikation über AzureAD SAML Single Sign On beschrieben und wie man die Zugriffsberechtigungen hierzu auf Gruppen einschränkt. Zusätzlich wird die Möglichkeit zur Authentifizierung per Conditional Access auf IP-Ebene eingeschränkt.
Microsoft weist inzwischen darauf hin, dass man für neue Projekte die Microsoft Identity Platform verwenden soll. Das ist dan OpenID oder OAuth.
Wir benötigen einen AzureAD Admin mit entsprechenden Zugriffsrechten auf die folgenden Portale:
portal.azure.com
admin.microsoft.com
Das Portal admin.microsoft.com erreicht man auch über portal.office.com und dann links über das Symbol Admin.
Als erstes eine kleine Empfehlung: belasst das Portal portal.azur.com und admin.office.com auf Englisch. Die Übersetzung ist maximal schlecht. Meine Meinung.
SAML Dienst erstellen
Portal: aad.portal.azure.com
Unter Enterprise Applications eine neue Applikation erstellen.
In der rechten Seitenleiste einen sinnvollen Namen vergeben und Non-gallery Application erstellen:
Die neue Applikation findet man nun in der Liste aller Applikationen oder man sucht alternativ nach dem eben vergebenen Namen. Mit einem Klick auf den Namen gelangt man in das Konfigurationsmenu für unsere neue Applikation.
Hier wählen wir nun den Punkt Single Sign On->SAML
Etwas Theorie: SAML funktioniert über REST-Endpunkte. Der Dienst, für den man die SAML Authentifikation aufetzt, liefert normalerweise ein sogenanntes Metadata File in XML-Format. In der Datei sind die Endpunkte und das Zertifikat der gegenseite hinterlegt. Man kann diese Datei nun einfach in unsere AzureAD Applikation importieren. Dazu klicken wir oben auf „Upload metadata file“.
Wählt man die Datei aus erscheint rechts ein neuer Dialog, in dem man die Daten nochmal überprüfen kann. Im Normalfall kann man hier einfach oben auf „Save“ klicken.
Attribute und Claims
Der Dienst kann aus dem AzureAD bestimmte Attribute abfragen, bzw. diese werden beim einer Authentifizierung einfach mitgeliefert. Wenn also die Authentifizierung eines Benutzers über SAML erfolgreich ist, werden die hier definierten Attribute an den Dienst geliefert. Der Dienst sagt normalerweise über Hilfeseiten oder den Support an, welche Attribute benötigt werden. Das wichtigste Attribut ist hier der Unique User Identifier. Man verwendet normalerweise entweder den Userprincipalname (UPN) oder die E-Mail Adresse. Der UPN ist vorausgewählt. Wir ändern beispielhaft auf die E-Mail-Adresse.
Wir ändern den Wert user.principalname, indem wir auf das Feld klicken und aus der vorgegebenen Liste user.mail auswählen. Dann oben auf „Save“ klicken:
Die Gegenseite benötigt nun unser Metadata File. Die Datei kann man einfach unter Download Metadata File runterladen. Sie liegt im XML-Format vor.
Man kann dem Dienst auch noch das Base64-Zertifikat, die LoginURL, den AzureAD Identifier und die LogoutURL mitgeben. Damit könnte der Dienst seine Seite auch ohne Metadata File von uns konfigurieren (z.B. falls er die nicht importieren kann).
Zugriff auf bestimmte Benutzer beschränken
1. Benutzerquelle aus onPremise AD per AzureAD Connect
Azure Active Directory > Security > AzureAD Conditional Access > Named locations
Auf „+IP ranges location“ klicken. Es geht rechts eine neue Eingabemaske auf.
Wenn wir ein vertrauenswürdiges Netz einrichten wollen, den Haken für „Mark as trusted location“ setzen. Dann einen Namen für das Netz vergeben, z.B. „Trusted Location Branch Office 1“. Unten auf das + klicken und die entsprechenden Netzbereiche eingeben. Wenn es nur eine IP ist, wird trotzdem eine Netzmaske verlangt. Wir geben dann IP/32 ein und speichern alles.
Damit haben wir die Conditional Access Location konfiguriert. Im nächsten Schritt verknüpfen wir die Location mit dem Dienst.
MFA Trusted IP’s
Portal: portal.azure.com
Pfad: Azure Active Directory > Security > Conditional Access > Named Locations
Eine Conditional Access Policy setzt normalerweise mindestens einen weiteren Sicherheitsfaktor voraus, meist Multi Factor Authentication. Um das zu umgehend Setzen die IP’s auch als MFA Trusted IP’s.
Conditional Access Policy für SAML Dienst einrichten
Portal: portal.azure.com
Wir wählen in der linken Spalte „Enterprise Applications“. Es werden alle Applikationen aufgelistet, die wir im Tenant konfiguriert haben. Wir wählen nun die App aus, für die wir den Conditional Access einrichten wollen. Dann wählen wir im Bereich Security „Conditional Access“ und klicken auf „+New policy“.
Folgende Informationen werden für eine Contitional Access Policy benötigt:
Ein Name für die Policy
Welchen Benutzern die Policy zugewiesen wird
Die Anwendung, der die Policy zugewiesen wird
Die Konditionen (Conditions, z.B. IP’s)
Access Control über Grant oder Session Block
Folgendes sollte man außerdem beachten:
Nie alle Benutzer in eine Policy einschließen. Es sollte sogenannte Break Glass Benutzer geben, die Zugreifen können, falls man sich über eine Fehlkonfiguration ausgeschlossen hat.
Die Richtlinie nie direkt aktivieren, sondern erst über Report-only prüfen was passiert.
Wir vergeben einen Namen, klicken auf Conditions->Locations->Configure: Yes und wählen die im obigen Abschnitt konfigurierten Locations. ACHTUNG: unten die Policy aktivieren, sonst wird nur berichtet was passieren würde, wenn man die Policy aktiviert hätte.
Wir bauen uns nun eine Deny-Regel. Wir blockieren also alle Locations, bis auf die oben spezifizierten Locations. Diese Regel wenden wir auf alle Benutzer an, bis auf die Break Glass Benutzer und evtl. spezielle Admins.
Users or workload identities
Include: All users
Exclude: Break Glass und Admins
Cloud apps or actions
Die SAML App auswählen
Conditions
Locations -> Include: Any location
Locations -> Exclude: Selected Locations (hier die Locations auswählen, die wir erlauben wollen)
