App Kennwort für Microsoft 365 Exchange Online Postfach erstellen

Nicht schnell eingerichtet, aber sehr hilfreich: App Kennwörter als Ergänzung zur Multi-Faktor Authentifizierung – als Teil von Microsoft 365 ist ein fundamentaler und sehr gut umgesetzer Schutzfaktor für den Zugang.

Der geneigte Microsoft 365 Administrator kann Multi-Faktor Authentifizierung mit wenigen Klicks (oder via PowerShell) für einzelne oder alle Anwender aktivieren. Wie steht es aber um statische App Kennwörter – Wie erstellt man nun für ältere Programme oder SMTP-Clients (Kopierer, Scanner, CNC-Maschinen …) App-Kennwörter?

Limitierungen bei App Kennwörtern

  • Pro Benutzer maximal 40 App-Kennwörter
  • App-Kennwörter funktionieren nur in Microsoft 365, auch bei Hybrid-Szenarien nicht im lokalen Server
  • Funktioniert nicht bei „bedingtem Zugriff“ mit MFA (und modernern Auth)
  • App Kennwörter werden generiert (z.B. xmnfgsaofn3DSk) vorgegeben und können nicht geändert werden. Muss ein Kennwort „getauscht“ werden, geht das nur über löschen > Neu
  • Bei den „Hohen Sicherheitsstandarts“ muss MFA pri User erzwungen sein

Schritt 1 – App-Kennwörter für Benutzer erlauben

Man kann App Kennwörter nur erlauben, wenn die Azure AD Multi-Factor Authentication für den betreffenden Nutzer aktiviert ist.

  1. „Mehrstufige Authentifizierung“ Center als Administrator öffnen: https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx
  2. Ganz Oben (!) unter „diensteinstellungen“ den „Benutzern das Erstellen von App-Kennwörtern zum Anmelden bei nicht browserbasierten Apps gestatten“

Schritt 2 – MFA erzwingen

Ganz oben unter „benutzer“ muss die Verwendung von MFA erzwungen werden, wenn die „Hohen Sicherheitsstandarts“ für das AzureAD eingeschaltet sind (Standard seit 2020).

Die Einstellung wird in aller Regel nicht sofort aktiv, aber man kann die Übernahme erzwingen, indem man als Administrator alle Sitzungen des Nutzers abmeldet und der Nutzer sich neu (in einem Browser) anmeldet

Schritt 2 – App Kennwort erstellen

  1. Das My-Signins Center als Benutzer (nicht mehr als Administrator) öffnen: https://mysignins.microsoft.com/security-info
  2. Unter Sicherheitsinformationen > Methode hinzufügen ein App Kennwort einrichten

Exchange OnPremises Ressourcen (Ressourcen-Postfächer wie Räume) nach Exchange Online migrieren

Benutzer-Postfächer kann man im Exchange Control Panel (ECP) durch einen schnellen Klick auf „Postfach verschieben > Zu Exchange Online“ recht einfach verschieben.

Leider hat Microsoft noch keine solche Funktion für Ressourcenmailboxen eingebaut. Also muss man Räume und Geräte manuell an der PowerShell verschieben. Das geht allerdings relativ problemlos.

Raum- oder Gerätepostfächer zu Exchange online verschieben

Zuerst eine Verbindung zur Exchange Online PowerShell herstellen:

PS C:\> Import-Module ExchangeOnlineManagement
PS C:\> Connect-ExchangeOnline

Dann ein Credential-Objekt für die lokale Domäne erstellen:

PS C:\> $OnPremCred = Get-Credential

Und schliesslich die Migrationsaufträge (MoveRequests) erstellen:

PS C:\> New-MoveRequest -Identity "<Name der Ressource>" -Remote -RemoteHostName <Name Exchange> -TargetDeliveryDomain <Tenant Name>.onmicrosoft.com -RemoteCredential $OnPremCred

Mit den üblichen Tools wie Get-MoveRequest lässt sich der Auftrag dann verfolgen. Im GUI sieht man diese allerdings leider nicht – dafür freifen Parameter wie das BadItemLimit und so weiter.

Benutzerprofil-Datenträger Maximal Größe nachträglich anpassen

In einer RDS-Sammlung kann man die maximal Größe einer User Profile Disk bei der Erstellung vorgeben. Nachträgliche Änderungen sind jedoch nicht mehr möglich. Die Option „Maximale Größe“ ist ausgegraut. Man müsste die ganze Sammlung dafür eigentlich neu erstellen …

Die Option maximal Größe ist ausgegraut

