Exchange Online PowerShell mit Windows Terminal

Ich möchte euch hier eine meiner Anpassungen für das neue Windows Terminal vorstellen. Mein Fokus für die Anpassung, lag darin eine Verbindung zu den Exchange Shells herstellen zu können.
Ich habe meine Anpassung auf Basis dieses Docs Artikels und den Post von Thomas Maurer vorgenommen.
Aber vorher noch Informationen zum neuen Windows Terminal

Das Windows-Terminal ist eine moderne, schnelle, effiziente, leistungsstarke und produktive Terminal-Anwendung für Benutzer von Befehlszeilentools und Shells wie beispielsweise Eingabeaufforderung, PowerShell und WSL. Die wichtigsten Funktionen des Windows-Terminals umfassen mehrere Registerkarten, Bereiche, Unicode- und UTF-8-Zeichenunterstützung, GPU-beschleunigtes Textrendering-Modul sowie benutzerdefinierte Designs, Formatvorlagen und Konfigurationen.
Dies ist ein Open Source-Projekt, und wir freuen uns über die Teilnahme an der Community. Um teilzunehmen, besuchen Sie bitte die Website https://github.com/microsoft/terminal

Source: https://www.microsoft.com/de-de/p/windows-terminal/9n0dx20hk701?activetab=pivot:overviewtab#

Meine Lösung ist sicher nicht die optimalste aber so lässt sich einfach eine Verbindung mit einem Exchange Server oder Exchange Online herstellen.

Ich führe im Hintergrund beim Starten eines neuen Terminal Profiles ein Powershell Script aus, welches die Remote Session zum Exchange Shell herstellt.

Dazu habe ich noch eine kleine Logik eingebaut, in der man auswählen kann ob man eine Verbindung zu einer Exchange Online Shell oder einer OnPremise Exchange Shell herstellen möchte.

Die Werte können im Script auch so angepasst werden, um immer die gleiche Verbindung zur Shell zu erhalten.

Redundanz des Active Directorys bei LDAPS beibehalten

Ausgangslage:

Die erzwungen Umstellung der LDAP Abfragen auf LDAP Channel Binding oder LDAPs "ADV190023" bringt so manchen Domain Admin und Administrator ins schwitzen. Was sollt man tun, wenn die Anwendung nur eine Eingabefeld für den Authentifizierungsserver hat (Bsp: Tomcat) und man die Redundanz der Domainaufrufs beibehalten will.

Hier die Lösung:

Die für LDAPs benötigten Zertifikate sind meist schon auf den jeweiligen Domain Controller vorhanden und beinhalten wie von Microsoft gefordert als CN= den FQDN des Domain Controllers. Dieser eindeutiger Eintrag im Zertifikat ist aber hinderlich wenn man in der Applikation welche man umstellt nur ein Feld für die LDAP Server hat, sich aber die Redundanz der mehrfach vorhanden Domain Controller zu Nutze machen will.
Bei einer reinen LDAP Abfrage auf den Domain Name war dies  bisher einfach möglich.

Durch die Umstellung auf LDAPs hat man das Problem, dass die Abfrage welche zuvor auf den hinterlegten Domain Name lautete z.B. ldap:///DomainName.Beispiel.com   nicht mit dem CN des Zertifikates übereinstimmt und somit die LDAPS Abfrage nicht erfolgreich ist.

Workaround der funktioniert aber umständlich ist:
Der einfachste Weg ist es das Zertifikat der Domain Controller mit den benötigten Inhalten wie dem Domain Namen oder einem (falls gewünscht) extra für LDAPs definierten DNS Namen zu ergänzen. Das Attribut dafür gibt es schon und nennt sich das SAN Attribut.

Dieser Workaround ist umständlich und für mich nicht zufriedenstellend. Durch diese Anpassung müssen beim beziehen des Zertifikates die SAN-Felder manuell ausgefüllt werden und das bei jedem erneuern auf jedem Domain Controller. Somit ist das automatische erneuern der Zertifikate nicht mehr möglich.

Lösung dieses Dilemmas lässt sich durch einen zwar nicht offiziell von Microsoft unterstützen Kniff lösen. Man bedient sich dem automatischen Renewal Prozess von Zertifikaten welche schon ausgestellt sind.
Dazu erstellt man das Zertifikate in der initialen Version manuell oder per PS Befehl, so wie auf den jeweiligen Domain Controllern benötigt. Das Autoenrollment wird erst danach aktiviert. So wird das Zertifikat zukünftige automatisch erneuert und die manuellen Tasks werden auf ein Minimum begrenzt.