Acer Icona W511 fährt seit dem letzten Patchday nach ca. 2 Minuten automatisch herunter

Wer ein Acer Icona W511 mit Windows 8.1 besitzt und brav alle Sicherheits- und optionale Updates installiert, der wird feststellen, dass sein Tablet nach kurzer Zeit automatisch herunterfährt. Dies kann man dann endlos wiederholen bis man irgendwann keine Lust mehr hat. Aufgrund dessen, dass der Zeitraum extrem kurz ist, lässt sich hier auch nichts debuggen, indem man z.B. das Ereignisprotokoll überprüft.

Betrachtet man die letzten Updates genauer, so stellt man fest, dass unter den optionalen Updates ein Treiberupdate dabei ist:

intel_update

Dieses klingt verdammt nach systemnahen Treibern, welche anscheinend das System dazu veranlassen das Tablet herunter zu fahren. Installiert man alle Updates des letzten Patchdays, außer dem genannten, so stellt man fest, dass das System reibungslos wie zuvor läuft. Also ist der Schuldige somit gefunden.

Was macht man nun, wenn das Update bereits installiert wurde?

Dank Wiederherstellungspunkten kann man das System auf einen funktionierenden Systemstand zurücksetzen. Dazu am einfachsten das System bis zur Anmeldung hochfahren und über die Kombination SHIFT + Neustarten das System mit den erweiterten Startoptionen starten. Hier dann in der Reihenfolge auf folgende Kacheln klicken:

intel_update2

Im Anschluss daran, öffnet sich der Assistent zur Auswahl des Wiederherstellungspunkts. Im Normalfall legt Windows automatisch vor jeder Installation von Windows-Updates einen Wiederherstellungspunkt an. Nachdem dieser ausgewählt wurde beginnt die Wiederherstellung und nach ein paar Minuten startet das System wieder problemlos und man kann die Updates, diesmal ohne das entsprechende Intel-Platform-Update, installieren.

0  

Fileserver vor Locky, Teslacrypt und Co schützen

Wie jedem Admin bekannt sein sollte kursieren mittlerweile einige Verschlüsselungstrojaner, die bei Ausführung bestimmte Dateien verschlüsseln. Ist der Trojaner erst einmal ausgeführt, so wird der Benutzer damit erpresst einen bestimmten Geldbetrag zu bezahlen, um den Entschlüsselungskey zu bekommen. Für Unternehmen kann dies kritisch werden, wenn durch ein Versehen eines Benutzers auf einmal der gesamte Fileserver verschlüsselt ist. Aufgabe der Admins ist es deshalb hier vorzusorgen bzw. Abhilfe zu schaffen, damit dieser Status nicht eintreten wird.

Wie kann man das erreichen?

a) Sensibilisierung der Benutzer, suspekte E-Mails nicht zu öffnen bzw. nicht auf deren Anhänge oder Links zu klicken
 
b) Überprüfung der Virenscanner auf aktuelle Signaturen
 
c) Pflege des Antispam-Systems, damit suspekte E-Mails nicht beim Benutzer landen, bzw. E-Mails mit Office-Makrodokumenten blockieren/in Quarantäne packen
 
d) Überprüfen der Einstellungen der Makrosicherheit in Office-Produkten
 
e) Zugriff der Benutzer auf Fileserver mit Berechtigungen einschränken, dadurch können nur zugreifbare Dateien verändert werden
 
f) Benutzern keine Adminrechte auf den Systemen geben
 
g) Einsatz von aktueller Software, wie z.B. Browser oder Office-Produkten die Schutzmechanismen besitzen, wie z.B. Smartscreen-Filter oder Sandboxing
 
h) Überprüfen der Funktion der Datensicherung/Schattenkopien
 

 

Einer der größten Fehler ist es im schlimmsten Fall die Schuld auf den Benutzer zu schieben, vorher sollte man sich überlegen, ob man als Admin einen guten Job gemacht und wirklich alles versucht hat, um die Ausführung des Trojaners zu verhindern. Wichtigster Punkt aus obiger Liste ist für mich aber Punkt a, denn dieser ist letztendlich entscheidend, ob der Benutzer den Link bzw. den Anhang öffnet. Ein Antivirussystem oder eine Filterliste sind nur so gut, wie diese auch gepflegt wird und diese arbeiten nach match oder nicht-match. Ein Mensch kann allerdings zweifeln, ob es sich bei dieser E-Mail um Spam/Malware handelt.

Wie es einem in Leben eines Admins so geht, kommt dann doch irgendwann der Anruf mit der Nachricht: “Ich habe hier eine Meldung die mich auffordert Geld zu überweisen, damit ich an meine Dateien komme. Was soll ich tun?” In diesem Fall den Benutzer sofort anweisen den Stromstecker des Rechners zu ziehen. Den der Trojaner ist jetzt bereits an der Arbeit und verschlüsselt im Kontext des Benutzers fröhlich jede Datei die er zwischen die Finger bekommt und auf die dieser Rechte besitzt. Jetzt kann man als Admin nur hoffen, dass die Datensicherung auch funktioniert, denn eine einfache Entschlüsselung gibt es nicht, außer Geld für die Entschlüsselung zu bezahlen.

Nachdem ich meinen ersten Fall live miterleben durfte, bei dem zum Glück nicht viele Dateien davon betroffen waren und die Wiederherstellung dank Schattenkopien möglich war, habe ich mir ausführlicher Gedanken darüber gemacht. Es war zum Glück nicht mein Netzwerk, aber trotzdem schreckt einen dies ab. Der Ansatz meiner Gedanken war es zu verhindern, dass der Trojaner die Dateien verändern kann. Schaut man sich die Vorgehensweise der Trojaner an, so wird die Datei verschlüsselt z.B. mit der Dateiendung .encrypted oder .locky abgespeichert. Dies muss man doch irgendwie abfangen können? Nach etwas Überlegen bin ich dann schließlich auf eine Möglichkeit gestoßen 🙂