Lösung

Man muss direkt das VHDX-Template das die Sammlung bei der Erstellung anlegt bearbeiten. Das Template heisst UVHD-template.vhdx und liegt in dem in der Sammlung festgelegten Share.

Die VHDX „Festplatte“ vergrößert man am einfachsten mit DISKPART.

C:> Diskpart

DISKPART> select vdisk file="F:\vhdx\UVHD-template.vhdx"
(Datei auswählen)

DISKPART> expand vdisk maximum=20000
(Vergrößern, 20000 = 20 Gbyte)

DISKPART> attach vdisk
(vDisk mounten)

DISKPART> list volume
(Volumes auflisten)

DISKPART> select volume <VOLUME-ID>
(Auswählen des Volumes, die ID der VHDX-Partition wählen)

DISKPART> extend

DISKPART> detach vdisk

DISKPART> exit

Im Live-Betrieb sieht das dann so aus:

Leider wird die Anzeige im Windows Server-Manager dazu nie aktualisiert, der Wert bleibt im GUI auf dem erstmalig eingetragenen Wert stehen. Die Box also müsste eigentlich „Maximale Größe bei erstellung“ heißen. Da der Server-Manager aufgrund seiner Fehler und generellen Schwerfälligkeit grundsätzlich aber nicht unbedingt das Lieblingswerkzeug von Administratoren ist, kann man diese rein kosmetische Angabe dort ganz gut ignorieren.

Privaten Schlüssel eines Zertifikat aus dem Windows Zertifikatsspeicher exportieren der als „nicht exportierbar“ markiert ist

Manchmal findet sich ein Zertifikat im Windows-Zertifikatsspeicher (Cryptostore), welches man einschliesslich des zugehörigen privaten Schlüssel benötigt.

Beispielsweise kommt das vor bei einer Migration (IIS, Webserver), einem VPN-Service (RRAS) oder Software, die selber eine Schlüsselprüfung durchführen möchte. Windows verbietet allerdings den Export direkt aus dem Cryptostore, unabhängig von den Berechtigungen auf dem Schlüssel.

Die zugehörige Option im Zertifikatsmanager-Assistenten ist daher auch ausgegraut:

