IIS: X-Forwarded-For Header im Log

Wenn man einen Microsoft Internet Information Services (IIS) hinter einem Reverse Proxy oder einem Load Balancer betreibt, sieht man in den Logs des IIS nur immer die IP-Adresse der Reverse Proxys bzw. dem Load Balancers und nicht die eigentliche IP des Clients.

Wenn der Reverse Proxy bzw. Load Balancer richtig konfiguriert wurde – z.B. bei Nginx wäre es

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

dann wird die IP des Clients an den IIS jedoch sauber übergeben.

Um diese jetzt in den Logs zu sehen muss jetzt nur noch der X-Forwarded-For-Header aktiviert werden.

Den IIS Manager starten und den Punkt Protokollierung öffnen

Dort bei Format auf Felder auswählen…

Dort auf Feld hinzufügen

Dort folgende Werte eintragen:

Feldname: x-forwarded-for
Quelltyp: Anforderungsheader
Quelle: X-Forwarded-For

und mit OK bestätigen.

nochmal mit OK bestätigen und auf Übernehmen klicken

Jetzt taucht im Log-Verzeichnis eine Log-Datei mit eine vorangestellten x_ auf – dort wird jetzt reingeloggt – mit dem X-Forwarded-For-Header und so auch mit der originalen Client-IP.

Quelle: www.loadbalancer.org

Exchange 2013 und 2016: Mails bleiben in Entwürfe hängen

Es gibt manchmal mal das Problem unter Exchange Server 2013 und 2016 dass Emails nicht versendet werden und in Entwürfe (Drafts) bzw. manchmal auch in Postausgang hängen bleiben.

Das Problem tritt sowohl in Outlook als auch in der Outlook Web App (OWA) auf.

Der Grund war bei mir bisher immer eine fehlerhafte DNS-Konfiguration des Exchanges!

Vor allem bei mehreren Netzwerkkarten oder bei mehreren DNS-Servern kann hier die Automatik versagen.

Einzustellen ist das am einfachsten in der ECP:

Hier stehen die DNS-Lookups (intern und extern) standardmäßig auf „Alle Netzwerkkarten“:

Hier kann die richtige Netzwerkkarte ausgewählt werden – oder auch ein DNS-Server manuell eingetragen werden:

Danach sollte das Problem gelöst sein 🙂

Quelle: thoughtsofanidlemind.com

PowerShell: Der watch-Befehl aus Linux

Unter Linux gibt es ja den watch-Befehl mit dem man einen Befehl alle x Sekunden wiederholen kann. Unter der Windows PowerShell gibts sowas leider standardmäßig nicht – aber man kann den Befehl mit Boardmitteln nachbauen:

while ($true) {Clear-Host; gci; sleep 15}

In diesem Beispiel wird zuerst mit Clear-Host die aktuelle Anezige der PowerShell gelöscht, dann gci ausgeführt und zum Schluss 15 Sekunden gewartet. Danach wiederholt sich das ganze bis man es mit STRG-C abbricht.

der Befehl lässt sich natürlich durch fast jeden anderen Befehl ersetzten 😉

Das ganze lässt sich gut für z.B. anzeigen von Verschiebeanforderungen bei Exchange benutzen:

while ($true) {Clear-Host; get-moverequest; sleep 15}

man kann auch Befehle kombinieren – z.B. das Datum anzeigen und etwas pingen

while ($true) {Clear-Host; date; ping 9.9.9.9; sleep 15}

Outlook für Mac: Ändern des Servernames über AutoDiscover deaktivieren

Verbindet man Outlook für Mac von extern mit einem Exchange wird über den AutoDiscover-Mechanismus der Servername automatisch konfiguriert – bzw. geändert.

Problematisch ist es aber wenn hier der lokale Name des Exchange-Servers eingetragen wird – und somit keine Verbindung mehr zustande kommt.

Dieses Verhalten von Outlook kann man aber deaktiveren:

1) Outlook öffnen

2) AppleScript Editor öffnen (Script Editor.app in Programme/Dienstprogramme)

3) folgendes Script ausführen

tell application "Microsoft Outlook"
set background autodiscover of every exchange account to false
end tell

Danach den Servernamen im Outlook nochmal auf den externen Namen setzten – jetzt sollte der Servername nicht mehr geändert werden und die Verbindung funktionieren!

Windows Server Deduplication – Chunk Ordner wird riesengroß

Wenn man auf einem Windows Server das Dedup-Feature einschaltet kann es passieren, dass der ChunkStore (dieser befindet sich in dem Ordner „System Volume Information“) in dem die Informationen für das Dedup gespeichert werden immer weiter wächst und so riesig wird das er teilweise den ganzen freien Platz auf dem Volume verbraucht.

