Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

3. Dezember 2006 um 13:25

RunAs: gleiches Recht für alle

Wenn man unter Windows keine Administrator-Rechte hat, dann passiert es immer wieder, dass man etwas nicht tun darf. Die Meldungen sind unterschiedlich, die Ursache immer gleich: nicht genug Rechte. Anstelle jetzt seinen Account gleich zum Admin zu machen, kann man auch einfach die betreffende Aufgabe unter dem Benutzer des Administrators ausführen lassen.

RunAs

Dazu gibt es verschiedene Alternativen. Als Kommandozeilen-Freak nutze ich am liebsten das Werkzeug RUNAS. Will ich beispielsweise eine DOS-Bos mit Admin-Rechten geht das so:

E:\temp>runas /user:Administrator "cmd.exe"
Geben Sie das Kennwort für "Administrator" ein:
Es wird versucht, cmd.exe als Benutzer "MYBIGPC\Administrator" zu starten…

In der neuen Dos-Box kann ich dann alles tun, was Admins halt so tun.

CACLS

Beispielsweise kann ich mit dem Kommandozeilen-Werkzeug CACLS Rechte vergeben oder entziehen. Will ich der Gruppe der Benutzer und damit allen Mitgliedern Vollzugriff ("F") auf das Dokumentenverzeichnis geben, geht das beispielsweise so:

cacls d:\Daten\Dokumente /E /T /G VORDEFINIERT\Benutzer:F

Die Option "/E" bewirkt, dass die vorhanden Rechte nicht gestrichen und durch das neue ersetzt werden. Statt dessen wird das neue Recht nur ergänzt.
"/T" lässt auch alle Unterverzeichnisse und Dateien bearbeiten.

Tipp: Das Werkzeug Subinacl ist deutlich eleganter, muss aber bei Microsoft runtergeladen werden.

MachMichAdmin

Ein sehr guter Artikel mit viel mehr Tipps zu dem Thema findet sich bei Heide.de unter dem Titel "Heute ein Admin". Man kann ihn dort für 50Cent kaufen.

Darin wird das Werkzeug MachMichAdmin beschrieben mit dem man bestimmte Programme sehr komfortabel mit Admin-Rechten ausstatten kann, obwohl sie unter dem eigenen Benutzer ausgeführt werden.

Die Tools stehen als kostenloser Download bei Heise, die lesenswerte FAQ ist ebenfalls kostenlos.

1. Dezember 2006 um 20:03

Harte Links

Heute hatte ich wieder das Problem, dass ich unter zwei verschiedenen Pfaden die gleiche Ausgabe einer Datei benötigte. Es ging um die INI-Datei von zwei Instanzen des gleichen Programmes. Als ich schon fast den Copy-Batch fertig hatte, um die eine Datei immer wieder über die andere zu kopieren, damit ich die Änderungen nicht doppelt pflegen muss, fiel mir eine bessere Alternative ein:

Hardlinks anlegen

Wenn man NTFS als Dateisystem einsetzt, dann kann man sogenannte Hardlinks anlegen. Das bedeutet, dass man auf die gleiche Datei einen echten Link legt. Man kann dann unter dem Pfad des Links und dem originalen Pfad auf die Datei zugreifen. Die Programme merken gar nicht, ob das ein Hardlink ist oder das Original, weil einfach ein echter Eintrag im Verzeichnis angelegt wurde.
Hier die Syntax:
fsutil hardlink create <neuer Dateinname> <vorhandener Dateiname>

Hier ein Beispiel:
Angenommen es existiert die Datei "E:\temp\dir1\MyOriginal.ini" und ich will auf die gleiche Datei auch unter dem Pfad "E:\temp\dir2\MyCopy.ini" zugreifen, dann kann man den Hardlink so anlegen:

C:\>fsutil hardlink create E:\temp\dir2\MyCopy.ini E:\temp\dir1\MyOriginal.ini
Hardlink erstellt für E:\temp\dir2\MyCopy.ini <<===>> E:\temp\dir1\MyOriginal.ini