Windows Server beinhaltet des Ressourcen-Manager für Dateiserver, über den man z.B. Quotas festlegen kann oder sich eine Auswertung über die Speichernutzung geben lassen kann. Ein weiterer Punkt ist die Dateiprüfungsverwaltung, durch die festgelegt werden kann, welche Dateien auf einem Fileserver abgelegt werden dürfen, um so z.B. zu verhindern, dass ein Benutzer seine private MP3-Sammlung auf dem Server ablegt. Diese Funktion kann man sich zu nutze machen, um den Trojaner daran zu hindern seine verschlüsselte Datei auf dem Server abzulegen. Was muss ich dazu tun?

Zunächst muss die Rollenfunktion Ressourcen-Manager für Dateiserver installiert werden. Dies kann man über den Assistenten im Servermanager oder per Powershell erledigen.Ist die Rollenfunktion installiert, so findet man diese unter Systemsteuerung->Verwaltung auf dem Server.

cryptofile1
Unter dem Konten Dateiprüfungsverwaltung findet man die drei Punkte Dateiprüfung, Dateiprüfungsvorlagen und Dateigruppen. Zunächst benötigt man eine Dateigruppe, in der man alle Dateiendungen hinterlegt, die man verweigern möchte. Dazu den Knoten Dateigruppen auswählen und rechts im Aktionsbereich die Aufgabe Dateigruppe erstellen auswählen.

cryptofile2

Zunächst muss der Dateigruppen ein Name vergeben werden und danach unter den Einzuschließenden Dateien die Dateiendungen hinzugefügt werden, welche verhindert werden sollen. Ist die Dateigruppe erstellt, so kann zum nächsten Schritt übergegangen werden und die Dateigruppe in einer Dateiprüfungsvorlage zu hinterlegen. Dazu den Knoten Dateiprüfungsvorlagen auswählen und aus dem Aktionsbereich die Aufgabe Dateiprüfungsvorlage erstellen ausführen.

cryptofile3

Der Vorlage einen Namen vergeben, damit diese eindeutig zu identifizieren ist und unter Dateigruppen die soeben erstellte Dateigruppe Malware auswählen. Unter der Option Prüfungstyp kann man festlegen, wie die Überprüfung auf unerwünschte Dateien funktionieren soll. Man hat hier die Möglichkeit zwischen Aktiv und Passiv zu wählen. Damit der Trojaner keine Chance hat die verschlüsselten Dateien zu erstellen muss hier die Option Aktiv gewählt werden, denn diese Verhindert, dass die Datei auf dem Fileserver erstellt werden kann. Passiv würde hier z.B. nur informativ ins Ereignisprotokoll schreiben. Eine gute Idee ist es z.B. den Admin beim Auftreten eines solchen Ereignisses per E-Mail zu benachrichtigen, dies kann ebenfalls in der Vorlage hinterlegt werden. Auf diesen Schritt möchte ich hier aber nicht tiefer eingehen. Sobald die Vorlage erstellt ist, kann diese für die Überwachung aktiviert werden. Dazu links den Knoten Dateiprüfungen auswählen und unter Aktionen auf die Aufgabe Dateiprüfung erstellen klicken. Dadurch wird eine neue Überwachung für den Fileserver erstellt.

cryptofile4

Zunächst muss unter Dateiprüfungspfad der Pfad auf dem Fileserver angegeben werden, welcher überwacht werden soll. In diesem Beispiel ist es der Pfad D:\Daten, wodurch auch die darunterliegenden Ordner geschützt werden. Die vorhin erstellte Vorlage muss unter Eigenschaften aus dieser Dateiprüfungsvorlage übernehmen ausgewählt werden. Nach Anlage der Dateiprüfung ist die Überwachung aktiv und verhindert somit die Erstellung von Dateien mit den hinterlegten Dateiendungen. Sollten zu einem späteren Zeitpunkt weitere Dateiendungen hinzukommen, so müssen diese nur der Dateigruppe hinzugefügt werden.

Versucht nun der Trojaner die Dateien verschlüsselt abzuspeichern, so wird dies durch die Dateiprüfung auf dem Fileserver verhindert. Testen kann man dies ganz einfach, indem man eine Datei erstellt und versucht diese in Texdokument.txt.locky umzubenennen. Man erhält dann folgende Fehlermeldung:

cryptofile5

Diese Methode ist natürlich keine Wunderwaffe oder ein Allheilmittel gegen Cryptotrojaner, aber kann in der Reihe der Abwehrmachanismen ein weiteres Glied darstellen. Wie vorhin schon erwähnt ist der wichtigste Punkt die Sensibilisierung der Benutzer.

 

 

0  

Azure AD Connect bringt Fehler 906

Zur Synchronisierung der Anmeldeinformationen zwischen dem lokalen Active Directory und dem Azure Active Directory gibt es mittlerweile einige Tools, aktuell ist Azure AD Connect. In den Anfängen hies das Tool DirSync und war ziemlich einfach gestrickt, mittlerweile steckt hinter Azure AD Connect ein Microsoft Identity Manager mit dem sich ziemlich viel bewerkstelligen lässt. Auch was die Benutzeroberfläche angeht hat sich bei diesem Tool einiges an Benutzerfreundlichkeit getan. Das Tool läuft soweit eigentlich ganz gut, so dass man kaum bemerkt.

Seit letzten Freitag (04.03.2016) erhalte ich jedoch einmal täglich eine Benachrichtigung, dass die letzte erfolgreiche Synchronisierung länger als 24 Stunden in der Vergangenheit liegt. Der Inhalt der E-Mails sieht wie folgt aus:


