Mittwoch, 28. Mai 2014

MS14-025 - Das Ende der gespeicherten Passwörter

Gruppenrichtlinien bieten die Möglichkeit Passwörter für gewisse Aufgaben zu setzen.

Hierbei handelt es sich um folgende Gruppenrichtlinieneinstellungen
(Group Policy Preferences):



  •     Laufwerkzuordnungen
  •     Lokale Benutzer und Gruppen
  •     Geplante Aufgaben
  •     Dienste
  •     Datenquellen 

XML als Basis
Group Policy Preferences basieren auf XML Dateien.
Passwörter die für die oben genannten Einstellungen gespeichert werden, werden im SYSVOL innerhalb der betreffenden XML Dateien in einem Attribut gespeichert. Hierbei handelt es sich um das Attribut "cPassword".
Das Passwort wird nicht im Klartext in die XML Datei geschrieben. 
Das Passwort ist mittels 32-Byte AES verschlüsselt.
Diese Verschlüsselung ist relativ schwach.

Das zusätzliche Problem: 
Der Schlüssel wurde veröffentlicht und ist somit frei zugänglich.

Speichert man mittels GPP ein Passwort im SYSVOL, so wird ein Warnhinweis angezeigt.


Im Übrigen wird diese Meldung unter Windows 8 / 8.1 nicht in die jeweilige Sprache übersetzt und ist folglich immer Englisch :-)

Passwörter per GPP vermeiden
Da standardmäßig alle "Authentifizierten Benutzer" Lesezugriff auf diese Dateien haben, stellt dies also ein großes Sicherheitsrisiko dar.

MS14-025 - Microsoft reagiert
Microsoft hat nun auf diese Sicherheitslücke reagiert und ein Sicherheitsbulletin veröffentlicht. 

Eine ausführliche Beschreibung von Microsoft und weiterführende Downloadlinks findet ihr hier:

http://support.microsoft.com/kb/2962486/de


GPP Password Finder
Mit diesem Update wird einem zwar die Möglichkeit genommen, zukünftig Passwörter per GPPs zu setzen, jedoch bleiben die bestehenden Passwörter unberührt.

Policies die ein cPassword Attribut enthalten könnt ihr mittels PowerShell ermitteln. Zusätzlich habt ihr die Möglichkeit meinen "GPP Password Finder" zu verwenden. Dieser basiert nicht auf PowerShell.

https://onedrive.live.com/redir?resid=62A6D19FFDA7F555%21172

Das Programm benutzt ihr natürlich auf eure eigene Verantwortung.




Weiterführende Links
Zwei sehr gute Artikel findet ihr bei MVP Alan Burchill.



http://www.grouppolicy.biz/2014/05/remove-cpassword-values-active-directory/

http://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/

Donnerstag, 27. März 2014

Internet Explorer Content Advisor wird für alle Benutzer übernommen

Zugriff auf Internet-Seiten beschränken
Der Zugriff auf Webseiten im Internet sollte immer an einem Proxyserver bzw. Firewall beschränkt werden. 

Wird der Zugriff am Proxy / an der Firewall eingeschränkt, so ergeben sich folgende Vorteile:
  • Diese Lösung ist unabhängig vom verwendeten Browser
  • Diese Einstellungen werden zentral am Proxy gesetzt 
  • Die Einschränkungen können nicht durch das Ändern von Clienteinstellungen umgangen werden
Internetzugriff komplett sperren
Hier kursieren diverse GPO-basierende Lösungen.
Die Idee vieler Admins: Einen Proxyserver setzen der nicht existiert und dem Benutzer die Möglichkeit entziehen diesen Eintrag zu ändern.


Hier enstehen ebenfalls Probleme:
  • Diese Lösung ist nicht unabhänig vom verwendeten Browser
  • Dienste die auf einen Proxyserver angewiesen sind (z.B. Windows-Update Dienst der die Updates direkt von Microsoft laden soll) sind ebenfalls von dieser Einschränkung betroffen
  • Ein erfahrener Benutzer kann diese Einstellung umgehen
Intranet- und Internetzugriff einschränken
Der Benutzer soll auf eine definierte Whitelist von Intra- und Internetseiten zugreifen können. 