Wenn man eher visuell orientiert ist, dann kann man natürlich auch Shell-Utilities verwenden. Ich habe von denen aber noch keines ausprobiert.

Hardlinks entfernen

Wenn man Hardlinks entfernen will, dann löscht man sie einfach, als seien sie Dateien. Dabei wird aber nur der Eintrag aus dem Verzeichnis gelöscht. Erst mit dem letzten Verweis wird auch die Datei gelöscht. Das gilt auch, wenn man das ursprüngliche Original zuerst löscht. Die "Kopie" bleibt erhalten.

Beispiel: lösche zuerst die ursprüngliche Datei und sehe trotzdem noch den Hardlink:

E:\temp>dir /B dir1
MyOriginal.ini

E:\temp>del dir1\MyOriginal.ini

E:\temp>dir /B dir2
MyCopy.ini

Erst wenn ich auch den letzten Verweis auf die Datei lösche, dann ist sie weg:

E:\temp>del dir2\MyCopy.ini

E:\temp>dir /B dir2

Hinweis: Hardlinks können leider nur auf Dateien in der gleichen Partition verweisen. Das gilt auch für Junction-Points…

Junction-Points (Abzweigungspunkte)

Leider geht das mit Verzeichnissen nicht. Hier bietet NTFS Junction-Points (Abzweigungspunkte) an. Sie arbeiten intern aber leider anders. Es werden wieder echte Links gelegt. Von Verzeichnis A nach Verzeichnis B. Unter B sehe ich also genau die Dateien, die unter A stehen. Deswegen die Warnung vorab: Wenn ich also eine Datei aus B lösche, dann ist sie auch aus A gelöscht.

Dazu benötigt man das Tool LinkD aus dem Windows Server Ressource Kit. So sieht die Syntax aus:

LINKD <Link-Verzeichnis> <originales Verzeichnis>

Beispiel:

E:\temp>dir /B dir1
file1.txt
file2.txt

E:\temp>linkd linkdir dir1
Link created at: linkdir

E:\temp>dir /B linkdir
file1.txt
file2.txt

Aber Vorsicht: Es ist in beiden Fällen jetzt das gleiche Verzeichnis.

E:\temp>dir /B dir1
file1.txt
file2.txt

E:\temp>del linkdir\file1.txt

E:\temp>dir /B dir1
file2.txt

Wenn man den Junction-Point wieder los sein will, dann geht das so:

E:\temp>linkd linkdir /D
The delete operation succeeded.

Das originale Verzeichnis ist dann mit samt Inhalt noch da.

Die Wikipedia listet ein paar Risiken und Nebenwirkungen, die interessant sind. Microsoft stellt auch ein paar weiterführende Infos bereit.

Und wie geht es weiter?

Diese netten Features wurden offenbar unter Vista aufgewertet. Wissenswertes dazu hat Daniel Melanchthon zusammengestellt.

29. November 2006 um 20:35

Mein erster Trojaner

Na prima, da habe ich doch meinen ersten Trojaner entdeckt. Leider habe ich keine Ahnung wie er auf mein System kam. Da ich in letzter Zeit mit ziemlich vielen Programmen rumexperimentiert habe, ist das nicht so genau zu sagen. Vielleicht sollte ich mir mal die "Software Virtualization Solution" von Altiris ansehen, um Software in einer virtualisierten Umgebung zu testen ohne gleich jedesmal eine VM-Ware zu starten.

Gemeinerweise fand ihn mein Virenscanner nicht, auch auf der Virenscanseite von jotti.org erkannte ihn keiner der 15 als Schädling. Lediglich NOD32 merkte aufgrund der heuristichen Analyse an, dass dies möglicherweise ein Schädling sei.

Immerhin hat McAfee aufgrund meiner Einsendung gleich regiert. Im ersten Durchlauf schrieben die AVERT(tm) Labs, Aylesbury, UK bereits am gleichen Tag:

We have examined the file and didn't see anything suspicious. As an additional test, we tried to run it on a test system and observed no
suspicious behaviour.