On Sonntag, 06 März 2016 23:48:15 GMT, Azure Active Directory did not register a synchronization attempt from the Identity synchronization tool in the last 24 hours for XXXXXXXXXXXXXX GmbH [xxxxxxxxx.onmicrosoft.com].

You can troubleshoot this issue by running the Directory Synchronization troubleshooter on the server that has Azure Active Directory identity synchronization tools installed.


In der E-Mail ist ein Link zum Directory Synchronization Troubleshooter enthalten, den man zunächst ausführen sollte, um die Konfiguration zu überprüfen. Dieser liefert leider keine hilfreichen Informationen zu diesem Problem, außer dass seit mehreren Stunden keine Synchronisierung stattgefunden hat.

Schaut man in das Ereignisprotokoll Anwendung des Severs, so findet man folgenden Eintrag mit dem Event ID 906:


Scheduler::SchedulerThreadMain : Encountered error while waiting for signal.
Exception: System.ArgumentOutOfRangeException: Die Zahl muss entweder nicht negativ und kleiner oder gleich dem Int32.MaxValue oder -1 sein.
Parametername: timeout
bei System.Threading.WaitHandle.WaitOne(TimeSpan timeout, Boolean exitContext)
bei Microsoft.MetadirectoryServices.Scheduler.Scheduler.SchedulerThreadMain()


Durch Suchen in der Suchmachine seiner Wahl findet man dann folgenden Beitrag in den O365-Foren. Darin wird zum Schluß als Lösung genannt, dass ein Update von Azure AD Connect auf die aktuellste Version (1.1.110) das Problem beheben sollte. Da vor kurzem erst auf Azure AD Connect aktualisiert wurde, habe ich auf dem Server über Programme und Features die installierte Version geprüft und diese war 1.1.105. Die aktuellste Version kann man unter der URL Download AAD Connect herunterladen und anschließend die bereits installierte Version durch Ausführen der heruntergeladenen Datei aktualisieren. Nachdem die Aktualisierung und der Assistent durchlaufen sind, sollte die Synchronisierung wieder ohne Fehler durchlaufen.

Wer nach der Aktualisierung Einträge bzgl. Probleme bei der Erstellung von Perfmon-Countern erhält, der findet hier Abhilfe. Bei mir musste zum Abschluß allerdings ein Neustart des Servers erfolgen, ansonsten blieb der Fehler bestehen.

 

0  

Windows 10 – Vorgeschlagene App-Links aus dem Start entfernen

Wie bereits unter Windows 8/8.1 wird auch unter Windows 10 das Betriebssystem mit vorinstallierten Modern UI Apps, wie z.B. Scanner, Kamera usw. , ausgeliefert. Dem spricht eigentlich nichts dagegen, denn so schlecht sind die Apps nicht und man kann sie bei Bedarf auch deinstallieren. Dazu gibt es unterschiedliche Wege. Entweder man modifiziert das Installations-Image und installiert diese Apps somit erst gar nicht auf das System oder man entfernt diese nach der Installation des Rechners global oder pro Benutzer. Ich möchte in diesem Blogpost allerdings nicht weiter auf diese Wege eingehen, sondern das Thema mit folgenden zwei Links abhaken.

-> Apps aus dem Image entfernen (Link)

-> Apps nach der Installation entfernen (Link)

Hinweis: Es handelt sich hierbei um externe Links, ich übernehme keinerlei Haftung für die Inhalte von externen Links

Die Prozedur ist ganz einfach und schnell erledigt. Abhängig von bestimmten Editionen von Windows 10 bleiben nach der Deinstallation der Apps allerdings einige Überreste.

suggestedApps1

Betrachtet man diese genau, so stellt man fest, dass es sich dabei nicht um installierte Apps, sondern um vorgeschlagene Apps handelt. Klickt man auf die Kachel so landet man im Store und kann die App installieren.  Man kann diese vorgeschlagenen Apps über das Kontextmenü entfernen, aber das gilt dann wieder nicht für alle Benutzer, also muss eine andere Lösung her.

Wie bekommt man nun die Kacheln von Candy Crush Saga, Minecraft, Twitter und N-TV aus dem Start Layout? Dies ist der Zeitpunkt bei dem ich persönlich schon seit Beginn meiner IT-Karriere die Krise bekomme. Dem einen oder anderen geht es bestimmt geanu so wie mir mit PCs und den vorinstallierten Betriebssystemen. Bei diesen ist dann allmöglicher “Müll” vorinstalliert und man ist nach dem Auspacken erstmal Stunden damit beschäftigt eine saubere Installation zu bekommen, sofern man nicht gleich die blanke Installations-DVD (oder heutzutage USB-Stick ;-)) schiebt. Dieser Artikel ist, nebenbei angemerkt, bei der Installation einer Windows 10 Enterprise Edition entstanden. Und hier ist der Punkt erreicht wo ich auf absolutes Unverständnis stosse, bei den Privat-Editionen sehe ich das noch ein, denn der günstige Preis lässt sich halt nur einmal durch “Werbung” finanzieren, aber bitte nicht in Versionen für  Unternehmen.

