Windows 10 Anmeldung mit Fingerabdruck in Active-Directory Domäne via GPO erlauben

Problem

Windows 10 erlaubt im Prinzip die „komfortable Anmeldung“ mittels PIN und Fingerabdruck über den Live-Account („Microsoft-Account“). Standardmäßig ist das in der Domäne aber deaktiviert und nur die Anmeldung an lokalen Benutzerkonten erlaubt.

Das ist daran zu erkennen, das praktisch alle Optionen unter Einstellungen > Konten > Anmeldeoptionen ausgegraut sind.

Sollte das ebenfalls in der lokalen Anmeldung der Fall sein, ist zumeist der Treiber des Biometrie-Gerätes schuld: Aufgrund der hohen Sicherheitsanforderungen (und dem geldlichen Notleiden des Konzerns) müssen Treiber für die Biometrischen Geräte zur Anmeldung ausnahmslos zertifiziert sein. Eine Menge älterer Treiber (Synaptics, WD, Asus …) sind das nicht und müssen vorher aktualisiert werden.

Sollte das endlich alles klappen, kann man die Biometrische Anmeldung in der Domäne aktivieren.

Lösung

windows10-biometrie-erlauben

Fingerabdruck-Anmeldung und Biometrische Anmeldung via GPO (Gruppenrichtlinie) erlauben:

  1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Verwendung von Biometrie zulassen
    1. aktivieren
  2. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Benutzeranmeldung mithilfe von Biometrie zulassen
    1. aktivieren
  3. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Domänenbenutzeranmeldung mithilfe von Biometrie zulassen
    1. aktivieren

Fingerabdruck-Anmeldung via Live-ID (Die PIN ist eine Voraussetzung) mithilfe der GPO (Gruppenrichtlinie) erlauben:

  1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Anmelden > PIN-Anmeldung aktivieren

Wichtig: Bei der Anmeldung via PIN wird das Kennwort des Benutzers im Tresor („Anmeldeinformationsspeicher“) lesbar gespeichert. Mit „lesbar“ ist an dieser Stelle Mimikatz oder ähnliches gemeint.

Active Directory Zertifikatsdienste Webregistrierung Fehler 0x80070057 (WIN32: 87)

Problem

Wenn man versucht die Zertifizierungsstellen-Webregistrierung nach der Installation oder Migration (oder Wiederherstellung einer CA) zu installieren („Konfiguration abschliessen“), tritt dieser Fehler auf:

Certification Authority Web Enrollment: Konfiguration fehlgeschlagen
Active Directory Certificate Services-Setup ist fehlgeschlagen mit dem folgenden Fehler: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

0x80070057-windows-ca-zertifizierungsstelleLösung

Mir sind bisher zwei Ursachen untergekommen, wahrscheinlicher ist die zweite.

Möglichkeit 1

Die Node zu den Public-Key Services im Active Directory existiert (noch) nicht oder der ausführende Benutzer hat keine Berechtigungen darin.

  1. ADSIEdit öffnen, Zum Konfigurationskontext verbinden
  2. Zu dieser Node navigieren: CN=Public Key Services, CN=Services, CN=Configuration, DC=DOMAIN,DC=TLD
  3. Wenn diese noch nicht existiert, anlegen.
  4. Wenn diese existiert, die Rechte auf den Schlüssel prüfen. Die Organisations-Admins sollten hier Vollzugriff haben (und der Account der das Setup abschliesst sollte dort Mitglied sein)

0x80070057-windows-ca-zertifizierungsstelle-ldap
Möglichkeit 2 (*wahrscheinlich*)

Das wahrscheinlichere Problem ist, dass der Wert des Schlüssels Setupstatus unter HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration falsche Daten enthält. Vermutlich steht hier der (HEX) Wert 6003 drin. Der Wert 6003 zeigt an, dass CA Webregistrierung bereits installiert ist. Der korrekte Wert für die Aktivierung lautet 6001 (not installed).

  1. In HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration den Wert Setupstatus von 6003 in 6001 ändern:
    certutil -setreg config \ Setupstatus 0x6001
  2. Den Abschluss von Setup erneut versuchen

Outlook 2016 gegen Exchange 2016 fragt immer wieder nach Kennwort („MAPI Virtual Directory Bug in Exchange 2016 CU2“)

Problem

