Markus Bäker

On thing I was always missing in System Center Operations Manager (SCOM) was the notification with other instant messaging (IM) protocols than the build in Microsoft Communicator.

On friday I had some time to test a solution which I will describe here.

On warnung at the beginning: This current solution is experimental. It will run a Miranda client in the system context and can be a large security hole for your SCOM server!

The first thing I had to to is finding a client which can be controlled by command line or by a SDK. I stumbled upon the command line plugin for Miranda IM. Miranda IM is an open source mutli-protocol instant messaging client. With it you can integrate multiple protocols with plugins.

Read more…

Eine häufig bemängelte Einschränkung des SCCM 2007 ist es, dass die darin enthaltene Updateverteilung keine Updates automatisch freigeben kann. In größeren Umgebungen ist dies im Allgemeinen auch nicht wünschenswert, da neue Microsoft Updates zuerst getestet und dann erst verteilt werden sollten.

Bei Antivirendefinitionen macht ein solches Vorgehen keinen Sinn. Tests gegen alte und neue Viren oder gegen bestimmte Clients, um False-Positives zu erkennen kann man ein paar Mal machen, sobald Updates mehrfach am Tag kommen ist dies nicht mehr sinnvoll.

Forefront Client Security 2010 integriert sich so tief in den SCCM, dass auch für die Definitionsverteilung der SCCM genutzt werden kann. Hat dieser keine aktuellen Definitionen, so kann der Client auf eine Freigabe (UNC-Pfad), einen WSUS oder Microsoft Updates ausweichen. Als WSUS wird natürlich der auf dem Client hinterlegte verwendet, der bei einem SCCM Client immer der vom Server gemanagte WSUS sein muss.

Daher wäre es wünschenswert, wenn dieser die Definitionsupdates automatisch freigibt. Generell ist es nicht empfehlenswert in einen vom SCCM verwalteten WSUS einzugreifen. In diesem Szenario ist es die einzige sinnvolle Lösung.

Um das (von mir ebenfalls schon umgesetzte) Verfahren nicht erneut beschreiben zu müssen, verlinke ich einfach auf den nachfolgenden Blog Post:

Approve updates for Forefront Endpoint Protection 2010

Neue Management Packs im Zeitraum zwischen 01.05.2011 und 31.05.2011

Aktualisiert wurde das SQL Server Management Pack mit:

SQL Server Management Pack version 6.1.400.00 includes the following changes:

• Documented association of Run As profiles and targets for account mapping.
• Made minor fixes in string resources.
• Made security improvements.

Hier die direkten Downloadlinks: (Die Word-Dokumente mit den Beschreibungen sind ganz am Ende der Liste)

Read more…

Sometimes the acs forwarder doesn’t connects successfully to the acs server and states in the operations manager event log, that you have to activate debugging to see more details.

You can activate it by following this instruction:

1. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AdtAgent\Parameters
2. Create DWORD value = TraceFlags
3. Edit the TraceFlags entry and enter decimal value 524420
4. Restart the AdtAgent service