Es hat leider ziemlich lange gedauert bis ich letztendlich auf die Lösung gekommen bin. Da es sich bei den vorgeschlagenen Apps nicht um installierte Apps handelt kann man diese auch nicht deinstallieren, somit scheidet das schon aus. Das Startmenü war/ist unter ein paar üblichen Orten definiert, wie z.B. C:\ProgramData\Microsoft\Windows\Start Menu, aber auch hier sind keine Links zu den vorgeschlagenen Apps zu finden. In der Registry findet man Verweise auf die Apps, aber dieser Weg bringt auch keine Lösung. Ein vorgeschlagener Weg wäre gewesen das Start Layout zu definieren, also die Links per Hand zu entfernen und die benötigten Kacheln zu platzieren, anschließend das Layout zu exportieren und per Richtline zuweisen. Haken an der Sache ist, dass der Benutzer hier keine Veränderungen am Start Layout vornehmen kann, was auch nicht gewollt ist. Durch absoluten Zufall bin ich in den TechNet-Foren auf einen Beitrag gestossen, weil ich hier eigentlich meinen Senf dazu geben wollte 🙂 Darin wurde dann auf folgenden Ariktel in der MSDN verweisen. Dieser beschreibt, wie man das Start Layout definieren kann. Dazu befindet sich im Verzeichnis C:\Users\Default\Appdata\Local\Microsoft\Windows\Shell die Datei DefaultLayouts.xml in der für unterschiedliche Editionen und Sprachen die Start Layouts definiert sind.

suggestedApps2

Betrachtet man diese Datei genauer, so findet man z.b. die markierte Zeile, über die festgelegt wird wo vorgeschlagene Apps platziert werden sollen/dürfen. Man könnte jetzt hergehen und diese modifizieren, was ich persönlich nicht für gut halte, denn der Standard sollte gewahrt bleiben, oder über eine Datei namens LayoutModification.xml anpassen und wirft somit die vorgeschlagenen Apps aus dem Start Layout. Der Unterschied zwischen dieser Methode und der Vorgabe des Start Layouts über eine Gruppenrichtlinie ist, dass der Benutzer hier Veränderungen vornehmen kann.

Mir persönlich ist die Vorgabe des Layouts nicht wichtig, und wenn dann würde ich das Layout über eine Gruppenrichtlinie verteilen. Somit habe ich aus dem Verzeichnis C:\Users\Default\Appdata\Local\Microsoft\Windows\Shell die Datei in den Papierkorb gesichert. Dadurch existiert keine Vorgabe des Layouts für neue Benutzer und mein Problem sollte behoben sein. Und siehe da nach der Anmeldung eines neuen Benutzers sieht das Start Layout sauber aufgeräumt aus und die vorgeschlagenen Apps sind verschwunden.

suggestedApps3

Diese Methode klappt natürlich nur bei neuen Profilen, die Entfernung der vorgeschlagenen Apps bei bestehenden Profilen bedarf weiterer Analyse, aber auch hierfür gibt es sicherlich einen Weg.

 

 

 

 

 

 

0  

Bestimmte Versionen von Windows und Browsern für RDWeb sperren

Wie jedem mittlerweile bekannt sein dürfte wurde der Support von Windows XP seit dem 8. April 2014 eingestellt, d.h. es gibt hierfür keine Sicherheitsupdates mehr. Ebenso gilt dies für den Internet Explorer, hier hat Microsoft am 12. Januar 2016 einen Cut gemacht (Support IE). Es wird hier z.B. unter Windows 7 nur noch die letzte Version, also der IE 11, unterstützt. Nutzer des IE 10 unter Windows 7 erhalten keine Updates mehr dafür.

Diese Abkündigungen bedeuten natürlich auch, dass der Admin hier mittlerweile aufpassen muss, wenn z.B. über Privatrechner auf Unternehmensressourcen zugegriffen wird. Ein veralteter Rechner mit Windows XP kann z.B. über einen VPN-Tunnel Malware ins Unternehmensnetzwerk einschleussen, oder ein nicht mehr supporteter Browser könnte eine Sicherheitslücke haben, über welche ein Kennwort ausgelesen werden kann. Leider trifft man heutzutage noch einige Rechner mit veralteten Betriebssystemen oder Browsern an.

Am Beispiel von RDWeb kann man hier mit einfachen Mitteln gegenwirken, indem man beim Aufruf der Website bestimmte Parameter überprüft. Jeder Browser übermittelt mit dem UserAgent Informationen über das System, wie z.B. die Windows-Version oder den Browser. Diese Informationen kann man dazu nutzen um den Client zu überprüfen, ob dieser die “Unternehmensrichtlinien” erfüllt. Eine Beschreibung des User-Agents findet man hier https://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx. Ein UserAgent sieht z.B. wie folgt aus:

“Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 10.0; WOW64; Trident/7.0; Touch; .NET4.0C; Tablet PC 2.0; InfoPath.3)”

Obiger UserAgent erzählt z.B. folgendes über den Client:

Wert Bedeutung
MSIE 9.0 Browser ist der IE 9 oder IE9 im Kompatibilitätsmodus
Windows NT 10.0 Betriebssystem ist Windows 10
WOW64 Betriebssystem ist 64-Bit
Trident/7.0 Browser ist IE 11

 

Um eine Überprüfung des Clients vor der Anmeldung am RDWeb durchzuführen muss die Login-Seite, bzw. das dahinterliegende JavaSkript, angepasst werden. Dieses liegt auf dem Server mit RDWeb im Verzeichnis C:\Windows\Web\RDWeb\Pages und heisst renderscripts.js.

Hinweis: Es ist sinnvoll die Datei renderscripts.js vorher zu sichern, bevor Änderungen an dieser vorgenommen werden, damit im Notfall diese schnell wiederhergestellt werden kann.

Zu Beginn wird darin die Funktion onPageload ausgeführt, welche zur Überprüfung des Clients angepasst werden muss. Folgender Code stellt die vollständig abgeänderte Funktion dar, grün ist hier der Originalcode und schwarz sind die Änderungen im Code.

