Anpassungsmöglichkeiten

Wie in früheren Versionen bietet der CRANIX verschieden Anpassungsmöglichkeiten.

1 Netzwerkkonfiugration anpassen

Die Netzwerkkonfiugration des Transportnetzes kann man einfach mit dem yast2 lan modul oder durch die Anpassung der Konfigurationsdateien in /etc/sysconfig/network/ erledigen. Auf einem CRANIX-Server müssen jedoch noch folgende Änderungen durchgeführt werden:

• /etc/hosts extip-Eintrag muss geändert werden.
• /etc/sysconfig/cranix Folgende Variablen müssen angepasst werden: CRANIX_SERVER_EXT_GW, CRANIX_SERVER_EXT_IP, CRANIX_SERVER_EXT_NETMASK
• Anschließend apache2 neu starten: systemctl restart apache2

Die Änderung der Konfiguration des internen Netzwerks kann mit einfachen Handgriffen überhaupt nicht bewerkstelligt werden. Wenn es doch erforderlich sein sollte, können Sie uns mit der Durchführung beauftragen.

2 Passwortüberprüfung

Grundsätzlich wird das Script /usr/share/cranix/tools/check_password_complexity.sh ausgeführt um die Qualität der Benutzerpasswörter zu überprüfen. Sowohl samba als auch cranix-api verwendet dieses Script. Das Verhalten dieses Scripts kann man durch die System-Variablen CHECK_PASSWORD_QUALITY, MINIMAL_PASSWORD_LENGTH und MAXIMAL_PASSWORD_LENGTH steuern. Ist CHECK_PASSWORD_QUALITY auf ‘’’yes’’’ gesetzt, gelten folgende Regeln:

• MINIMAL_PASSWORD_LENGTH und MAXIMAL_PASSWORD_LENGTH müssen eingehalten sein.
• Passwort muss mindestens ein Großbuchstaben enthalten.
• Passwort muss mindestens ein Kleinbuchstaben enthalten.
• Passwort muss mindestens einen Ziffer enthalten.
• /usr/sbin/cracklib-check muss das Passwort gut finden.

Möchte man völlig andere Regel verwenden, muss eine Ausführbare Datei namens /usr/share/cranix/tools/custom_check_password_complexity.sh erstellt werden, welche das zu überprüfende Passwort vom STDIN liest. Ist das Passwort nicht in Ordnung muss das Script den Grund in STDOUT liefern. Sonst darf keine Ausgabe erfolgen.

Auch wenn CHECK_PASSWORD_QUALITY auf no steht oder eigene Regel gelten, muss ein Passwort mindestens 6 Zeichen erhalten.

3 Gruppenrichtlinien mit CRANIX verteilen

Damit die, auf dem Server gespeicherte, Gruppenrichtlinien auf Windows-Domainmitgliedrechner aktiviert werden können, muss auf allen Clients der lokaler Benutzer Administrator aktiviert werden.

Seit Version 4 ist der CRANIX Server ein (fast) vollwertiger AD-Server. Als solcher speichert er für Windows-Domänen, Gruppenrichtlinien und verteilt diese automatisch an Domänenmitglieder (Windows-Clients). Gruppenrichtlinien ermöglichen es, spezifische Konfigurationen für Benutzer und Computer zu implementieren. Der CRANIX-Server selbst bietet keine Möglichkeiten GPO-s zu erstellen bzw zu bearbeiten. Diese Arbeit muss als Domänenadministrator von einem Windows-Client aus erledigt werden. Das dazu nötige Programm wird mit jedem Windows 10 Education oder Professional mitgeliefert muss jedoch als optionales Feature aktiviert werden. Melden Sie sich dazu als lokaler Benutzer Administrator an einem Windows-Domainmitgliedrechner an und führen Sie folgende Schritte aus:

• 

  Apps und Features starten

• 

  Optionale Features

• 

  Features zufügen

• 

  Gruppenrichtlinien-verwaltung installieren

Wichtig Um optionale Features aktivieren zu könne muss das Windowsupdateservice laufen. Bitte beachten Sie, dass dieser Dienst auf CRANIX-Clients durch SALT beim Hochfahren ausgeschaltet wird, wenn die globale Variable ALLOW_WINDOWS_UPDATES auf no gestellt ist. Sie können den Dienst von der Konsole des Servers mit folgendem Befehl starten:

 salt  "FQHN-des-Clients" crx_client.enableUpdates