Hier scheitern viele Proxylösungen. Die meisten Produkte können nur den Internetzugriff beschränken.

Eine Lösung auf Clientbasis bietet sich an.

Der Internet Explorer bringt eine solche Lösung bereits mit:
Den Content Advisor


Diese Funktion lässt sich über Gruppenrichtlinen steuern.
Die CSE Internet Explorer Wartung kann diese Einstellungen setzen.
Die gilt allerdings nur bis einschließlich IE 9.

Sollen diese Einstellungen für alle Benutzer des Clients/Servers gelten, so werden diese übernommen.

Definiert man jedoch eine Policy, die nur von gewissen Benutzern (bzw. Benutzergruppen) übernommen werden soll, so wirkt sich diese auch auf alle anderen Benutzer aus.

Beispiel:
  • Am Terminalserver "RDS01" soll eine Benutzergruppe "KIOSK-USERS" auf eine Whitelist von Webseiten eingegrenzt werden
  • Die Einstellungen werden per Internet Explorer Wartung in einer Policy gesetzt
  • Die Policy wird nur von der Gruppe "KIOSK-USERS" übernommen
  • Alle anderen Benutzer erhalten keine IEM (Internet Explorer Maintenance) Einstellungen
ACHTUNG:
In diesem Falle gelten die Einstellungen für alle Benutzer.

Über die Frage ob es sich hier um einen Bug handelt oder ein gewolltes Design,
lässt sich streiten.

Stellt man diese Einstellung manuell am Server als Administrator in eurem IE ein, so gelten diese auch für alle Benutzer des Clients/Servers.

Mittwoch, 19. Februar 2014

Computerkonten auf allen DCs löschen

Einige Umstände machen es nötig, dass ein Client erneut in die Domäne aufgenommen werden muss. Wird zum Beispiel ein Image / Snapshot einer VM zurückgespielt, so stimmt das lokal gespeicherte Computerkennwort nicht mehr mit dem im Active Directory gespeichertem Kennwort überein.

In der Regel reicht es aus, das Computerkonto beizubehalten und nur den "Domain Join" aufzufrischen. 

Domäne raus / rein 
Der Rechner kann zunächst in eine Arbeitsgruppe aufgenommen werden:



Nach einem Reboot kann er dann wieder in die Domäne aufgenommen werden.

Ohne in die Workgroup zu wechseln 
Wer sich an dieser Stelle den Übergang in die Workgroup sparen will, der kann wie folgt vorgehen:



Wir ändern einfach den FQDN der Domäne ("my.domain") in den Netbios-Namen der Domäne "DOMAIN". Das akzeptiert die GUI als Änderung und lässt uns
damit das AD Konto auffrischen. Danach ist ein Neustart erforderlich.



Der Rechner kann natürlich auch mittels PowerShell (Add-Computer) oder netdom der Domäne hinzugefügt werden.


Computerkonto löschen? 
In einigen Fällen ist es jedoch nötig auch das Computerkonto zu löschen.
Die ist zum Beispiel der Fall, wenn ein Client umbenannt werden soll, es aber das Konto (bzw. den Hostnamen) des Clients bereits gibt.

An dieser Stelle sollte man das AD Konto löschen.

Löscht man das Computerkonto, sollte man die vollständige Replizierung der Domain Controller abwarten. Windows hat die Eigenschaft beim Domain-Join
verschiedene DCs nach einem bereits vorhandenen Konto zu durchsuchen.
Hierbei spielt die AD-Sitezuordnung keine Rolle.

Hier ein Beispiel:

Wird haben zwei DCs am Hauptstandort. DC-MAIN01, DC-MAIN02

Zusätzlich gibt es einen DC in einem Außenbüro. DC-SITE01

Das Computerkonto wird auf DC-MAIN01 gelöscht. DC-MAIN02 repliziert relativ schnell diese Änderung. Bei DC-SITE01 dauert dies jedoch länger (abhängig davon wie die Inter-Site Replikationspläne im AD gesetzt wurden).

Versucht man direkt nach dem Löschen des Computerkontos den Client wieder in die Domain aufzunehmen, dann ist die Wahrscheinlichkeit groß, dass dieser auf DC-SITE01 das noch vorhandene Konto findet und verwendet.

