12.11.2001

ADS-Zusatz

GPO \ Softwareeinstellungen:

Nehmen wir an, ein Client soll eine Software erhalten. Normalerweise würde man das lokal erledigen, aber schöner ist es doch, diese über einen Server bereitzustellen. In erster Linie sind dafür Rechte notwendig. Beispielsweise kann ja kein normaler Benutzer Treiber installieren. Um Software zu installieren, muss auf dem Client der Windows-Installer-Dienst laufen. Dieser ist manuell startbar in der Verwaltung (W2k) und installiert, repariert oder entfernt Software. Auf dem Server muss sich natürlich eine Freigabe mit den Installationsdateien befinden. Es kann auch sein, dass sich nur eine Datei mit der Endung *.msi dort liegt. Diese enthält die komplette Installation. Hauptsächlich befinden sich in den msi-Dateien die Informationen zur Installation. Seien es Reg-Einträge, Ordner-Erstellungen oder Variablen wie %windir% und natürlich die Einträge, welche Dateien wohin kopiert werden sollen. Diese Datei bekommt man meistens vom Hersteller, aber man kann sie mit relativ wenig Aufwand selbst erstellen. Ich habe dazu den Veritas Discover benutzt, welcher als Light-Version umsonst zu bekommen ist. Man erstellt einen Snapshot vom System, installiert die Software und erstellt einen zweiten Snapshot. Die Differenz dazwischen wird als msi-Datei erstellt. Auf der W2k-Proffesional CD ist das Programm unter folgenden Namen: valueadd \ 3rdparty \ mgmt \ winstle.msi.

Es gibt aber auch mst-(Transform)Dateien. Diese Dateien sind für Anpassung einer vorhandenen msi-Datei gedacht. Die Erstellung einer mst-Datei ist mit einem Tool aus dem Ressource-Kit möglich. Diese mst-Dateien sind übrigens nur während der jew. Installation wirksam.

Weiterhin gibts noch msp-(Patch)Dateien, welche aber sehr selten sind.

Will man eine msi-Datei direkt ausführen, muss man an der Kommandokonsole den Befehl msiexec *.msi eingeben, alternativ kann man sie auch direkt doppelklicken.

Die noch zusätzlich erwähnten zap-(...)Dateien sind simple Textdateien, welche auf ein Setupprogramm verweisen. Dieses ist dann über Systemsteuerung \ Software \ Programme hinzufügen erreichbar. Es würde in dem leeren Feld dort auftauchen.

  zuweisen bereitstellen (veröffentlichen)
pro Benutzer automatische Installation bei Anforderung durch den Benutzers (Es wird eine Verknüpfung vordefiniert, beim Klicken wird danach die Software installiert oder eine Datei (*.xls) wird geöffnet, die das Programm benötigt), nur *.ms*-Dateien möglich über Systemsteuerung \ Software \ Programme hinzu... verfügbar, *.msi, *.zap-Dateien möglich
pro Computer automatische Installation beim Start des Rechners  nicht möglich

Wir installieren mal eine Software: Der Dienst (msiexec.exe) wird erstmal gestartet und auf "automatisch starten" gesetzt. Der Server erhält eine Freigabe namens "Softwarevert". Das Standardrecht bei Freigaben war "Jeder Vollzugriff". Wir kopieren aus dem Systemverzeichnis eine Datei namens adminpak.msi in diese Freigabe. In dieser Datei befinden sich sämtliche Verwaltungskonsolen. Ich kann somit auf einem W2k-Prof-Rechner die Konsolen für die Serververwaltung installieren und verwenden. Als nächtes rufen wir die Gruppenrichtlinie auf (Active Directory-Benutzer und -Gruppen) auf, erstellen uns eine neue OU namens Remote_admins. Wir erstellen einen Benutzer in der OU, mit dem wir uns anmelden wollen. Wir lassen uns die Eigenschaften der OU anzeigen und erstellen eine neue Richtlinie namens Adminpak. In dieser Gruppenrichtlinie klicken wir uns zu den Softwareeinstellungen des Benutzers durch und wählen als msi-Datei die Freigabe des Servers. Wir weisen die msi-Datei zu. Die Installation gelingt nicht auf Anhieb, weil es offensichtlich Probleme mit dem Terminalserver gibt. Wir mussten den Terminalserver deinstallieren, dann gabs keine Probleme mehr.

 

