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.

Active Directory Managed Service Accounts (gMSA)

Voraussetzungen und Restriktionen

AD MSA können nur auf Domain Controller auf Basis Windows 2008 R2, Win7 und neuere Windows Versionen verwendet werden. Sollte eine ein ältere Version im Einsatz sein schafft dieser KB Artikel Abhilfe.

http://technet.microsoft.com/en-us/library/dd548356(v=ws.10).aspx

Auf jedem Computer darf immer nur ein ADMSA Account geben.

Verwaltung und Administration der gMSAccounts

Alle Accounts müssen via Powershell und geladenem Module "ActiveDirectory" administriert werden. 

CMDLets

Add-ADComputerServiceAccount                    
Get-ADComputerServiceAccount                      
Get-ADServiceAccount                              
Install-ADServiceAccount                          
New-ADServiceAccount                            
Remove-ADComputerServiceAccount      
Remove-ADServiceAccount                      
Reset-ADServiceAccountPassword          
Set-ADServiceAccount                              
Uninstall-ADServiceAccount        

     

Create and manage gMSAccount : 

erstelle eines gMSAccounts 

New-ADServiceAccount -name <Account-Name> -Path "DestinguishedName der AblageOU" -enabled $true

Verbinden des gMSAccounts  mit dem Computer Objekt.

Add-ADComputerServiceAccount -Identitiy <Zielcomputer> -ServiceAccount <Account-Name>

Verifizieren des verlinkten gMSA 

In den Attributen des Computer Objekts kann dies geprüft werden mit den Namen "msDS"

Vorbereitung Client

Auf dem Client müssen die AD Powershell CMDlet und .Net 3.5 installiert werden.

Installation des gMSA auf dem Client

Der Account muss auf dem Client installiert werden. Hierfür nutz man den Befehl 

Install-ADServiceAccount -Identity <Account-Name>

Hinterlegen des Accounts wird über die Services.msc (Dienst Konsole) mit Anmelden -> Dieses Konto -> Account aus dem AD wählen und das PW Feld löschen -> Service Restart


Änderungen und neue Features zu Server 2012 folgen....

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Tipps und Tricks:

Error: Beim ausführen des Befehls

New-ADServiceAccount -Name <TestAccount> -Path <CN=Managed Service Accounts,DC=Domain,DC=test> 

kommt diese PS Errors

New-ADServiceAccount: Der Schlüssel ist nicht vorhanden
New-ADServiceAccount: Key does not exist

Man muss 10 Stunden warten um die Replikation zeit zu geben. Dies liegt an der Passwort Generierung welche verhindert, dass ein DC diese Anfrage annimmt. In einer Testumgebung oder kleinen Domain mit nur einem DC kann dies ausgehebelt werden mit dem Command:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))   

Error: Installieren des Accounts auf dem Client

Zeichenmaximum bei gMSAccounts ist bei 15 Stellen. Beim installieren des Accounts auf dem Client erhält man sonst diese Fehlermeldung in der PS.

Install-ADServiceAccount : Cannot install service account. Error Message: 'Unknown error (0xc0000017)'.

Quellen:
http://technet.microsoft.com/en-us/library/jj128431.aspx
http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/82617035-254f-4078-baa2-7b46abb9bb71/

Active Directory - Change Site to Site Replication Time

Problem:
Wenn die Replikation zwischen zwei Sites nicht schnell genug ist kann diese über die Konfiguration verkürz werden.
Szenario:
Dieses Ansatz ist sehr hilfreich, wenn die Standard Replikation welche mindestens 15min beträgt nicht ausreicht.
Beispiel: Site ist ausschließlich mit einem Read only Domain Controller (RODC) ausgestattet. Somit werden Änderungen an einen Objekt welche in der Site mit dem RODC an den nächsten Writeable Domain Controller (RWDC) weitergeleitet. Diese müssen aber die empfangene Änderung wieder an den RODC zurück schreiben. Da nicht alle Attribute am PDC abgefragt werden sondern auschliesslich am RODC kann es sein, dass das Objekt vom RODC nicht aktuell ist. Dies kann zu Problemen fürhren wenn wenn z.B. das Computer Objekt Password erneuert wurde.

Beispiel

Lösung:
Die Site Replikation muss von 15min (mindest Wert welcher über die GUI eingestellt werden kann) herunter gestellt werden. Dies kann über ein Site Attribute angepasst werden.
In ADSIEDIT kann unter
Konfiguration/Sites/Inter-Site Transports/IP
für die jeweilige Site welche eine sofortige Replikation ausgelöst werden. Dies wird durch das Attribute "Options" gesetzt welches im Default Wert leer ist. Wird hier der Wert 1 eingesetzt so informiert der DC seinen nächsten Replikationspartner welche über die Site mit diesem DC kommunizieren.

Diese Option sollte mit Vorsicht definiert werden, da die übertragene Datenmenge erhöht wird. Auch die Auslastung des DC wird merklich erhöht.


Quelle: http://www.msexchangefaq.de/konzepte/adsitelinkreplication.htm

Logon Probleme beim WSUS Installation am Service "Interne Windows-Datenbank"

Problem:
GPO Steuerung der "Anmelden als Dienst" oder "Logon as a Service" ist unter Windows 2012 definitiv komplizierter geworden.
Etliche Roles erstellen bei der Installation mehrere Accounts welche über dieses Recht verfügen müssen.

Die Installation für WSUS auf Win Server 2012 erstellt einen lokalen Account "NT SERVICE\MSSQL$MICROSOFT##WID" welcher für die Services z. B. "Interne Windows-Datenbank" benötigt wird.

Lösung:
Diesen Service explizit via GPO zu definieren ist mir noch nicht gelungen. Welche Lösung definitiv hilft ist diesen Account in der GPO zu hinterlegen "NT SERVICE\ALL SERVICES"
http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/7768ffb1-fd78-430f-b122-873f5306580f


Eventuell Tips sind erwünscht.