Der Client funktioniert erst einmal wie gewohnt. Repliziert jedoch nun irgendwann DC-SITE01 mit DC-MAIN01 oder 02, so wird das Konto gelöscht.

Egal ob dieses noch einmal geändert wurde oder nicht.


Abwarten? 

Man könnte nun natürlich einfach abwarten, bis die Löschung repliziert wurde. 
Im Zweifelsfalle dauert dies jedoch zu lange.
In kleineren Umgebungen können wir auch die Replizierung manuell erzwingen.
Dazu könnt ihr dieses PowerShell Skript verwenden:

repadmin /viewlist * | Foreach-Object `
{
  If($_)
  {
    $StrDCName = ([regex]::match($_,"(?<=DSA_LIST\[\d?\]\s\=\s).+").value)
    Write-Host "Processing "$StrDCName -for Green
    repadmin /kcc $StrDCName 
    repadmin /syncall /A /e $StrDCName 
  }
}

Hierbei werden euch alle Inter-Site Replikationen angestoßen.

Bei größeren Umgebungen ist dies jedoch zu träge und dauert ebenfalls zu lange.


Computerkonten sofort löschen 

Die einfachste Methode ist ein Skript, das die Computerkonten auf allen DCs sofort löscht.

cls
@echo off

IF NOT EXIST "%windir%\system32\dsquery.exe" (
    echo.
    echo Program will end. dsquery.exe not found
    echo.
    pause
    exit
)


set /P PC=Please enter the Computername you want to delete:
for /f "delims=" %%A in ('dsquery computer -name %PC%') do set "DN=%%A"

echo.%DN%|findstr /C:"CN=" >nul 2>&1
if errorlevel 1 (
    cls
    echo.
    echo Program will end. No Computer found in Active Directory.
    echo.
    pause
    exit
)

cls
echo.
echo dsrm %DN% -s DCNAME -noprompt
echo.
set /P c=Do you want to run the command above [Y/N]?
if /I "%c%" EQU "Y" goto choice
if /I "%c%" EQU "J" goto choice
exit

:choice
cls
echo.
for /F %%i IN ('dsquery Server -o rdn -Forest') DO (
echo.
echo Trying to delete account on %%i
dsrm %DN% -s %%i -noprompt
echo.
)
pause


Hierbei handelt es sich um ein reguläres Batch-Skript.
Auf dem Client auf dem das Skript ausgeführt wird, müssen jedoch die AD-Commandline Tools installiert sein. Installiert man mittels RSAT das Snapin "Active Directory Users and Computers", so werden diese auf dem Client per Default mit installiert. 


Nachdem ihr das Skript ausgeführt habt, wird das Konto auf allen erreichbaren DCs gelöscht und ihr könnt den Rechner ohne Probleme in die Domäne aufnehmen.

An dieser Stelle sei gesagt, alle Skripte führt ihr wie immer auf eigene Verantwortung aus.

Freitag, 17. Januar 2014

Group Policy Caching - sinnvoll oder sinnlos?

Microsoft hat unter Windows 8.1 (bzw. Server 2012 R2) eine neue Funktion eingeführt die sich "Policy Caching" nennt.

Microsoft selbst ist jedoch relativ schweigsam wie Group Policy Caching funktioniert und wann es Verwendung findet.

Siehe TechNet:
http://technet.microsoft.com/en-us/library/dn265973.aspx#BKMK_gpresults

Was ist Group Policy Caching?
GPC (Group Policy Caching) ist ein lokaler Zwischenspeicher im Verzeichnis "C:\Windows\system32\grouppolicy\DataStore".

Dieser Speicher wird bei jedem Group Policy Refresh aktualisiert.
Es handelt sich dabei mehr oder weniger um eine Kopie der im SYSVOL befindlichen Daten. Der nächste Policy Zyklus (beim Starten oder Login) verwendet dann evtl. (später mehr dazu) diesen Cache um die Abarbeitungszeit der Richtlinien zu verringern.



Eine Sache ist hier entscheidend:
Der Group Policy Cache ist nur bei der synchronen Richtlinienverarbeitung aktiv!

Den Unterschied zwischen synchroner und asynchroner Richtlinenverarbeitung findet ihr in meinem Blogeintrag "Der große Group Policy Troubleshooting Guide - Teil 3/3 "

Wann wird Group Policy Caching wirklich verwendet?
Genau diese Frage zeigt das große Problem des neuen Features GPC.

Unter folgenden Umständen wird GPC nicht verwendet:
  1. Die Richtlinienverarbeitung ist asynchron
  2. Die Richtlinienverarbeitung ist synchron, jedoch ist die Einstellung "Always wait for network at computer startup and user logon" aktiviert
  3. Die Richtlinienverarbeitung ist synchron, jedoch nur weil der User sich das erste Mal an diesem Gerät anmeldet 
  4. Group Policy Caching ist deaktiviert
  5. Der DC antwortet nicht oder der DC antwortet mit einer Zeitüberschreitung (der Zeitüberschreitungswert wird in der gleichen Policy definiert)
Unter folgenden Umständen wird GPC verwendet:
  1. CSEs, die eine synchrone Verarbeitung erfordern, lösen eine synchrone Verarbeitung aus.

    Windows 8.1 hat nur noch zwei CSEs die eine synchrone Verarbeitung erfordern:
  • Folder Redirection
    • Software Installation
      Die Wahrscheinlichkeit dass der GPC-Mechanismus überhaupt benutzt wird, ist relativ gering. 

      Microsoft macht ebenfalls nicht deutlich, wie das genaue Zusammenspiel zwischen Group Policy Caching und Slow Link Detection funktioniert.

      Der offizielle Hilfetext der Richtlinieneinstellung lässt Folgendes vermuten:
      • Wird der Cache gelesen, so wird der DC kontaktiert
      • Ist diese Antwort außerhalb des Timeouts (bzw. gibt es keine Antwort) so wird die Verarbeitung der Richtlinien abgebrochen und beim nächsten Background-Refresh durchgeführt
      • Das Herunterladen in den Cache wird ebenfalls beschränkt, sobald eine langsame Verbindung erkannt wird. Hier werden jedoch nicht die Einstellungen dieser Policy verwendet, sondern die Einstellungen dieser Policy
      Leider lässt die unvollständige Microsoft-Dokumentation das genaue Verhalten nur vermuten.

      Was sind die Nachteile des Group Policy Caching?
      1. Die Abarbeitungszeit der Hintergrundaktualisierung (auch gpupdate, gpupdate /force) ist deutlich höher, da die Policies in den Cache kopiert werden müssen
      2. Während der Hintergrundaktualisierung wird durch das Caching sehr häufig auf das SYSVOL-Share der DCs zugegriffen
        (siehe auch http://www.grouppolicy.biz/2013/07/windows-8-1-group-policy-update-performance-changes/)
      3. Während des Cachings werden alle Dateien, die sich in diesen Ordner befinden, auf den Client kopiert:

        \\domain.intern\sysvol\domain.intern\Policies\{GUID}\Machine 

        \\domain.intern\sysvol\domain.intern\Policies\{GUID}\User


        Hierbei wird keine Unterscheidung gemacht welche Dateien kopiert werden müssen. Liegen hier aus irgendeinem Grund große Datenmengen, so werden alle Dateien auf den Client kopiert.
      Fazit
      Der Grundgedanke von GPC ist gut. Jedoch findet es in der Praxis kaum Verwendung. Die vielen Außnahmen deaktivieren in der Praxis GPC.

      Das Caching ist gerade im Zusammenhang mit langsamen Netzwerkverbindungen interessant. Allerdings müssen die gesetzten Schwellwerte korrekt sein. Wird ein Schwellwert überschritten, so ist GPC ebenfalls deaktiviert (genauer gesagt wird die ganze Richtlinienverarbeitung abgebrochen).

      Führt man häufig manuelle Policy-Refreshs durch, so sollte man überlegen GPC ggf. zu deaktivieren. 


      weiterführende Informationen:

      http://sdmsoftware.com/group-policy-blog/group-policy/understanding-group-policy-caching-in-windows-8-1/

      http://sdmsoftware.com/group-policy-blog/windows-8-1/clarifying-group-policy-caching-in-windows-8-1/