Archive for the ‘Windows XP’ Category

QoS in IP-Netzwerken testen

1 April 2017

QoS also Quality of Service soll dabei helfen Datenpakete zu priorisieren damit z. B. ein VoIP-Telefonat reibungslos läuft. Nur leider hat die Sache wie immer einen Haken.

Man muss im Zusammenhang mit QoS in IP-Netzten aktuell RSVP (IntServ) und ToS (DiffServ) unterscheiden. https://de.wikipedia.org/wiki/Quality_of_Service#Realisierung_in_IP-Netzen. Wann immer man über RSVP liest kann man es eigentlich gleich abhaken, denn es hat sich nicht durchgesetzt und wurde einer breiten Basis mit der Aufgabe von Windows XP beraubt. Dieser Artikel geht zum Beispiel auf den Ping.EXE –v Parameter ein und welche Änderungen bei Windows Vista bzw. Windows 7 gekommen sind: http://htluo.blogspot.de/2016/05/qos-test-tool-on-windows-7-or-above.html. Ich möchte noch auf diesen Artikel verweisen wo beim Server 2012 von RSVP in Verbindung mit QWave die Rede ist: https://technet.microsoft.com/de-de/library/hh831592(v=ws.11).aspx. Aber ich gehe davon aus, dass dies ein Versehen ist oder MS?

Windows, auch ein aktuelles Windows 10 ist also ein Totalreinfall in Sachen QoS-Tests. Zum Glück gibt es Linux, dort kann man fast mit Bordmitteln einen Endpunkt auf QoS Unterstützung testen.

Man benötigt also ein Ubuntu oder Debian System, dort hat der Ping-Befehl den Parameter –Q. Mit diesem kann man die TOS-Angabe übergeben. Ein Mapping zwischen DSCP und TOS-Werten ist hier zu finden: https://www.tucny.com/Home/dscp-tos. Hier wird auch gleich noch auf ein paar Besonderheiten eingegangen. Die gängigsten Werte sind 104 (DSCP 26) für SIP und 184 (DSCP 46) für RTP.

Nun zur praktischen Anwendung. So prüft man z. B. sipgate, genauso gut könnte man auch eine Fritzbox mittels fritz.box testen:

ping proxy.live.sipgate.de –Q 184

Man bekommt ganz normal Ping-Pakete zurück. Wie kann man nun aber nachvollziehen, ob die Gegenseite tatsächlich QoS unterstützt?

Man macht in einem zweiten Terminalfenster eine Abfrage mittels TCPDump. Gegebenenfalls muss man TCPDump noch mittels apt-get installieren.

tcpdump –i eth0 –v ip[1]==184 and icmp[0]==0

Wenn nun Antwortpakete von der Gegenseite kommen, werden diese hier angezeigt. Sobald hier etwas angezeigt wird, passt es. Wird nichts angezeigt hat man ein Problem.

Bei Problemen sollte man zuerst schauen, ob die ICMP-Requests auch rausgehen:

tcpdump –i eth0 –v ip[1]==184 and icmp[0]==8

Es sollte tos mit 0x8b was 184 Dezimal entspricht angezeigt werden.

Wenn man mehr Infos haben möchte, kann man noch TShark oder Wireshark bemühen. Wie man damit umgeht zeigt dieser Artikel sehr schön: http://conceptsfortheroad.com/2016/01/01/using-linux-to-verify-dscp/.

Bilder unter Windows gezielt mit der Windows Fotoanzeige öffnen

30 August 2015

Eine Variante die unter Windows XP – Windows 10 immer verfügbar ist, solange es um übliche Dateiformate wie PNG, BMP, TIFF oder JPG handelt ist die Windows Fotoanzeige. Hier der passende Aufruf:

RunDLL32 "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll",ImageViewer_Fullscreen C:\temp\test.bmp

Dabei muss der Bilddateiname immer als absoluter Pfad angegeben werden!

Leider kennen die Server Versionen von Windows den Photoviewer nicht.

http://www.autohotkey.com/board/topic/51203-run-rundllexe-photoviewerdll-syntax/

Passwörter ändern bei Remote-Desktop bzw. Terminalserversitzungen von Windows XP bis Windows 10

20 Juli 2015

