Irgendwie mochte der XenServer die Realtek dann doch nicht. Das Interface wurde zwar hochgefahren, aber der XenServer (genauer XenApi) fuhr die Interfaces immer nach 2 Minuten wieder runter. Glücklicherweise schmeisse ich meine alte Hardware nur ungern weg (sehr zum Ärgernis meiner Frau). Aber so konnte ich mit einer alten 3Com3c905b-TX dann doch noch testen.

Soweit ich mich noch an meine CentOS Installation erinnere, war es da auch nicht so einfach die Realtek r8168 mit einzubinden. Mal sehen was man mit dem XenServer Driver Development Kit so erreichen kann.

…

Der XenServer ist erfolgreich gestartet – aber Netzwerk hat er noch immer nicht. Das liegt daran, dass das Kernelmodul nur während der Installation eingebunden war. Nun muss das Modul fest mit eingebunden werden. Die Prozedur ist änhlich wie beim Setup. Es wird der USB-Stick oder die Floppy gemountet und das Modul wird kopiert. Damit das Modul aber auch während des Bootvorgangs geladen wird, muss unter die Datei /etc/modprobe.conf angelegt werden.

echo „alias eth0 r8168″ >> /etc/modprobe.conf

Danach folgt ein:

depmod -a

Zum Schluss fehlt noch das aktiveren der Interfaces. Das passiert in den ifcfg-* Files unter /etc/sysconfig/network-scripts. In den Files ifcfg-eth0 und ifcfg-xenbr0 den Wert onboot=yes setzten. Danach ein reboot und die NICs sollten nach dem Booten vorhanden sein.

…

Um Citrix XenDesktop zu evaluieren, habe ich mir letzte Woche für meinen Rechner 8GB RAM und eine 500GB eSATA Platte bestellt. Gestern habe ich die Teile bekommen. Also gleich eingebaut, die Citrix XenServer Server CD eingelegt und los gings. Da kam auch prompt die erste Entäuschung. Meine Realtek 8168 wird nicht erkannt und die Installation bricht mit folgender Fehlermeldung ab: „No Network Interface found on this host“

Glücklicherweise gibt es dazu einige Anleitungen im Netz, wie man den Treiber einbindet:
http://www.alessandrorossini.org/2007/11/30/how-to-install-xenserver-4-on-systems-with-realtek-rtl81118168b-based-network-adapters/

Falls das Modul nicht geladen wird, sollte die Kernel Version mit „uname -r“ überprüft werden. Nach ein wenig googeln findet man auch das Modul für andere XenServer Versionen.

Nachdem der Treiber eingebunden war, gab es dann aber gleich das nächste Problem. Das Base Repository konnte nicht gefunden werden. Also fix ein PROFTPD auf meinem UBUNTU aufgesetzt, den Ordnerinhalt von Packages.main unter /var/ftp kopiert und während der Installation das HTTP/FTP Repository ausgewählt Aber auch so wurde das Repository nicht gefunden. Wenn man den FTP Server spezifiziert, muss dieser über ftp://<IP-Address> angegeben werden. Ansonsten wird anscheinend nur HTTP versucht (sagt zumindest wireshark). Danach lief dann endlich die Installation.

Mal sehen, was noch kommt …

Um nun dem Helpdesk eine Möglichkeit an die Hand zu geben, welcher User von welcher Maschine aus gesperrt wurde, kann man sich per VBScript an das EventLog des PDCs binden. Wie schon besprochen, wird auf dem PDC ein Eintrag mit der ID: 644 erstellt. Ein solches Script könnte z.B. so aussehen:

strComputer = „.“

Set objWMIService = GetObject(„winmgmts:{(Security)}\\“ & _
strComputer & „\root\cimv2″)

Set colMonitoredEvents = objWMIService.ExecNotificationQuery _
(„Select * from __InstanceCreationEvent Where “ _
& „TargetInstance ISA ‘Win32_NTLogEvent’ “ _
& „and TargetInstance.EventCode = ‘644′ “ _
& „and TargetInstance.LogFile = ‘Security’ „)

Do
Set objLatestEvent = colMonitoredEvents.NextEvent

set fso = createobject(„scripting.filesystemobject“)
set tf = fso.OpenTextFile(„c:\\act_lockout.log“,8, true)

tf.write(objLatestEvent.TargetInstance.TimeWritten & vbtab)
tf.write(objLatestEvent.TargetInstance.User & vbtab)
tf.write(objLatestEvent.TargetInstance.Message)

tf.close()
Loop

Das hier gezeigt Script hält jeden Account Lockout in einer Log-Datei fest. Dies ist in größeren Umgebungen oftmals einfacher als das EventLog des PDCs zu durchsuchen. Damit dieses Script ständig läuft, kann das Script als Scheduled Task eingerichtet werden, der nach dem Booten startet.

Um mehr Daten aus dem EventLog zu erhalten, kann das Script modifiziert werden. Alle Event Informationen können über Win32_NTLogEvent abgefragt werden:
http://msdn2.microsoft.com/en-us/library/aa394226(VS.85).aspx

to be continued…

Nachdem alle gespeicherten Kennwörter gelöscht oder überarbeitet wurden, der User sich aber noch immer aussperrt, gilt es herauszufinden, von welcher Maschine dieser Lockout ausgelöst wird.

Dazu ist es wichtig zu verstehen, dass jede Anmeldung über den Logonserver durchgeführt wird. Kann dieser die Credentials nicht bestätigen, wird die Anmeldung über den PDC-Emulator versucht. Und genau hier ist der Punkt an dem man ansetzen kann.

Wird ein Account gelockt, dann wird dies im EventLog des PDC-Emulators festgehalten. Ein solcher Eintrag sieht so aus:

Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 644
Date: 17.04.2008
Time: 13:23:43
User: NT AUTHORITY\SYSTEM
Computer: <PDC-Emulator>
Description:
User Account Locked Out:
Target Account Name: <Username>
Target Account ID: <Domain>\<Username>
Caller Machine Name: <Machinename>
Caller User Name: <PDC-Emulator>
Caller Domain: <Domain>
Caller Logon ID: (0×0,0×3E7)

Interessant ist hier der Account der gelockt wurde (Target Account ID) und die Maschine (Caller Machine Name) von der aus die falschen Anmeldeinformationen übermittelt wurden. Handelt es sich bei ‚Caller Machine Name’ nicht um die Maschine wo der User derzeit angemeldet ist, könnte es sich um einen Angriff handeln (DoS). Aber oft ist es nur ein Kollege, der noch nicht das neue Passwort bekommen hat.

to be continued…

Welcher Admin kennt das nicht? Der Helpdesk hat wieder einen User, der sich ständig sperrt. Und schon hagelt es die Standardantworten…

Aber was kann man eigentlich tun, wenn ein User sich immer und immer wieder aussperrt. Um nicht gleich mit Kanonen auf Spatzen zu schießen, sollte man zuerst einmal prüfen ob der User nicht irgendwo sein Passwort gespeichert hat und dieses nach einem Passwort Change nicht nachgezogen hat.

Jetzt kann es mehrere Stellen geben wo der User seine Kennwörter gespeichert hat. Oft wird der Fehler gemacht, nur im Internet Explorer nach gespeicherten Kennwörtern zu suchen. Sehr wichtig ist aber auch der Punkt: Gespeicherte Benutzernamen und Kennwörter! Diesen Dialog erreicht man über die Systemsteuerung – falls der Punkt dort ausgeblendet ist, bleibt noch die Möglichkeit den Dialog über folgenden Befehl zu starten:

rundll32 keymgr.dll KRShowKeyMgr

to be continued…