If you still believe this is a virus or trojan file, please provide more
information on why you feel this is a suspect file.

Es ging um die Datei "C:\WINDOWS\system32\clipboard.exe". Sie behauptete von sich von Microsoft zu stammen, hatte aber eine ziemlich MS-untypische Versionsnummer, gehörte angeblich zu Windows 2000 (ich habe XP) und sei in "China (VR)" hergestellt worden.
Außerdem lief der Prozess permanent und hatte sich in der Registry eingetragen:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"clipboard.exe"="C:\\WINDOWS\\system32\\clipboard.exe"

Nach dem Anmelden startete ein Browserfenster und leitete mich auf eine mir unbekannte Webseite (irgendwas unter www.coolsheep.com, aber die Seite konnte wegen eines JS-Fehlers nicht dargestellt werden). Nach dem Austragen aus dem AutoRun war das Verhalten weg.

Nachdem ich Avert das geschrieben hatte, wurde die Datei als "Generic Backdoor.b" klassifiziert und mir eine neue Signaturdatei zur Verfügung gestellt, die den Schädling einwandfrei identifizierte und löschte. Sie kommt mit dem nächsten Update an alle Kunden. Offenbar hatte ich Glück, weil kein weiterer Schaden entstand…

Auf die Schliche kam ich dem Fießling übrigens mit der Werkzeug HijackThis.

28. November 2006 um 01:49

Prioritäten setzen

In win-insight.de wird beschrieben, wie man laufenden Prozessen eine höhere oder niedrigere Priorität geben kann. Das ist schon nicht schlecht, aber ziemlich unpraktisch, wenn man erst die Anwendung starten muss, dann in den Task-Manager wechseln muss, usw.

Man kann auch beim Start einer Anwendung festlegen, dass die Anwendung eine andere als die Priorität "normal" haben soll. Wenn man dem SQL-Management-Studio zu mehr Saft verhelfen will, dann startet man es einfach so:

start "Fenstertitel" /high "C:\Programme\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"

oder wenn man den Virenscan im Hintergrund mit niedriger Priorität laufen lassen will, dann geht das mit McAfee zum Bleistift so:

start "Virenscan" /low "C:\Programme\Network Associates\VirusScan\scan32.exe" /NoSplash /AutoScan

Tipp: Wenn man die Anwendung über eine Verknüpfung startet, dann in die Eigenschaften dieser Verknüpfung gehen (rechte Maustaste -> Eigenschaften) und dort bei "Ziel" vor den eigentlichen Eintrag einfach Folgendes setzen:

start "xy" /low

PS: Bitte daran denken, dass man keinem Prozess die Priorität "REALTIME" gebe sollte, wenn man nicht ganz genau weiß was man tut. Damit hat man ratzfatz das System lahmgelegt.

23. November 2006 um 21:47

Microsoft Netmon 3.0 freigegeben

Im NetMon-Blog kann man es nachlesen: Der neue NetMon 3.0 wurde freigegeben. Er wartet mit einer Reihe von Features auf, die wirklich interessant klingen:

  • A completely new user interface
  • Real time capture and display of frames
  • Simultaneous capture on multiple network adapters
  • Multiple simultaneous capture sessions
  • Network conversations and a tree view displaying frames by conversation
  • A new script-based protocol parser language, and script-based parsers
  • Support for Vista/Windows XP/Windows Server 2003
  • Support for 32bit and 64bit platforms

Das klingt schon mal vielversprechend.

Den Download bietet Microsoft nur auf der Seite connect.microsoft.com an. Man benötigt einen Life- oder Passport-Account. Sogar für die finale Version muss man sich derzeit noch für das Beta-Programm anmelden…. 😐

15. November 2006 um 15:28

Windows PowerShell 1.0

So, jetzt ist es tatsächlich so weit, die "Windows PowerShell 1.0" ist freigegeben…

Und hier gibt es Infos zum Download: How to Download Windows PowerShell 1.0

Endlich mal eine richtige Shell unter Windows. Das war echt das was mir seit WinNT schon gefehlt hat…