Das kann man aber über einen DedupJob aber wieder fixen -hier am Beispiel eines Volumes F: :

eine Powershell als Administrator öffnen

und

Start-DedupJob -Volume “F:” -Type GarbageCollection -Memory 50

man kann mit

Get-DedupJob

überprüfen wie weit der Job schon ist.

Hilft dies nicht ist eine Möglichkeit noch die Deduplizierung rückgänging zu machen.

Dazu lässt man Dedup auf dem Volume aktiviert – deaktiviert aber die Hintergrundaktivität

Set-DedupSchedule BackgroundOptimization -enable $false

Start-DedupJob -Volume „F:“ -Type Unoptimization

Start-DedupJob -Volume “F:” -Type GarbageCollection

danach sollte der Chunk-Ordner weg sein – dann kann dedup bei Bedarf wieder aktiviert werden.

Openssl: Zertifikat und Key zu einem PFX exportieren

Hat man eine Zertifikats-Datei (cert, pem oder ähnliches) und die dazugehörige KEY-Datei ist es ziemlich einfach daraus eine PFX-Datei zu erstellen – um z.B. das Zertifikat einfach in einem IIS zu installieren.

mit folgendem Befehl konvertiert man:

openssl pkcs12 -inkey cert.key -in cert.cert -export -out cert.pfx

nur noch ein Export-Kennwort eingeben – fertig 🙂

Quelle: stackoverflow

Windows-Prozessaktivierungsdienst startet nicht – Fehler 6801

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net

Microsoft: KB3159398 macht Probleme bei der Gruppenrichtlinenverarbeitung

Das KB3159398, dass über Windows Update zur Zeit verteilt wird, ändert ein wenig die Art und Weise wie die Sicherheitsfilterung bei der Gruppenrichtlinienverarbeitung funktioniert.

Das kann zu Problemen führen, wie z.B.:

– Laufwerke werden nicht mehr gemappt
– Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt
– Diverse Gruppenrichtlinien (z.B. Druckerzuweisungen, etc) funktionieren nicht mehr

Das Problem liegt an einem fehlendem Lese-Recht des Authentifizierte Benutzer (Authenticated Users) unter Delegierung, dass durch den Patch jetzt allerdings benötigt wird.

In dem KB dazu hat Microsoft das Problem auch beschrieben:

Known issues

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:

3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
3163017 Cumulative update for Windows 10: June 14, 2016
3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
– Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
– If you are using security filtering, add the Domain Computers group with read permission.

Lösung: Die Authentifizierten Benutzer manuell mit dem Lese-Recht bei den Delegierungen hinzufügen

AuthUsersGPO

Es gibt auch hier ein Script dass das automatisch macht.

Empfehlenswerter Artikel zu lesen: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Windows: Event 2103 – AD-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt

Ich hatte in einem AD das Problem, dass nach einem Restore aus einem Snapshot die Domain Controllern die Anmeldung der User verweigerten und auch untereinander nicht mehr replizierten. Im Eventlog wurde folgender Fehler protokolliert:

Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.

Und bei der Replikation wurde die Fehlermeldung (z.B. bei repadmin /showrepl)

Der Quellserver nimmt keine Replikationsanforderung entgegen

ausgegeben.

Das ganze Problem wurde verursacht, dass durch die nicht unterstützte Wiederherstellung – in meinem Fall ein Snapshot – die Datenbank der Active Directorys auf Not Writeable gesetzt wurde.

Das ganze wieder ans laufen bekommt man wenn man in der Registry auf dem DC unter

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

den Wert „Dsa Not Writable“ von 4 auf 0 setzt.

Dazu legt man noch einen REG_DWORD “Ignore USN Rollback” an und setzt den Wert auf 0

Danach muss man den Server neustarten.

Damit die Replikation wieder sauber funktioniert muss man auf allen DC-Servern die Befehle

repadmin /options “ServerName” -DISABLE_OUTBOUND_REPL
repadmin /options “ServerName” -DISABLE_INBOUND_REPL

ausführen – wobei „ServerName“ mit dem jeweiligen lokalen Servernamen des DCs ersetzten.

Jetzt sollte eigentlich alles laufen.

Falls allerdings die Replikation noch nicht funktioniert – oder andere Fehler im Eventlog protokolliert werden – kann noch ein Reset des Passwortes des Computerkontos der Domaincontroller nötig sein.

Das macht man auf den DCs folgendermaßen (am besten davor einen Reboot machen):

netdom resetpwd /server:anderer_dc /userd:domain\administrator /passwordd:*

Danach den Server rebooten.

Jetzt sollte es wirklich wieder laufen 🙂

Quelle: hyper-v-server.de