3.1 Ein Gruppenrichtlinienobjekt erstellen

Wie man ein Gruppenrichtlinienobjekt erstellt, zeigen wir Ihnen an einem konkreten Beispiel. Im Juli 2016 hat Microsoft ein Update veröffentlicht, um Sicherheitsprobleme im Windows-Druckspooler zu beheben. Dieses Update ändert das Verhalten und schränkt Unterstützung für nicht paketfähige Druckertreiber ein. Im Oktober 2016 hat Microsoft ein Update veröffentlicht, um diese Probleme in einem AD-Umgebung zu entschärfen. Weitere Einzelheiten finden Sie unter MS16-087. Dieser Abschnitt beschreibt das Verfahren zur Umgehung dieses Problems. Diese GPO muss auf jeden CRANIX Server erstellt werden, damit der Server für Windows-Clients Druckertreiber verteilen kann. Es muss ein neues Gruppenrichtlinienobjekt mit zwei Gruppenrichtlinien (Point-and-Print-Einschränkungen und Point-and-Print-Pakete-Genehmigte-Server) in folgenden Schritten erstellt werden:

1. Starten Sie die Gruppenrichtlinienverwaltung:
2. Öffnen Sie den Pfad Gruppenrichtlinienverwaltung -> Gesamstruktur -> Domänen -> Domänenname.
3. Durch Rechtsklick auf den Domänenname öffnet sich ein Kontextmenü. Gruppenrichtlinienobjekt hier erstellen und verknüpfen... wählen.
4. Als Name für das neue Gruppenrichtlinienobjekt Legacy Printer Driver Policy eintragen.
5. Durch Rechtsklick auf den neuen Eintrag Legacy Printer Driver Policy öffnet sich ein Kontextmenü. Wählen Sie hier bearbeiten um eine neue Gruppenrichtlinie zu erstellen. Dadurch wird der Gruppenrichtlinieneditor gestartet.
6. Öffnen Sie den Pfad Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Drucker
7. Doppelklick auf den Eintrag Point-and-Print-Einschränkungen. Folgende Einstellungen müssen vorgenommen werden:
   1. Aktiviert
   2. Benutzer können Point-and-Print nur mit folgenden Server verwenden: anhacken.
   3. Vollqualifizierte Servernamen eingeben. Hier printserver.<IHR-DOMAINNAME> eingetragen.
   4. Beim Installieren von Treibern für eine neue Verbindung -> Warnung oder Anhebungsaufforderung nicht anzeigen.
   5. Beim Aktualisieren von Treibern für eine vorhanden Verbindung -> Warnung oder Anhebungsaufforderung nicht anzeigen.
   6. OK drücken.
8. Doppelklick auf den Eintrag Point-and-Print für Pakete - Genehmigte Server und nehmen Sie folgende Einstellungen vor:
   1. Aktiviert
   2. Vollqualifizierte Servernamen eingeben Hier printserver.<IHR-DOMAINNAME> eintragen.
   3. OK drücken.
9. Doppelklick auf den Eintrag Beschränkt die Installation von Druckertreiber auf Administratoren
   1. Deaktiviert
   2. OK drücken.
10. Ab Win11 H22:
    1. Die Einstellung Konfigurieren von RPC-Verbindungseinstellungen -> Aktivieren
    2. Die Einstellung Für ausgehende RPC-Verbindungen zu verwendendes Protokoll -> RPC über benannte Pipes
11. Gruppenrichtlinieneditor beenden
12. Gruppenrichtlinienverwaltung beenden

• 

  Gruppenrichtlinienverwaltung starten

• 

  Neues GPO Erstellen

• 

  Name des neuen GPO

• 

  Point-and-Print-Einschränkungen

• 

  Point-and-Print-Einschränkungen Einstellungen

• 

  Point-and-Print-Pakete - Genehmigte Server

• 

  Point-and-Print für Pakete - Genehmigte Server eintragen

• 

  Beschränkt die Installation von Druckertreiber auf Administratoren

• 

  Beschränkung deaktivieren

Nun wird das neue Gruppenrichtlinienobjekt auf dem Server in Sysvol geschrieben. Diese wird nach einer gewisser Zeit auf allen laufenden Rechner in der Domäne automatisch aktiviert. Um die neue Richtlinien sofort zu aktualisieren,