gefunden beim PowerShell-Blog

8. November 2006 um 12:17

Process Monitor v1.0

Es gibt Neuigkeiten von Sysinternals. Nach dem Kauf durch MS hatte ich nicht ernsthaft mit neuen Tools gerechnet. So kann man sich täuschen…
In der TechnNet gibt es jetzt sogar einen eigenen Bereich "Sysinternals"!

Dort steht seit zwei Tagen das neue Killer-Tool für alle Windows-Entwickler:

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon, and adds an extensive list of enhancements including rich and non-destructive filtering, comprehensive event properties such session IDs and user names, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and much more.

Hier gibt mehr Infos zum Process Monitor und den Download .

gefunden bei heise.de

16. Juli 2006 um 19:44

Abläufe automatisieren

Gestern las ich im TecChannel Kompakt 02/2006 im Artikel "Windows Server Automaten" zwei gute Tipps, die ich bei Gelegenheit mal ausprobieren will:

eventtriggers.exe

Mit dem Tools EventTriggers (seit Windows XP im System enthalten) kann man einer Event-ID ein Programm zuweisen, das kann ein EXE, WSH oder CMD sein. Dann wird die eingetragene Aktion automatisch beim Protokollieren eines bestimmten Events in der Ereignisanzeige ausgeführt. Dabei kann man auch Filter angeben, die vor der Ausführung geprüft werden.

Beispiele siehe TecChannel.

SendMail

Um E-Mails per Commandozeile zu senden habe ich mir mal ein kleines Progrämmchen geschrieben, aber laut TecChannel geht es auch mit Windows-Scripting. Da hier aber nirgends ein Benutzer und Passwort zur Anmeldung am Mail-Server angegeben werden, nehme ich an, dass der Windows-Benutzer hergenommen wird. Das kann eigentlich nur klappen, wenn der Batch in einem Benutzerkontext ausgeführt wird. Nicht hingegen in Kombination mit obigen Events. Damit sich jeder selber eine Meinung bilden kann, gebe ich den Tipp weiter.

Aber natürlich nicht ohne eine Fallback-Strategie vorzuschlagen: Ein Kollege empfahl neulich mal Kunden den Einsatz von BLAT, um aus einem Batch heraus E-Mails zu versenden. Bei ihm hat es gut gekappt. Hat jemand schon Erfahrungen damit?

16. Juli 2006 um 01:08

Nützliche Einblicke ins Innere von Windows mit WMIC

Meine aktuellen Versuche mit WMIC wurden durch die neue ct (Ausgabe 15/2006, Softlink 0615204) angestoßen. Wer irgendwie die Chance hat den Artikel im Original zu lesen, sollte das tun, wirklich gut. Die Beispiele sind deswegen auch daraus…

Mit folgendem Befehl kann man sich alle Programme anzeigen lassen, die beim Start (alle, d.h. Autostart, Run, RunOnce, …) ausgeführt werden:
[code]wmic /output:startup.htm STARTUP list /format:htable
startup.htm
del startup.htm[/code]

Dieser Befehl kopiert die Liste der installierten Programme ins Clipboard:

[code]wmic /output:Clipboard PRODUCT list[/code]

Der hier gibt die Liste aller Drucker in der DOS-Box aus:

[code]wmic Printer get Caption[/code]

Und hiermit wird die Prozessliste sortiert in eine HTML-Datei geschrieben und angezeigt:

[code]wmic /output:process.htm Process get Caption, ProcessId, CommandLine /format:htable:"sortby=ProcessId":"datatype=number":"title=Prozessliste: "
process.htm
del process.htm[/code]

Und das ist nur die Spitze des Eisberges. Eine Liste der Möglichkeiten bekommt man mit

[code]wmic /?[/code]

PS: Habe ich schon erwähnt, dass man zur Ausführung der WMIC Admin-Rechte benötigt? Sonst kommt eine komische Fehlermeldung… 😉

15. Juli 2006 um 09:28

Tipp, wenn WMIC nicht klappt