Ein harmloses Thema aber dank der Genialität von Microsoft ein Thema, welches schnell ausarten kann. Zunächst einmal die Ausgangsbasis. Es geht darum den Windows Sicherheitsschirm zu bekommen, dass ist der, wenn man an einem physikalischen Rechner sitzt und STRG+ALT+ENTF drückt. Dort werden meistens diese Punkte angezeigt:

  • Computer sperren
  • Benutzer wechseln
  • Abmelden
  • Kennwort ändern
  • Task Manager starten

Jetzt das Problem: Bei einer Remotedesktopsitzung wird STRG+ALT+ENTF immer auf dem lokalen, also physikalischen Rechner ausgeführt und nicht in der Remotesitzung. Ergo kann der Benutzer sein Kennwort nicht selbständig ändern.

Zu Windows XP und Windows 7 Zeiten konnte man nun im normalen Startmenü in der rechten Spalte auf “Windows Sicherheit” klicken. Dieser Eintrag ist immer automatisch verfügbar sobald man sich in einer Remotedesktopsitzung befindet. Aber durch das verschwinden des Startmenü bei Windows 8 verschwand auch der Eintrag mit “Windows Sicherheit”. Selbst die ganzen nachfolgenden Updates zu Windows 8 mit Windows 8.1 Update Update usw. brachten keine Lösung. Auch Windows 10 mit Build 10240 kennt dazu keinen direkten Startmenüeintrag mehr.

Hier nun die möglichen Lösungen:

Variante 1)
Die einfachste Variante man drückt anstatt STRG+ALT+ENTF die Tastenkombination STRG+ALT+ENDE, also anstatt der Entfernen-Taste die Ende-Taste drücken. In den meisten Fällen sollte dies zum Erfolg führen.

Variante 2)
Alternativ kann man mit der Bildschirmtastatur arbeiten. Dazu ruft man OSK.EXE auf und _wichtig_ drückt auf seiner physikalischen Tastatur STRG+ALT und klickt dann auf dem OSK-Keyboard mit der Maus auf die ENTF-Taste.

Variante 3)
Man verwendet ein kleines Skript, üblicherweise Powershell:

Powershell  -command  "(New-Object -ComObject Shell.Application).WindowsSecurity()"

Damit wird auch der Windows Sicherheitsbildschirm angezeigt. Allerdings funktioniert dieses Skript nur, wenn man sich in einer Remotedesktopsitzung befindet. Im normalen Betrieb aufgerufen passiert einfach nichts.

https://msdn.microsoft.com/en-us/library/windows/desktop/gg537748(v=vs.85).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1

Variante 4)
Seit Windows 8 hat sich ja alles auf die modernen Apps verlagert was bei Tablets auch Sinn macht, denn wer hat schon STRG+ALT-Tasten an seinem Tablet? Deshalb gibt es bei Windows 8 und nachfolgend unter PC-Einstellungen->Konten->Anmeldeoptionen die Möglichkeit sein Kennwort zu ändern. Unter Windows 10 geht man dazu auf Einstellungen->Konten->Anmeldeoptionen.

Eine weitere Variante für Commandliner ab Windows 10 ist der Aufruf von:

start ms-settings:signinoptions

Man kann auch im hypermodernen Edgebrowser in der URL-Zeile direkt ms-settings:signinoptions eingeben und landet dann in der Einstellungsseite. Nur Cortana versteht das noch nicht, irgendwie komisch…

 

So das war der kleine Ausflug in der Geschichte der Passwortänderungen für die Benutzer. Hier noch hilfreiche Links zum Thema:

http://superuser.com/questions/492856/how-can-i-send-a-ctrlaltdelete-through-remote-desktop-in-windows-8

https://social.technet.microsoft.com/forums/windowsserver/en-US/2b67fa96-707b-47c4-90f5-c3a087ba16a9/how-do-i-change-password-when-connected-to-remote-desktop

Hier noch Links zum Thema ms-settings: http://winaero.com/blog/how-to-open-various-settings-pages-directly-in-windows-10/ sowie https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn741261.aspx und wo es herkommt: https://msdn.microsoft.com/en-us/library/windows/apps/jj662937(v=vs.105).aspx

Altes Windows XP aus VHD-Datensicherung wiederbeleben

31 Dezember 2014