function onPageload(e) {
//
// Browser Name in the form : ‘MSIE x.x’.
//
var iePattern = /MSIE (\d+)\./;
var ieMatch = iePattern.exec(window.navigator.userAgent);  if (ieMatch) {
if (parseInt(ieMatch[1]) <= 6)
{
ApplyPngTransparency();
}
}

// Browser and Windows check

var signinbtn = document.getElementById(‘btnSignIn’);

var min_windows = 6.1; // Versions of Windows starting at Windows 7
var min_trident = 7; // Versions of IE starting at IE 11

var tridentPattern = /Trident\/(\d+)\./;
var windowsPattern = /Windows NT (\d+\.\d+)/;

var tridentMatch = tridentPattern.exec(window.navigator.userAgent);
var windowsMatch = windowsPattern.exec(window.navigator.userAgent);

var check = false;

// Check version of Windows

if (parseFloat(windowsMatch[1]) < min_windows)
{
// Unsupported version of Windows
check = true;
}
else if (parseFloat(windowsMatch[1]) >= min_windows)
{
// Supported version of Windows now check IE

if ((ieMatch) && (parseInt(tridentMatch[1]) < min_trident))
{
// Version of IE is below minimum
check = true;
}
}

if (check)
{
// Hide login button and notify user
signinbtn.style.visibility = ‘hidden’;

alert(unescape(‘Sie verwenden leider eine nicht unterst%FCtzte Version von Windows oder Internet Explorer.\n\nSie ben%F6tigen als Betriebssystem    mindestens Windows 7 und als Browserversion den Internet Explorer 11.\n\nBei Fragen wenden Sie sich bitte an Ihre IT-Abteilung.’));
}

}

 

In der Variable min_windows wird die Minimalversion für das Betriebssystem hinterlegt, in diesem Fall ist es die Zahl 6.1 für Windows 7. Bei der Browserversion wird es etwas schwieriger, da es möglich ist im Browser über den Entwicklermodus die Browserversion zu verändern. Aus diesem Grund wird im UserAgent zusätzlich das Trident-Token hinzugefügt, welches die eigentliche Version des Browsers verbirgt. Die Version 7 steht hier in der Variable min_trident für den IE 11. Über Muster werden im Anschluß aus dem UserAgent die Windows- und Browser-Version ausgelesen und in Variablen zur späteren Verarbeitung ausgelesen.

Zunächst wird überprüft, ob die ausgelesene Windows-Version den Mindestanforderungen entspricht, falls nicht, dann wird eine check-Variable gesetzt, welche  später im Code steuert, ob eine Anmeldung erlaubt ist. Ist die Windows-Version zulässig, so wird im Anschluss daran überprüft, ob der Aufruf über den IE stattgefunden hat und das Trident-Token ausgewertet. Entspricht dies nicht der Mindestanforderung, so wird wieder die check-Variable gesetzt. Nachdem alle Überprüfungen durchlaufen sind wird anhand der check-Variable entschieden, ob die Anmeldung am System erlaubt ist oder nicht. Ist das System nicht zulässig, so wird hier der Login-Button ausgeblendet und der Benutzer erhält eine Mitteilung am Bildschirm. Dies sieht dann wie folgt aus:

rdweb_check1

Das gezeigte Skript soll als Ansatz dienen, um auf einfache Weise bestimmte Windows- oder Browser-Versionen, den Zugriff auf Unternehmensressourcen zu verweigern.

Wer mag kann dies gerne einsetzen und auch abändern, ich übernehme jedoch keinerlei Haftung für eventuelle Schäden.

0  

Bearbeiten von Abwesenheitsbenachrichtigungen von anderen Benutzern

Ich war bislang immer der Meinung, dass die Abwesenheitsbenachrichtigung eines Benutzers nur von diesem selbst bearbeitet werden kann. Durch Zufall habe ich herausgefunden, dass es Powershell-Befehle gibt, mit denen der Admin die Abwesenheitsbenachrichtigungen von Benutzern verändern kann. Dies kann z.B. nützlich sein, wenn ein Mitarbeiter erkrankt und dieser keine Abwesenheitsbenachrichtigung konfiguriert hat.

Mit dem Powershell-Befehl  Get-MailboxAutoReplyConfiguration -Identity <Benutzer> kann man sich die Konfiguration der Abwesenheitsbenachrichtigung eines Benutzers anzeigen lassen.

autoreply_1

Am Attribut AutoReplyState sieht man welchen Status die Abwesenheitsbenachrichtigung besitzt. Steht dieses Attribut auf Enabled oder Scheduled ist die Abwesenheitsbenachrichtigung aktiviert bzw. von/bis zu einem bestimmten Datum aktiviert. Der Text der Abwesenheitsbenachrichtigung steht in den Attributen ExternalMessage und InternalMessage, als HTML-Code.

Veränderungen an der Abwesenheitsbenachrichtigung kann man über den Befehl Set-MailboxAutoReplyConfiguration vornehmen. Folgender Befehl aktiviert z.B. die Abwesenheitsbenachrichtigung bis zum 01.03.2016 15:00 Uhr und verändert den Text der internen Abwesenheitsbenachrichtigung:

Set-MailboxAutoReplyConfiguration -Identity <Benutzer> -AutoReplyState Scheduled -EndTime “03/01/2016 15:00” -InternalMessage “Ich bin bis zum 01.03.2016 nicht im Haus”

Das Ergebnis sieht dann wie im folgenden Bild zu sehen aus:
autoreply_2
Mit den beiden Befehlen kann man natürlich noch mehr verändern, welche weiteren Parameter existieren und was noch verändert werden kann findet man in der TechNet zu den Befehlen Get-MailboxAutoReplyConfiguration und Set-MailboxAutoReplyConfiguration.

 

 

0  

Weitere Mailbox lässt sich nicht über OWA öffnen wenn über WAP veröffentlicht

Die Zeiten von TMG sind schon lange gezählt und wer seinen TMG noch nicht durch ein anderes Produkt ersetzt hat sollte sich nun doch Gedanken darüber machen, durch was er seinen TMG ablöst. Ich weiß, TMG war ein geniales Produkt und er würde auch jetzt noch super funktionieren, doch aufgrund des abgekündigten Supports besteht ein gewisses Risiko TMG weiter zu betreiben. Eine Alternative aus dem Hause Microsoft ist der Web Application Proxy (WAP), der insgeheim als Ablöse für TMG gilt.