Outlook 2016 verbindet sich nicht zu Exchange 2016. OWA geht. Die wichtigen URLs sind alle richtig konfiguriert:

Get-ClientAccessServer | fl autodiscover*
Get-ActiveSyncVirtualDirectory | fl *url*
Get-OutlookAnywhere | fl *hostname
Get-WebServicesVirtualDirectory | fl *url*
Get-OwaVirtualDirectory | fl *url*
Get-OabVirtualDirectory | fl *url*

Outlook 2013 funktioniert einwandfrei. Bei Outlook 2016 schlägt allerdings schon das hinzufügen eines Profils in der Systemsteuerung fehl – Man wird immer wieder nach Name und Kennwort gefragt.

Lösung

No+MAPI+AuthenticationExchange 2016 CU2 bringt einen (bisher ungefixten) ziemlich fiesen und schwer zu jagenden Bug mit. Wenn man im GUI (ECP) das virtuelle Verzeichnis „mapi“ (für die RPC/HTTP von Outlook 2016) bearbeitet, wird beim Speichern immer die IIS-Authentifizierung zurückgesetzt. Immer. Auf nichts. Leer. Egal ob man auf der Seite etwas macht oder nicht, egal was man macht.

Fix für alle mapi-Verzeichnisse

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate,OAuth

Vielen Dank Microsoft für erfüllte neun (!) Stunden Fehlersuche mit viel Haare raufen. Vor allem vielen Dank für die absolute Abstinenz jeglicher Outlook-Discovery debugging-Werkzeuge (nein, dieser Server war nicht extern erreichbar).

Exchange 2016: „Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container.“

Problem

Das Setup von Exchange 2013/2016 brit untätig mit dieser Fehlermeldung ab:

Setup encountered a problem while validating the state of Active Directory:
Couldn't find the Enterprise Organization container

Das Exchange Setup Logfile (C:\ExchangeSetupLogs\ExchangeSetup.log) liefert ähnlich genau Details:

[11/08/2016 05:36:10.0207] [1] Failed [Rule:AdInitErrorRule] [Message:Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.]
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.
[11/08/2016 05:36:10.0223] [1] [REQUIRED] Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.
[11/08/2016 05:36:10.0223] [1] Help URL: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx
[11/08/2016 05:36:10.0238] [1] Ending processing test-SetupPrerequisites

Lösung

In dieser Domäne wurde ein Exchange 2007 oder Exchange 2010 Server deinstalliert. Im letzten Schritt entfernt das Exchange Setup nämlich die „Erste Organisation“ aus dem ActiveDirectory, aber hinterlässt die Microsoft Exchange System Objects. Das verwirrt das 2013’er Setup. Vermutlich wurde dieser Fall bei Microsoft nicht getestet (wer will auch Exchange deinstallieren?).

Das Setup von Exchange 2007 (SP3+) oder Exchange 2010 einfach nochmal aufrufen:

C:\THINGS\ex2007> setup /preparead /on:"<ORGANISATIONSNAME>"

Die Installation ist nicht notwenig, nur das PrepareAD. Das Setup baut die entsprechenden Contain wieder ein und das Exchange 2013/2016 Setuo läuft problemlos durch.

Veeam Backup & Replication – Access Denied bei einigen Backup Copy Jobs

Problem:

In Veeam Backup & Replication (v9) schlagen manche Backup Copy Jobs fehl.
Situation:
Mehrere Backup Copy Jobs
Repository auf einem eigenständigen Repository-Server
Einer der Copy Jobs schlägt fehl mit „Access Denied“ – alle anderen funktionieren.
veeam_copy_access-denied

Lösung:

Die Anmeldung für den Veeam Backup Service erfolgt standardmäßig mit dem lokalen Systemkonto, ändert man die Einstellung z.B. auf ein Domänenkonto, welches Zugriff auf die Ziel-Repositories hat, funktionieren die fehlerhaften Copy Jobs nach neustart des Dienstes.
veeam_copy_service

  1. Continuous Copy Jobs auf Disabled stellen
  2. Beachten, dass keine weiteren Veeam Backup Jobs laufen
  3. Veeam Konsole schließen
  4. Anmeldedaten des Dienstes „Veeam Backup Service“ auf ein entsprechendes Domänenkonto ändern
  5. den Dienst neustarten
  6. Veeam Copy Jobs wieder aktivieren