Natürlich möchte man, nachdem die Domain aufgesetzt wurde auch zentrale Distributionpoints für die Software haben. Insbesondere der Virenscanner ist für mich in der Domain ein Mußkriterium. Die Fragestellungen sind dabei:

• Welcher Client hat überhaupt eine entsprechende Software installiert
• Wann wurde zuletzt ein Fullscan durchgeführt
• Auf welchem Stand sind die Signaturen

Ich persönlich verwende seit Jahren Kaspersky Anti Virus. Der Rest meiner Familie, naja, unterschiedlichste freie Programme aber wenigstens verwenden sie eines.

Diese Heterogene Infrastrukutur ist natürlich problematisch. Also kurz ein paar Programme evaluiert. Ein Paar stimmt in diesem Fall wirklich; McAfee und Kaspersky. Norton kann  mich seit einiger Zeit nicht mehr begeistern.

McAfee: Die für mich Interessante Variante ist relativ teuer und besitzt eine Remoteadministration. Diese liegt leider nicht bei mir Lokal sondern auf einem McAfee-Server. Laut McAfee ist diese für kleine Firmen ohne ständiges IT Personal gedacht. Für Firmen, welche nicht im IT-Bereich tätig sind,  ist das sicher interessant.  Für mich vollkommen inakzeptabel. Die Features sind soweit vollständig.

Kaspersky: Das Kaspersky Administration Kit ist kostenlos. Das ist schon mal ne super Sache. Die Verwendung von vorhanden Linzenen ist möglich und für mich somit sehr interessant. Zur Administration wird ein SQL Server (2000 und 2005 inkl. Express und MSDE) oder eine MySQL Datenbank verwendet. Die Installation gestaltet sich denkbar einfach. Einzig mit den Rechten des Serviceaccounts für den Administrationsservice bestehen auf meiner Seite noch Unklarheiten.

Letztlich habe ich mich für Kaspersky entschieden. Interne Administration, hoher Wiedererkennungseffekt (subjektiver Faktor) und relativ günstige Lizenzen ( ca. 38 € netto pro Lizenz ) und keine Kosten für die zentrale Administration.

Praktischer Einsatz

Man kann, bei entsprechenden Lizenzen, auch Serverbetriebssysteme scannen. Interessant und das Keyfeature, welches ich wollte: Clients lassen sich Remote mit der Software bestücken und die Definition von Policies ist zentral, in meinem Netzwerk, möglich. Wann, Was und Wer wird gescannt lässt sich zentral konfigurieren. Ein einsichtiger Überblick über den Stand der Dinge ist vorhanden. Überprüfung des EMailpostfachs ebenso wie Spam und Spywareschutz. Selbst an Notebooks, welche geraume Zeit nicht im Netzwerk waren, wurde gedacht. Diese können bei connect zur Domain, soweit die Software einen Stand oberhalb des erlaubten Bereiches signalisiert, automatisch gescannt werden.

Bisher kann ich dieses Paket nur empfehlen. Wie der Dauereinsatz verläuft wird sich zeigen. Ich werde in diesem Kanal davon berichten.

So long...
Wilko

hatte ich heute.

Es ist immer so eine Sache mit der Kindererziehung. Man darf die Dinge nicht dem Selbstlauf überlassen und sollte seinen Kindern versuchen etwas beizubringen. Klassisch zählt dazu: Im Garten irgend etwas bauen, damit das handwerkliche Geschick und die Koordinationsfähigkeit geschult wird, Besuch von kulturellen Einrichtungen und dergleichen.

Unter diesem Motto stand der heutige Tag und ich hätte nie gedacht, dass er soviel Anklang findet. Das Thema: Build your own computer and configure a domain controller.

12.00 Uhr - 15.00 Uhr: Mainboard ausbauen, neues Mainboard einbauen und korrekt verkabeln
16.00 Uhr - 19.00 Uhr: DC konfigurieren und über Vor- und Nachteile von Rechtebeschränkungen diskutieren.

Ich hätte im Leben nicht gedacht, das ich damit einmal Glanz in den Augen eines Kindes erzeugen kann. Wahrscheinlich ist das modernes Budenbauen. Ich hoffe, das wir bald von diesem Administrationkram wegkommen und zu den wirklich interessanten Sachen übergehen können: Die Programmierung.

Neues von der Front!

Endlich, ich habe es geschafft. Die Debian-Installation hat wunderbar funktioniert und das aus meiner Sicht geniale Installationsverfahren hat sofort für viel Freude und Wiedererkennungseffekt gesorgt.

Nachdem ich alle benötigten Pakete installiert hatte; erstmal die Wohlfühlsoftware ala vim und dann die Dinge zum Verrichten der Arbeit, konnte das Konfigurieren losgehen. Zuerst wurde Kerberos konfiguriert, damit die Authentifizierung mit dem DC klappen kann. Das bedeutet Realm einrichten, Passwordserver bekanntgeben und hoffen das es funktioniert. Welch wunder, es ging

Als nächstes kam dann die winbind- und Sambakonfiguration dran. Mit korrektem Kerberos eigentlich kein Problem aber man glaubt nicht, welcher Unsinn so im Netz kursiert. Zum Teil von der ganz üblen Sorte. Nach einigem hin und her habe ich es dann zum laufen bekommen.

Ich konnte den "Rechner" in der Domain anmelden und wbinfo -u listete mir alle Domainnutzer auf. Der Zugrifftest vom Windowsclient funktionierte natürlich nicht; Mist. Die Rechner wird korrekt aufgelistet und ein Blick auf die Freigaben offenbart mir das gewünschte Bild. Leider erfordert er beim Aufrufen der Freigabe eine Authentifizierung. Hallo? Genau das sollte doch nicht passieren!