Hat man Outlook Web App  über WAP, unter Server 2012 R2, mit den bekannten Pfaden veröffentlicht, so funktioniert dies eigentlich reibungslos. Bis zu dem Moment wo ein Benutzer auf eine andere Mailbox zugreifen will. Hier begrüßt der Browser einen dann mit einer HTTP 404-Fehlermeldung.

WAP OWA HTTP 404

Schaut man sich die URL im Adressfeld an, so ist hier nichts außergewöhnliches zu erkennen, wie z.B. http:// anstelle von https:// oder Ähnliches. Auch im Ereignisprotokoll des Servers mit WAP ist nichts zu entnehmen. Probiert man dies intern, so wird der Zugriff auf die weitere Mailbox reibungslos funktionieren. Es muss also etwas mit dem WAP zu tun haben. Leider bietet hier WAP nicht die Möglichkeiten wie sie in TMG vorhanden waren, um dem Fehler auf die Schliche zu kommen. Aber es wird sicherlich nicht die letzte Version von WAP gewesen sein und so blicken wir hoffnungsvoll in die Zukunft 🙂

Wer die Suchmaschine seiner Wahl betätigt wird auf den KB-Artikel 3042127 stoßen. Dieser beschreibt einen Hotfix, für WAP unter Windows Server 2012 R2, der genau dieses Verhalten beim Zugriff auf eine weitere Benutzer-Mailbox über OWA behandelt. Es ist also ein bekanntes Problem, welches durch falsche Codierung  von reservierten Zeichen in der URL hervorgerufen wird. Beheben lässt sich diesen, indem man den Hotfix installiert und den Server danach neu startet. Ist der Server wieder verfügbar, so bekommt der Benutzer nun auch die gewünschte Mailbox angezeigt anstelle der HTTP 404-Fehlermeldung.

 

0  

Update von ESET Remote Administrator 6 (ERA) schlägt fehl

Jede Software muss von Zeit zu Zeit aktualisiert werden, sei es dass ein Hotfix oder ein Update installiert werden muss, damit die Software wieder auf dem aktuellsten Stand ist. Dadurch wird unter anderem sichergestellt, dass die Software vor aktuellen Bedrohung geschützt ist. Besonders wichtig ist dies bei Sicherheitsprodukten wie z.B. dem Virenscanner, dieser  ist ohne aktuelle Signaturen eigentlich nutzlos. In Unternehmen gibt es für die Sicherheitsprodukte meistens eine zentrale Verwaltungssoftware über welche die Clients konfiguriert und überwacht werden können.

Bei ESET wird die Verwaltung der Clients über den Remote Administrator (ERA) vorgenommen. Diesen kann man auf unterschiedliche Art und Weise betreiben, wie z.B. auf einem Windows Server oder unter Linux als virtuelle Appliance. Auch diese Software muss aktuell gehalten werden, dazu kann man einen Task konfigurieren der diese Aufgabe übernimmt und die Software des ERA automatisch aktualisiert (ESET KB 3668). Wer gerne etwas mehr Kontrolle darüber haben möchte kann dies auch manuell über die Linux-Shell vornehmen. Dazu muss von der ESET-Website das Installationspaket heruntergeladen werden und auf dem Server ausgeführt werden.

Dabei kann das Update mit folgendem Fehler fehlschlagen:

ERA Update Error

Die Fehlermeldung ist eindeutig, es muss etwas mit den Anmeldeinformationen an der MySQL-Datenbank zu tun haben. Man kann nun versuchen diese über die Parameter mitzugeben, doch auch dieser Versuch wird scheitern, denn der Grund ist eigentlich ganz einfach. Stöbert man etwas im ESET-Forum, dann stößt man auf folgenden Thread. Darin wird von einem ESET-Mitarbeiter der Grund für das Scheitern genannt:

“Yes, it is trying to connect to database using credentials it found in connection string and SERVER configuration – but unfortunately it seems loading of them failed at some point -> most probably fetching of password for “era” user was not successful. Is there any chance you are using “special” characters (characters with special meaning in shell scripting, like {}[]”;\’@$<\n>*) in password?”

Es liegt also an bestimmten Sonderzeichen im Kennwort, welches für den Zugriff auf die MySQL-Datenbank verwendet wird. Kennwörter an Servern sollten eigentlich immer komplex gewählt werden und somit ist die Wahrscheinlichkeit sehr hoch, dass eines dieser Sonderzeichen im Kennwort verwendet wurde sehr hoch. Die Lösung des Problems liegt jetzt darin ein sicheres Kennwort zu verwenden, welches diese Sonderzeichen nicht verwendet. Dabei muss wie folgt vorgegangen werden.

1.) Das Kennwort für den Zugriff auf die MySQL-Datenbank ist in einer .ini-Datei auf dem Server hinterlegt und muss dort über einen Editor geändert werden.

vi /etc/opt/eset/RemoteAdministrator/Server/StartupConfiguration.ini

ERA_Update2

Wichtig hier sind die rot markierten Informationen.
User: Benutzer für den Zugriff auf die MySQL-Datenbank
Password: Das Kennwort für den Zugriff auf die MySQL-Datenbank
Database: Die MySQL-Datenbank in der die ERA-Informationen gespeichert sind

Am Besten schreibt man sich diese Informationen ab, denn diese werden später noch benötigt. Zunächst muss aber in der Datei anstelle des bislang verwendeten Kennworts ein anderes gesetzt werden, welches keines der genannten Sonderzeichen enthält. Folgend wird hier zur Demonstration als Kennwort die Zeichenfolge Kennwort verwendet.