(Source: http://helpmemanage.blogspot.com/2007/05/enable-detailed-logging-for-acs.html)

You can find the log under c:\windows\temp

One cause can be that the acs cannot operate over forest borders or from a workgroup (kerberos authentication – some reason for the scom agent).

The workaround is a little bit mor complicated that a simple certificate exchange.

A good and working explanation can be found here:

http://www.directtechnology.com/BlogEngine/post/2010/08/17/Problems-with-non-trusted-computers-reporting-to-ACS-%28Audit-Collection-Services%29.aspx

Mir begegnen regelmäßig Situationen, in dem im ADDS und Eventlog bestimmte Dinge nachgeschaut werden müssen. Dabei gehen viele direkt ins Eventlog und suchen nach dem Namen des gesperrten Users oder ähnliches. Gerade in größeren Umgebungen ist diese Vorgehensweise sehr ineffizient und auch nicht präzise, da andere Ereignisse die Suchergebnisse beeinträchtigen können.

Daher sollte die Devise sein: Zuerst Zeitpunkt und Ort herausfinden und dann im Eventlog nachschauen.

Solange am Objekt nichts geändert wurde, ist der letzte Änderungszeitpunkt und Ort eigenschaftsgenau kontrollierbar.

Dazu ein kleines Beispiel: Ein Anwender beschwert sich, dass sein Konto ständig gesperrt wird. Er hat vor einigen Stunden sein Kennwort geändert.

Bevor das Konto zurückgesetzt wird, werden noch schnell wichtige Eigenschaften mittels repadmin extrahiert:

repadmin /showobjmeta * "CN=User1,OU=Benutzer,,DC=temp,DC=local" > user.txt

Dabei werden die Metadaten des per DN angegebenen Objektes (CN=…) auf allen Domänenkontrollern (*) ausgelesen und in eine Textdatei gespeichert.

In der Textdatei steht jetzt pro Domänencontroller eine Liste aller Attribute des Objektes und weitere wesentliche Parameter. Für dieses Beispiel relevant ist die LockoutTime:

153243532 Standardname-des-ersten-Standorts\dc1   1100175 2010-11-23 11:11:11   37 lockoutTime

Dieser Eintrag zeigt deutlich, dass das Attribut lockoutTime (also wann das Konto gesperrt wurde) auf dem Domänencontroller dc1 um 11:11 geändert wurde.

Somit kann man direkt diese Daten nutzen und ins Securitylog vom dc1 um 11:11 schauen.

Ereignistyp:    Fehlerüberw.

Ereignisquelle: Security

Ereigniskategorie:      (9)

Ereigniskennung:        675

Datum:          23.11.2010

Zeit:           11:11:11

Benutzer:               NT-AUTORITÄT\SYSTEM

Computer:       dc1

Beschreibung:

Fehlgeschlagene Vorbestätigung:

         Benutzername:   user1

         Benutzerkennung:                TEMP\user1

         Dienstname:     krbtgt/TEMP.LOCAL

         Vorauthentifizierungstyp:       0×2

         Fehlercode:     0×18

         Clientadresse:  192.2.0.10

Die Sperrung ging als vom Client 192.2.0.10 aus. Eine Rückfrage beim User ergibt direkt, dass er das Kennwort an einem anderen Client geändert hat, aber an dem oben angegebenen Client schon länger angemeldet ist.

Aufwand: 5 Minuten. Wilde Sucherei: Minimal. Präzision: Hoch

Interessant: Windows kann bereits das Eventlog automatisch in eine Datei sichern und danach löschen. Gerade auf Rechnern, auf denen keine Events verloren gehen sollen, ist das eine bessere Lösung als ein automatisches Herunterfahren bei einem vollen Security Log.

Hier die Erklärung wie man es einstellen muss: Support Seite (unter More Information).

So sieht es aus, wenn Windows ein Log abgeschnitten hat:

Ich habe gerade einen interessanten KB Artikel bei VMWare gefunden: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009852

Darin wird ein Update vorgestellt, dass eine Sicherheitslücke schließt, die es ermöglicht aus einer Virtuellen Maschine (VM) Code auf dem Host System (in diesem Fall ESX 3.5) auszuführen. Leider stehen auch im CVE Eintrag keine Details.

Viele Virtualisierungsgegner haben immer genau davor gewarnt. Aber es hieß immer, dass VMWare ESX so sicher ist, dass so was nicht vorkommen kann.  Der Artikel zeigt jetzt etwas anderes. Wie riskant die Lücke ist, kann ich nicht einschätzen. Aber allein die Existenz ist natürlich Wasser auf die Mühlen der Virtualisierungsskeptiker.

Um schnell ein Zertifikat eines ADDS Servers zu überprüfen, bietet sich überraschender Weise ein Webbrowser wie der Firefox auf. Trägt man dort in der Adressleiste https://dns-name-des-domänencontrollers:636 ein. Beim Aufruf erscheint unten links das bekannte SSL-Schloss, dass man zur genaueren Inspektion nutzen kann.

Aber: Neuere Firefoxversionen verhindern https Verbindungen auf ungewöhnlichen Ports. Daher muss hier eine Ausnahme für ldaps eingetragen werden:
Um in die erweiterten Einstellungen des Firefoxes zu gelangen muss man in die Adressleiste about:config eingeben. Dort als zusätzlichen Eintrag network.security.ports.banned.override hinzufügen und als Wert den Port 636 hinterlegen (weitere Ports kann man durch Komma getrennt eingeben):

Details s.a. http://kb.mozillazine.org/Network.security.ports.banned.override