Wie es immer ist: Es beginnt die Suche nach der Nadel im Heuhaufen.

• Kerberos (Check)
• Winbind - Test mit wbinfo -u und wbinfo -g (Check)
• Samba - Alles unnötige rausgelöscht, Kommentare entfernt - sieht gut aus (Check)

Nix geändert, kann nicht gehen. Mist!

Also habe ich den Computer wieder aus der Domain rausgeschmissen und ihn erneut hinzugefügt. Nix geht. Test mit kinit und klist, ich bekomme gültige Tickets. Warum geht es nicht? Nochmal die Sambakonfiguration durchschauen und alle Einstellungen welche auf Rechtebeschränkung abzielen auskommentieren. Ups, es geht! Soviel zu obiger Behauptung: Alles unnötige rausgelöscht.

Das Problem war letztlich eine Einstellung in der smb.conf.

valid users = %S

Hmm... komisch, überall wird es so empfohlen/angegeben. Wie dem auch sei, jetzt funktioniert es erstmal. Warum %S nicht klappt muss und werde ich noch herausfinden.

Wenigstens kann ich, wenn auch nur auf Umwegen, einen neuen Merksatz ableiten:

Merksatz 4.0
Wenn der Wagen nicht läuft, solltest du erst nach den Zündkerzen sehen und nicht gleich den Motor austauschen.

Heute habe ich mir den Network Storage Link for USB gekauft. Warum? Ehrlich gesagt wusste ich das zum Kaufzeitpunkt nicht genau. Es war nur mehr die Wage Hoffnung, einen Fileserver mit geringsten (Geld)Mitteln aufzusetzen und dieser sollte natürlich auch noch in meiner neuen Windows-Domain verfügbar sein.

Nachdem ich mir einen DC aufgesetzt habe, möchte ich auch Homeverzeichnisse, Bilder und Musik als Speicherort per Logonscript mit einbinden aber, die Dateien sollen nicht in einer virtuellen Maschine gespeichert werden. Mein Maxtor Shared Storage wäre/ist dafür schon sehr gut geeignet. Leider besitzt dieses keine Domainunterstützung, so dass eine separate Authentifierzung notwendig ist. Sehr unschön

Mit dem obigen Gerät kann ich externe USB Festplatten im Netzwerk, leider wieder mit separater Authentifizierung/Autorisierung, verfügbar machen. Das kann mein Shared Storage auch. Ich bin also dem Ziel keinen Schritt näher, wäre da nicht die Möglichkeit, ein spezielles Debian zu installieren.

Der Plan: Das System per Samba in die Domain einbinden und das Maxtor Shared Storage in der Zukunft nur noch als Backupmedium nutzen.

Momentan läuft noch die Debian-Installation aber ich schaue voller Hoffnung in die Zukunft, sofern ich Samba mit kompiliertem ADS Support installiert bekomme. Schau mer mal. Ich werde berichten, wie das Aufsetzen und Einbinden funktioniert hat.

So long..
Wilko

Nachdem ich einen DC aufgesetzt habe, wollte ich natürlich auch die vorhandenden (virtuellen) Maschinen in die Domain aufnehmen. Bei Rechnern, welche mittels Installation von CD aufgesetzt wurden funktioniert dies auch wunderbar. Bei virtuellen Maschinen deren Installation auf Basis eine Images, ohne weitere Vorbereitungen/Maßnahmen, erfolgte, kommt es naturgemäß zu Problemen. Die Rechner besitzen alle die gleiche SID und das mag der DC nun überhaupt nicht.

Also mit dem Tool NewSid dem Rechner eine SID verpasst und dann funktioniert es auch mit dem Aufnehmen in die Domain. Soweit so gut.

Nach dem notwendigen Reboot und dem obligatorischen Blick in das Eventlog wird mir fast schwarz vor Augen. Da lächelt mich doch diese (siehe Bild) schöne Fehlermeldung an. Der Blick auf die Eigenschaften offenbarte mir folgenden Text:

Unable to get the private bytes memory limit for the W3WP process. The ASP.NET cache will be unable to limit its memory use, which may lead to a process restart.

Was bedeutet das denn nun schon wieder? Nach einigen Ursachenforschungen kam dann folgendes heraus; Natürlich hat sich auch die SID der Accounts geändert und das verursacht beim IIS Probleme, da im konkreten Fall die Gruppe IIS_WPG nicht mehr die nötigen Rechte auf die Applikationpools besitzt. Ist zwar komisch, da NETWORK SERVICE und die anderen Accounts in der Metabase des IIS korrekt eingetragen wurden aber was solls, dass klärt sich sicher auch noch auf. Abgesehen von den Leichen, die ehemaligen Accounts mit nun "ungültiger" SID, sowie der fehlenden Gruppe waren die Einstellungen der IIS Metabase korrekt.

Die Fehlerbehebung erfolgte dann in zwei Schritten.

1. Entfernung der ungültigen Accounts aus der Metabase
2. Hinzufügen von IIS_WPG mit den nötigen Rechten.

Beides kann mittels dem Script Metaacl.vbs durchgeführt werden. Der Aufruf zum Hinzufügen von IIS_WPG sieht dann folgendermaßen aus:

cscript Metaacl.vbs "IIS://LocalHost/W3SVC/AppPools" <RECHNER>\IIS_WPG U

Das U steht für die zu setzenden Rechte, in diesem Fall für "Unsecure properties read" und genau diese Einstellung ist nötig. Nach dieser Prozedur sah mein Eventlog, abgesehen von den Problemen welche sich ergeben wenn ein installierter Team Foundation Server in eine Domain gehoben wird, richtig gut aus. Doch dazu später mehr.