Lösung

  1. Windows Defender ausschalten
  2. mimikatz herunterladen (https://github.com/gentilkiwi/mimikatz/releases), am besten den aktuellen trunk
  3. mimikatz „Als Administrator“ ausführen

In mimikatz Ausführen:

privilege::debug

crypto::cng

crypto::capi

crypto::certificates /systemstore:local_machine /store:my /export

Die Ausgabe sollte in etwa wie folgt aussehen:

mimikatz # privilege::debug
 Privilege '20' OK

mimikatz # crypto::cng
 ERROR kull_m_patch_genericProcessOrServiceFromBuild ; kull_m_patch (0x00000000)

mimikatz # crypto::capi
Local CryptoAPI RSA CSP patched
Local CryptoAPI DSS CSP patched

mimikatz # crypto::certificates /systemstore:local_machine /store:my /export
 * System Store  : 'local_machine' (0x00020000)
 * Store         : 'my'

 0. [IIS] <CERTNAME>
    Subject  : CN=<CERT-CN>
    Issuer   : C=<CERT-DATA>
    Serial   : <CERT-SERIAL>
    Algorithm: 1.2.840.113549.1.1.1 (RSA)
    Validity : <CERT-VALID>
    Hash SHA1: <CERT-HASH>
        Key Container  : {<CNG-ID>}
        Provider       : Microsoft RSA SChannel Cryptographic Provider
        Provider type  : RSA_SCHANNEL (12)
        Type           : AT_KEYEXCHANGE (0x00000001)
        |Provider name : Microsoft RSA SChannel Cryptographic Provider
        |Key Container : {<MACHINE CNG ID>}
        |Unique name   : <CERT-NAME>
        |Implementation: CRYPT_IMPL_SOFTWARE ;
        Algorithm      : CALG_RSA_KEYX
        Key size       : 3072 (0x00000c00)
        Key permissions: 0000003b ( CRYPT_ENCRYPT ; CRYPT_DECRYPT ; CRYPT_READ ; CRYPT_WRITE ; CRYPT_MAC ; )
        Exportable key : NO
        Public export  : OK - '<PATH TO DER>'
        Private export : OK - '<PATH TO PFX>'

Und schon findet man die (alle) Zertifikate aus dem lokalen Speicher im Ausführungsverzeichnis.

„Der neue Edge“ Browser von Microsoft download

Microsoft hat den Download des neuen Edge Browsers … versteckt? Oder zumindest wirkungsvoll eingeschränkt. Man kann den Browser auf seiner eigenen Webseite nicht mehr wie gewohnt herunterladen sondern der Button will seinerseits nur noch Edge (?) öffnen (?!?).

Wir sind nicht sicher, ob diese Aktion der Verbreitung des neuen Browser wirklich zuträglich ist

Wie auch immer, mach ein Admin würde trotzdem gerne Edge auf Windows 10 oder Windows Server 2019 installieren und benötigt daher weiterhin den „MicrosoftEdgeSetup.exe“ Installer. Oder das Edge MSI zur Verteilung im Netzwerk.

Download Microsoft Edge (Setup/MSI)

MicrosoftEdgeSetup.exe (Windows 10/Server 2019) Download: https://go.microsoft.com/fwlink/?linkid=2069324&Channel=Stable&language=de

Microsoft Edge Offline-Installer X64.msi oder X86.msi

IIS ARR Reverse Proxy mit Redirects und Ausnahmen für Let’s Encrypt

Problem

Man möchte einen Webserver hinter einem IIS als „Frontend“ Reverse Proxy via ARR (Application Request Routing) betrieben und dem IIS das SSL-Offloading überlassen.

Der reverse Proxy ist schnell eingerichtet, aber wie vermeidet man, das ein ACME-Tool (beispielsweise win-acme) an der Validierung des Zertifikates scheitert, weil der IIS die Requests an /.well-known/acme-challenge/* ebenfalls an den Webserver weiterleitet?

Lösung

Man verwendet verschiedene Regeln um das zu verhindern. Entweder erstellt man diese im wundervollen IIIS GUI oder bearbeitet die zugehörige web.config:

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />


<!-- Letsencrypt-Ausnahme -->
                <rule name="LetsEncryptException" stopProcessing="true">
                    <match url=".well-known/acme-challenge/*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="None" />
                </rule>


<!-- Redirect auf HTTPS -->
                <rule name="Redirect-HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://DEINEDOMAIN.COM/{R:1}" appendQueryString="false" redirectType="Found" />
                </rule>


<!-- Redirect root "/" in Verzeichnis (oft hilfreich bei Tomcat Apps) -->
		<rule name="redirect-to-subdir" stopProcessing="true">
			<match url="^$" />
			<action type="Redirect" url="https://DEINEDOMAIN.COM/DEINVERZEICHNIS/WHATEVER" />
		</rule>


<!-- Reverse Proxy -->
                <rule name="ReverseProxy" stopProcessing="false">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="Rewrite" url="http://INTERNERSERVER:8059/{R:1}" />
                </rule>


            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Word/Excel Fehlermeldung bei Nutzung mehrere OneDrive Konten auf einem Computer

Problem

Verwendet man mehrere OneDrive-Konten auf einem Computer, kommt es gelegentlich zu diesem Fehler, wenn man Dateien aus dem „zweiten“ OneDrive Ordner öffnet. Die Meldung kommt immer, unabhängig ob man die Dateien „on demand“ nutzen möchte oder vollständig synchronisiert hat.

Ihre Änderungen können nicht hochgeladen oder heruntergeladen werden, weil ihre zwischengespeicherten Anmeldeinformationen abgelaufen sind.

Wenn man sich dann anzumelden versucht, wie von Excel so prominent vorgeschlagen, erhält man die Fehlermeldung:

Leider ist an diesem Computer bereits ein anderes Konto aus Ihrer Organisation angemeldet.

Lösung

Das Problem sind die Office-Apps, die direkt versuchen mit dem angemeldeten Benutzer in das „fremde“ OneDrive zu schreiben. Das schlägt natürlich fehl, aber Office ignoriert hier scheinbar (äußerst penetrant) die erfolgte und korrekte Einrichtung als zweites OneDrive.

Glücklicherweise kann man dem OneDrive Client abgewöhnen, die Office-Apps zu konfigurieren. Die Option ist nur etwas seltsam benannt.

OneDrive-Symbol > Einstellungen > Office > „Office-Dateien, die ich öffne, mit Office-Anwendungen synchronisieren“ abschalten

Und schon funktrioniert der Zugriff wieder fehlerfrei – es ist nicht einmal ein Neustart notwendig (außer von den Office-Apps).

Allerdings gehen durch diese Umstellung die synchronen Online-Features verloren, wie die gleichzeitige Bearbeitung einer Datei durch mehrere Benutzer oder das automatische Online-Speichern.