Benutzer und Gruppen:

Auf einem DC ist die lokale Benutzer- und Gruppenverwaltung deaktiviert. Lokale Konten sind auch nur auf einem lokalen Rechner verfügbar. Davon ist auch die SAM betroffen. Benutzerkonten in einer Domäne sind globale Konten. Global bedeutet, sie sind innerhalb einer Domäne überall verfügbar und, je nach Vertrauensstellung, sogar darüber hinaus. In einer Gesamtstruktur richtet W2k automatisch transistive Vertrauensverhältnisse zwischen den Domänen ein. Die Konten sind in der eigenen und in jeder vertrauenden Domäne verfügbar.

Habe ich in D1 einen Benutzer (B1) und eine Ressource(R1), und in D2 ebenfalls, so kann B1 auf R1 zugreifen, nicht aber auf R2. B2 kann auf R2 und auf R1 zugreifen. Der Leitsatz dazu lautet, dass der Zugriff auf Ressourcen im Gegensatz zum Vertrauenspfeil gezeichnet werden kann.

Hat man keine Domäne, braucht man auf jeden Rechner, auf den man zugreifen möchte, ein lokales Konto. In einer Domäne werden die Freigaben vom Domänencontroller verwaltet. Auf einem Client wird man sich deshalb so gut wie immer mit einem globalen Konto anmelden, um die Domänenfreigaben zu nutzen. Ausserhalb einer Domäne existieren die lokalen Konten nur in der SAM.

Gruppenstrategien:

Lokal gesehen gehört ein Benutzer zu einer Gruppe, und diese hat NTFS- oder Freigaberechte auf eine Ressource. In der Domäne gesehen befindet sich ein Benutzer in einer globalen Gruppe, diese wiederum optional in einer universalen Gruppe, diese wiederum in einer lokalen Domänengruppe und diese kann auf Ressourcen zugreifen.

Globale Gruppen sind in der eigenen und in jeder vertrauenden Domäne verfügbar, insbesondere im tree. Ausserdem kann sie Mitglieder nur aus der eigenen Domäne aufnehmen. Im Gegensatz dazu können lokale Domänengruppen aus der eigenen und jeder vertrauten Domäne aufnehmen , sind aber nur in der eigenen Domäne verfügbar.

Universalgruppen sind im Tree komplett erreichbar und können andere Mitglieder des Trees aufnehmen, sind aber nur in einem einheitlichen Modus (ohne WinNT-Rechner) verfügbar. W2k befindet sich bei der Einrichtung von ADS im Mixed-Mode. Auf den Eigenschaften der Domäne muss man den einheitlichen Modus erst auswählen.

Wir müssten die globale Gruppe zu allen lokalen Domänengruppen hinzufügen, erst so können sie auf die Ressourcen der anderen Domänen hinzufügen. Bei einer zweiten globalen Gruppe bräuchte man doppelt soviele Verknüpfungen, usw.

Stattdessen kann man alle globalen Gruppen zu einer universalen Gruppe hinzufügen und diese Gruppe zu allen lokalen Domänengruppen einbinden. Der Vorteil macht sich bei Änderungen bemerkbar. Logischerweise sollte man vorher die User nach Aufgabenbereichen sortieren.

Als Gruppentypen gibt es die Sicherheit, welche zum Zuweisen von Rechten und für eine Verteilerliste für E-Mails sinnvoll ist. Der zweite Gruppentyp ist die Verteilergruppe, welche nur für ne E-Mail-Zuweisung gut ist. Diese erzeugen nämlich keinen Token-Eintrag und sind deshalb nicht für Rechtezuweisungen gedacht.