Möchte man die lokale Revision eines Git Repositories ermitteln so reicht es in der Konsole:
git log -n 1
einzugeben. Das ganze sieht auf dem Terminal dann so aus:
commit 1c40074d28676ec996ec91f1719cff43077f15f6
Author: Example <>
Date: Tue Jan 3 09:52:23 2013 +0800
Bugfixes in example function.
Soll nur der Hash ausgeben werden so muss die Kommandozeile wie folgt aussehen:
git log -n 1 --pretty=format:"%H"
Damit bekommt man dann nur den entsprechenden Hashwert ausgegeben.
In der Ereignisanzeige im Unterpunkt „Anwendung“ eines Domain Controllers fand sich folgende Warnung:
MS DTC konnte das Höher-/Tieferstufen eines Domänencontrollers nicht ordnungsgemäß verarbeiten. MS DTC funktioniert weiterhin und verwendet die vorhandenen Sicherheitseinstellungen. Fehler: %1 Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Bei mir half in diesem Fall folgende Vorgangsweise. Auf der Konsole wird der Dienst mittels:
msdtc -uninstall
deinstalliert und anschließend der Rechner neu gestartet um den Dienst dann wieder mittels:
msdtc -install
wieder zu installieren. Danach wird der Dienst „Distributed Transaction Coordinator“ über die Eigenschaften konfiguriert. Dabei wird im Tab „Anmelden“ für den Punkt „Anmelden als“ das lokale Systemkonto ausgewählt.
Die Eigenschaften des Distributed Transaction Coordinator Dienstes
Anschließend wird das ganze bestätigt und der Dienst neu gestartet. Nachdem dies passiert ist geht man wieder in die Eigenschaften des Dienstes und stellt die „Anmelden als“ Eigenschaft auf den Nutzer „NT AUTHORITY\NetworkService“ und lässt das Passwortfeld leer. Nach einem weiteren Neustart des Dienstes sollte dieser wieder funktionieren.
Weitere Informationen gibt es unter:
http://www.eventid.net/display-eventid-53258-source-MSDTC-eventno-4493-phase-1.htm
Wenn ein Active Directory aufgesetzt ist, so kann ein Domain Controller bis zu 5 Rollen (FSMO oder auch Betriebsmasterrollen) auf sich vereinen:
Möchte man sich diese Rollen nun anzeigen lassen, so geht das auf der Kommandozeile mittels des Befehles:
netdom query FMSO
Allerdings benötigt man für das „netdom“ Kommando unter „Windows Server 2003“ die „Windows Server 2003 Service Pack 2 32-bit Support Tools“ welche unter http://www.microsoft.com/en-us/download/details.aspx?id=15326 zu finden sind. Diese werden dabei auf einem 64 Bit System unter „C:\Programme (x86)\Support Tools“ installiert.
Wenn man das lokale Passwort für einen Windowsrechner vergessen hat so ist das ärgerlich, kann aber dank ntpasswd sehr schnell behoben werden. Schwieriger wird es wenn man das administrative Passwort in einer Windows Domäne verlegt hat. Hier kommt man mit „ntpasswd“ nicht sehr weit, auch die Windows Bordmittel helfen im ersten Moment nicht. Allerdings gibt es natürlich auch hier Mittel und Wege, in diesem Beispiel anhand des Windows Server 2003 beschrieben.
Im ersten Schritt sollte das Passwort für die „Verzeichnisdienstwiederherstellung“ auf eine leere Zeichenkette gesetzt werden. Dies geschieht mittels „ntpasswd“. Dort leert man einfach das Passwort für den Nutzer „Administrator“. Nachdem dies erledigt ist drückt man beim Start von Windows im richtigen Moment die F8 Taste damit die erweiterten Windows-Startoptionen geöffnet werden. Dort wird der Punkt „Verzeichnisdienstwiederherstellung (Windows-Domänencontroller)“ ausgewählt. Das Windows wird damit im abgesicherten Modus gestartet. Der Login lautet dabei „Administrator“ verbunden mit einem leeren Passwort.
Für den nächsten Schritt benötigt man die „Windows Server 2003 Resource Kit Tools“ welche unter http://www.microsoft.com/en-us/download/details.aspx?id=17657 heruntergeladen werden können. Den Installer sollte man unter Umständen mit einem Packprogramm seiner Wahl (z.B. 7-Zip) entpacken, so das man die enthaltenen Dateien zur Verfügung hat. Bei entsprechender Serverkonfiguration kann es nämlich passieren, das der Installer als solches nicht auf dem Domaincontroller ausgeführt werden darf.
Aus dem „Windows Server 2003 Resource Kit Tools“ werden die Dateien „instsrv.exe“ und „srvany.exe“ benötigt. Diese kopiert man sich in ein Verzeichnis seiner Wahl z.B. nach „C:\Temp“. Danach öffnet man die Kommandozeile, wechselt in den Ordner und gibt dort folgendes ein:
instsrv tmpService "C:\Temp\srvany.exe"
Im nächsten Schritt müssen die Parameter des Dienstes „tmpService“ in die Registry eingetragen werden. Dazu wird der Registrierungseditor mittels „regedit“ gestartet“ und dort der Schlüssel (bzw. der Ordner):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmpService
gesucht. In diesem wird ein neuer Schlüssel mit dem Namen „Parameters“ angelegt und in diesem werden folgende Zeichenfolgen angelegt:
Application -> C:\Windows\System32\cmd.exe AppParameters -> /k net user Administrator neuesPasswort /domain
In der „Systemsteuerung“ sollte danach in der „Verwaltung“ das Fenster „Dienste“ geöffnet werden und dort nach dem Dienst „tmpService“ gesucht werden. In den Eigenschaften wird als Starttyp „Automatisch“ sowie unter „Anmelden“ der Haken bei „Datenaustausch zwischen Dienst und Desktop zulassen“ aktiviert. Nachdem der Dialog bestätigt wurde kann der Rechner neugestartet werden.
Beim Neustart wird das Passwort nun auf „neuesPasswort“ gesetzt und es ist möglich sich mit diesem einzuloggen. Nun muss der entsprechende Dienst wieder deaktiviert und entfernt werden. Dazu gibt man in der Kommandozeile folgendes ein:
net stop tmpService sc delete tmpService
Als letzter Schritt müssen nur noch die kopierten Dateien gelöscht werden. Das Passwort des Domaincontrollers wurde damit zurückgesetzt.
Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/Domain_Controller
Vor einigen Tagen kam die Version 2.0 der Anwendung Outbank heraus. Dabei handelt es sich um eine Banking Software für Mac OS X und iOS. Allerdings hatte sich in die Version ein schwerer Fehler eingeschlichen. So wurde das Passwort welches zu lokalen Verschlüsselung der Daten benutzt wird, im Klartext in die „system.log“ geschrieben, was dann im Beispiel so aussieht:
Jan 17 09:17:03 delphi.localdomain OutBank[537]: Open Store:Core Data key:123456->abcdefghijklmnopqrstuvwxyzABCDEF
Neben diesem Problemen hatte die erste Version dank iCloud Synchronisierung auch mit Problemen wie doppelten Umsätzen und ähnlichem zu kämpfen. Problematisch an dem Fehler im Log ist auch das Mac OS X von Zeit zu Zeit das ganze archiviert und es so dazu kommen kann, das dieses Passwort an mehreren Stellen zu finden ist. Das gleiche trifft auch auf die Kombination mit Backupsystemen wie Time Machine zu. Um nach dem Update auf Outbank die entsprechenden Logeinträge zu entfernen wird von „stoeger it“ folgende Zeile empfohlen welche man im Terminal ausführen sollte:
sudo -i -- 'cd /var/log && grep -vE "OutBank\[" system.log > system.log.clean && mv system.log.clean system.log && if [[ -f system.log.0.bz2 ]]; then for a in system.log.*.bz2; do bunzip2 $a && grep -vE "OutBank\[" ${a%.*} > ${a%.*}.clean && mv ${a%.*}.clean ${a%.*} && bzip2 ${a%.*} ; done; fi; rm -f /var/log/asl/*.asl'
Witzig sind in diesem Zusammenhang Aussagen von Tobias Stöger aus der Zeitschrift SFT (Spiele | Filme | Technik) wo er auf die Frage ob Outbank sicher ist unter anderem wie folgt antwortet:
Der Artikel bezog sich mal wieder auf das unsichere Android-OS. […] Hinzu kommen noch unsere Sicherheitsmaßnahmen, wie automatische Passwortsperre oder verschlüsselte Datenbank.
Das war dann wohl ein Fall von pauschaler Aussage zum falschen Zeitpunkt. Natürlich stellt sich die Frage warum (wenn auch nur für Debugzwecke) Passwörter überhaupt im Klartext gespeichert werden. Auch war keine Auskunft zu erhalten ob die neue Version von Outbank die Bereinigung der Dateien selber vornimmt. Zur Sicherheit sollte man dies also auf alle Fälle manuell nachholen und anschließend das entsprechende Passwort ändern.
Weitere Informationen gibt es unter:
http://www.outbank.de/outbank-os-x-mac-sicherheitshinweis-zu-version-2-0-0/
http://www.heise.de/mac-and-i/meldung/Outbank-2-mit-Passwort-Leck-1786837.html