Hinweis: Für den Live-Betrieb sollte natürlich ein sichereres Kennwort gewählt werden!

ERA Neues Kennwort

Das neue Kennwort muss zwischen die beiden Klammern geschrieben und die geänderte Datei anschließend abgespeichert werden. Jetzt ist das neue Kennwort für den Zugriff von ERA auf die MySQL-Datenbank gesetzt, allerdings werden die Zugriffe fehlschlagen, da in der MySQL-Datenbank noch das alte Kennwort hinterlegt ist.

2) Das Kennwort kann über verschiedene Wege geändert werden. Folgend wird das Kommandozeilentool mysql verwendet. Zunächst muss eine Verbindung mit der MySQL-Datenbank mit einem Admin-Account hergestellt werden.

Die Befehlszeile dazu sieht wie folgt aus: mysql -u root -p –database era_db

Als Wert für den Parameter database muss hier der Wert aus der .ini-Datei angegeben werden, damit eine Verbindung mit der richtigen Datenbank hergestellt wird. Nach der Eingabe des Kennworts ist man dann auch verbunden und kann mit der Änderung des Kennworts beginnen.

Dazu zunächst zur Sicherheit über den SQL-Befehl select host,user,password from mysql.user where user =’era’; die Benutzer ausgeben lassen.

ERA select user
Als Benutzername für die Spalte User muss hier der Wert aus der .ini-Datei angegeben werden, damit der richtige Benutzer ausgegeben wird.

Im nächsten schritt muss über den SQL-Befehl update mysql.user set password=PASSWORD(‘Kennwort’) where user =’era’; das neue Kennwort für die in der Datenbank hinterlegten Benutzer gesetzt werden.

ERA update user

Wurde der Befehl erfolgreich ausgeführt ist das Kennwort geändert und die MySQL-Befehlszeile kann über exit verlassen werden. An dieser Stelle am Besten den Server über shutdown -r now neu starten und anschließend wieder eine Verbindung mit der Console herstellen.

Nun das Update der Serverkomponente erneut über ./Server-Linux-x86_64.sh –skip-license anstoßen.

ERA update working

Das Update sollte nun funktionieren und auch in Zukunft keine Probleme mehr bereiten.

 

 

 

 

 

 

 

 

 

0  

Partnerschaft alter Mobilgeräte automatisch löschen

Im Laufe der Zeit hat sich die Anzahl der mobilen Endgeräte der Benutzer stark verändert. Mittlerweile besitzt ein Benutzer nicht nur ein Smartphone, sondern auch ein Tablet und gegebenenfalls weitere Geräte auf denen er seine E-Mails mobil lesen kann. Für jedes Gerät welches mit dem Exchange Server synchronisiert wird muss eine Partnerschaft angelegt werden. Die maximale Anzahl der Partnerschaften wird durch die Throttling-Policy festgelegt, Standard sind hier 10 Geräte pro Benutzer. Ist für einen Benutzer der maximale Wert an Partnerschaften erreicht so kann er keine neuen Geräte synchronisieren und er erhält am Gerät eine (ggf. nicht aussagekräftige 🙂 ) Fehlermeldung während der Einrichtung. Durch den häufigen Wechsel der Geräte kann dieser Wert ziemlich schnell erreicht werden.

Der Benutzer kann über Outlook Web App in der Exchange Verwaltung (ECP) seine Geräte verwalten und dort ggf. auch löschen. Doch dies wissen leider die wenigsten und somit bleibt diese Aufgabe meistens beim Administrator hängen und dieser muss veraltete Gerätepartnerschaften löschen. Ein anderer Weg wäre die Anzahl der maximalen Parnterschaften in der dafür verantwortlichen Throttling-Policy zu erhöhen, wie in folgendem Artikel beschrieben wird: MSExchange.org: Throttling-Policy. Letztendlich verzögert man dadurch aber nur das eigentliche Problem und schafft keine dauerhafte Lösung. Exorbitant hohe Werte, wie z.B. 10000 Geräte, sind nicht ratsam, da hierdurch die Verwaltbarkeit der Mobilgeräte nicht mehr gegeben ist.

Ein weitaus eleganterer Weg ist die Partnerschaft älterer Mobilgeräte automatisch per Powershell-Skript zu löschen. Hierbei werden alle Partnerschaften überprüft, wann die letzte erfolgreiche Synchronisierung stattgefunden hat. Überschreitet diese einen konfigurierbaren Zeitraum, so wird die Partnerschaft automatisch durch das Skript gelöscht. Folgendes Skript soll einen Ansatz dazu liefern, wie man diese Aufgabe automatisieren kann:


Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -Erroraction: silentlycontinue

$check = $false
$ts = (Get-Date).AddMonths(-2)

$devices = Get-ActiveSyncDevice | Get-ActiveSyncDeviceStatistics | Where {$_.LastSuccessSync -lt $ts}

$message = “Folgende Geräte wurden seit dem ” + $ts.ToShortDateString() +” nicht synchronisiert und wurden deshalb gelöscht: `n`r`n`r”

foreach ($device in $devices)
{

$check = $true
$user = $device.Identity.Split(“/”)

$message += “Gerät : ” + $device.DeviceFriendlyname + “`n`r”
$message += “Letzer Kontakt : ” + $device.LastSuccessSync + “`n`r”
$message += “Idenität : ” + $user[$user.Count-3] + “`n`r`n`r”

Remove-ActiveSyncDevice -Identity $device.Identity -Confirm:$false

}

