Servolution Logon
Client for OS/2
Technische Beschreibung
September 2000
Version 1.0 – Build 1.0.0.14
Inhaltsverzeichnis
Vorschlag für den Einsatz von
Policy Files in Verbindung mit dem Servolution Logon Client:
Bild
5. LAN-Server Gruppen Verwaltung
Bild
6. LAN-Server Benutzer Berechtigungen.
Bild
7. LAN-Server Benutzer Verbindungen
Bild 8. LAN-Server Benutzer
Homedirectory
Bild 10. Windows Workstation „net
use“
Bild 12. Policy Editor GINA Template
Bild 13. Policy Editor GINA und Windows Templates
Bild 14. Policy Editor GINA
Konfiguration
Servolution
OS2 Logon Client Modul für Windows 2000 1.0
Build
1.0.0.14
(english
und german)
September.
2000, Michael Wagner, PC-Services GmbH Wien
(mailto:michael.wagner@pcservices.at)
Der
Servolution Logon Client ermöglicht es für NT 4.0 und Windows 2000
Workstations, sich an einen OS/2 Server anzumelden.
Achtung, Build 1.0.0.13 ist nur unter
Windows 2000 lauffähig.
Er
wurde für große Umgebungen entwickelt, in denen die Benutzerverwaltung und das
File- und Print-Service auf OS/2 Servern betrieben und im Frontoffice Windows
2000 eingesetzt wird.
In
diesen Netzwerken besteht kein Bedarf an GUI’s für Installation und
Konfiguration auf der Anwenderseite, hingegen sind Funktionen wie zentrale
Konfiguration und einfache Möglichkeit der SW-Verteilung sehr wichtig.
Genau
für diesen Einsatzbereich wurde der Servolution Logon Client entwickelt, er ist
aber auf Grund seiner sehr einfachen Handhabung auch für den Einsatz in kleinen
Netzwerken geeignet.
LAN Server 4.0, 5.0, WARP Server oder WARP
Server for e-business (German od. UK)
Protokoll NetBEUI
NT 4.0 mind. SP6, W2K Professional (German
od. UK)
Protokoll NetBEUI (NetBIOS over TCP/IP)
Die Datei pcs_gina.reg anpassen
und das Programm Setuplc.exe Ausführen.
Für Installationen über SW-Verteilung die
Datei install.cmd ausführen.
Für die
Installation sind lokale Administrator-Rechte notwendig!
Neustart des Systems.
Alle Einstellungen werden in der Registry
unter dem Key "HKEY_LOCAL_MACHINE\SOFTWARE\PCS\GINA" verwaltet.
Das Programm Setuplc.exe
Ausführen.
Für Installationen über SW-Verteilung die
Datei uninstall.cmd ausführen.
Für die Deinstallation sind lokale
Administrator-Rechte notwendig!
Definiert den vollen Pfad des Policy-Files.
z.B.:
"PolicyPath"="%OS2_LOGONSERVER%\\netlogon\\ntconfig.pol"
Damit wird der Pfad für das Default Profile
festgelegt. Kann das angegebene Verzeichnis nicht gefunden werden, wird das
lokale Default Profile verwendet.
z.B.:"DefaultUserProfile"="%OS2_LOGONSERVER%\\netlogon\\default
profile"
"HomeDirDrive"="H:"
Sollte in der LAN Server Domäne kein
Laufwerksbuchstabe definiert sein, wird dieser Laufwerksbuchstabe verwendet.
Sollte in der LS Domäne kein Homedirektory
definiert sein, wird versucht, diese Netzwerkpfad als HomeDirektory zu
verbinden.
z.B.:
"HomeDirPath"="%OS2_LOGONSERVER%\\%USERNAME%"
Achtung: Der Parameter
"HomeDirDrive" muss definiert sein!
Dieses Script wird beim Initialisieren von
Windows mit System-Privilegs ausgeführt
Z.B.:“InitScript"="c:\cmd\init.cmd"
Dieses Script wird beim Logon mit
System-Privilegs ausgeführt.
z.B.:"SystemLogonScript” =
“c:\cmd\system.cmd"
Dieses Script wird beim Logon im User
Environment mit System-Privilegs ausgeführt.
z.B.:"SysUsrLogonScript“=“c:\system.cmd"
Dieses Script wird beim Logon im User
Environment mit User-Privilegs ausgeführt.
z.B.:"UserLogonScript"="%OS2_LOGONSERVER%\ibmlan$\dcdb\users\%USERNAME%\profile.cmd"
Dieses Script wird beim Logon im User
Environment mit Admin-Privilegs ausgeführt.
z.B.:"UserLogonScript"="%OS2_LOGONSERVER%\ibmlan$\dcdb\users\%USERNAME%\profile.cmd"
Dieses Script wird beim Logoff im User
Environment mit User-Privilegs ausgeführt.
z.B.:"UserLogonScript"="%OS2_LOGONSERVER%\ibmlan$\dcdb\users\%USERNAME%\profile.cmd"
"UserLogoffScriptErrorlevel"=dword:00000000
Ist dieser Wert „1“, wird der Errorlevel des
UserLogoffScripts abgefragt, und bei ungleich „0“ wird der Logoff abgebrochen.
Dieses Script wird beim Logoff im (das User
Envrionment ist nicht mehr vorhanden) mit System-Privilegs ausgeführt.
z.B.:
"systemLogoffScript"="c:\cmd\cleanup.cmd"
Script |
Zeitpunkt und Reihenfolge der Ausführung |
lokale
Berechtigung |
Einvironment |
Zugriff auf
Netzwerk-ressourcen |
Zugriff auf
HKEY_CURRENT_USER |
Zugriff auf
HKEY_LOCAL _MACHINE |
InitScript |
System Boot |
System |
System |
Nein |
Nein |
Ja |
SystemLogonScript |
Logon (1) |
System |
System |
Nein |
Nein |
Ja |
AdminUsrLogonScript |
Logon (2) |
User mit
Lokalen Admin Rechten |
User |
Ja |
Nein |
Ja |
SysUsrLogonScript |
Logon (3) |
System |
User |
Nein |
Nein |
Ja |
UserLogonScript |
Logon (4) |
User |
User |
Ja |
Ja * |
Ja * |
UserLogoffScript |
Logoff (1) |
User |
User |
Ja |
Ja * |
Ja * |
SystemLogoffScript |
Logoff (2) |
System |
System |
Nein |
Nein |
Ja |
* Abhängig von der
effektiven User Policy
"DisablePasswordChange"=1
„0“ = Passwort ändern ist erlaubt (Das
Lanserver Passwort und das lokale Password werden geändert)
„1“ = Passwort ändern ist nicht erlaubt, der
User bekommt eine POP-UP Message, welche im Value "ChangePasswordInfo" definiert ist.
z.B:
„ChangePasswordInfo“=“Passwort ändern ist
unter Windows nicht erlaubt, nur über Web-Interface!“
"ForceUnlockTime"= 258
Damit wird die Zeit in Sekunden definiert, in
welcher ein “Abmelden erzwingen” im gesperrten Zustand möglich ist.
Ist Dieser Wert „0“, ist diese Funktion
deaktiviert.
"ScriptTimeout"=19
Dieser Wert definiert die Sekunden, die auf
die Scripts gewartet wird.
"DisplayWError"=1
Ist dieser Wert „1“, werden interne Fehler über
ein POP-UP ausgegeben, ist dieser Wert „0“, werden die Fehler nur in das File
%systemroot%\gina.log geschrieben.
Diese Funktion kann auch im Logon Dialog, mit
gleichzeitigem Drücken der Taste „L-SHIFT“ und Klicken mit der linken Maustaste
in den Dialog ein oder ausgeschaltet werden.
"PrefDomain"="OS2DOMT"
Gibt die Standard Domäne an, welche im Logon
Dialog immer angezeigt wird.
(siehe Bild 1.)
"DisplayProgressBox"=dword:00000001
Damit kann die ProgressBox ein- bzw.
ausgeschaltet werden.
"RoamingUserGroup"="USERS"
Über eine Gruppenmitgliedschaft am LAN Server
kann gesteuert werden, ob der User ein Roaming Profile verwendet oder nicht.
Mit diesem Wert kann die jeweilige Gruppe
definiert werden.
Z.B. am LAN Server wird eine Gruppe mit dem
Namen ROAMINGP definiert, und nur die User, die ein Roaming Profile im
Homedirectory bekommen sollen, werden Mitglied dieser Gruppe.
"RoamingUserGroup"="ROAMING"
Ist dieser Wert auf die Gruppe “USERS”
gesetzt, werden alle User, die als User am LAN Server definert sind, als
RoamingUser behandelt.
(siehe Bild 5.)
"Language"="german"
Damit wird die Dialog Message definiert.
Es kann zwischen „english“ und „german“
gewählt werden.
Der Logon Client überprüft beim Start von
Windows, ob alle notwendigen Dienste bereit sind, erst dann wird ein OS2 Logon
möglich.
Kann z.B. der Workstationdienst nicht gestartet
werden, kommt eine Fehlermeldung, und es wird auf die Microsoft Gina
umgeschaltet.
Nach Angabe im Logon Dialog (siehe Bild 1.)von Username, Passwort, Domäne und Bestätigung durch ENTER oder OK,
wird der OS2 Logon gestartet.
Zuerst wird ein Domain Controller für die
angegebene Domäne und den User gesucht.
Kann diese nicht gefunden werden, wird ein
lokaler Loginversuch auf ein bereits lokal vorhandenes Userprofil angeboten und
bei richtigem Passwort durchgeführt.
Wird ein OS/2 Domain Controller gefunden,
wird das Passwort am am LAN Server
geprüft.
Stimmt die User/Passwort Kombination am LAN
Server, wird ein LAN-Server Logon durchgeführt
(siehe Bild 9)und
der lokale User wird vorbereitet.
Ist noch kein lokaler Benutzer vorhanden,
wird dieser mit selbem Usernamen und Password angelegt. Die
Gruppenmitgliedschaft am LAN Server wird abgefragt, und nach Möglichkeit auch
auf lokale Gruppen zugewiesen. (siehe Bild 5.)
Z.B. ist der User am LAN Server in der Gruppe
„Hauptbenutzer“, wird er auch lokal Mitglied der Gruppe „Hauptbenutzer“.
Für LAN Server 4.0 (max 8 Zeichen für Gruppen
und User Definition) wird die Abfrage der Gruppen „PUSERS“ und „WSADMIN“ je
nach Betriebsystemsprache auf die lokalen Gruppenmitgliedschaften von
Hauptbenutzern/Administratoren durchgeführt bzw. auf die lokalen Gruppen Power
User/Administrators übertragen.
Z.B.: Ist der User in der LS Domäne Mitglied
der Gruppe WSADMIN, wird er Mitglied der lokalen Gruppe Administratoren.
Diese Gruppenmitgliedschaften lassen sich
beliebig erweitern und werden bei jedem Logon auch auf bereits existierende
User aktualisiert.
Build 1.0.0.3:
Manuell erstellte Benutzer können durch LAN
Server Einstellungen keine Gruppenmitgliedschaften verlieren.
Dynamische Shares für Homedirectories am LAN
Server werden bei Bedarf freigegeben.
Die User-Assingments, Aliases und Printer,
der LS Domäne werden abgearbeitet und verbunden.
Der Desktop wird für den User freigegeben.
(siehe Bild 7., Bild 8 und Bild 10.)
Handelt es sich um einen Roaming User, wird
das lokale User-Profil mit dem am Server gespeicherten Profil (\\Server\Homedir\profile)
synchronisiert.
Ein ein LAN-Server Logoff wird durchgeführt (siehe Bild 9)
Die Policy Funktionalltät von NT 4.0 ist
unter Windows 2000 weiterhin funktionsfähig.
Sie wurde zwar von den GPO’s, welche im
Active Directory verwaltet werden, abgelöst. Steht aber kein ADS zu Verfügung, muß auf die alte klassische Policy
Methode zurückgegriffen werden.
Für die Verwaltung von Win2000 Workstations
müssen die Templates „winnt.adm“ und „common.adm“ von einem Windows 2000 Server
verwendet werden.
PolicySettings, welche in den sogenannten
„*.pol“ Files definiert sind, werden abgearbeitet, d.h. beim Logon Prozess
werden Policy Settings für „default Computer“ in den HIVE „HKEY_LOCAL_MACHINE“
und Policy Settings für „default User“ in den „HIVE HKEY_CURRENT_USER“
aktualisiert.
Settings im HIVE „HKEY_LOCAL_MACHINE“ werden
im Registry-File “system” gespeichert und sind benutzerunabhängig.
Settings im HIVE „HKEY_CURRENT_USER“ werden
im Profil des jeweiligen Benutzers abgespeichert (File: ntuser.dat).und wandern
bei einem Roaming-User-Konzept mit dem User mit.
WICHTIG: Policy Settings müssen in beide Richtungen berücksichtigt werden,
d.h. möchten Sie eine bereits gesetzte Policy wieder aufheben, reicht es nicht,
das Policy File vom Server zu entfernen. Policy Settings müssen durch neue
Policy Definitionen wieder zurückgesetzt werden.
Im Policy Editor („poledit.exe“ im
Lieferumfang von NT 4.0 Server, oder NT Server Ressource Kit) passiert das
mit den Schaltflächen, welche drei Modi annehmen können:
Feld ist grau: Kein Eintrag im Policy File,
alles bleibt, wie es ist.
Feld ist angehakt: Der Policy Eintrag wird
aktiviert.
Feld ist weiß: Der Policy Eintrag wird in die
Gegenrichtung aktiviert.
Bei Textfelder muß bei einer neuen
Wertzuweisung das Feld angehakt bleiben
Der LogonClient übergibt beim Logon den
vollen Pfad des Policy-Files, welches im Parameter „PolicyPath“
defniert ist, dem Winlogon Prozess.
Dieses File sollte auf jedem Domain
Controller im selben Share mit Leserechten für alle freigegeben sein.
Die Verwendung des Directory Replicator Service wird empfohlen. Daher
ergibt sich z.B. dieser Pfad: „%OS2_LOGONSERVER%\netlogon\ntconf1.pol“
Da alle Parameter des Logon Clients im MACHINE HIVE der Registry
gespeichert sind, kann die Konfiguration auch über Policy Settings erfolgen.
Dafür muss zuerst das Template „pcs_gina.adm“ im Policy Editor geladen
werden.(siehe Bild 12.)
Dann kann mit dieser Schablone die Lokale Registry geöffnet werden, z.B.
für die Lokale Konfiguration und Tests mit dem Logon Client. (siehe Bild 11).
Durch Klicken auf „Local Computer“ werden die Logon Clients Einstellungen
angezeigt. (siehe Bild 14.)
Änderungen werden durch die Menüauswahl "Datei, Speichern" in der
lokale Registry aktualisiert.
Diese Änderungen werden erst beim nächsten OS/2 Logon vom Logon Client
übernommen.
Für eine zentrale Verwaltung muss entweder ein bestehendes Policy File
geöffnet werden, oder ein neues erstellt werden. (Achtung: Bestehende Policy
Files immer mit den gleichen Templates öffnen!).
Mit dieser Funktion haben Sie die Einstellung des Logon Clients zentral
unter Kontrolle.
Möchten Sie zusätzliche Policy Einstellungen für die Windows Workstation
verwalten, müssen bei der Erstellung des Policy Files die Windows Schablonen
zusätzlich geladen werden. (siehe Bild 13).
Das Zuorden von Policy Einstellungen für bestimmte Benutzer oder Gruppen
ist nicht möglich.
Durch das Definieren von mehreren Gruppen und deren Zuweisung
unterschiedlicher Policy Files, kann jedoch eine individuelle Verwaltung
erreicht werden.
Die Environment Variable USER_PRIV wird
abhängig von den LAN Server Gruppen-Mitgliedschaft gesetzt:
Benutzer ist Mitglied der LS Gruppe |
USER_PRIV erhält den Wert |
Lokale Gruppen Mitgliedschaft |
-, USERS, keine zusätzliche Gruppen
Definition |
USER |
Benutzer/Users |
PUSER |
PUSER |
Hauptbenutzer/Power User |
WSADMIN |
WSADMIN |
Administratoren/Administrators |
USER_PRIV erhält den Wert |
Lokale Gruppen Mitgliedschaft |
ADMIN |
Administratoren/Administrators |
Benutzer, Hauptbenutzer, Workstation Administratoren sollen
verschiedene Policy Einstellungen erhalten.
Über die LAN Server Gruppenmitgliedschaft und der Definition
mehrere Policy Files läßt sich diese Funktionalität realisieren.
Es werden vier Policy Files mit dem Policy Editor (Poledit.exe,
Lieferumfang NT/W2K Server, für die Verwaltung von W2K Arbeitsstationen muß der
Poledit 5.0 und die Schablonen von einem W2K Server verwendet werden) erstellt,
und auf alle OS/2 Domain Controller im Netlogon Share freigegben.
User.pol, puser.pol, wsadmin.pol, admin.pol.
Der Parameter PolicyPath wird mit
Verwendung der USR_PRIV Variable gesetzt.
.:
"PolicyPath"="%OS2_LOGONSERVER%\\netlogon\\%USER_PRIV%.pol"
WICHTIG! Alle vier Policy Files müssen exact die selben Policy
Settings berücksichtigen.
z.B.: Benutzer soll das Ausführen der Registry Tools verboten
werden, somit muß dieses Setting im Policy-file: user.pol gesetzt sein und bei allen anderen wieder
zurückgesetzt werden (kästchen ist angehakt oder weiß, NICHT grau!).
Mit der Tasten Kombination SHIFT + ENTER
im Logon Dialog kann auf die Microsoft Gina umgeschaltet werden.
Damit wird ein Modus erreicht, der sich
verhält, als würde der Logon Client nicht installiert sein.
Diese Funktion ermöglicht einem Benutzer das Login (das Profil des
jeweiligen Benutzers wird geladen) mit lokalen Administratorrechten.
Der Benutzer wird temporär ( nur
für diese Sitzung) Mitglied der lokalen Administratorgruppe.
Mit diesem Modus können Einstellungen am Benutzerprofil, Installationen von
SW-Pakten oder Wartungs- arbeiten vorgenommen werden.
Aus Sicherheitsgründen muß zuerst der
Anwender wie gewohnt seine Benutzer ID und Passwort im Logon Dialog eintragen.
(siehe Bild 1) Anstelle der Bestätigung mit „ENTER“
od. „OK“ kann nun ein Administrator mit gedrückter linken „CTRL“ Taste und
Klick auf das „SERVOLUTION“ Logo den Adminlogon Dialog aktivieren.
Es erscheint ein weiterer Dialog, in dem der
Administrator aufgefordert wird, seinen Benutzernamen und sein Passwort
einzugeben.(siehe Bild 2)
Nun wird zuerst überprüft, ob der
Administrator Account in der OS/2 Domäne gültig ist und mind. „Account
Operator“ Rechte besitzt (siehe Bild 6),
dann wird ein Login des angegebenen
Benutzers mit lokalen Administratorrechten durchgeführt.
Diese Spezifikation wird in der
SW-Entwicklung verwendet, wenn
jener Bestandteil von Windows NT
bzw W2K ersetzt werden soll, der das
Identifizieren und Authentisieren der
interaktiven Benutzer durchführt. Diese austauschbare Funktionalität wird
als dynamic-link library (DLL) zu
Verfügung gestellt, von WINLOGON.EXE geladen und aufgerufen. Diese DLL wird als
“Graphical Identification and Authentication” oder
GINA bezeichnet.
GPO steht für “Windows 2000
Group Policy”.
SAS steht für “Secure Attention
Sequence”, welche im Standardfall über die Tasten Kombination „Strg+Alt+Del.”
ausgelöst wird.