Rss

  • youtube
  • google

Archives for : Februar2018

HAProxy vor Squid Proxy – Client IP-Adressen weiterleiten

Verwendet man einen Loadbalancer wie z.B. HAProxy um Webzugriffe von Clients auf mehrere Squid Proxy Server zu verteilen, sieht es im access.log des Squid Proxy so aus, als kämen die Zugriffe alle vom HAProxy nicht vom eigentlichen Client. Da das HTTP Forwarding des HAProxy auf Applikationsebene basiert, ist dieses Verhalten korrekt. Wenn man TCP Offloading machen würde, wäre dies wahrscheinlich nicht der Fall.

Um beim HTTP Forwarding dennoch die originale Client-IP im Squid access.log zu sehen, kann man diese über den HTTP Header X-Forwarded-For (Beschreibung) weiterleiten.

In Squid kommen die Requests alle von der IP-Adresse des HAProxy:

In HAProxy müssen die folgenden beiden Optionen gesetzt werden. Diese setzen den Header „X-Forwarded-For“ auf die Client IP-Adresse. Dadurch wird die eigentliche Client IP im Header mitgegeben:

Der Squid Proxy registriert den veränderten Header, verwirft ihn aber aus Sicherheitsgründen standardmäßig – sofern nicht anderweitig konfiguriert. Also muss in der Konfiguration des Squid der QuellIP des HAProxy vertraut werden. Dies wird dementsprechend über eine acl in der squid.conf angepasst:

Abschließend den Squid neustarten und den Webzugriff über ein Client testen. Wie man nun im access.log sieht, ist die Client-IP jetzt korrekt weitergeleitet.

Exchange 2016 – Enable & Troubleshoot Certificate Based Authentication for OWA/Active Sync

Um die zertifikatsbasierte Authentifizierung des Exchange 2016 zu aktivieren empfehle ich, sich an folgenden Technet-Artikel zu halten. Dieser beschreibt die Konfiguration schritt für schritt.

Der anschließende Test war jedoch wenig erfolgreich und brachte auf den Client Geräten immer den Fehler „Anmeldung fehlgeschlagen“. Die Analyse des IIS Logfiles bestätigte in dem Fall die Fehlermeldung:

Da der Microsoft Exchange Health Manager (+ Recovery) durchgängig Testaufrufe machen, wird das IIS Logfile schnell unübersichtlich gefüllt. Daher hatte ich einfach eine neue Site im IIS Manager erstellt und dort unter einem anderem Port Binding die Authentifizierung via Client Zertifikate getestet. (Unterer Logeintrag) Man kann aber auch den Health Manager Dienst temporär deaktivieren, dass funktioniert auch.

Zurück zur Fehlermeldung, welche im Detail wie folgt aussieht:

  • 403 = HTTP Statuscode (Authentication Failed)
  • 16 = Subfehler (Client certificate is untrusted or invalid.)
  • 2148204809 = Detaillierter Fehlercode (0x800b0109 CERT_E_UNTRUSTEDROOT)

Sucht man nach der Fehlermeldung findet man folgenden Technet-Artikel, der eigentlich auf den IIS 8 bezogen ist. Windows Server verwendet IIS 10 – aber der Artikel trifft auch darauf zu.
Hintergrund: Seit Windows Server 2012 wurden strengere Überprüfungen für die zertifikatsbasierte Authentifizierung eingeführt. Einer dieser Checks prüft ob sich im Zertifikatsspeicher (Trusted Root Certification Authorities) auch wirklich nur sogenannte Root-Zertifikate befinden. Ein Root Zertifikat muss logischerweise immer selbst-signiert sein. Wenn sich dort ein Zertifikat befindet, was von einer anderen Zertifikatstelle ausgestellt wurde, ist dies eigentlich ein „Zwischenzertifikat / Intermediate“ und gehört an einen anderen Zertifikatsspeicherort.

In meinem Fall befand sich das „StartCom Class 3 OV Server CA“ in den Root-CA’s welches den Fehler produzierte. Um den Fehler zu beheben, müssen alle nicht selbst-signierten Zertifikate aus dem Root-CA entfernt bzw. zu den Zwischenzerifikaten verschoben werden.

Um bei der Vielzahl von Zertifikaten nicht alle händisch zu überprüfen kann man dies per Powershell identifizieren:

Um die Zertifikate anschließend in den Speicher für „Intermediate Certification Authorities“ zu verschieben kann man folgenden Befehl nutzen:

Anschließend den kompletten Server neustarten. Eventuell reicht auch nur ein Neustart des IIS (W3SVC). Hatte in meinem Fall jedoch nicht ausgereicht.

Winbuilder (Win10PE) hinter Proxy benutzen

Wer sich selbst ein Windows PE erstellen will, kommt um den WindowsBuilder nicht herum. Ein Tool aus der Sammlung, nämlich GetWaikTools (GWT.exe) lädt die Windows Imaging Features (ADK, Dism etc.) herunter und benötigt daher Internetzugriff. Wer hinter einem Proxy sitzt, bekommt hier eine Fehlermeldung und muss den Proxy von Hand konfigurieren.

Das Tool verwendet Curl als Downloader, für den über die Umgebungsvariablen ein Proxy eingerichtet werden kann:

Anschließend funktioniert die Verbindung über den Proxyserver 😉

Windows 10 – Standarddrucker verwalten

Ihr wundert euch warum euer Standard Drucker immer wechselt? Ein neues „Feature“ in Windows 10 setzt den aktuellen Standarddrucker immer auf den zuletzt benutzten Drucker.
Hierbei wird auch berücksichtigt, an welchem Standort sich das Gerät im Moment befindet. Sprich zuhause wird der Heimdrucker automatisch als Standard ausgewählt und im Büro ein anderer.
Das kann ganz praktisch sein, stört aber vielleicht auch. Daher beschreibe ich hier kurz wie ihr die Funktion „Windows verwaltet Standarddrucker“ entweder per Hand oder via Gruppenrichtlinie / Registry deaktivieren könnt.

Von Hand

  1. Öffnet die Einstellungen von Windows 10 (z.B. Windows Taste + i)
  2. Navigiere zu Geräte und anschließend Drucker & Scanner
  3. Entferne den Haken bei „Windows verwaltet Standarddrucker“

Per Registry

  1. Navigiere zu folgendem Pfad:
  2. Ändere den Wert „LegacyDefaultPrinterMode“ (DWORD) auf 1 ab.

 

Per Gruppenrichtlinie

Per GPO findet ihr die Option „Turn off Windows default printer management“ unter: