Der Windows Defender ist bei Windows Server 2016 integriert und auch per Default aktiviert. Dieses kann zu Problemen führen, wenn ein weiterer verwalteter Virenscanner installiert wird. Da wohl in den meisten Unternehmen auf einen Virenscanner eines Drittherstellers (Symantec, Kaspersky, TrendMicro, Intel Security, etc)  gesetzt wird, ist es sinnvoll den Windows Defender zu deinstallieren.

Die Deinstallation kann über den Servermanager durchgeführt werden:

Alternativ lässt sich der Windows Defender auch über die Powershell entfernen:

Remove-WindowsFeature Windows-Defender-Features

Nach der Deinstallation ist ein Neustart des Servers erforderlich.

Natürlich lässt sich auf diese Weise der Windows Defender bei Bedarf auch wieder installieren. Die Installation ist ebenfalls via Servermanager oder PowerShell möglich:

Add-WindowsFeature Windows-Defender-Features,Windows-Defender-Gui

Im Falle eines installierten Windows Defenders werden Signaturupdates nicht automatisch installiert, wenn die Windows Update Einstellungen eine manuelle Installation der Updates vorsehen. Im folgenden Fall werden neue Signaturen nicht automatisch installiert:

In diesem Fall können Signaturupdates mit einem geplanten Task automatisch installiert werden. Dazu kann eine neue Aufgabe angelegt werden, die stündlich ausgeführt wird:

Die Aufgabe startet dann das Signaturupdate mit dem Programm:

„C:\Program Files\Windows Defender\MpCmdRun.exe -SignatureUpdate“

Somit lassen sich auch via Eingabeaufforderung die Updates für Windows Defender installieren:

Alternativ lassen sich die Updates auch via PowerShell ausführen:

Update-MpSignature

Wenn der Windows Defender eingesetzt wird, sollten unbedingt entsprechende Ausnahmen je nach Anwendung vorgenommen werden um Performanceprobleme zu vermeiden. Ausnahmen lassen sich ebenfalls einfach per PowerShell konfigurieren:

Set-MpPreference -ExclusionExtension .edb,.log
Set-MpPreference -ExclusionPath c:\Dir1,c:\Dir2
Set-MpPreference -ExclusionProcess proc1.exe,proc2.exe

Für Exchange Server 2016 habe ich bereits hier ein entsprechendes Script veröffentlicht:

https://www.frankysweb.de/exchange-2016-virenscanner-ausschlsse-script-fr-windows-defender/

Ähnliches gilt natürlich auch für andere Dienste wie zum Beispiel SQL Server.

Zum Schluss noch eine Liste der verfügbaren PowerShell CMDLets für Windows Defender:

• Add-MpPreference
• Get-MpComputerStatus
• Get-MpPreference
• Get-MpThreat
• Get-MpThreatCatalog
• Get-MpThreatDetection
• Remove-MpPreference
• Remove-MpThreat
• Set-MpPreference
• Start-MpScan
• Start-MpWDOScan
• Update-MpSignature

Mit den vorhandenen CMDLets lässt sich auch der Windows Defender entsprechend anpassen und Aufgaben wie automatische Virenscans und Signaturupdates einplanen. Leider mangelt es an einem übersichtlichen Report, aber mit der PowerShell lässt sich dies ebenfalls bewerkstelligen.

Der Beitrag Server 2016: Windows Defender deinstallieren / anpassen erschien zuerst auf Frankys Web.

Während der Migration von Exchange 2013 zu Exchange 2016 kann der folgende Fehler (Version mismatch) beim Verschieben von Benutzerpostfächern von Exchange 2013 zu Exchange 2016 auftreten:

A version mismatch was detected (Actual:6, Expected:5)

Im Log des Exchange 2013 Servers ist dann folgende Meldung zu sehen:

2017-04-23T20:37:21.432Z,6,Default,Error,“,,“,“RegisterMigrationBatch failed, exception at Microsoft.Exchange.Migration.MigrationServiceHelper.SafeInvokeImplMethod(Action method, MigrationServiceRpcMethodCode methodCode) at Microsoft.Exchange.Migration.MigrationNotificationRpcSkeleton.RegisterMigrationBatch(IMigrationNotification implementation, MdbefPropertyCollection inputArgs)|A version mismatch was detected (Actual:6, Expected:5).|Microsoft.Exchange.Transport.Sync.Migration.Rpc.MigrationServiceRpcException|The RPC call failed with result ‚MigrationTransientError‘.|“

Das Problem kann behoben werden, indem zuerst ein Systempostfach mit dem Namen “Migration” von Exchange 2013 auf den Exchange 2016 Server verschoben werden. Das Postfach lässt sich mit folgenden Befehl anzeigen:

get-mailbox Migration* -Arbitration

Das Systempostfach kann einfach im Exchange Admin Center in eine Datenbank auf dem Exchange 2016 Server verschoben werden:

Nachdem das Postfach verschoben wurde, lassen sich die Postfächer der Benutzer verschieben. Sobald das Postfach in eine Exchange 2016 Datenbank verschoben wurde, wird die Versionsnummer entsprechend angepasst:

Get-Mailbox Migration* -Arbitration | ft Name,AdminDisplayVersion

Wenn die Version 15.1 angezeigt wird, wurde das Postfach korrekt verschoben und die Version angehoben. Der “Version mismatch”-Fehler tritt nun nicht mehr beim Verschieben von Benutzerpostfächern auf.

Der Beitrag Exchange 2016: Fehler beim Verschieben von Postfächern (A version mismatch was detected) erschien zuerst auf Frankys Web.

Zugegeben die Ankündigung kommt etwas spät, trotzdem möchten wir alle Interessierten herzlich zum dritten Treffen der Exchange User Group OWL (EUGO) am 12.05.2017 einladen.

Der Veranstaltungsort “Allegro Habichtshöhe” in Bielefeld bleibt bestehen, allerdings hat sich Andi viel Mühe mit einer neuen Website speziell für die EUGO gegeben. Anmeldungen brauchen also nun nicht mehr auf einem der Blogs durchgeführt werden, sondern können über die folgende Seite getätigt werden:

http://www.exchangeusergroupowl.de/

Hier noch einmal die Daten zum nächsten Treffen:

Freitag den 12. Mai 2017 um 19:30 Uhr

Allegro Habichtshöhe GmbH in Bielefeld

Bodelschwinghstr. 79
33604 Bielefeld

Link: Google Maps

Link: Allegro Habichtshöhe

Auch wenn die verbleibende Zeit recht kurz ist, würden wir uns wieder um zahlreiche Anmeldungen freuen. In Zukunft werden wir wieder rechtzeitig und früh genug über neue Treffen informieren. Nach wie vor streben wir Treffen im Abstand von etwa 3 Monaten an.

Für alle Interessierten aus dem Berliner Raum findet am 11.05.2017 das Treffen unseres Partners “Exchange User Group Berlin” statt:

http://exusg.de/events/user-group-treffen-q2-2017/

Der Beitrag EUGO: Nächstes Treffen schon am 12.05.2017 erschien zuerst auf Frankys Web.

Manchmal sieht man den Wald ja vor lauter Bäumen nicht, in diesem Fall hat mich folgendes Problem auf das Glatteis geführt.

Ein Benutzer berichtet, dass er zwar Elemente in einem freigegebenen Kalender eines Kollegen anlegen, aber die Einträge nicht mehr löschen kann. Beim Versuch einen Kalendereintrag zu löschen, zeigt Outlook nur die folgende Fehlermeldung:

Das Element kann nicht verschoben werden. Es wurde entweder bereits verschoben oder gelöscht, oder der Zugriff wurde verweigert.

Hört sich ja ziemlich eindeutig an: Zugriff verweigert. Also einmal die Rechte auf den Kalender des Kollegen prüfen, geht ja schnell mit der Shell (exemplarisch):

Get-MailboxFolderPermission frank:\kalender

Der Screenshot dient als Beispiel, allerdings hab ich erst einmal etwas verdutzt geguckt: Ein “Editor / Bearbeiter” hat doch das Recht Elemente zu löschen, oder nicht?

Hier hat dann mein Baum/Wald Problem begonnen… Der Benutzer hat also offensichtlich die Rechte “Alle Elemente löschen” für den Kalender, trotzdem zeigt Outlook eine Fehlermeldung die irgendwie was mit “Zugriff verweigert” enthält.

Nach einer gewissen, durchaus etwas längeren, Zeitspanne ist mir dann aufgefallen, dass der Benutzer ein zusätzliches Postfach verbunden hat, auf welches er Vollzugriff hat. Ungefähr so:

Hier klappt das Löschen natürlich einwandfrei, ohne Fehlermeldung, nur in dem zusätzlichen Kalender aus einem anderen Postfach wird die Fehlermeldung angezeigt und kann nicht gelöscht werden.

Bis ich endlich aus dem Wald gefunden habe, vergeht noch einmal etwas Zeit…

Ursache in dieser Konstellation: In der Registry (HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Options\General) des Benutzers wurde das DWORD “DelegateWastebasketStyle” auf den Wert “4” geändert, welches bewirkt, dass Elemente die in freigegeben Postfächern gelöscht werden im Ordner des Postfachbesitzers gespeichert werden.

Der Standard ist also wie folgt, wenn ein Benutzer ein Element in einem freigegeben Postfach löscht:

Benutzer “Frank” greift auf das freigegebene Postfach von “A” zu und löscht im Posteingang eine Mail. Die Mail wird dann in den Ordner “Gelöschte Elemente” von Frank verschoben.

Der oben genannte Registry Schlüssel bewirkt nun folgendes:

Benutzer “Frank” greift auf das freigegebene Postfach von “A” zu und löscht im Posteingang eine Mail. Die Mail wird dann in den Ordner “Gelöschte Elemente” des Postfachbesitzers A verschoben.

Für den zusätzlich freigegebenen Kalender greift nun ebenfalls der Registry Eintrag “DelegateWastebasketStyle”. Das Element in dem Kalender des Kollegen W, wird bei der Löschaktion des Benutzers in den Ordner “Gelöschte Elemente” von W verschoben:

In diesem Fall hat aber Benutzer “Frank” keine Rechte auf den Ordner “Gelöschte Elemente” von W, sondern nur nur Bearbeiter-Rechte auf den Kalender:

Das Element was “Frank” versucht im Kalender von “W” zu löschen, kann also nicht in den Ordner “Gelöschte Elemente” von “W” verschoben werden, da “Frank” keine Rechte darauf besitzt und es kommt zur Fehlermeldung. Benutzer “Frank” benötigt also mindestens “Autor / Author“ Rechte auf den Ordner:

Add-MailboxFolderPermission "webmaster:\Gelöschte Elemente" -User frank -AccessRights Author

Jetzt klappt auch das Löschen ohne Fehlermeldung. Ich bin raus aus dem Wald und ich verrate nicht wie lange es gedauert hat…

Das Verhalten ist ja auch im Technet dokumentiert und ich hätte darauf deutlich schneller aufmerksam werden sollen, hätte ich vielleicht auch den ersten Teil der Fehlermeldung lesen sollen?

Hoch die Hände: Wochenende!

Der Beitrag Outlook: DelegateWastebasketStyle, Shared Mailbox und ein freigegebener Kalender erschien zuerst auf Frankys Web.

Mit den Performance Tuning Guidelines für Windows Server 2016 wurden zahlreiche Tipps für die Optimierung der Geschwindigkeit veröffentlicht:

Performance Tuning Guidelines for Windows Server 2016

Derzeit werden Tipps zur Steigerung der Geschwindigkeit für die folgenden Punkte angeboten:

Server Hardware

• Hardware performance considerations
• Hardware power considerations

Server Rollen

• Active Directory Servers
• File Servers
• Hyper-V Servers
• Remote Desktop Servers
• Web Servers
• Windows Server Containers

Server Subsystem

• Cache and memory management
• Networking subsystem
• Storage Spaces Direct (SSD)
• Software Defined Networking (SDN)

Der Guide ist webbasiert und verlinkt direkt auf die Maßnahmen inklusive einer Erklärung. Der komplette Guide lässt sich aber auch als PDF runterladen:

Download PDF

Vielleicht kommen ja auch noch andere Dienste wie Exchange und SQL dazu.

Der Beitrag Server 2016: Performance Tuning Guidelines erschien zuerst auf Frankys Web.

Bereits am 27.04.17 hat Sophos ein Update für die Sophos UTM veröffentlicht, welches Zertifikatswarnungen in Verbindung mit Chrome 58 und eingeschaltetem HTTPS Scanning behebt. Mir wird das Update bisher nicht via Up2Date angeboten, daher hier ein kleiner Hinweis.

Das Update auf die Version 9.413-4 kann hier runtergeladen und manuell installiert werden:

http://ftp.astaro.de/UTM/v9/up2date/

Das Update adressiert ausschleißlich das Zertifikatsproblem mit Chrome 58:

Bugfix:
Fix [NUTM-7586]: [Web] Chrome v58 and higher fail verification with HTTPS scanning enabled

Das Problem, welches auch auf Golem behandelt wurde, resultiert darin, dass Chrome den CommonName (Ausgestellt für) auf Zertifikaten ignoriert und sich nur noch an Namen, die als SubjectAlternateName (Alternative Antragsteller) konfiguriert wurden, richtet. Eine genaue Beschreibung steht im verlinkten Golem Artikel.

Ich konnte das Problem allerdings auch nicht nachvollziehen, setze allerdings für die CA der UTM ein Zertifikat ein, welches von meiner internen CA ausgestellt wurde. Die UTM arbeitet somit als Sub-CA, in dieser Konfiguration kann ich das Problem nicht nachvollziehen. Hier ein aktuelles Beispiel, der Hostname wird als CommonName und SubjectAlternateName eingetragen:

Die Konfiguration mit interner CA als Root-CA für den Webfilter ist übrigens hier beschrieben:

• Untergeordnete Zertifizierungsstelle für Sophos UTM HTTPS CA (Web Filter)

Der Beitrag Sophos UTM: Neues Update behebt Zertifikatswarnungen mit Chrome 58 erschien zuerst auf Frankys Web.

In dem Kommentaren zu dem Artikel “Exchange 2016: Kumulative Updates (CU) installieren” wurde ich darauf hingewiesen, dass mit Veeam Backup & Replication 9.5 U1 und Exchange 2016 CU5 Probleme mit dem Single Item Restore gibt. Die Datenbanken können normal gesichert und wiederhergestellt werden, allerdings funktioniert der Veeam Explorer for Exchange nicht mehr mit Exchange 2016 CU5 Datenbanken.

Im Veeam Explorer können keine Postfächer mehr angezeigt werden, daher ist auch kein Restore von einzelnen Mails oder Postfächern möglich. Ein Aufklappen der Datenbank funktioniert nicht:

Im Log ist dazu nur der folgende Meldungen zu sehen:

03.05.2017 21:14:25    1 (4356) Trying to find mount for file path: ‚E:\File Restore\FWDB.edb’…
03.05.2017 21:14:25    1 (4356)   Mount not found.
03.05.2017 21:14:26    6 (1176) Counting items in: FWDB.edb…
03.05.2017 21:14:26    6 (1176)   found 0 items.

Ein aktualisieren der ESE.dll hat bei mir nicht geholfen. Scheinbar wird das Problem durch Änderungen an der Exchange 2016 CU5 Datenbank Struktur hervorgerufen.

Auch andere Backup Tools können seit CU5 kein Single Item Restore mehr durchführen, hier zum Beispiel Veritas:

• https://www.veritas.com/support/en_US/article.000126392

oder Unitrends:

• https://support.unitrends.com/UnitrendsBackup/s/question/0D54000004JsUZQCA3/exchange-2016-cu5-restore

Als Workaround lässt sich allerdings weiterhin die Datenbank in eine Recovery Datenbank wiederherstellen, aus der Recovery Datenbank können dann mit Exchange Bordmitteln einzelne Postfächer wiederhergestellt oder exportiert werden.

Veeam wird das Problem mit dem U2 beheben, welches schon in den Startlöchern steht. Vielen Dank an Ralle für den Hinweis!

Der Beitrag Achtung: Veeam 9.5 U1 und Exchange 2016 CU5 Probleme erschien zuerst auf Frankys Web.

Seit gestern Morgen ist die Sophos UTM in der Version 9.5 verfügbar. Alle, die das Update wie ich noch nicht via Up2Date angeboten bekommen, können es hier runterladen (301 MB):

http://ftp.astaro.de/UTM/v9/up2date/

Das Update kann dann manuell über die GUI hochgeladen und somit die UTM aktualisiert werden:

Da es in der Vergangenheit immer mal wieder Probleme mit Updates gab, empfiehlt es sich eine aktuelle Sicherung zur Hand zu haben, bei virtuell installierten UTMs sollte vorsichtshalber ein Snapshot angelegt werden.

Die Liste der neuen Features ist zwar überschaubar, bietet aber trotzdem interessante Neuerungen. Die für mich persönlich interessantesten Features habe ich mal markiert. Leider fehlt noch die Unterstützung für Let’s Encrypt, die wird es wohl erst mit der Version 9.6 geben.

Features:

• WAF URL redirection
  
• WAF configurable TLS version
  
• WAF true file type detection
• WAF templates
• Sophos Sandstorm configuration of data Center
• Sophos Sandstorm file exceptions
• RESTful API to configure UTM
  
• AWS CloudWatch Logs Agent
• 64-bit PostgreSQL database
• Email notification for expiring certificates
  
• Support Access for SSH
• SNMP monitoring of the file system

Die Liste der Bugfixes ist dafür umso länger:

• Fix [NUTM-6503]: [AWS] Migrate to new iaas_* functions
• Fix [NUTM-6646]: [AWS] REST API panic when unlocking unlocked mutex
• Fix [NUTM-6657]: [AWS] Configure AWS profiles via WebAdmin
• Fix [NUTM-6696]: [AWS] Configure CloudWatch support via WebAdmin
• Fix [NUTM-6708]: [AWS] Cloud update not working with conversion deployments
• Fix [NUTM-6814]: [AWS] Rest API is accessible with default password if basic setup has not completed
• Fix [NUTM-6887]: [AWS] REST API panic when inserting into node which is not of type array
• Fix [NUTM-7032]: [AWS] SignalException not handled for SecurityGroupsManagement#update
• Fix [NUTM-7055]: [AWS] queen_configuration_management / aws_resource_management SIGUSR1 handling
• Fix [NUTM-7056]: [AWS] LocalJumpError
• Fix [NUTM-7057]: [AWS] aws_set_sd_check AWS::EC2::Errors::RequestLimitExceeded
• Fix [NUTM-7061]: [AWS] Connection refused – connect(2) for „localhost“ port 4472
• Fix [NUTM-3194]: [Access & Identity] incorrect SSH logins trigger backend authentication requests
• Fix [NUTM-3222]: [Access & Identity] RED10/50: DNS port open on WAN interfaces
• Fix [NUTM-3260]: [Access & Identity] User Portal – IPsec Windows Support
• Fix [NUTM-4149]: [Access & Identity] [RED] Use Sophos NTP pool servers
• Fix [NUTM-4323]: [Access & Identity] NULL pointer deref in red_nl_cmd_tunnel_dump
• Fix [NUTM-4705]: [Access & Identity] Don’t use DNS server from the RED branch as an ISP forwarder
• Fix [NUTM-4852]: [Access & Identity] [RED] flock() on closed filehandle $fhi at /</var/confd/confd.plx>Object/itfhw/red_server.pm line 563.
• Fix [NUTM-4994]: [Access & Identity] STAS creates users even if automatic user creation is disabled
• Fix [NUTM-5134]: [Access & Identity] [OTP] User Portal should recommend Sophos Authenticator
• Fix [NUTM-5925]: [Access & Identity] [RED] prevent configuration for VLAN for Split modes
• Fix [NUTM-6387]: [Access & Identity] HTML5 VNC connection not disconnecting
• Fix [NUTM-6641]: [Access & Identity] [OTP] user can select algorithm for automatic tokens
• Fix [NUTM-6668]: [Access & Identity] [IPsec] L2TP/Cisco policy changes do not update ipsec.conf
• Fix [NUTM-6749]: [Access & Identity] RED15w does not send split DNS traffic over RED tunnel
• Fix [NUTM-5965]: [Basesystem] Sensors command on SG125w doesn’t show hardware fan RPM
• Fix [NUTM-6468]: [Basesystem] BIND Security update (CVE-2016-9131, CVE-2016-9147, CVE-2016-9444)
• Fix [NUTM-6718]: [Basesystem] Update NTP to 4.2.8p9
• Fix [NUTM-6846]: [Basesystem] Linux kernel: ip6_gre: invalid reads in ip6gre_err() (CVE-2017-5897)
• Fix [NUTM-6847]: [Basesystem] BIND Security update (CVE-2017-3135)
• Fix [NUTM-6902]: [Basesystem] Linux kernel: ipv4 keep skb->dst around in presence of IP options (CVE-2017-5970)
• Fix [NUTM-7048]: [Basesystem] Implement software workaround for Intel CPUs
• Fix [NUTM-7067]: [Basesystem] Update OpenSSH to openssh-6.6p1
• Fix [NUTM-7370]: [Basesystem] Bootsplash still shows 9.4 instead of 9.5
• Fix [NUTM-7653]: [Basesystem] Internal SSL certification verification broken
• Fix [NUTM-5658]: [Confd] Stripped restore unaccessable if default internal interface is removed
• Fix [NUTM-3062]: [Email] Mails From mail spool gets quarantined because of „500 Max connection limit reached“ in cssd
• Fix [NUTM-4753]: [Email] Support recipient verification with multiple AD servers
• Fix [NUTM-5350]: [Email] Per user blacklist does not apply until smtp service restarts
• Fix [NUTM-5823]: [Email] Scanner timeout or deadlock for all mails with a .scn attachment
• Fix [NUTM-5892]: [Email] SMTP Exception doesn’t allow ‚&‘ sign within the email address
• Fix [NUTM-6135]: [Email] DLP custom expression doesn’t get triggered if the email body contains certain strings
• Fix [NUTM-6355]: [Email] Email not blocked with expression list
• Fix [NUTM-4474]: [Kernel] Kernel panic – not syncing: Fatal exception in interrupt
• Fix [NUTM-6358]: [Kernel] Kernel: unable to handle kernel NULL pointer dereference at 0000000000000018
• Fix [NUTM-4969]: [Network] Uplink does not recover from error state
• Fix [NUTM-5314]: [Network] 10gb SFP+ flexi module interface fails when under load
• Fix [NUTM-5428]: [Network] Bridge interface can not acquire Dynamic IPv6 address correctly. This interface repeats up/down.
• Fix [NUTM-5831]: [Network] Changing static IP on interface does not take effect immediately
• Fix [NUTM-5861]: [Network] IPv4 static address gets deleted from confd (and WebAdmin) once IPv6 on the same interface fails to obtain dynamic address
• Fix [NUTM-6077]: [Network] Static route on bridge interface disappears after rebooting the UTM
• Fix [NUTM-6807]: [Network] SSL VPN not being redistributed into OSPF
• Fix [NUTM-6901]: [Network] Eth0 is removed while configuring bridge interface
• Fix [NUTM-2420]: [WAF] Remove session management from basic authentication
• Fix [NUTM-5603]: [WAF] Issue with expired lifetime of WAF connections without any hint
• Fix [NUTM-5628]: [WAF] WAF – Provide import and export options for HTTPS domain list
• Fix [NUTM-5640]: [WAF] GUI issue when adding wildcard certificate into Virtual Webservers
• Fix [NUTM-6156]: [WAF] UTM still fails scan for CVE-2016-2183 (SWEET32) after update to 9.408
• Fix [NUTM-6294]: [WAF] WAF – Naming collisions for default profiles
• Fix [NUTM-6522]: [WebAdmin] SMC Test failed after Settings are applied
• Fix [NUTM-6788]: [WebAdmin] Add support for SG105W, SG135W and SG230 in WebAdmin
• Fix [NUTM-7337]: [WebAdmin] Fix appliance picture for SG105w N9
• Fix [NUTM-6467]: [Web] FTP connection fails when using transparent FTP Proxy
• Fix [NUTM-6732]: [Web] Certificate issue with transparent Web Proxy – „unable to get local issuer certificate“
• Fix [NUTM-6876]: [Web] Remove insecure RC4 from default cipher list for Web Protection HTTPS scanning on upgrade to 9.5 or restore of pre-9.5 backup
• Fix [NUTM-7586]: [Web] Chrome v58 and higher fail verification with HTTPS scanning enabled
• Fix [NUTM-5638]: [WiFi] RED15w – integrated AP isn’t shown as pending in transparent / split mode
• Fix [NUTM-5786]: [WiFi] RED15w – if more then one SSID is configured only one is working correctly
• Fix [NUTM-6215]: [WiFi] Issue when roaming between wireless with some clients
• Fix [NUTM-6335]: [WiFi] VLAN fallback not working for integrated AP from RED15w
• Fix [NUTM-6448]: [WiFi] AP55 stuck as inactive
• Fix [NUTM-6511]: [WiFi] AP does not get IP address on 100 Mbit ethernet link

Ich habe das Update bereits installiert und konnte auf die schnelle keine Probleme feststellen. Die Version wird auf 9.500-9 angehoben.

Der Beitrag Sophos UTM 9.5 verfügbar erschien zuerst auf Frankys Web.

Sophos hat kürzlich das Update auf die Version 9.5 für die UTM veröffentlicht. Eine der Neuerungen UTM 9.5 ist die Möglichkeit die TLS-Version für die Web Application Firewall einzustellen. Das reicht allerdings noch nicht um bei dem SSL Server Test von Qualys SSL Labs  ein A+ Rating zu bekommen.

Zwar ist ein A-Rating nicht unbedingt schlecht, aber A+ wäre schöner. Hier also meine (von Sophos nicht supportete) Konfiguration:

TLS v1.1 oder höher verwenden

Mit der Sophos UTM 9.5 lässt sich jetzt die TLS  Version für den virtuellen Webserver festlegen, mit früheren UTM Versionen war dies über die GUI nicht möglich:

Dies ist schon mal ein Fortschritt, denn in der Standardeinstellung wurde auch noch TLS 1.0 zugelassen. Mit der oben gezeigten Einstellung besteht jetzt immerhin die Möglichkeit nur noch TLS ab der Version 1.1 zu verwenden.

Um das A+ Rating zu erreichen, muss hier die Einstellung “TLS v1.1 oder höher” ausgewählt werden.

Nur starke Cipher verwenden

In der Standardeinstellung bietet die UTM noch zwei Ciphersuiten an, die nicht mehr ganz auf dem aktuellen Stand sind. Leider können die Cipher nur per Shell geändert werden, was Nachteile mit sich bringt (siehe Ende des Artikels).

Um die Cipher zu ändern, muss sich per SSH an der UTM angemeldet werden, dazu muss zunächst SSH aktiviert werden:

Danach kann sich per SSH mit dem Benutzer “loginuser” an der UTM angemeldet werden. Mit dem Befehl “sudo su –“ erlangt man Root-Rechte:

Mit vim wird nun die folgende Datei geöffnet:

vim /var/storage/chroot-reverseproxy/usr/apache/conf/httpd.conf

Sucht nun die Zeile mit dem folgenden Inhalt:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS

und ersetzt die Zeile mit folgenden Inhalt:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AES:!ADH:!AECDH:!MD5:!DSS:!3DES

Dies deaktiviert alle schwachen Cipher. Die Datei kann gespeichert und geschlossen werden. Die Shell wird auch für den nächsten Schritt benötigt.

HTTP Strict Transport Security (HSTS) aktivieren

Ebenfalls via Shell muss für das A+ Rating HSTS aktiviert werden. Eine kurze Beschreibung von HSTS findet sich auf Wikipedia.

Um HSTS zu aktivieren, muss die folgende Datei per VIM geöffnet werden:

vim /var/storage/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf

Bei jedem Virtual Host, der per HTTPS (Port 443) erreichbar ist, muss nun die folgende Zeile zur Konfiguration hinzugefügt werden:

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

Die <VirtualHost IP:443> Einträge können je nach Konfiguration der WAF mehrfach vorkommen, alle Server die ein A+ Rating bekommen sollen, benötigen den HSTS Eintrag.

Damit die Änderungen an den Cipher und der VirtualHost Konfiguration wirksam werden, muss der Reverse Proxy neugestartet werden:

/var/mdw/scripts/reverseproxy restart

Die beiden Warnungen sind bei mir übrigens schon vorher aufgetreten und haben nichts mit den geänderten Einstellungen zu tun.

SSL Server Test von Qualys SSL Labs

Nachdem alle Einstellungen wie oben beschrieben gesetzt wurden und das Zertifikat von einer öffentlichen CA ausgestellt wurde, stellt Qualys SSL Labs das A+ Ratating aus:

Falls der Test mehrfach gestartet wurde, muss der “Clear Cache” Link angeklickt werden, damit der Test wiederholt wird.

Nachteile

Die Änderung via Shell wird durch Sophos nicht unterstützt, in meiner Umgebung kann ich diesen Nachteil noch verschmerzen, in produktiven Umgebungen ist dieses allerdings ein Showstopper.

Weiterer Nachteil: Sobald eine Änderung der WAF Konfiguration über die GUI erfolgt, sind die manuellen Änderungen in via Shell hinfällig und werden überschrieben, somit ist dann auch das A+ Rating wieder futsch.

Bleibt die Frage warum Sophos diese recht einfachen Schritte nicht in der GUI verfügbar macht. Dies dürfte eigentlich keinen großen Aufwand darstellen.

Der Beitrag Sophos UTM 9.5: Web Application Firewall und SSL Labs A+ Rating erschien zuerst auf Frankys Web.

Der folgende Fall ist sicherlich nicht ganz alltäglich: Es ging darum eine Active Directory Gruppe auf bestimmte Mitglieder hin zu überwachen. Nur ganz bestimmte Benutzerkonten sollten in dieser Gruppe vorhanden sein, alle zusätzlichen oder entfernten Mitglieder sollten gemeldet werden.

Auf die Schnelle habe ich dazu ein kleines PowerShell Script erstellt, in welchem die Benutzer angegeben werden, die in der Active Directory Gruppe sein sollen. Abweichungen von der konfigurierten Liste, werden per Mail gemeldet. Falls jemand ähnliches gebrauchen kann, hier ist mein Ansatz:

$ADGroup = "MyADGroup"
$AllowedMembers = @(
    'User1'
    'User2'
    'User3'
	)
$SmtpServer = "smtp.frankysweb.local"
$From = "GroupWarning@frankysweb.de"
$To = "frank@frankysweb.de"
$Subject = "Warning"

#import AD-Module
 Import-Module ActiveDirectory

#fetch Groupmember from AD
 $ADGroupMembers = Get-ADGroup $ADGroup | Get-ADGroupMember -Recursive | select SamAccountName,name

#compare groupmembers with allowedmembers
 $Difference = Compare-Object -ReferenceObject $ADGroupMembers.SamAccountName -DifferenceObject $AllowedMembers
  if ($Difference)
   {
    #User allowed, but not member of the group
     $NotGroupMember = ($Difference | where {$_.SideIndicator -eq "=>"}).InputObject

    #User is member of the group, but not allowed
     $NotAllowedMember = ($Difference | where {$_.SideIndicator -eq "<="}).InputObject

    #Build mail
     $Mail = "
			 User is not allowed to be member of the group $ADGroup :
			 $NotAllowedMember

			 User is allowed to be member of the group $ADGroup, but isn't member:
			 $NotGroupMember
			 "

	#Send mail
	 Send-MailMessage -SmtpServer $SmtpServer -From $From -To $To -Body $Mail -BodyAsHtml -Subject $Subject
 }

Das Script wurde dann einfach jede Stunde als Aufgabe gestartet. Vielleicht kann ja jemand damit etwas anfangen und es für sich nutzen / abwandeln. Ein vernünftiges Auditing lässt sich damit selbstverständlich nicht ersetzen, hier geht es einfach nur um eine kurze Mail, wenn die Mitglieder einer Gruppe nicht mehr passen. So in etwa sieht dann die Mail aus:

Der Beitrag Quick & Dirty: Active Directory Gruppe auf Mitglieder überwachen erschien zuerst auf Frankys Web.

Gerade habe ich die neue Version der Message Tracking GUI hochgeladen und zwei Probleme behoben, die viele Benutzer gestört haben.

Folgende Probleme wurden behoben:

• Bei kleinen Bildschirmauflösungen ist das Fenster jetzt in der Größe veränderbar und blendet bei Bedarf Scrollbalken ein
• Die Empfänger werden jetzt korrekt in die CVS-Datei eingetragen

Die aktuelle Version kann hier runtergeladen werden:

• https://www.frankysweb.de/message-tracking-gui/

Leider habe ich andere Punkte auf der Todo bisher noch nicht umsetzen können, ich versuche es aber zeitnah nachzuholen. Bei Problemen bitte das Formular auf der Seite nutzen und möglichst einen Screenshot hochladen. Dies erleichtert mir die Fehlersuche enorm.

Noch ein kleiner Hinweis: Die Message Tracking GUI muss nicht direkt auf dem Server ausgeführt werden, es reicht ein Rechner der die Exchange Management Tools installiert hat.

Der Beitrag Exchange 2016 Message Tracking GUI: Neue Version erschien zuerst auf Frankys Web.

Am 12.05.2017 haben wir uns nun schon zum dritten Mal zur EUGO getroffen um in lockerer Atmosphäre über IT-Themen zu sprechen. Dabei ging es nicht nur um Exchange und Office 365, sondern auch andere Themen wie zum Beispiel WLAN wurden ausgiebig diskutiert.

Einige Teilnehmer sind schon seit dem ersten Treffen mit dabei und Andi und ich freuen uns immer ganz besonders unsere “Stammgäste” begrüßen zu dürfen. Ich hoffe, dass auch die vielen neuen Gesichter und vor allem die Leute mit langen Anfahrtswegen von dem Abend profitiert haben und die Gelegenheiten nutzen konnten, sich mit anderen auszutauschen.

Ich persönlich hatte wieder viel Spaß, gutes Essen und nette Gespräche an unserem EUGO Treffen, daher allen Teilnehmern: Herzlichen Dank!

Aufgrund der guten Resonanz, der engagierten Teilnehmer werden wir auch in Zukunft die Exchange User Group Treffen organisieren. Beim letzten Treffen im Februar waren wir um ca. 00:00 Uhr die Letzten in der Location Allegro Habichtshöhe, dieses mal wurde es mit 01:00 Uhr sogar noch etwas später

An dem Konzept euch nicht mit langatmigen Vorträgen zu langweilen, wollen wir auch in Zukunft festhalten. Wir halten es nach wie vor für zielführender, wenn miteinander gesprochen wird und nicht ein einzelner den ganzen Abend spricht.

Da von euch Teilnehmern aber auch der Wunsch nach kurzen und knackigen Vorträgen oder Präsentationen geäußert wurde, haben Andi und ich uns dazu entschlossen dies mal auszuprobieren. Noch steht allerdings nicht fest, wie viele, wie lang oder zu welchen Themen wir solche Vorträge organisieren können. Wer einen Vorschlag für ein Thema hat, oder selbst einen kleinen Vortrag halten möchte, kann Andi und mir gerne eine Mail schicken. Ich hoffe wir schaffen das bis zum nächsten Treffen, welches voraussichtlich irgendwann im August stattfinden wird.

Wir würden uns freuen, wenn wir euch beim nächsten Treffen wieder begrüßen dürfen und natürlich sind auch alle neuen Interessenten herzlich Willkommen.

Der Beitrag EUGO: Ein kleines Fazit des Treffens vom 12.05.17 erschien zuerst auf Frankys Web.

Nachdem das “Exchange 2016 Autodiscover Whitepaper” recht guten Anklang gefunden hat und über 6000 Downloads aufweist, gab es eine kleine Abstimmung von April bis Mai über ein neues Thema für das nächste Whitepaper.

An der Abstimmung haben sich insgesamt 637 Personen beteiligt, die meisten Stimmen hat das Thema “Exchange und Zertifikate” bekommen. Hier die finale Auswertung:

Vielen Dank an dieser Stelle an alle Personen die abgestimmt haben. Aufgrund der vielen Mails die mich zum Thema SSL-Zertifikate und Exchange erreichen, hat mich das Ergebnis nicht verwundert.

Daher habe ich bereits angefangen Themen zu sammeln, die in dem Whitepaper behandelt werden sollen. Die folgenden Punkte plane ich derzeit in das Whitepaper aufzunehmen:

• Funktionsweise
• Konfiguration
• Offloading
• Dienste / DNS Namen
• IIS Front End / Backend
• TLS und Connectoren
• Eigene CA
• Öffentliche CA
• Renewal
• Beispielkonfigurationen
• Outlook

Vom Aufbau und den Themen her soll sich das Whitepaper eher an der Leute richten, für die Zertifikate bisher ein rotes Tuch bedeutet haben.Es soll Leuten helfen, deren Schwerpunkt nicht auf Administration und Verwaltung einer PKI liegt, sondern eher “notwendiges Übel” darstellt.

Vorschläge für weitere Themen nehme ich gerne über das Kontaktformular entgegen. Schickt mir einfach alles was für euch relevant ist, so kann ich das Inhaltsverzeichnis nach und nach aufbauen und mich dann dem Inhalt selbst widmen.

Den Zeitpunkt der Veröffentlichung lasse ich erst einmal offen. Die erste Version möchte ich aber schon noch dieses Jahr fertig haben.

Der Beitrag Ankündigung neues Whitepaper: Exchange und Zertifikate erschien zuerst auf Frankys Web.

Seit ca. einem Monat ist .NET Framework 4.7 verfügbar, voraussichtlich wird es auch bald per Windows Update verteilt. Auch wenn .NET 4.7 auf Windows Server bereits unterstützt wird, sollte man bei Exchange Servern vorsichtig sein. Hier die aktuelle Supportmatrix für Windows Server und .NET 4.7:

The .NET Framework 4.7 is supported on the following Windows Server versions:

• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1

Allerdings wird .NET Framework noch nicht in der Exchange Server Kompatibilitätsmatrix angezeigt:

Quelle: Exchange Server Supportability Matrix

Da es in der Vergangenheit schon Probleme mit Updates von .NET Framework in Verbindung mit Exchange Server gegeben hat, sollte zurzeit .NET 4.7 nicht auf Exchange Servern installiert werden um Kompatibilitätsprobleme zu vermeiden. Der entsprechende Hinweis findet sich ebenfalls in der Matrix:

Der Support für .NET 4.7 wird sicherlich mit dem nächsten CU nachgeliefert, hier lohnt es sich also etwas Geduld zu haben. Bisher sind mir zwar keine Probleme bekannt, aber das soll ja nichts heißen.

Hier steht beschrieben, wie die installierte .NET Version ermittelt werden kann:

https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx

Sollte .NET 4.7 bereit installiert sein, würde ich es derzeit deinstallieren, bis es offiziell freigegeben wird.

Der Beitrag Achtung: .NET Framework 4.7 nicht auf Exchange Servern installieren erschien zuerst auf Frankys Web.

Einleitung

Dieser Artikel beinhaltet meine Favoriten für die generellen Anpassungen der Exchange Umgebung nach bzw. während der Installation. Die im folgenden beschriebenen Maßnahmen für das Hardening sind sehr allgemein, sodass sie auf bestehende und neue Umgebungen angewendet werden können.

Die Maßnahmen beziehen sich auf den Exchange Server und das Betriebssystem selbst, ob die Maßnahmen in der eigenen Umgebung nötig oder überflüssig sind, muss jeder selbst entscheiden / bewerten.

Hardening als Keyword ist an dieser Stelle übertrieben, es handelt sich eher um meine „Basis Sicherheitsrichtlinie“: Einfach und immer umzusetzen.

Alte SSL/TLS Protokolle deaktivieren

Die veralteten Protokolle SSL2, SSL3 und TLS1 sollten nicht mehr eingesetzt werden, denn es gibt bekannte Schwachstellen die für Angriffe ausgenutzt werden können. Die alten Protokolle sind aber aus Kompatibilitätsgründen immer noch aktiviert. Daher sollten die alten Protokolle deaktiviert werden, auch wenn dies bedeutet, dass veraltete Software als Client nicht mehr genutzt werden kann.

Alte Protokolle und Cipher lassen sich am Einfachsten mit dem Tool IIS Crypto deaktivieren. IIS Crypto kann hier runtergeladen werden:

Nartac IIS Crypto

Nachdem das Tool auf dem Exchange Server gestartet wurde, reicht ein Klick auf “Best Practises” um die alten SSL Protokolle zu deaktivieren. Damit auch TLS1 abgeschaltet wird, muss dieses noch separat abgewählt werden:

Die Einstellungen werden nach einem Neustart des Servers angewendet. Hier gibt es weitere Informationen:

Chrome und Windows Server 2016: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

X-AspNet-Version deaktivieren

In der Standardeinstellung übermittelt der IIS die eingesetzte ASP Version. Zwar erhöht das Abschalten der Versionsübermittlung nicht direkt die Sicherheit, aber wenn schon jemand nach Schwachstellen sucht, dann muss man ja nicht unbedingt noch Fährten legen.

Im “Konfigurations-Editor” des IIS Servers lässt sich die Übermittlung der eingesetzten ASP Version abschalten:

Im Feld Abschnitt muss dazu der Eintrag “system.web/httpRuntime” ausgewählt werden, dann kann der Wert für “enableVersionHeader” auf den Wert “False” gesetzt werden:

Dies deaktiviert die Versionsübermittlung im HTTP-Header des IIS.

Header Firewall

In der Standardkonfiguration schreibt Exchange einige interne Informationen in den Mail Header. Ohne aktivierte Header Firewall sind zum Beispiel interne IPs und Hostnamen sichtbar:

Hier der Mail Header mit aktivierter Header Firewall, hier stehen deutlich weniger Informationen im Header:

Weniger Informationen erschweren die automatische Schwachstellensuche. Die Header Firewall kann einfach per Exchange Management Shell aktiviert werden:

Get-SendConnector | Remove-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing

Mehr ist nicht nötig um die Header Firewall einzuschalten.

NetBIOS über TCP/IP deaktivieren

NetBIOS über TCP/IP wird von vielen Schwachstellenscannern als problematisch angesehen, für Exchange wird es nicht benötigt und kann daher deaktiviert werden.

In den Eigenschaften der Netzwerkverbindung kann NetBIOS über TCP/IP deaktiviert werden:

SMB1 deaktivieren

SMB in der Version1 ist schon einige Jahre alt und weißt ein paar bekannte Schwachstellen auf, in der Standardeinstellung ist es allerdings aktiviert:

Um SMB1 abzuschalten genügt der folgende Befehl:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Der Befehl deaktiviert nur SMB1. SMB2 und SMB3 bleiben davon unangetastet. SMB2 und SMB3 sollten nicht deaktiviert werden.

Exchange Administrative Center (EAC) deaktivieren

Das Exchange Admin Center (EAC) ist in der Standardkonfiguration auf allen Exchange Servern aktiviert. Werden der oder die Exchange Server per NAT oder Web Application Firewall im Internet veröffentlicht, hängt auch das EAC im Internet. Die EAC lässt sich je Server abschalten, allerdings wird sie dann auch für das interne Netzwerk abgeschaltet. In größeren Umgebungen mit mehreren Exchange Servern ist dies normalerweise kein Problem, hier können beispielsweise 2 Exchange Server im Internet per Web Application Firewall veröffentlicht werden und ein dritter Exchange Server wird für die Administration benutzt und nur im Fehlerfall aktiviert.

Wenn nur ein Exchange Server im Unternehmen vorhanden ist, kann man sich mit einem kleinen Workaround behelfen. Dem Exchange Server wird eine zusätzliche IP Adresse vergeben:

Im IIS wird nun eine neue Website angelegt, die an die zuvor konfigurierte IP gebunden wird:

Für die neue Website werden ein neues ECP und OWA Verzeichnis angelegt:

New-EcpVirtualDirectory -Server ETEX1 -WebSiteName EAC
New-OwaVirtualDirectory -Server ETEX1 -WebSiteName EAC

Jetzt kann unter der zusätzlich konfigurierten IP auf das EAC zugegriffen werden:

Für das EAC welches im Internet veröffentlicht wird, in diesem Fall die IP 172.16.100.26, kann der Zugriff nun abgeschaltet werden:

Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false

Nachdem die Änderungen übernommen wurden, ist der Zugriff auf das EAC nur noch über die zusätzliche IP 172.16.100.99 möglich. Sofern der Router oder Web Application Firewall Verbindungen nur an die 172.16.100.26 leitet, ist der Zugriff aus dem Internet auf EAC nicht mehr möglich.

Lokalen Administrator deaktivieren

Das Deaktivieren des lokalen Kontos “Administrator” ist schon beinahe so alt wie Windows selbst und gehört damit zum Standard. BruteForce Attacken werden deutlich schwieriger, wenn der Benutzername nicht im Vorfeld bekannt ist.

Das lokale Konto “Administrator” sollte nicht nur umbenannt werden, sondern ein neuer lokaler Benutzer erstellt werden, der die Rolle “Administratoren” bekommt. Dazu muss zunächst ein neues lokales Benutzerkonto erstellt werden:

Das neue Benutzerkonto wird dann der Gruppe “Administratoren” auf dem Exchange Server hinzugefügt:

Jetzt kann das Konto “Administrator” deaktiviert werden:

Natürlich sollte nicht nur der lokale Administrator deaktiviert werden, sondern auch das Konto “Administrator” im Active Directory.

Software auf dem aktuellen Stand halten / Unnötige Software deinstallieren

Das regelmäßiges Aktualisieren der eingesetzten Software wichtig ist, brauch nicht erwähnt werden, denn es ist eh jedem klar. Aber es reicht nicht nur regelmäßig und möglichst zeitnah die Windows Updates zu installieren, auch alle anderen Komponenten müssen auf dem aktuellen Stand gehalten werden:

• Firmwares
• Treiber
• BIOS oder VMware Tools / Hyper-V Tools
• zusätzliche Software auf dem Exchange Server (Backup Agent, Virenscanner, etc)
• Exchange Server (aktuelle CUs)
• Windows Updates

Wenn man schon dabei ist die Komponenten zu aktualisieren, lohnt es sich auch über die installierten Programme und Tools zu schauen. Adobe Flash / Reader, Firefox, Chrome, Java, Classic Shell und so weiter und so weiter, haben NICHTS auf einem Exchange Server verloren. Zusätzliche Windows Features die nicht von Exchange vorausgesetzt werden, haben ebenfalls nichts auf dem Exchange Server zu suchen.

Windows Firewall

An der Windows Firewall muss im Grunde nichts verändert werden. Exchange erstellt während der Installation alle nötigen Regeln. In manchen Umgebungen wird die Windows Firewall allerdings per GPO oder manuell deaktiviert. Es gibt keinen Grund die Windows Firewall abzuschalten, vielleicht sind zusätzliche Regeln für bestimmte Tools nötig (Backup, Virenscanner), die Firewall sollte aber in jedem Fall aktiviert bleiben:

Der Beitrag Exchange 2016 Installation absichern (Hardening) erschien zuerst auf Frankys Web.

Der Zustand einzelner Exchange Protokolle lässt sich bequem über eine URL ermitteln, dies ist insbesondere für Loadbalancer interessant, da auf einfache Weise festgestellt werden kann, ob das Protokoll auf dem jeweiligen Server verfügbar ist. Die Abfrage der jeweiligen URLs ist aussagekräftiger als eine einfache Prüfung ob der Port am Exchange Server noch geöffnet ist, aber nicht so lastintensiv wie eine Anmeldung an einem Postfach.

Über die Exchange HealthCheck URLs können Loadbalancer somit feststellen, ob weiterhin Verbindungen an den Server geschickt werden sollen oder ob der Server aus dem Pool genommen wird.

Die HealthCheck Seiten selbst bieten nur wenige Informationen:

“200 OK” kann als Anhaltspunkt für den Loadbalancer genommen werden, um weiterhin Verbindungen an den Server zu senden. Bei anderen Statuscodes sollte der Loadbalancer den Server aus dem Pool nehmen. Aufwendige Tests von Loadbalancern mit Anmeldung an ein Postfach usw. können somit entfallen und verursachen keine zusätzliche Last auf den Exchange Servern.

Die URLs für Exchange 2016 und Exchange 2013 SP1 lauten wie folgt:

• https://<ExchangeServer>/owa/healthcheck.htm
• https://<ExchangeServer>/ecp/healthcheck.htm
• https://<ExchangeServer>/rpc/healthcheck.htm
• https://<ExchangeServer>/mapi/healthcheck.htm
• https://<ExchangeServer>/ews/healthcheck.htm
• https://<ExchangeServer>/oab/healthcheck.htm
• https://<ExchangeServer>/Microsoft-Server-ActiveSync/healthcheck.htm
• https://<ExchangeServer>/autodiscover/healthcheck.htm

Auch für die Fehlerdiagnose können die HealthCheck URLs hilfreich sein, etwa wenn nach einem Update die ComponentStates nicht wieder in den Status “Aktiv” gesetzt werden.

Mit diesem kleinen PowerShell Script, lassen sich die HealthCheck URLs abfragen:

$ExchangeServer = "EXSRV1.frankysweb.local"

#$AllProtocols = [System.Net.SecurityProtocolType]'Tls11,Tls12'
#[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols

$OWA = "https://$ExchangeServer/owa/healthcheck.htm"
$ECP = "https://$ExchangeServer/ecp/healthcheck.htm"
$RPC = "https://$ExchangeServer/rpc/healthcheck.htm"
$EWS = "https://$ExchangeServer/ews/healthcheck.htm"
$MAPI = "https://$ExchangeServer/mapi/healthcheck.htm"
$OAB = "https://$ExchangeServer/oab/healthcheck.htm"
$EAS = "https://$ExchangeServer/Microsoft-Server-ActiveSync/healthcheck.htm"
$AutoDiscover = "https://$ExchangeServer/autodiscover/healthcheck.htm"