• müssen die Clients neu starten
• oder der Domänen-Administrator muss auf dem Client folgenden Befehl ausführen:

gpupdate /force 

• Sie können den Befehl allerdings auch an alle salt-minions ausliefern:

salt '*' cmd.run 'gpupdate /force'

4 Pluginskripten

Bei verschieden Aktionen werden sog. Pluginscripten am CRANIX gestartet. Solche Aktionen sind das Erstellen, Ändern und Löschen von verschiedenen Objekten über die Adminoberfläche, die Auf und Abbau von Verbindungen zu den verschiedenen Freigaben des CRANIX-Server bzw. das Starten von Clients die als salt-Minion an CRANIX angemeldet sind.

Die Pluginskripten befinden sich auf dem CRANIX unter /usr/share/cranix/plugins in verschiedenen Verzeichnissen.

Der CRANIX selbst liefert einige Plugins die zur Funktionsfähigkeit des Server zwingend erforderlich sind. Diese Scripte soll man weder löschen noch ändern, da diese beim Updates neu erstellt werden. Die von CRANIX gelieferten Pluginkripten fangen immer mit "100" an. Will man selbst Skripten kann man den Ausführungszeitpunkt durch den Namen steuern. Möchte man ein eigenes Skript nach dem vom CRANIX ausführen lassen, muss dieses Script mit einem Zahl größer als 100 anfangen.

4.1 Objekt-Plugins

Die Objekt-Pluginscripten werden durch das Programm /usr/share/cranix/plugins/plugin_handler.sh aufgerufen und liegen in Ordner mit den Namen der Objektaktionen. Für folgende Objektaktionen existieren Pluginscripten.

• add_device
• add_group
• add_printer_queue
• add_room
• add_user
• change_member
• delete_device
• delete_group
• delete_hwconf
• delete_printer_queue
• delete_room
• delete_user
• manage_printer_queue
• modify_device
• modify_group
• modify_user
• reset_device

Die Scripten lesen die Daten aus dem STDIN. Die Daten haben folgendes Format:

<parameter1>: <value1>
<parameter2>: <value2>
usw.

4.2 Share-Plugins

Die Pluginscripten für die Freigaben befinden sich in im Verzeichnis /usr/share/cranix/plugins/shares/ und werden folgender Weise sortiert:

/usr/share/cranix/plugins/shares/<Share-Name>/<Aktion>

Es gibt zwei Aktionen: open oder close. Die Share-Pluginscripten werden mit folgenden Argumenten aufgerufen:

1. Uid des Benutzers
2. IP-Adresse des Clients
3. Arhitektur des Clients
4. Hostname des Clients
5. Kerberos/AD Realm

4.3 Client-Plugins

Die Client-Pluginskripten befinden sich im Verzeichnissen

/usr/share/cranix/plugins/clients/<Atkion>

Wobei Aktion lost start present sein kann. Die Client-Pluginskripten werden mit dem Minionnamen (normaler Weise ist das der FQHN des Clients) als Argument aufgerufen.

5 Automatische Konfiguration mit Salt

Salt wird vom CRANIX u.a. für die Softwareverteilung benutzt und ist daher auf dem System vorhanden und vorkonfiguriert. Das vorhandene System beruht auf einem sogenannten Environment namens base. Es ist möglich, ein zweites, völlig unabhängiges Environment namens z.B. schule aufzusetzen und in diesem Environment die automatische Konfiguration von Client-Rechnern an die eigene Schule durchzuführen.

5.1 Eigenes Salt-Environment

Die Datei

/etc/salt/master.d/crx.conf

enthält die Variable file_roots, die um die Zeilen für das eigene Environment ergänzt werden muss:

file_roots:
  base:
    - /srv/salt
    - /srv/salt/packages
  schule:
    - /srv/salt/schule

Damit das neue Environment auch korrekt verwendet wird, muss noch in der Datei

/etc/salt/master

die Zeile

top_file_merging_strategy: merge_all

eingebaut werden. Diese Zeile ist vorhanden, aber auskommentiert.

Nach einem Neustart des salt-master ist das System einsatzbereit.

systemctl restart salt-master
systemctl restart crx_salt_event_watcher

5.2 Verwendung des eigenen Environments

Im folgenden wird beschrieben, wie das Environment zur Konfiguration von Linux-Clients verwendet werden kann.

• Linuxrechner_am_OSS_ab_Version_4.0
• Automatische Konfiguration mit salt