if ($check)
{
Send-MailMessage -From “activesynccleanup@domain.tld” -To “exadmins@domain.tld” -Subject “Es wurden veraltete ActiveSync-Geräte bereinigt” -Body  $message.Replace(“`n”,””) -SmtpServer localhost -Encoding Default
}


Über die Variable $ts wird der Wert in Monaten festgelegt, welcher überschritten werden muss, damit eine Partnerschaft automatisch entfernt wird. Anschließend werden alle Mobilgeräte gesucht, deren letzte Synchronisierung den festgelegten Zeitraum überschreiten. In einer Schleife über diese wird die Nachricht aus den Gerätedaten gebildet und die Partnerschaft entfernt. Zum Abschluss werden die Admins per E-Mail über die erfolgte Bereinigung informiert.

Das obige Skript kann entweder manuell oder automatisiert per geplanten Task ausgeführt werden. Sollte durch das Skript eine Partnerschaft gelöscht werden, die noch benötigt wird, z.B. weil der Mitarbeiter das IPad nur selten nutzt, ist dies kein Problem, denn bei erneuter Synchronisierung wird die Partnerschaft wieder neu angelegt.

Hinweis: Die Powershell-BefehleGet-ActiveSyncDevice, Get-ActiveSyncDeviceStatistics und Remove-ActiveSyncDevice werden in Exchange Online und Exchange 2016 durch Get-MobileDevice, Get-MobileDeviceStatistics und Remove-MobileDevice ersetzt. Mehr Informationen hier: Microsoft Technet. Sollten Sie also eine dieser genannten Versionen verwenden, so müssen Sie die Befehle im Skript durch die Neuen ersetzen.

 

0  

Überprüfen von Zertifikaten auf deren Ablauf mit Powershell

Die gesicherte Übertragung von Daten ist ein wichtiges Thema in der IT und jeder der einen Computer oder ein Smartphone benutzt hat direkt oder indirekt damit zu tun. Zum Beispiel der Zugriff auf Outlook Web App oder die Synchronisierung der E-Mails per ActiveSync auf dem Smartphone laufen alle über eine gesicherte HTTP-Verbindung (HTTPS), damit niemand deren Inhalt während der Übertragung ausspähen kann. Dazu kommen meistens Zertifikate zum Einsatz, um die Identitätsbestätigung der Gegenstelle durchzuführen und zum Herstellen einer gesicherten Verbindung. Eine gute Beschreibung zum Thema Zertifikate und Verschlüsselung findet man hier: Anleitung Thawte.

Wichtig beim Einsatz von Zertifikaten ist, dass diese folgende drei Kriterien erfüllt werden:

– Das Zertifikat darf nicht abgelaufen sein
– Die Aufgerufene URL muss mit dem CN/SAN des Zertifikats übereinstimmen
– Das Zertifikat muss von einer vertrauten Zertifizierungsstelle ausgestellt sein

Sollte einer der drei genannten Punkte nicht erfüllt sein, so sollte man aus Sicherheitsgründen keine Verbindung mit dem Server eingehen. Es könnte sein, dass es sich hierbei um einen Ausspähversuch durch einen kompromittierten Server handelt.

Für den Betrieb ist es wichtig, dass das eingesetzte Zertifikat gültig ist, deshalb hatte Forefront TMG einen Überprüfungsmechanismus enthalten der alle Zertifikate von veröffentlichten Webservern und lokalen Weblistenern regelmäßig auf deren Ablaufdatum überprüft hat. Näherte sich ein Zertifikat dem Ablaufdatum, so wurde ein Alarm in Forefront TMG generiert, der den Administrator darüber informierte. Da das Ende von Forefront TMG mit dem 31.12.2015 immer näher kommt sollte man sich so langsam Gedanken über eine Alternative machen. Die alternativen Firewall-Produkte bieten diese Funktion der Zertifikatsüberprüfung allerdings nicht an und man ist dazu gezwungen die Ablaufdaten der verwendeten Zertifikate anderweitig im Auge zu behalten. Eine Möglichkeit wäre diese im Kalender von Outlook einzutragen, was allerdings ziemlich aufwendig in der Pflege sein kann. Eine andere Möglichkeit wäre die Überprüfung der Server auf den Ablauf von Zertifikaten mittels Powershell-Skript. Folgendes Powershell-Skript zeigt einen Ansatz, wie man mit Hilfe von Powershell die installierten Computer-Zertifikate auf Windows-Servern auf deren Ablauf überprüfen kann. Sollte ein Zertifikat innerhalb der nächsten Woche ablaufen, so wird automatisch eine E-Mail an eine definierte E-Mail-Adresse gesendet.

—- Start Skript —-

$servers = (“SERVER1″,”SERVER2″,”SERVER3”)
$today = Get-Date
$today = $today.AddDays(7)
$smtpserver = “192.168.0.1”
$smtpsubject = “Zertifikatscheck”
$smtpfrom = “certceck@domain.local”
$smtpto = “itadmins@domain.local”
$body = “Folgende Zertifikate laufen diese Woche aus: `r`n`r`n”

foreach ($server in $servers)
{

$certs = Invoke-Command -ComputerName $server {$foo = Get-ChildItem -Path Cert:\LocalMachine\My ; return $foo}

foreach ($cert in $certs)
{

if ($cert.NotAfter -lt $today)
{

$body += $server + ” : ” + $cert.Subject.Split(“,”)[0] + ” : ” + $cert.NotAfter.ToShortDateString() + “`r`n`r`n”

}

}

}

if ($body -ne “”)
{

Send-MailMessage -SmtpServer $smtpserver -From $smtpfrom -To $smtpto -Subject $smtpsubject -Body $body -Priority High

}

—- Ende Skript —-

Obiges Skript kann man z.B. per geplanten Task jeden Sonntag ausführen, so wird man automatisch über den Ablauf der Zertifikate der kommenden Woche informiert.

Hinweis: Die Verwendung des Skripts erfolgt auf eigene Gefahr, ich übernehme keinerlei Haftung für eventuelle Schäden.

0