Ich bin gerade dabei die Tiefen von WMI mittels wmic.exe zu erforschen. Dabei klappte es bei mir einfach nicht:
[code] wmic /output:startup.htm STARTUP list /format:htable [/code]

Das lieferte beim ersten Aufruf folgende Meldung:

[code]Warten Sie, während WMIC installiert wird.
MOF-Datei wird verarbeitet: C:\WINDOWS\system32\wbem\Cli.mof(Phasenfehler – 3)
Kompilierer hat folgenden Fehler zurückgegeben: 0x80041001[/code]

Und beim zweiten Mal:

[code]Please wait while WMIC compiles updated MOF files.
MOF-Datei wird verarbeitet: C:\WINDOWS\system32\wbem\Cli.mof(Phasenfehler – 3)
Kompilierer hat folgenden Fehler zurückgegeben: 0x80041001[/code]

Ich habe daraufhin viele nützliche Links gefunden, die mir aber letztlich nicht weiterhalfen. Aber zwei die wirklich viele gute Informationen enthalten, gebe ich mal weiter:

Die echte Ursache war natürlich trivial: es fehlten einfach die Rechte. Ich hatte vergessen, dass ich mir neulich aus Sicherheitsgründen selber die Adminrechte entzogen habe…

Kaum führte ich den Befehl als Admin aus, schon klappte es:

[code] runas /user:Administrator "wmic /output:startup.htm STARTUP list /format:htable"[/code]

14. Juli 2006 um 15:56

Daten aus völlig defekten Datenbankdateien lesen

Die Serie in der ich berichten welche Ursachen erfahrungsgemäß hinter Datenbank-Defekten stecken, hat mich darauf gebracht vielleicht auch ein paar Werkzeuge oder Vorgehensweisen zu beschrieben. Immerhin ist es manchmal nicht ganz einfach den SQL Server 2000 überhaupt dazu zu bringen eine korrupte Datenbank zu akzeptieren.
Recovery for SQL Server
Wenn uns Kunden eine defekte Datenbank schicken, dann können wir relativ häufig doch noch eine ganze Menge an Daten aus den Dateien rausholen, selbst wenn der SQL Server sich weigert die Dateien auch nur als Datenbank-Dateien zu erkennen.
Leider bietet MS dazu keine Unterstützung, eine echte Lücke in die eine estländische Firma gesprungen ist.
Mit dem Werkzeug Recovery for SQL Server haben wir schon aus so mancher Kunden-Datenbank wieder etwas rausholen können. Natürlich fehlen dann die Daten aus den defekten Seiten und die Daten sind nicht mehr in sich konsistent. Sprich: Es erfordert noch eine gründliche Portion Nacharbeit, um die Daten wieder in einen halbwegs sauberen Stand zu bringen.

Nun könnte man sich auf den Standpunkt stellen: "Keine Datensicherung – selbst schuld." Wenn man bedenkt, dass die meisten unserer Kunden bei einem Totalverlust der Daten vor dem wirtschaftlichen Ruin stehen, dann versteht man warum wir das tun…. 🙂

13. Juli 2006 um 20:36

Dienst startet automatisch

Es passiert ja zum Glück selten, aber ab und an erleben wir, dass der SQL Server sich bei Kunden aus dem Tritt bringen lässt und sich einfach verabschiedet.
Dann gibt es zwei Dinge zu tun: erstens den SQL-Server-Dienst schnellstens neu starten und zweitens die Ursache finden.

Da ein Admin normalerweise auch bloß 9 von 24 Stunden an 5 von 7 Tagen im Büro ist, der Chef aber auch mal spät abends oder am Wochenende drin ist, sind die Chancen groß, dass es dann passiert wenn der Admin gerade sonstwo ist. Hier hilft ein ganz nettes Feature des Dienstemanagers: Er kann den Dienst sofort wieder starten oder erst nach 1 oder 2 oder 3 … Minuten:

Dienstemanager

Wenn es wieder passiert, dann kann man sich auch lieber eine Mail schicken lassen oder ein anderes Programm aufrufen. Das finde ich echt nützich.