$OWAResponse = (Invoke-WebRequest -Uri $OWA).RawContent
if ($OWAResponse -match "200 OK
")
	{
		write-host "OWA:	OK" -foregroundcolor green
	}
else
	{
		write-host "OWA:	Fehler" -foregroundcolor red
	}

$ECPResponse = (Invoke-WebRequest -Uri $ECP).RawContent
if ($ECPResponse -match "200 OK
")
	{
		write-host "ECP:	OK" -foregroundcolor green
	}
else
	{
		write-host "ECP:	Fehler" -foregroundcolor red
	}

$RPCResponse = (Invoke-WebRequest -Uri $RPC).RawContent
if ($RPCResponse -match "200 OK
")
	{
		write-host "RPC:	OK" -foregroundcolor green
	}
else
	{
		write-host "RPC:	Fehler" -foregroundcolor red
	}

$EWSResponse = (Invoke-WebRequest -Uri $EWS).RawContent
if ($EWSResponse -match "200 OK
")
	{
		write-host "EWS:	OK" -foregroundcolor green
	}
else
	{
		write-host "EWS:	Fehler" -foregroundcolor red
	}

$MAPIResponse = (Invoke-WebRequest -Uri $MAPI).RawContent
if ($MAPIResponse -match "200 OK
")
	{
		write-host "MAPI:	OK" -foregroundcolor green
	}
else
	{
		write-host "MAPI:	Fehler" -foregroundcolor red
	}

$OABResponse = (Invoke-WebRequest -Uri $OAB).RawContent
if ($OABResponse -match "200 OK
")
	{
		write-host "OAB:	OK" -foregroundcolor green
	}
else
	{
		write-host "OAB:	Fehler" -foregroundcolor red
	}

$EASResponse = (Invoke-WebRequest -Uri $EAS).RawContent
if ($EASResponse -match "200 OK
")
	{
		write-host "EAS:	OK" -foregroundcolor green
	}
else
	{
		write-host "EAS:	Fehler" -foregroundcolor red
	}

$AutodiscoverResponse = (Invoke-WebRequest -Uri $Autodiscover).RawContent
if ($AutodiscoverResponse -match "200 OK
")
	{
		write-host "Autodiscover:	OK" -foregroundcolor green
	}
else
	{
		write-host "Autodiscover:	Fehler" -foregroundcolor red
	}

Die Ausgabe des Scripts ist simpel und kann daher nur zur ersten Diagnose dienen (wenn überhaupt):

Der Beitrag Exchange 2016: HealthCheck URLs für Loadbalancer erschien zuerst auf Frankys Web.

Ich habe angefangen ein kleines PowerShell Script zu erstellen, welches dabei unterstützen soll ungültige oder verwaiste Gruppenrichtlinien aufzuspüren. Die erste Version des Scripts sucht nach Gruppenrichtlinien die nicht mit einer OU verbunden sind, keine Sicherheitsfilterung besitzen oder alle Einstellungen der GPO deaktiviert wurden. Das Script werde ich zukünftig noch um weitere Funktionen erweitern und als kleines Tool veröffentlichen. Hier aber erst einmal ein Vorgeschmack.

Das Script gibt den Status “Disabled” aus, wenn alle Einstellungen der Richtlinie deaktiviert wurden, hier ein Beispiel:

Der Status “Not Linked” wird ausgegeben, wenn die Gruppenrichtlinie mit keiner Organisationseinheit (OU) verknüpft ist, wie hier zu sehen:

Wenn die Sicherheitsfilterung leer ist, wird der Status “No Permissions” angegeben:

Das Script erfordert das PowerShell Modul “GroupPolicy”, welches Bestandteil ab Windows Server 2008 R2 ist. Getestet habe ich das Script bisher auf Windows Server 2012 R2, Windows Server 2016 und remote via Windows 10.

So sieht die Ausgabe des Scripts in der PowerShell aus:

Und hier nun das eigentliche Script, welches gerne angepasst oder umgeschrieben werden kann:

$AllGPOs = Get-GPO -All

$GPOCount = $AllGPOs.count
write-host ""
write-host "Found $GPOCount GPOs..."
write-host "Analyzing, please wait..."

$InvalidGPOs = @()

#Disabled GPOs
$DisabledGPOs = $AllGPOs | where {$_.GpoStatus -match "AllSettingsDisabled"}
foreach ($DisabledGPO in $DisabledGPOs)
	{
		$GPOName = $DisabledGPO.Displayname
		$InvalidGPOs += new-object PSObject -property @{GPOName="$GPOName";State="Disabled"}
		#write-host "Not active: $GPOName"
	}

#GPO Links / Permissions
$EnabledGPOs = $AllGPOs | where {$_.GpoStatus -notmatch "AllSettingsDisabled"}
foreach ($EnabledGPO in $EnabledGPOs)
	{
		$GPOName = $EnabledGPO.Displayname
		[XML]$GPOReport = Get-GPOReport $GPOName -ReportType XML
		$GPOLinks = $GPOReport.GPO.LinksTo
		$GPOApplyPermission = Get-GPPermission $GPOName -All | where {$_.Permission -match "GpoApply"}

		if (!$GPOLinks)
			{
				#write-host "Not linked: $GPOName"
				$InvalidGPOs += new-object PSObject -property @{GPOName="$GPOName";State="Not Linked"}
			}

		if (!$GPOApplyPermission)
			{
				#write-host "No permissions: $GPOName"
				$InvalidGPOs += new-object PSObject -property @{GPOName="$GPOName";State="No Permissions"}
			}
	}

$InvalidGPOs | sort state | ft GPOName,State

$InvalidGPOCount = $InvalidGPOs.Count
write-host "Found $InvalidGPOCount invalid GPOs"
write-host ""

#Optional: delete invalid GPOs
<#

foreach ($InvalidGPO in $InvalidGPOs)
	{
		Remove-GPO $InvalidGPO.GPOName
	}

#>

Der untere Teil nach #Optional kann verwendet werden, um die gefundenen ungültigen GPOs zu löschen. Das Objekt “$InvalidGPOs” enthält alle gefunden ungültigen GPOs und lässt sich somit auch weiterverwenden.

Vielleicht nützt es ja jemanden.

Der Beitrag Quick & Dirty: Ungültige und verwaiste Gruppenrichtlinien finden erschien zuerst auf Frankys Web.

Ich wollte heute einen neuen UniFi AccessPoint der Firma Ubiquiti in Betrieb nehmen. Meine vorhandenen AccessPoints befinden sich im gleichen Subnetz (und VLAN) wie auch der UniFi Controller, daher gab es bisher keine Probleme die AccessPoints mit dem Controller zu verbinden. Der neue AccessPoint sollte jetzt allerdings in ein anderes Subnetz und VLAN.

Damit sich AccessPoints aus anderen Subnetzen automatisch mit dem Controller verbinden, kann die DHCP Option 43 benutzt werden. Die Option 43 teilt dem AccessPoint mit, unter welcher IP-Adresse der UniFi Controller zu erreichen ist. Dies funktioniert dann auch aus anderen Subnetzten / VLANs wenn der Controller erreichbar ist.

In meinem Fall ist der DHCP Server die Sophos UTM und daher folgt hier die entsprechende Konfiguration des Sophos UTM DHCP Servers.

DHCP Option 43 für UniFi AccessPoints

Aus der UniFI Dokumentation geht folgendes hervor:

Quelle: https://help.ubnt.com/hc/en-us/articles/204909754-UniFi-Layer-3-methods-for-UAP-adoption-and-management

Auch die Sophos UTM erwartet für die Option 43 einen Hex Wert. Die ersten beiden Werte sind vorgegeben (01 und 04), gefolgt von der IP-Adresse des UniFi Controllers im Hex Format.

Hier gibt es ein kleines Tool, welches eine IP Adresse in das Hex Format konvertiert:

http://www.silisoftware.com/tools/ipconverter.php

Nachdem die IP-Adresse des Controllers in das Hex Format konvertiert wurde, kann daraus der Wert für die Option 43 des DHCP Servers der Sophos UTM erstellt werden:

• 01 (suboption)
• 04 (content length of payload)
• IP-Adresse des Controllers in Hex (in meinem Fall 192.168.100.252: 0xC0A864FC)

Die UTM erwartet die Werte getrennt mit Doppelpunkten, daher muss in meinem Fall der folgende Wert eingetragen werden:

• 01:04:C0:A8:64:FC (Die führenden Zeichen (0x) der IP-Adresse entfallen)

Die Konfiguration des DHCP Servers im Detail:

• Code: 43
• Name: unifi
• Hex: (siehe oben)
• Bereich: Anbieter-ID (Vendor-ID)
• Anbieter-ID (Vendor-ID): ubnt

Nachdem die Konfiguration gespeichert wurde, sollte es in etwa so aussehen:

Nach einem Neustart des AccessPoints, hat er sich direkt mit dem Controller verbunden. Endlich WLAN im Garten :-)

Der Beitrag Sophos UTM: DHCP Option 43 für UniFi AccessPoints erschien zuerst auf Frankys Web.

Der Beitrag Windows Server 2016 Datenschutz GPO Vorlage erschien zuerst auf Frankys Web.

Neben Windows 10 überträgt auch Windows Server 2016 eine ganze Menge Daten an Microsoft. In vielen Unternehmen dürfte dieses geschwätzige Verhalten von den aktuellen Windows Versionen unerwünscht sein. Microsoft scheint sich dessen durchaus bewusst zu sein und hat eine umfangreiche Dokumentation veröffentlicht, welche Dienste Daten an Microsoft übertragen.

Die Dokumentation gibt es hier:

Manage connections from Windows operating system components to Microsoft services

Allein für Windows Server 2016 ist die Liste recht lang. Ich habe daher eine Vorlage für eine Gruppenrichtlinie zum Datenschutz erzeugt, die die meisten von Microsoft vorgeschlagenen Einstellungen schon beinhaltet.

Die folgenden Punkte aus dem oben angegebenen Dokument habe ich unberührt gelassen:

• NTP Einstellungen
• Windows Defender Einstellungen
• Microsoft Edge Einstellungen

Diese Vorlage kann etwas Arbeit ersparen, jedoch sind ausführliche Tests unvermeidlich.

Einstellungen der Vorlage

• Die folgenden Einstellungen sind in der Vorlage enthalten:
• Konten: Microsoft-Konten blockieren
• Schriftartenanbieter aktivieren
• Teredo-Status festlegen
• Werbe-ID deaktivieren
• Abrufen von Gerätemetadaten aus dem Internet verhindern
• Continue experiences on this device
• Aktive Tests der Windows-Netzwerkverbindungs-Statusanzeige deaktivieren
• Windows SmartScreen konfigurieren
• Benutzersteuerung für Insider-Builds ausschalten
• Telemetrie nicht zulassen
• Beitritt zu Microsoft MAPS deaktivieren
• Dateibeispiele senden, wenn eine weitere Analyse erforderlich ist deaktivieren
• „Vorgeschlagene Sites“ deaktivieren
• AutoVervollständigen für Webadressen deaktivieren
• Browser-Geolocation deaktivieren
• Für Microsoft-Dienste das Bereitstellen von erweiterten Vorschlägen nicht zulassen, wenn Benutzer Text in die Adressleiste eingeben
• Verwalten von SmartScreen-Filter verhindern
• SmartScreen-Filtermodus
• Laden von Websites und Inhalten im Hintergrund zur Optimierung der Leistung deaktivieren
• Vorblättern mit Seitenvorhersage deaktivieren
• Kompatibilitätsansicht deaktivieren
• Verwendung von OneDrive für die Dateispeicherung verhindern
• Automatische Ermittlung von Feeds und Web Slices verhindern
• Hintergrundsynchronisierung für Feeds und Web Slices deaktivieren
• AVS-Onlineüberprüfung für KMS-Client ausschalten
• Alle Apps aus dem Windows Store deaktivieren
• Automatisches Herunterladen und Installieren von Updates deaktivieren
• Cortana auf Sperrbildschirm nicht zulassen
• Cortana nicht zulassen
• Der Suche und Cortana die Nutzung von Positionsdaten nicht erlauben
• Festlegen der in der Suche freizugebenden Informationen
• Nicht im Web suchen und keine Webergebnisse in der Suche anzeigen
• Websuche nicht zulassen
• Keine zusätzlichen Daten senden
• Windows-Fehlerberichterstattung deaktivieren

Während des Imports können Einstellungen verifiziert werden. Nach dem Import lassen sich die Einstellungen den eigenen Anforderungen anpassen.

Download

Die Vorlage für die Gruppenrichtlinie für den Datenschutz für Windows Server 2016 kann hier runtergeladen werden:

Windows Server 2016 Datenschutz GPO Vorlage 47.21 KB

Download

Die Vorlage kann auf einem Domain Controller entpackt werden. Im Archiv findet sich auch eine HTML-Datei mit den Einstellungen der Vorlage. Der Import der Einstellungen ist im nächsten Abschnitt beschrieben.

Gruppenrichtlinie importieren

Um die Einstellungen der Gruppenrichtlinie zu importieren, muss zunächst eine leere Gruppenrichtlinie angelegt werden:

Im Kontextmenü der neuen Gruppenrichtlinie findet sich die Option “Einstellungen importieren”:

Es öffnet sich der Importeinstellungen-Assistent, in dessen Verlauf der Pfad zum Verzeichnis der Gruppenrichtlinie mit den Voreinstellungen angegeben werden kann:

Im nächsten Fenster des Assistenten lassen sich die Einstellungen anzeigen und die Richtlinie importieren:

Sobald die Gruppenrichtlinie importiert wurde, sind die Einstellungen in der neu angelegten Gruppenrichtlinie hinterlegt:

Die neue Gruppenrichtlinie muss jetzt nur noch mit einer Organisationseinheit verknüpft werden:

Optional lässt sich die Auswahl auch noch mittels WMI Filter einschränken, damit die Richtlinie nur auf Server 2016 angewendet wird.

Der Beitrag Server 2016: Gruppenrichtlinie für die Datenschutz Einstellungen erschien zuerst auf Frankys Web.