Nur als Referenz, falls nochmals notwendig. Kurz die Situation, es gab einen Datenbestand auf den unbedingt zugegriffen werden musste. Allerdings war nur eine VHD-Komplettsicherung eines Windows XPs vorhanden. Man hätte nun zwar die Daten aus der VHD extrahieren können, allerdings lagen die Daten in einer Software vor, welche auf einem neuen Rechner nicht mehr installierbar war. Somit musste das alte XP-System reaktiviert werden. Dazu wurde die XP-Maschine als virtueller Rechner unter einem Hyper-V eingebunden. hier nun kurz die nötigen Schritte:

Diese Lösung setzt voraus, das Windows XP zum Einsatz kommt, nur eine Partition zurückgespielt werden muss und diese kleiner 128GB ist.

o Hyper-VM VM anlegen, falls Auswahl nur Generation 1
o Anlegen einer Partition die nicht größer als 128GB sein darf
o Booten von einer WinPE oder Windows-Start-CD
o Shift-F10 für Eingabeaufforderung
o Einbinden der VHD-Sicherung mittels DISKPART

DISKPART
SELECT VDISK FILE="Vollständige Pfad zu VHD-Datei"
ATTACH

o Einrichten und Formatieren des neuen Laufwerks

SELECT DISK 0
ACTIVE
CREATE PARTITION PRIMARY
FORMAT FS=NTFS QUICK
LIST VOLUME
EXIT

o Kopieren der Daten von VHD-Sicherung zum leeren Laufwerk. Dabei ist zu beachten, welche Laufwerksbuchstaben den Laufwerken bei der Ausgabe von obigem “List Volume” angezeigt werden. In meinen Beispiel war E: das Laufwerk mit der eingehängten VHD-Datei und C: die neue, noch leere Platte. Infos zu den Paramtern von XCOPY: http://support.microsoft.com/kb/323007/de.

XCOPY E:\*.* C:\  /O X /E H /K
BOOTSECT /NT52 C: /MBR

o Damit die Geschichte unter Hyper-V bootbar ist und kein “Inaccessible Bootdevice” Fehler auftritt, muss noch ein IDE-Treiber aktiviert werden. Weitere Infos hier: https://newyear2006.wordpress.com/2009/09/12/computer-bzw-hardware-virtualisieren-p2v-fr-microsoft-hyper-v-server/

REG LOAD HKLM\Temp C:\WINDOWS\SYSTEM32\CONFIG\SYSTEM
REG ADD "HKLM\Temp\ControlSet001\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_7111"
REG ADD "HKLM\Temp\ControlSet001\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_7111" -v Service -t REG_SZ -d intelide 
REG ADD "HKLM\Temp\ControlSet001\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_7111" -v ClassGUID -t REG_SZ -d "{4D36E96A-E325-11CE-BFC1-08002BE10318}"
REG ADD HKLM\Temp\ControlSet001\Services\intelide -v start -t REG_DWORD -d 0

REG UNLOAD HKLM\Temp

Das wars auf die Schnelle. Die Methode funktioniert im Prinzip auch bei Windows Vista, 7,8 usw. Allerdings muss man dort mit /NT60 bei BOOTSECT arbeiten und darauf Rücksicht nehmen, dass mehrere Partitionen vorhanden sind.

SSL/TLS Fehler in Powershell, bzw. wie man Zertifikatsprobleme unter Windows analysieren kann

4 Januar 2014

Beim Herumspielen mit Chocolatey, dazu ein anderes Mal mehr, gab es Probleme auf einem Windows XP-Rechner. Der Windows XP Rechner war für Chocolatey noch nicht vorbereitet, d. h. er hatte zwar .Net 1, 2 und 3.5 bereits aber noch kein .Net Framework 4. Powershell 2 war bereits installiert.

Ausgangslage
Der Aufruf von

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(‚https://chocolatey.org/install.ps1‘))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

für die Installation, führte zu folgender Fehlermeldung:

Exception calling "DownloadString" with "1" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
At line:1 char:47
+ iex ((new-object net.webclient).DownloadString <<<< (‚https://chocolatey.org/
install.ps1′))
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Der entscheidende Punkt ist oben rot markiert. Aber was macht man jetzt? Die Meldung ist leider doch zu allgemein.

Erster Versuch mehr Infos zum Fehler zu bekommen
Powershell kennt das $error Objekt. In diesem ist immer der letzte Fehler enthalten. Aber gleichzeitig sind bestimmte Randbedingungen und tiefergehende Infos zum Fehler abrufbar. Wichtig: Wenn man beim Rumspielen einen neuen Fehler verursacht, dann gehts schnell durcheinander und man untersucht nicht den eigentlichen Fehler, sondern einen nachfolgenden! Also geht man zuerst her und sichert den Fehler:

$myE = $error[0]

Damit kann nun nichts schiefgehen und mittels verschiedenen Abfragen kommt man dann irgendwann dazu:

((($myE).Exception).InnerException).Innerexception
The remote certificate is invalid according to the validation procedure.

Aha, wir haben also ein Zertifikatsproblem.

Prüfung mittels Browser
Aber welches Zertifikat macht nun die Probleme? Wie kann man dies überprüfen? Ein einfacher Versuch ist mittels Browser, in diesem gibt man einfach im aktuellen Fall https://chocolatey.org ein und schaut was passiert. Wer jetzt Chrome benutzt, der ist fein raus und bleibt verdutzt zurück, wer es aber mit dem Internet Explorer probiert, welcher den gleichen Weg einschlägt wie eben Powershell, bekommt diese Meldung:

Es besteht ein Problem mit dem Sicherheitszertifikat der Website.

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.

Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.

Klicken Sie hier, um diese Webseite zu schließen.

Laden dieser Website fortsetzen (nicht empfohlen).

Weitere Informationen

Ja das kennen wir schon. Wenn man aber “Laden dieser Website fortsetzen (nicht empfohlen)” anklickt, bekommt man den bekannten roten Balken des IE mit dem Zertifikatsfehler. Dort kann man nun auf Zertifikatsfehler klicken und sich die Sache etwas genauer anschauen. Blöd nur das, dass es nicht offensichtlich ist, wo das Problem wieder genau liegt. Auf jeden Fall bekommt man raus, dass es sich in diesem Fall um Geotrust-Zertfikate handelt. Übrigens bekommt man diese Info auch von Chrome geliefert, wenn man auf das Schloss in der Adresszeile klickt und das Register Verbindung auswählt. Aber Hallo! Hier wird ein Go Daddy Zertifikat für chocolatey.org genannt! Ja was denn nun? GeoTrust oder Go Daddy? Des Rätsel Lösung nennt sich SNI und wird am Ende aufgelöst.

Tiefergehende Suche mittels Powershell
Wie kann man die Geschichte aber mittels Powershell besser in Griff bekommen? Da zu unterst immer irgendwo eine TCP-Verbindung aufgebaut werden muss, kann nur der direkte Aufruf über TCPClient etwas bringen.

Die einfachste Variante wäre nun:

$host = "chocolatey.org"
$port = 443
$conn = New-Object System.Net.Sockets.TcpClient ($host, $port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream())
$result=$stream.AuthenticateAsClient($host)
$conn.Close()

aber hier kommt nur wieder die Fehlermeldung wie oben bei der doppelten InnerException. Also was tun?

Der Konstruktor von SslStream kennt noch weitere Parameter. Unter anderem den RemoteCertificateValidationCallback Delegaten. http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs.110).aspx. Dieser wird üblicherweise benutzt, um bestimmte Fehlermeldungen in Verbindung mit Zertifikaten zu unterdrücken. Ab Powershell 2.0 ist dies ohne weiteres möglich, wie dieser Artikel hier schön beschreibt: http://www.nivot.org/blog/post/2009/07/18/PowerShell20RCWorking
WithNETCallbacksPart1Synchronous
. Der Callback kennt aber alle relevanten Informationen, so dass man diesen nun so nutzen kann:

$conn = New-Object System.Net.Sockets.TcpClient($host,$port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream(), $null, {
                    Write-Host "Sender: $($args[0])";
                    Write-Host "Certificate: $(($args[1]).gettype())";
                    Write-Host "CertificateChain: $($args[2])";
                    Write-Host "PolicyErrors: $($args[3])"; 
         })
$result = $stream.AuthenticateAsClient($host)
$conn.Close()

nun bekommt man als Ergebnis dies geliefert:

Sender: System.Net.Security.SslStream
Certificate: System.Security.Cryptography.X509Certificates.X509Certificate2
CertificateChain: System.Security.Cryptography.X509Certificates.X509Chain
PolicyErrors: RemoteCertificateNameMismatch

Also genau was auf MSDN als Parameter dokumentiert steht. Vor allem interessant ist nun die Aussage mit RemoteCertificateNameMismatch. Jetzt wird die Sache schon etwas klarer. Sollte chocolatey.org nicht im Zertifikat genannt sein?

Hier nun das Script welches die richtigen Infos ausgibt:

$conn = New-Object system.net.sockets.tcpclient($host, $port)
$stream = New-Object system.net.security.sslstream($conn.getstream(), $null, {
                    Write-Host $args[2].ChainElements[0].Certificate.Subject;
                    Write-Host "PolicyErrors: $($args[3])";
         })
$result = $stream.authenticateasclient("chocolatey.org")
$conn.Close()

Als Ausgabe erhält man:

CN=*.apphb.com, O=AppHarbor Inc, L=San Francisco, S=California, C=US, SERIALNUMBER=MyGg//QgdanmdPPqqfNR5JjsvbrKA/uJ
PolicyErrors: RemoteCertificateNameMismatch

Aha, nun wird es klarer. Wir wollen auf die Seite chocolatey.org bekommen aber ein Zertifikat vom Server für AppHarbor. Findet hier eine Attacke statt? Oh Gott, alle Schotten dicht!

Zusammenfassung
Ich wollte nur mal schnell Chocolatey installieren und bin dann wegen den Sicherheitsanforderungen von Chocolatey bei einer Attacke gelandet, wo mir irgendjemand falsche Zertifikate unterjubeln möchte. Oder ist doch alles ganz anders?

Aufklärung
Die Lösung des Dilemmas lautet SNI “Server Name Indication”. Ein schöner Artikel dazu findet man auf der deutschen Wikipedia unter http://de.wikipedia.org/wiki/Server_Name_Indication. Dort wird im Zusammenhang von SNI darauf hingewiesen, dass Windows XP kein Server Name Indication unterstützt. Warum ist dies wichtig? Weil Powershell mittels der Systembibliotheken von Windows XP seine HTTPS Verbindung aufbauen möchte und ebenso wie der IE8 Probleme bekommt. Hintergrund dafür ist, dass chocolatey.org bei HTTPS-Verbindungen auf SNI angewiesen ist, wie dieser Test zeigt: https://www.ssllabs.com/ssltest/analyze.html?d=chocolatey.org.

Dort ist dann zu lesen:

This site works only in browsers with SNI support.

Dies erklärt nun auch die unterschiedlichen Zertifikate. Denn IE8 auf Windows XP kann kein SNI, Chrome jedoch kann es, obwohl Windows XP zum Einsatz kommt. Der Grund dafür ist, dass Chrome seine eigene Crypto-Library mitbringt.

Beim Versuch also die Verbindung ohne SNI aufzubauen, landet man nicht auf dem gewünschten Server sondern bekommt ein allgemeineres Zertifikat des Hosters zurück. Dies erklärt nun den Punkt mit den unterschiedlichen Zertifikaten von GeoTrust und Go Daddy.

Man kann die Sache sehr schön nachverfolgen, wenn man Fiddler einsetzt. http://fiddler2.com/. Damit kann man, wenn der HTTPS-Mitschnitt aktiviert ist, sehr schön sehen, dass Powershell 2.0 diesen Aufruf generiert:

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[0064] TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
[0062] TLS_RSA_EXPORT1024_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0006] SSL_RSA_EXPORT_WITH_RC2_40_MD5
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0063] TLS_DHE_DSS_EXPORT1024_WITH_DES_SHA

Compression:
[00] NO_COMPRESSION

Während Chrome dies zustande bringt:

Version: 3.1 (TLS/1.0)

Extensions:
 server_name chocolatey.org
renegotiation_info 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
NextProtocolNegotiation empty
ALPN  spdy/2; spdy/3; spdy/3.1; http/1.1;
channel_id empty
status_request 01 00 00 00 00
Ciphers:
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0035] TLS_RSA_AES_256_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA

Compression:
[00] NO_COMPRESSION

Der Extensions-Eintrag server_name chocolatey.org ist genau der Punkt, welcher beim Powershell-Aufruf fehlt und die Sache zum Scheitern bringt. Gleichwohl auch Chrome innerhalb von Fiddler Probleme mit dem Aufruf bekommt, denn Fiddler2 basiert auf .Net Framework 2.0 und damit ist der weitere Fortgang zum Scheitern verurteilt und man bekommt am Ende nicht das Go Daddy Zertifikat sondern wieder das falsche GeoTrust Zertifikat.

Übrigens geht genau dieser Artikel auf das aktuelle Problem ein und bestätigt nochmal alles: https://groups.google.com/forum/#!searchin/chocolatey/geotrust$20/chocolatey/r9EdhJdPjWM/FavaGm07VtoJ

Zu guter Letzt noch die Bestätigung, dass Powershell 4.0 unter Windows 8.1 problemlos damit umgehen kann:

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
 server_name chocolatey.org
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

Compression:
[00] NO_COMPRESSION

Also alles halb so wild, wenn man weiß, wie es zusammenhängt!

Windows Update meldet Fehler 0x80070005 beim Updates installieren

29 November 2013

Mal wieder die Härte schlechthin. Um die Fehlermeldung 0x80070005 beim Windows Updates installieren wegzubekommen, muss man sich als Administrator anmelden!! Irgendwie merken die bei MS echt die Einschläge nicht mehr. http://support.microsoft.com/kb/968003/en-us

Ein Tipp noch von mir: Um ganz sicher zu gehen, dass es auch klappt, sollte man sich immer mit dem lokalen Computer-Admin-Konto anmelden und nicht mit dem Domänen-Admin-Konto. Wenn schon denn schon!

Benutzer unter Windows umbenennen

20 März 2013

Wer in den aktuellen Windowsversionen in der Benutzerkontenverwaltung einen Benutzer umbenennt, bekommt immer nur den Anzeigenamen umbenannt.

Wenn man z. B. whoami benutzt oder das Stammverzeichnis des Benutzers öffnet, wird immer noch der alte Name angezeigt. Dies ist oftmals mehr als irritierend.

Mittels des Windows-EasyTransfer Programms kann man aber auch einen Benutzer auf ein und demselben Rechner umziehen. Alle Einstellungen und Dateien werden damit sauber umgezogen. Damit erübrigt sich das herumspielen mit NTUSER.DAT, NTUSER.DAT.LOG und NTUSER.INI.

http://answers.microsoft.com/en-us/windows/forum/windows_7-security/need-to-rename-user-profile-or-copy-profile-into-a/69097230-86e1-4e14-b76b-8e8e7d776db2

Hier die etwas sinnfremde offizielle Version: http://windows.microsoft.com/en-us/windows7/rename-a-user-account

Die Variante funktioniert auch bei Domänenbenutzern: http://support.microsoft.com/kb/928634/en-us.

Remotewebzugriff von Windows XP auf SBS2011 meldet “Der Remotedesktopdienste-ActiveX-Client ist nicht aktiviert”

1 März 2013

Wenn ein Windows XP SP3 Client versucht mittels Internet Explorer 7 oder Internet Explorer 8 auf einen Small Business Server 2011 den Remotewebzugriff auf einen Rechner im SBS-Netz zu nutzen, erhält man diese Meldung:

[Der Remotedesktopdienste-ActiveX-Client ist nicht aktiviert]
Auf dieser Website muss das folgende Add-On ausgeführt werden: Remotedesktopdienste-ActiveX-Client. Dieses Add-On wird von Microsoft Internet Explorer unterstützt.

Nett so eine Meldung. Früher hatte der IE noch eine kleine Einblendung parat, wo man dann sagen konnte, dass das ActiveX-Control geladen und ausgeführt werden soll. Aber im Zeitalter des zusammenbrechenden Vertrauens, muss also der Admin ran und überlässt man solche schwerwiegenden Entscheidungen nicht mehr dem Benutzer.

Dieser Artikel http://social.technet.microsoft.com/wiki/contents/
articles/4660.fix-my-remote-web-workplace.aspx
, hilft nicht wirklich weiter, denn der entscheidende Passus wird in der quasi Readme zum SBS2011 erläutert: http://technet.microsoft.com/de-de/library/gg491249.aspx, dort wird genau erklärt was zu tun ist.

Kurz man muss den Key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Ext\PreApproved\{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}

in der Regisitrierung anlegen und danach kann man das ActiveX-Control im Internet Explorer bei den Addons aktivieren!

Schutzverletzungen durch ACLayers.DLL wegen Shims und Komptibilitätseinstellungen

19 Januar 2013

Wer Probleme mit abstürzenden Programmen bekommt, bei denen Aclayers.dll mit genannt wird, der hat es mit Problemen des Application Compatibility Toolkit (ACT) von Windows zu tun.

Einleitung
Bereits bei Windows 2000 findet man das Verzeichnis C:\WINNT\APPPATCH welches die Aclayers.dll beinhaltet. Unter Windows XP ist diese natürlich nach C:\WINDOWS\APPPATCH gewandert. Auch Unter Windows 8 findet man dort die AcLayers.DLL noch. In Verbindung mit Aclayers.dll werden immer wieder msimain.sdb, drvmain.sdb, pcamain.sdb und sysmain.sdb genannt. Dies sind die einzelnen Datenbanken, welche die Kompatibilitätseinstellungen bzw. Meldungen für Programme und Treiber enthalten.

Dass ein Programm im Kompatibilitätsmodus ausgeführt wird, kann man immer im sehr schön im ProcessExplorer von Sysinternals erkennen, indem man sich bei der Lower Pane View die DLLs die der einzelne Prozess geladen hat anzeigen lässt. Dort taucht dann immer Aclayers.DLL auf.

Wenn man Programme mittels ProcMon.EXE beobachtet bzw. aufruft, findet sich hier immer der Aufruf von C:\WINDOWS\SYSTEM32\APPHELP.DLL. AppHelp.DLL ist die API für die Kompatibilitätsanfragen. Windows steuert je nachdem was in den Kompatibilitätsdatenbanken hinterlegt ist, welche Umgebung die Anwendung vorgesetzt bekommt oder ob evtl. auch eine Meldung angezeigt wird oder gar der Start blockiert wird.

Eine gute Erklärung, was genau passiert, wenn ein Programm im Kompatibilitätsmodus ausgeführt wird, ist hier zu lesen: http://technet.microsoft.com/en-us/windows/jj863250.aspx. Dabei wird von Shims gesprochen worüber der eigentlichen Anwendung eine ältere Umgebung vorgegaukelt wird.

Komplette Erklärung der Möglichkeiten unter Windows XP: http://technet.microsoft.com/en-us/library/bb457032.aspx, unter dem Titel “Windows XP Application Compatibility Technologies”. Hier die aktuelle Fassung für Windows 8: http://technet.microsoft.com/en-us/library/hh825181.aspx.

Shim Database (.SDB) dumpen: http://blog.kalmbach-software.de/2010/02/22/the-shim-database/. Hier noch der Link zur API-Beschreibung für die Zugriff auf die .sdb-Dateien. http://msdn.microsoft.com/library/bb432182.aspx. Hier noch ein Utility zum Auslesen der SDB-Datenbanken: http://blogs.msdn.com/b/heaths/archive/2007/11/02/sdb2xml.aspx.

Übrigens ist die ganze Geschichte auch dafür verantwortlich, wenn ein Update von Windows7 auf Windows 8 nicht möglich ist, weil z. B. Programm XY installiert ist. Man kann davon ausgehen, dass in einer .SDB dann die betreffende Software erfasst ist und der Upgrade -Assistent genau dies prüft.

Ein guter Blog mit vielen Infos zum Thema: http://blogs.msdn.com/b/cjacks/.

Konkrete Problemlösung
Jetzt aber nochmal zurück zum Anfang. Bei einem Kunden kam es beim Aufruf eines Programms ständig zu Schutzverletzungen wegen AcLayers.DLL. Die Software welche bei der Schutzverletzung genannt wurde, war ein VB6 Programm, welches vor einem Update tadellos auf dem besagten Rechner lief. Bei der Recherche, was genau in dem Programm geändert wurde, stellte sich heraus, dass eine neuere Version von MSXML benutzt wurde. Diese neuere Version war anscheinend von AcLayers.DLL geblockt worden, blöderweise durch die Schutzverletzung. Warum, war erst nicht klar. Aber nach einigem Suchen stellte sich heraus, dass die Anwendung, welche die VB6-Anwendung aufrief, auf Kompatibilität zu Windows 95 eingestellt war. Damit wurde die Anwendung von MSXML verhindert, welches mindestens Windows 2000 benötigte. Ergo die Schutzverletzung mit AcLayers.DLL!

Eingabeaufforderung mit lokalen Systemdienst Rechten unter Windows

29 Dezember 2012

Hin und wieder braucht man andere Rechte, als Admin hat man zwar auf alles Zugriff aber das System an sich darf noch viel mehr. Um schnell einen Wechsel mit Boardmitteln hinzubekommen, gibt es zwei geniale Befehle:

sc create ntauthcmd binpath= "cmd /K start" type= own type= interact

Obigen Befehl muss man natürlich als Admin absetzen und bekommt dann diesen Warnhinweis:

[SC] CreateService ERFOLG

WARNUNG:  Der Dienst "ntauthcmd" ist als interaktiver Dienst konfiguriert, desse
n Unterstützung abgelehnt wurde. Die einwandfreie Funktion des Dienstes ist nich
t gewährleistet.

Die Warnung kann aber einfach ignoriert werden, zum Starten gibt man:

sc start ntauthcmd

ein, wobei man wieder eine Warnung bekommt:

[SC] StartService FEHLER 1053:

Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderun
g.

Nun obacht geben auf die Taskleiste! Denn dort fängt auf einmal ein kleines Dienstsymbol mit Kamera und Drucker an zu blinken! Klickt man dieses an bekommt man einen Dialog mit folgender Meldung dargestellt:

[Window Title]
Erkennung interaktiver Dienste

[Main Instruction]
Von einem auf diesem Computer ausgeführten Programm wird versucht, eine Meldung anzuzeigen.

[Content]
Möglicherweise sind Informationen oder Berechtigungen erforderlich, damit das Programm den Vorgang abschließen kann.
Woran liegt das?

[V] Programmdetails einblenden  [Meldung anzeigen] [Später erneut nachfragen]

[Expanded Information]
Programme und Geräte, für die ein Eingreifen angefordert wird.

Nachricht:  C:\Windows\system32\cmd.exe
Programmpfad:  C:\Windows\system32\cmd.exe
Empfangen:  ‎Heute, ‎29. ‎Dezember ‎2012, ‏‎22:46:21

Dieses Problem tritt auf, wenn ein Programm nicht vollständig kompatibel mit Windows ist. Wenden Sie sich an den Programm- oder Gerätehersteller, um weitere Informationen zu erhalten.

Sieht alles dramatisch aus, aber führt zum Ziel! Also einfach “Meldung anzeigen” anklicken. Dann flackert bei den meisten Monitoren etwas die Darstellung weil der Grafikmodus geändert wird aber man kommt auf einen einsamen leeren Desktop mit einer Eingabeaufforderung. Es wird auch noch eine weitere Meldung dargestellt:

[Window Title]
Erkennung interaktiver Dienste

[Main Instruction]
Zurück zum Windows-Desktop

[Content]
Für Programm wird ein eigenes Fenster angezeigt, wenn noch weiteres Eingreifen erforderlich ist.

Wenn Sie Ihre Aktionen abgeschlossen haben oder wenn Sie zum Desktop zurückkehren möchten, klicken Sie auf "Jetzt zurück".

[Jetzt zurück]

Klickt man hier auf “Jetzt zurück” bleibt der separate Desktop erhalten und man kann hin und her wechseln. Der separate Desktop verschwindet erst, wenn man die Eingabeaufforderung schließt und dann zurückkehrt.

Frägt man an der Eingabeaufforderung mittels whoami nach, wer man ist, erhält man:

C:\windows\system32>whoami
nt-autorität\system

Da die Sache auf die Dauer auch etwas komisch aussieht, kann man den Dienst auch wieder entfernen:

sc delete ntauthcmd

Eine Alternative zu dieser Vorgehensweise wäre PSEXEC.EXE von den Sysinternals-Tool, aber die braucht man nicht wirklich: http://blogs.technet.com/b/askds/archive/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008.aspx

Quelle: http://myitforum.com/cs2/blogs/cnackers/archive/2009/05/06/nt-authority-context-command-prompt.aspx