Bei der Verwendung von Windows-Netzlaufwerken (Shares) unter Linux ist einiges zu beachten, um eine reibungslose Funktion sicherzustellen.
Neben den verschiedenen Methoden einen Mount unter Linux generell zu realisieren, sind auch einige Eigenheiten von Windows/Linux zu beachten.

Diese Anleitung beschreibt einige gängige Varianten, um Windows-Netzlaufwerke unter Ubuntu einzubinden und liefert unter Anderem auch Beispiele für die Nutzung mit der FAUAD.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden root-Zugriff auf den Rechner und allgemeine Kenntnisse im Umgang mit der Linux-Konsole vorausgesetzt.

Für Varianten mit Kerberos Authentifizierung ist die Einrichtung Kerberos erforderlich.
Entsprechende Hinweise zur Konfiguration von Kerbero finden Sie unter „Kerberos Grundkonfiguration„.

Pakete

Die folgenden Pakete müssen installiert werden.

CIFS unter Ubuntu 20.04 und höher

Für das Common Internet File System (CIFS) werden folgende Pakete benötigt.

bash$ sudo apt-get install cifs-utils

GVFS unter Ubuntu 20.04 und höher

Für Gnome Virtual Filesystem (GVFS) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install gvfs gvfs-bin gvfs-backends gvfs-fuse

FUSE unter Ubuntu 20.04 und höher

Für Nutzung des Filesystem in USErspace (FUSE) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install fuse

Besonderheiten zu Windows Distributed File Services (DFS) und der FAUAD

Windows (und damit auch die FAUAD) nutzen ein Feature namens Distributed File Services (DFS), um die von diversen Shares genutzten Pfade auf konkrete Dateiserver zu Mappen, die dann letztendlich den Dienst stellen. DFS-Pfade erkennt man an der Nutzung von fauad.fau.de als Servernamen.

Leider ist die Unterstützung dieses Features in den Linux-Implementierungen des CIFS-Protokolls nicht komplett integriert. Der empfohlene Workaround ist die direkte Nutzung der entsprechenden Dateiserver anstatt des DFS-Pfades (inkl. der genannten Nachteile bei Umstellungen).

Detaillierte Erklärung

Der Vorteil dieses Systems liegt daran, das bei Umzug eines Dateidienstes auf einen neuen Server lediglich das Mapping des bestehenden DFS-Pfades angepasst werden muss. Alle angebundenen Clients bleiben von der Änderung verschont, da diese weiterhin den ungeänderten DFS-Pfad nutzen und über das angepasste Mapping automatisch auf den neuen, aktualisierten Dateiserver geleitet werden.

Speziell wird in der FAUAD eine Aufteilung der Rechner auf mehrere Sites vorgenommen, die von der aktuellen CIFS Implementierung nicht beachtet wird. Daher kommt es bei Nutzung von DFS-Pfaden in CIFS-Mounts zu dem geht/geht-nicht Phänomen – je nachdem, ob man zufällig auf einem Domänenkontroller in der richtigen Site landet, oder eben nicht.

Einrichtung

Mountvorgänge für das Common Internet File System (CIFS) mittels mount.cifs können in der Regel nur mit root-Rechten durchgeführt werden.
Der Zugriff kann dann – je nach Dateirechten – als normaler Benutzer erfolgen.

Um auch als unprivilegierter Benutzer Netzlaufwerke einhängen zu können stehen ebenfalls verschiedene Möglichkeiten zur Verfügung. Zum Beispiel ermöglicht das Gnome Virtual Filesystem (GVFS) schon seit längerem das Einbinden von diversen Netzlaufwerkstypen über die graphische Oberfläche ohne besondere Rechte. Als Grundlage des gvfs-fuse Moduls soll auch das Filesystem in USErspace (FUSE) nicht unerwähnt bleiben.

Die Folgenden Abschnitte zeigen wie man die häufigsten Anwendungsfälle mit den verschiedenen Tools  bewältigen kann und geht auf Vor- und Nachteile, sowie die Besonderheiten der Lösungen ein.

Zunächst kann man zwischen zwei großen Hauptkategorien unterscheiden: systemweites oder benutzerbezogenes Einrichten eines Netzlaufwerkes

Systemweite Einrichtung

Das systemweite Einhängen von Netzlaufwerken ermöglicht den Zugriff durch alle Benutzer des Systems (passende Benutzer-/Dateirechte vorausgesetzt), kann aber nur als Administrator mit root-Rechten vorgenommen werden.

Manuelles Einhängen mit dediziertem Benutzer

Ein einfaches Beispiel ist das Einhängen mittels des mount Befehls auf der Konsole.

# mount
bash$ sudo mount -t cifs -o user=$USER,uid=$UID,gid=0,file_mode=0660,dir_mode=0770,domain=FAUAD,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte
Password for $USER@//projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share: ********

# check rights (uid/gid are mapped as access rights for the mountpoint)
bash$ ls -aldn /mnt/projekte
drwxr-xr-x 2 $UID 0 0 Mai 15 14:08 /mnt/projekte/

# umount
bash$ sudo umount /mnt/projekte

Der Einhängepunkt ist so zwar generell durch den Benutzer uid=$USER und alle Mitglieder der Gruppe gid=0 nutzbar, allerdings gelten auf dem Dateiserver lediglich die Rechte des Benutzers user=$USER mit dem der Mount aufgebaut wurde, egal welcher Benutzer auf Client-Seite den Zugriff durchführt.

Zudem ist der Mount nicht persistent, wird also nach Verlust des Mounts nicht wiederhergestellt.

Manuelles Einhängen mit Kerberos-Authentifizierung

Im Prinzip funktioniert dieser Mount ähnlich dem vorhergehenden, mit dem Unterschied, das die Authentifizierung gegen den Dateiserver diesmal nicht mit manuell einzugebenden Daten und nur einem Benutzer erfolgt.
Stattdessen kann jeder per Kerberos authentifizierte Benutzer des System mit den Rechten seines eigenen Prinzipals auf den Dateiserver zugreifen.
Siehe hierzu auch Kerberos Grundkonfiguration zur Einrichtung von Kerberos auf Ihrem System.

bash$ sudo mount -t cifs -o domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte

Möglich wird dies durch die Option multiuser:

multiuser
Map user accesses to individual credentials when accessing the server. By default, CIFS mounts only use a
single set of user credentials (the mount credentials) when accessing a share. With this option, the client
instead creates a new session with the server using the user’s credentials whenever a new user accesses the
mount. Further accesses by that user will also use those credentials.  Because the kernel cannot prompt
for passwords, multiuser mounts are limited to mounts using sec= options that don’t require passwords.

Nach erfolgreichem Mount können nun alle per Kerberos authentifizierten Benutzer des Systems auf das Netzlaufwerk mit ihren eigenen Benutzerrechten zugreifen.
Allerdings ist der Mount noch immer nicht persistent und wird bei einem Verbindungsabbruch nicht wiederhergestellt.

Automatisches Einhängen mit autofs

AutoFS ermöglicht die das automatische Ein- und Aushängen von Netzlaufwerken bei Bedarf und ermöglicht es auch Mounts nach Verbindungsabbrüchen wiederherzustellen.
Beachten Sie bitte hierzu  bitte zunächst die Hinweise zum Betrieb von AutoFS am RRZE.

Ein zu den bisherigen Beispielen passender Eintrag in der Datei /etc/auto.proj könnte zum Beispiel wie folgt aussehen:

bash$ sudo vi /etc/auto.proj
projekte -fstype=cifs,domain=FAUAD,sec=krb5,multiuser,cruid=$UID,noserverino,nodfs,vers=2.1 ://projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share

Vergessen Sie nicht nach Änderungen der Konfiguration den autofs Dienst neu zu starten.

Die Verwendung von AutoFS ist vom RRZE für die meisten Fälle empfohlen.

Benutzerbezogene Einrichtung

Das benutzerbezogene Einhängen von Netzlaufwerken ermöglicht lediglich den Zugriff durch den aktuellen Benutzer und kann ohne Administratorrechte durchgeführt werden.

Halbautomatisches Einhängen mittels GVS

Siehe  Gnome Samba Client.

Um Softwarepakete auf Debian-basierten Systemen (wie zB Ubuntu) zu verwalten kommt in der Regel das Paketverwaltungsystem rund um APT (Advanced Packaging Tool) zum Einsatz.  Dieses sehr mächtige System bietet eine Reihe von Möglichkeiten Pakete zu installieren und aktuell zu halten.

Diese Anleitung beschreibt das vom RRZE empfohlene Vorgehen im Umgang mit der APT Paketverwaltung und gibt Lösungsvorschläge für einige häufig auftretende Szenarien.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte, bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden grundlegende Kenntnisse im Umgang mit Ubuntu und der Kommandozeile vorausgesetzt.

Die Verwendung der erweiterten Funktionen wird nur erfahrenen Anwendern empfohlen.

Pakete

Folgender Pakete für Ubuntu 16.04/18.04 müssen installiert werden:

bash$ sudo apt-get install apt

Basisfunktionen

Hier soll auf die wichtigsten Kommandos und Abläufe im täglichen Umgang mit der APT Paketverwaltung eingegangen werden.
Weitere Informationen finden Sie auch auf der Ubuntu APT Übersichtsseite.

Paketquellen einrichten und aktualisieren

Die Konfiguration der APT Paketquellen findet sich unter /etc/apt/sources.list bzw. /etc/apt/sources.list.d/.

Sollten hier Erweiterungen um neue Paketquellen vorgenommen werden, empfiehlt es sich eine neue Datei mit thematisch passendem Namen und der Endung .list unter /etc/apt/sources.list.d/ anzulegen und die entsprechenden Repositories dort zu erfassen.
Die Datei /etc/apt/sources.list wird eher für die System-/Basiskonfiguration der Ubuntu Paketquellen verwendet und sollte nicht für externe Repositories „missbraucht“ werden.

Sobald Änderungen an den Paketquellen vorgenommen wurden oder die letzte Aktualisierung schon eine Weile her ist sollten die Paketinformationen aktualisiert werden bevor neue Pakete installiert oder Aktualisierungen eingespielt werden.

Die Aktualisierung der Paketquellen erfolgt mittels

bash$ sudo apt update

Pakete finden/installieren/entfernen

System aktuell halten

Einzelne Pakete von der Aktualisierung ausnehmen

Regelmäßige Aufräumarbeiten

Erweiterte Funktionen

Die hier beschriebenen Funktionen sollten nur von erfahrenen Anwendern verwendet werden, die wissen was sie tun.

Paketversion festziehen / Updates verhindern

Um Updates von Paketen zu verhindern können diese auf hold gesetzt werden:

bash$ sudo apt-mark hold firefox

Oder zum erneuten freigeben für Updates:

bash$ sudo apt-mark unhold firefox

Siehe auch https://wiki.ubuntuusers.de/apt/apt-Kommandos/ für weitere Informationen.

Priorisierung von Paketen und Paketquellen mit Apt-Pinning

Ein wesentlich mächtigeres Werkzeug um zu steuern wie Pakete installiert werden, ist das Apt-Pinning.
Hier kann in einer oder mehreren Konfigurationsdateien unter /etc/apt/preferences.d/ das Verhalten von APT beeinflusst werden.

TODO

Siehe auch https://wiki.ubuntuusers.de/Apt-Pinning/ für weitere Informationen.

Werte für Pin-Priority

Die Werte für Pin-Priority müssen positive oder negative ganze Zahlen sein. Sie werden wie folgt interpretiert:

• größer 999: Version wird in jedem Fall installiert, auch wenn das einen Downgrade des Paketes nach sich zieht
• von 990 bis 999 – Version wird installiert, auch wenn sie nicht zum Release gehört, es sei denn ein aktuelleres Pakete ist bereits installiert
• von 500 bis 989 – Version wird installiert, es sei denn, es gibt eine Version, die zum Release gehört oder eine aktuellere Version ist bereits installiert
• von 100 bis 499 – Version wird installiert, es sei denn, es gibt eine aktuellere die nicht zum Release gehört oder die bereits installierte Version ist aktueller
• von 1 bis 99 – Version wird nur dann installiert, wenn es keine bereits installierte gibt
• negativer Wert – Version wird nicht installiert

Das Paket mit der höchsten Punktzahl wird immer bevorzugt.

Beispiel: Pakete aus externen PPAs beschränken (inkl. erzwungenem Downgrade)

Diese Beispiel schlägt eine Möglichkeit vor, wie der Einfluss von externen Paketquellen eingeschränkt werden kann.
Besonders ist hier die Nutzung der Pin-Priority > 1000, um ebenfalls ein Downgrade bereits eingeschleppter Fremdpakete auf die offiziellen Ubuntu Versionen möglich zu machen.

bash$ sudo vi /etc/apt/preferences.d/LP-PPA

# Manually deployed packages in the RRZE RepRepo instance
Package: *
Pin: release o=RRZE Reprepro
Pin-Priority: 2000

# Saltstack PPA
Package: *
Pin: release o=SaltStack
Pin-Priority: 2000

# The local source (e.g. manually installed packages or packages that are not in any repo anymore)
Package: *
Pin: release a=now
Pin-Priority: 1900

# Ondrej Apache2 PPA
Package: *
Pin: release o=LP-PPA-ondrej-apache2
Pin-Priority: 1500

# Ondrej PHP PPA
Package: *
Pin: release o=LP-PPA-ondrej-php
Pin-Priority: 1500

Package: openssl
Pin: release o=LP-PPA-*
Pin-Priority: -1

# Official "Ubuntu" repos
Package: *
Pin: release l=Ubuntu
Pin-Priority: 1000

Um Systeme mit sensiblen Daten vor unbefugtem Zugriff zu schützen, können beim RRZE besondere Netzzugriffsfilter (ACLs) beantragt werden, die über netzseitige Hardware-Firewalls realisiert werden. In manchen Fällen kann es dennoch sinnvoll sein zusätzlich eine lokale Firewall zu pflegen, um zum Beispiel erhöhte Sicherheitsanforderungen oder sich häufig ändernde Regeln abbilden zu können.

Diese Anleitung beschreibt das vom RRZE empfohlene Anlegen und Verwalten einer IP-Tables basierten lokalen Firewall unter Ubuntu.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden Kenntnisse im Umgang mit Firewalls im Allgemeinen und IP-Tables im Speziellen vorausgesetzt.

Pakete

Die folgenden Pakete müssen installiert werden.

Ubuntu 16.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Ubuntu 18.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Einrichtung

Das netfilter-persistent Paket liefert bereits einige Möglichkeiten, um Firewall-Regeln aus dem laufenden Betrieb zu persistieren und beim Systemstart wieder zu laden.
Eine kurze Einführung in die wichtigsten Funktionen finden Sie unten.
Für weitere Informationen besuchen Sie am besten die Ubuntu Manpage zu netfilter-persistent

Systemdienst einrichten

Der netfilter-persistent Dienst wird über die Plugins in /usr/share/netfilter-persistent/plugins.d/ konfiguriert.
Die Aufrufe des Init-Systems werden im Wesentlichen an alle verfügbaren Plugins der Reihe nach weitergereicht.

Der netfilter-persistent Dienst kennt die folgenden Aufrufe:

# Load firewall rules from /etc/iptables/rules.v[4|6]
# IMPORTANT: stop can be called but is essentially a no-op
bash$ sudo systemctl start netfilter-persistent

# Flush the firewall rules
bash$ sudo netfilter-persistent flush

# Show some status info
bash$ sudo systemctl status netfilter-persistent

# Enable loading of configured rules on startup
bash$ sudo systemctl enable netfilter-persistent

Regeln erstellen/persistieren

Um Firewall Regeln zu erstellen nutzt man am besten die iptables Kommandos, um die Firewall manuell zu konfigurieren.
Eine bestehende Konfiguration kann dann mittels

bash$ sudo systemctl save netfilter-persistent

gespeichert werden.
Nach dem Speichern kann die Konfiguration in den Dateien /etc/iptables/rules.v4 bzw /etc/iptables/rules.v6 wiedergefunden werden.
Weitere Änderungen können – dem Format folgend – auch direkt in diesen Dateien vorgenommen werden.

Beim Systemstart wird die Firewall aus den Regeln dieser Dateien wieder aufgebaut.

Regeln flushen/Firewall deaktivieren

Um die Regeln der Firewall komplett zu entladen und somit die Firewall zu deaktivieren, kann man entweder das entsprechende netfilter-persistent Kommando oder direkt IP-Tables verwenden.
WICHTIG: Ein Stoppen des netfilter-persistent Dienstes bewirkt kein deaktivieren der Firewall!

bash$ sudo netfilter-persistent flush
bash$ sudo iptables -F

Erweiterung um benutzerdefinierte Skripte

Um es beispielsweise zu ermöglichen, dynamische Firewallregeln aus einem Bash-Skript zu laden oder zu generieren kann auch der Plugin-Mechanismus von netfilter-persistent, um ein Plugin zum Aufruf eines entsprechenden Bash-Skriptes erweitert werden.

Die beiden nötigen Dateien samt Inhalt können nach folgender Anleitung erstellt werden.
Im Anschluss nicht vergessen die entsprechenden Regeln zu definieren!

Skript für benutzerdefinierte Regeln

# create rules.custom skript and fill it with your firewall rules/generation script
bash$ sudo touch /etc/iptables/rules.custom
bash$ sudo chmod +x /etc/iptables/rules.custom
bash$ sudo vi /etc/iptables/rules.custom 
#!/bin/bash
set -e 
rc=0

load_rules() {
        # add config here
        echo "Called load_rules()!"   
}

flush_rules() {
        # add config here
        echo "Called flush_rules()!" 
}

case "$1" in
start)
        load_rules
        ;;
stop|flush)
        flush_rules
        ;;
*)
    echo "Usage: $0 {start|stop|flush}" >&2
    exit 1
    ;;
esac

exit $rc

Plugin für netfilter-persistent

# create netfilter-persistent plugin to execute your rules.custom script
bash$ sudo vi /usr/share/netfilter-persistent/plugins.d/99-custom
#!/bin/sh
set -e
rc=0

load_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to load)"
	else
		/etc/iptables/rules.custom start 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

flush_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to flush)"
	else
		/etc/iptables/rules.custom flush 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

case "$1" in
start|restart|reload|force-reload)
	load_rules
	;;
save)
	echo "Warning: skipping save_rules on rules.custom - not supported!"
	;;
stop)
	# Why? because if stop is used, the firewall gets flushed for a variable
	# amount of time during package upgrades, leaving the machine vulnerable
	# It's also not always desirable to flush during purge
	echo "Automatic flushing disabled, use \"flush\" instead of \"stop\""
	;;
flush)
	flush_rules
	;;
*)
    echo "Usage: $0 {start|restart|reload|force-reload|save|flush}" >&2
    exit 1
    ;;
esac

exit $rc

Test

Testen Sie die korrekte Initialisierung der Firewall einfach mit

bash$ sudo iptables -L

Das RRZE stellt für die FAU den Windows-Druckserver FAUPRINT bereit, der zum authentifizierten Drucken auf den angeschlossenen Geräten genutzt werden kann.
Für RRZE-betreute Geräte stellt dies die empfohlene Art der Anbindung dar und ist auch für Linux-Systeme empfohlen.

Die Nutzung von FAUPRINT erlaubt das authentifizierte Drucken auf Geräten, für die Sie die entsprechenden Berechtigungen besitzen. Optional ist auch eine Abrechnung bzw. Verwaltung von Druckkontingenten über die Software Papercut möglich (aktuell nur für CIP-Pools / Studierende). Hierfür fallen allerdings zusätzliche Kosten an.
Kontaktieren Sie uns diesbezüglich gerne für weitere Informationen.

Die Authentifizierung erfolgt wahlweise per IdM-Benutzername und Kennwort oder Kerberos.

Voraussetzungen

Pakete für Ubuntu ab 20.04

# one-liner
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get -y install samba-common samba python3-smbc smbclient

Kerberos

Voraussetzung für die Nutzung der Kerberos-Authentifizierung ist eine funktionierende Grundkonfiguration von Kerberos für Ihr System. Falls noch nicht geschehen, führen Sie bitte die entsprechenden Einrichtungsschritte wie beschrieben durch, bevor Sie dieser Anleitung weiter folgen.

Achten Sie besonders darauf, dass auch die folgenden Anpassungen durchgeführt wurden:

bash$ cat /etc/krb5.conf
...
[domain_realm]
    fauprint.rrze.uni-erlangen.de = FAUAD.FAU.DE
    fauprint2.rrze.uni-erlangen.de = FAUAD.FAU.DE
    wisoprint.wiso.uni-erlangen.de = FAUAD.FAU.DE
    wisoprint2.wiso.uni-erlangen.de = FAUAD.FAU.DE
...

Des Weiteren muss für das Drucken über Kerberos ein angepasster ksmb Backend-Handler installiert werden.
Der folgende Handler ist für die Verwendung mit FAUPRINT angepasst und kann nicht als allgemeiner Handler verwendet werden.

bash$ sudo vi /usr/lib/cups/backend/ksmb

#!/bin/bash
if [ $# -eq 0 ]; then
 echo "network ksmb ""Unknown"" ""Windows Printer via SAMBA using Kerberos"""
 exit 0
fi

REALM=FAUAD.FAU.DE
LOGFILE=/var/log/cups/krb5-smb_log
LOGPREFIX="[$$]"

CUPSBACKENDPATH=${0%/*}

# Options: smbspool {job} {user} {title} {copies} {options} [filename]
BACKEND_JOB="$1"
BACKEND_USER="$2"
BACKEND_TITLE="$3"
BACKEND_COPIES="$4"
BACKEND_OPTIONS="$5"
BACKEND_USERID=$(id -u "$BACKEND_USER")

# fix handling in case multiple ccache files are available
# Use newest as authentication source
KRB5FILE=$(find /tmp/ -mindepth 1 -maxdepth 1 -name "krb5cc_*" -user "$BACKEND_USER" -printf "%A@ %p\n" | sort -n | tail -n 1 | cut -d' ' -f2-)

if [ -z "$KRB5FILE" ]; then
 echo "$LOGPREFIX: ERROR: No valid credential cache found" >> "$LOGFILE"
 echo "$LOGPREFIX: exit 2 (CUPS_BACKEND_AUTH_REQUIRED)" >> "$LOGFILE"
 exit 2 # CUPS_BACKEND_AUTH_REQUIRED
fi
export KRB5CCNAME="FILE:$KRB5FILE"

# Dirty hack: Required if cross-realm ticket does not (yet) exist
DEVICE_URI_NOPREFIX="${DEVICE_URI#*//}"
PRINC="${DEVICE_URI_NOPREFIX%%/*}"
kvno cifs/$PRINC@$REALM >> "$LOGFILE"

# DEVICE_URI *must* begin with "smb://" otherwise odd errors will occur
export DEVICE_URI="smb://${DEVICE_URI_NOPREFIX}"

# Settings can be passed from backend to scheduler using
# stderr. Look here for details ("Communicating with the Scheduler"):
# https://www.cups.org/doc/api-filter.html
BACKEND_STDERR=$(${CUPSBACKENDPATH}/smb "$BACKEND_JOB" "$BACKEND_USER" "$BACKEND_TITLE" "$BACKEND_COPIES" "$BACKEND_OPTIONS" 2> /dev/stdout > /dev/null)
BACKEND_EXIT=$?

echo "$BACKEND_STDERR" | sed -e s+^+"$LOGPREFIX: stderr: "+ >> "$LOGFILE"

# Prevent smb backend from re-enabling username/password authentication
BACKEND_STDERR=$(echo "$BACKEND_STDERR" | sed 's/^ATTR: auth-info-required=.*/ATTR: auth-info-required=negotiate/')

echo "$BACKEND_STDERR" > /dev/stderr
exit "$BACKEND_EXIT"

Zuletzt nicht vergessen, die Rechte noch korrekt zu setzen.

bash$ sudo chmod 700 /usr/lib/cups/backend/ksmb

Konfiguration

Arbeitsgruppe konfigurieren

Damit die Authentifizierung an der FAUAD Domain klappt muss die Arbeitsgruppe auf dem Linux-Client entspechend konfiguriert werden:

bash$ sudo mv /etc/samba/smb.conf /etc/samba/smb.conf-$(date +%F)
bash$ sudo echo "[global]\n\tworkgroup = FAUAD\n" | tee /etc/samba/smb.conf
[global]
workgroup = FAUAD

Mit diesen Einstellungen können Kennungen bei Benutzung von SAMBA jetzt gegen die korrekte Domain authentifiziert werden.

Verfügbare Drucker finden

Das RRZE betreibt zur Lastverteilung mehrere Druckserver:

• fauprint.rrze.uni-erlangen.de
• fauprint2.rrze.uni-erlangen.de
• wisoprint.wiso.uni-erlangen.de
• wisoprint2.wiso.uni-erlangen.de

Um eine Liste der verfügbaren Drucker zu erhalten, können Sie eine entsprechende Abfrage an den FAUPRINT Druckdienst absetzen.

# mit Kerberos
bash$ kinit
...
bash$ smbclient -L fauprint.rrze.uni-erlangen.de --use-kerberos=required -N
Domain=[FAUAD] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]
Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
...

# ohne Kerberos
bash$ smbclient -L fauprint.rrze.uni-erlangen.de -U FAUAD/$USER
Enter FAUAD/$USER's password: 
Domain=[FAUAD] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]
Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
...

Suchen Sie in der Ausgabe nach Freigaben mit dem Typ Printer.
Diese können Sie dann im nächsten Schritt zur Bildung des Druckpfades verwenden.

Drucker hinzufügen

Informationen zur Einrichtung von CUPS Druckern inkl. einer Anleitung, um den richtigen Treiber zu finden, erhalten Sie unter CUPS Druckereinrichtung mit lpadmin

Im Folgenden sind einige Beispiele aufgeführt, um den Beispieldrucker aus oben genannter Dokumentation mit und ohne Kerberos-Authentifizierung einzurichten.
Der Unterschied besteht jeweils in der Einstellung für auth-info-required und dem verwendeten Backend Handler (jeweils fett hervorgehoben).

Beispiel 1

# mit Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd \
-o 'auth-info-required=negotiate' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "ksmb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035"

# ohne Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd \
-o 'auth-info-required=username,password' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035"

Beispiel 2

# mit Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rzpr-2035-lex-cs510de \
-m openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_CS510_Series.ppd \
-o 'auth-info-required=negotiate' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "ksmb://fauprint2.rrze.uni-erlangen.de/rzpr-2035-lex-cs510de" \
-D "Lexmark CS510de" \
-L "RRZE, 2.035"



# ohne Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rzpr-2035-lex-cs510de \
-m openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_CS510_Series.ppd \
-o 'auth-info-required=username,password' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint2.rrze.uni-erlangen.de/rzpr-2035-lex-cs510de" \
-D "Lexmark CS510de" \
-L "RRZE, 2.035"

Neben den verschiedenen grafischen Hilfsmitteln können CUPS Drucker auch vollständig über die Kommandozeile eingerichtet werden. Diese Art der Einrichtung lässt sich besser dokumentieren und nachstellen als die Nutzung der sich häufig ändernden grafischen Werkzeuge. Außerdem erleichtert dies auch die automatische Verteilung der Druckerkonfiguration über eine Konfigurationsverwaltung wie Saltstack oder Ähnliches.

Für betreute CIP-Pools oder Workstations können Druckerkonfigurationen nach Ihren Vorgaben auch automatisiert verteilt werden.
Kontaktieren Sie uns gerne für weitere Informationen.

Voraussetzungen

Pakete für Ubuntu 16.04/18.04

# one-liner 
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install cups-client

Verwendete Kommandos

lpadmin    https://www.cups.org/doc/man-lpadmin.html
lpinfo     https://www.cups.org/doc/man-lpinfo.html
lpoptions  https://www.cups.org/doc/man-lpoptions.html

Konfiguration

Beschreibung der Kommandos für verschiedene Einsatzszenarios.

Beispielhaft soll der Drucker Lexmark MX610de per FAUPRINT eingerichtet werden.

Generischen Druckertreiber finden/installieren

Um einen passenden Treiber im System zu finden kann man eine entsprechende Abfrage absetzen, wobei man den Hersteller und die Modellbezeichnung des Druckers als Suchparameter angibt.
Das Ergebnis ist eine Liste der passenden Treiber bestehend aus Pfad zur PPD-Datei und der Modellbezeichnung.
Da es sich bei unserem Beispiel-Modell um einen Lexmark MX610de handelt könnten wir den letzten Treiber aus der Liste wählen und den angegebenen PPD-Pfad in der weiteren Einrichtung verwenden.

bash$ lpinfo --make-and-model "Lexmark MX610" -m
foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610-Postscript.ppd Lexmark MX610 Foomatic/Postscript
openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:1/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:2/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:3/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd Lexmark MX610de Foomatic/Postscript

Herstellerspezifischen Druckertreiber finden/installieren

Sollte kein passender Treiber verfügbar sein, oder der vorhandene Treiber nicht die nötige Funktionalität bieten, kann man oft auf den Webseiten des Druckerherstellers auch für das jeweilige Modell spezifische Linux-Treiber herunterladen.
Dabei ist es oft nicht wichtig genau die richtige Software für eine bestimmte Distribution zu wählen. Es muss normalerweise sogar gar keine Software installiert werden.
Entscheidend ist irgendwie an die PPD-Datei zu kommen!

Für den Lexmark MX610de findet sich z. B. auch ein passender Treiber auf der Lexmark Homepage, den man nach dem extrahieren aus dem heruntergeladenen Archiv im System installieren und verwenden kann. Nach erfolgreicher Installation liefert die Abfrage liefert unter den schon bekannten Optionen auch den neu installierten Treiber.
Diesen verwenden wir nun in der weiteren Einrichtung des Druckers.

bash$ sudo cp /tmp/Lexmark_MX610_Series.ppd /usr/share/cups/model/
bash$ sudo chmod 644 /usr/share/cups/model/Lexmark_MX610_Series.ppd
bash$ lpinfo --make-and-model "Lexmark MX610" -m
...
Lexmark_MX610_Series.ppd Lexmark MX610 Series
...

Fehlende Druckerfilter installieren

Manchmal benötigen die Druckertreiber des Herstellers noch zusätzlich Filter zur Verarbeitung der Druckaufträge. Hinweise auf fehlende Filter geben häufig die Logdatei unter /var/log/cups/error_log oder auch die Statusanzeige des Druckers in den entsprechenden grafischen Benutzeroberflächen.

In diesem Fall war der fehlende Filter ebenfalls im heruntergeladenen Archiv des Herstellers enthalten und konnte nach dem Entpacken wie folgt nachinstalliert werden.

# Check the logfile for recent filter errors
bash$ sudo tail -n50 /var/log/cups/error_log | grep -i filter
E [03/May/2018:14:30:59 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/fax-pnh-filter\" nicht verfügbar: No such file or directory
E [03/May/2018:14:30:59 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/CommandFileFilterG2\" nicht verfügbar: No such file or directory
E [03/May/2018:14:31:56 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/CommandFileFilterG2\" nicht verfügbar: No such file or directory

# Install previously extracted filters
bash$ sudo cp /tmp/CommandFileFilterG2 /usr/lib/cups/filter/
bash$ sudo chmod 755 /usr/lib/cups/filter/CommandFileFilterG2

bash$ sudo cp /tmp/fax-pnh-filter /usr/lib/cups/filter/
bash$ sudo chmod 755 /usr/lib/cups/filter/fax-pnh-filter2

Der Drucker sollte jetzt funktionieren.

Drucker hinzufügen

Nach Auswahl des entsprechenden PPD-Pfades kann der Drucker nun im System angelegt werden.
Dabei können auch diverse Standardeinstellungen gleich mit angegeben werden.

Beispiel mit generischem Foomatic Treiber:

bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-o 'printer-is-shared=false' \
-o 'auth-info-required=none' \
-o 'media=A4' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035" \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd

Beispiel mit Treiber vom Hersteller:

bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-o 'printer-is-shared=false' \
-o 'auth-info-required=none' \
-o 'media=A4' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035" \
-m Lexmark_MX610_Series.ppd

Tests

Prüfen der Einstellungen

Anzeige der Einstellungen in einer Zeile:

bash$ lpoptions -p rrze-lexmark-mx610de
auth-info-required=negotiate copies=1 device-uri=ksmb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=ReportLevels,AutoConfigure printer-info='Lexmark MX610de' printer-is-accepting-jobs=true printer-is-shared=false printer-location='RRZE, R2.035' printer-make-and-model='Lexmark MX610 Series' printer-state=3 printer-state-change-time=1525351551 printer-state-reasons=none printer-type=10522836 printer-uri-supported=ipp://localhost/printers/rrze-lexmark-mx610de

Alternativ geht es auch etwas ausführlicher bzw. mit Anzeige von spezifischeren Einstellungen des Druckers:

bash$ lpoptions -p rrze-lexmark-mx610de -l
PageSize/Media Size: Letter Legal 8.5x13.4028 B5 *A4 Executive A5 A6 FanFoldGermanLegal Statement EnvMonarch Env9 Env10 EnvDL EnvC5 ISOB5 OthEnv Custom.WIDTHxHEIGHT
InputSlot/Media Source: *Tray1 Tray2 Tray3 Tray4 MultipurposeFeeder ManualPaper ManualEnv
OptDuplex/Duplexer: False *True
OptFlash/Flash: *False True
OptTray2/Tray 2: *False True
OptTray3/Tray 3: *False True
OptTray4/Tray 4: *False True
OptMultipurposeFeeder/Multipurpose Feeder: False *True
OptStapler/Staple: *False True
PnH/Print and Hold: *False Verify Repeat Reserve Custom.PASSCODE
FaxNumber/Fax Number: *False Custom.STRING
Duplex/Duplex: None *DuplexNoTumble DuplexTumble
Collate/Collation: *True False
SepPages/Separator Pages: *PrinterS NoneF Jobs Copies Pages
SepSource/Separator Source: *PrinterS Tray1 Tray2 Tray3 Tray4 MultipurposeFeeder
OutputBin/Output Bin: *PrinterS StandardBin
StapleJob/Staple Job: *PrinterS FalseM TrueM
LXResolution/Resolution: 1200dpi 604x600dpi *602x600dpi 600dpi
Halftone/Halftone: *PrinterS FalseF TrueF
TonerDarkness/Toner Darkness: *PrinterS 1 2 3 4 5 6 7 8 9 10
LexPixelBoost/Pixel Boost: *PrinterS False Fonts Horizontally Vertically BothDirections
LexMirror/Mirror: True *False
ColorMode/Color Mode: *PrinterS TrueM
LexBrightness/Brightness: PrinterS -6 -5 -4 -3 -2 -1 *0 +1 +2 +3 +4 +5 +6
LexContrast/Contrast: PrinterS *0 1 2 3 4 5
GrayCorrection/Gray Correction: *PrinterS Manual FalseM
MediaType/Paper Type: *PrinterS Plain Colored Transparency Card Labels Bond Letterhead Preprint RoughEnvelope Envelope Recycled Light Heavy Rough Custom1 Custom2 Custom3 Custom4 Custom5 Custom6
LexBlankPage/Print Blank Pages: *PrinterS False True

Das RRZE betreibt eine redundante LDAP-Server Infrastruktur mit dem primären Zweck der Authentifizierung von Benutzern angebundener Linux-Systeme. Obwohl dies der Haupteinsatzzweck ist, können prinzipiell auch andere Systeme/Software die Benutzerbasis zur Authentifizierung nutzen.

Diese Anleitung beschreibt die Voraussetzungen zur Nutzung des LinuxLDAP und den grundlegenden Aufbau der Daten im Verzeichnisdienst, so dass eine eigenständige Konfiguration der jeweils anzubinden Systeme/Software möglich ist.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Prüfen der Voraussetzungen

Bevor Sie weiter vorgehen, sollten Sie prüfen ob eine Anbindung ihres Systems/Software überhaupt sinnvoll möglich ist bzw. ob Sie eine Maschinenkennung benötigen oder nicht.

Restriktionen

Der RRZE LinuxLDAP Server gewährt keinen Zugriff auf die Passwort-Hashes der Benutzer!
Das bedeutet, das eine Authentifizierung nur mittels LDAP-BIND als der jeweils zu authentifizierende Benutzer möglich ist.

Einige Anwendungen bieten nur die Möglichkeit eine Art Admin-Zugang zum LDAP Server zu konfigurieren, um dann auf diesem Wege das Passwort des Benutzers mit dem im LDAP abgelegten Passwort zu vergleichen. Zum Schutz der Daten unserer Benutzer können wir diese Art der Authentifizierung nicht unterstützen.

Benutzerkennung vs. Maschinenkennung

Nach erfolgreichem LDAP-BIND haben Sie lesenden Zugriff auf Ihren eigenen Benutzereintrag im LDAP (und einige Teilbäume mit frei verfügbaren Daten, die hier keine Rolle spielen).
Neben diversen linuxspezifischen Attributen enthält der Benutzereintrag ebenfalls eine Liste der Gruppenzugehörigkeiten des Benutzers.

Sofern es Ihre Anwendung erlaubt, könnten Sie so bereits eine Benutzerauthentifizierung und Rechtevergabe basierend auf den Gruppenattributen des Benutzers einrichten.

In der Regel benötigen die meisten Anwendungen nach dem Login via LDAP-BIND jedoch (leider) einen Benutzer, mit dem Sie nach dem Posix-Standard (RFC2307) die Gruppenzugehörigkeiten mittels einer Suche über alle verfügbaren Gruppen ermitteln können. Sollte das bei Ihnen ebenfalls der Fall sein, so benötigen Sie einer Maschinenkennung, welche diese Rechte besitzt (siehe nächster Absatz).

Maschinenkennung für LinuxLDAP erhalten

Zur Regulierung des Zugangs zum LinuxLDAP wird eine sog. Maschinenkennung verwendet.
Die Maschinenkennung enthält den FQDN der Maschine auf dem Ihre Dienste laufen sollen und kann für alle Dienste auf diesem Rechner zur Authentifizierung gegen den LinuxLDAP verwendete werden.

Verwenden Sie eine spezifische Maschinenkennung nicht auf anderen Systemen!

Um eine entsprechende Maschinenkennung zu erhalten bzw. selbst anlegen zu können benötigen Sie einen Zugang als IT-Betreuer zu unserer Rechnerverwaltung. Wie Sie diesen erhalten und eine Maschinenkennung mittels unseres Kommandozeilentools anlegen können ist unter Installation des rrzelinux CLI Tools beschrieben.

Sofern Sie nicht selbst IT-Betreuer an Ihrer Einrichtung sind können Sie sich den Zugang auch von einem IT-Betreuer Ihrer Einrichtung anlegen und die Zugangsdaten aushändigen lassen.

Empfohlene Software

Um sich einen Überblick über die Struktur und des Verzeichnisdienstes zu schaffen und ggf. zu konfigurierende Suchfilter testen zu können empfehlen wir die Installation des Apache Directory Studio (ApacheDS).

Der  Download kann von der offiziellen Homepage unter http://directory.apache.org/studio/ erfolgen.
Wir empfehlen den Einsatz der letzten 1.x Version (1.5.3 zum Stand 12.07.2017), welche bei den „Older Versions“ unter http://directory.apache.org/studio/download-old-versions.html zu finden ist.

Anbindung

Im Folgenden wird kurz der Aufbau des Verzeichnisdienstes beschrieben und danach einige Tipps zur Anbindung einiger Software-Produkte gegeben.

Aufbau des Verzeichnisdienstes

Aus Sicherheitsgründen erlaubt der LinuxLDAP ausschließlich den SSL gesicherten Zugriff in den Varianten LDAPS und STARTLS.

Alle relevanten Daten zur Benutzerauthentifizierung und -authorisierung finden sich in den Teilbäumen people und group.

Daraus ergeben sich die folgenden Eckdaten:

Benutzereinträge

Benutzereinträge befinden sich flach im Teilbaum people.
Jeder Benutzer hat nach einem BIND Zugriff auf die Daten seines eigenen Eintrags.

Die wichtigsten Attribute sind:

Anmerkungen zum Attribut fauUidType

Neben der Hauptkennung existieren auch diverse Sonderkennungen wie kp (Kontaktpersonen), wm (Webmaster), fu (Funktionskennungen), usw.
Diese sind „unpersönlich“ und können somit unter bestimmten Umständen an andere Personen weitergegeben werden.

Der Wert user markiert persönliche IdM-Hauptkennungen. Diese bleiben für Ihre gesamte Lebenszeit mit derselben Person verbunden und können nicht weitergegeben werden.

In der Regel empfiehlt sich daher praktisch immer eine Filterung auf (fauUidType=user) vorzunehmen, um nur einen Login mittels der IdM-Hauptkennung zuzulassen.

Gruppeneinträge

Gruppeneinträge befinden sich flach im Teilbaum group.

Die wichtigsten Attribute sind:

Tipps zur Anbindung

Hier finden Sie eine Sammlung gängiger Konfigurationsparameter.
Die Sammlung kann in Zukunft ggf. noch wachsen.

Ein evtl. schon vorhandenes Kerberos Ticket kann auch über den Webbrowser zur Authentifizierung an Webseiten genutzt werden. Da der zentrale WebSSO Dienst der FAU diese Art der Authentifizierung unterstützt können somit alle angebundenen Webseiten ohne weitere Anpassungen ebenfalls davon Gebrauch machen.

Nach erfolgter Konfiguration Ihres Browsers, bedeutet dies, dass Sie automatisch via Kerberos am WebSSO Dienst der FAU angemeldet werden, sobald Sie auf eine entsprechend angebundene Webseite zugreifen – ohne zusätzliche Passworteingabe.

Voraussetzungen

Voraussetzung für diese Anleitung ist eine funktionierende Grundkonfiguration von Kerberos für Ihr System. Falls noch nicht geschehen, führen Sie bitte die entsprechenden Einrichtungsschritte wie beschrieben durch, bevor Sie dieser Anleitung weiter folgen.

Ob Ihr System korrekt konfiguriert ist, können Sie wie folgt prüfen.

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_Zn59m9
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting Expires Service principal
01.06.2017 14:30:51 02.06.2017 00:30:51 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

Der Aufruf von klist sollte eine ähnliche Ausgabe wie im Beispiel als Ergebnis liefern.

Konfiguration

In der Regel übermitteln die gängigen Webbrowser ein evtl. vorhandenes Kerberos Ticket aus Sicherheitsgründen nicht automatisch. Um die Übermittlung für bestimmte Domains freizuschalten bedarf es je nach Browser einiger spezieller Einstellungen.

In den unten aufgeführten Konfigurationsbeispielen wird jeweils der zentrale WebSSO Dienst der FAU freigeschalten. Für andere Dienste, die nicht das zentrale SSO nutzen sind zusätzliche Einträge erforderlich.

Mozilla Firefox

Zur Konfiguration von Mozilla Firefox gehen Sie bitte wie folgt vor.

• Geben Sie in die Adressleiste Ihres Browsers about:config ein
• Bestätigen Sie die Sicherheitswarnung
• Suchen Sie nach negotiate
• Passen Sie die folgende Einträge an

network.negotiate-auth.delegation-uris = .sso.uni-erlangen.de,.sso.fau.de
network.negotiate-auth.trusted-uris = .sso.uni-erlangen.de,.sso.fau.de

So sollte es am Ende aussehen.

Chromium

Zur Konfiguration von Chromium gehen Sie bitte wie folgt vor.

bash$ sudo vi /etc/chromium-browser/default
...
CHROMIUM_FLAGS="--auth-server-whitelist=.sso.uni-erlangen.de,.sso.fau.de --auth-negotiate-delegate-whitelist=.sso.uni-erlangen.de,.sso.fau.de"
..

Google Chrome

Zur Konfiguration von Google Chrome gehen Sie bitte wie folgt vor.

bash$ sudo mkdir -m 755 -p /etc/opt/chrome/policies/managed
bash$ sudo vi /etc/opt/chrome/policies/managed/kerberos.json 
{ 
     "AuthServerWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de", 
     "AuthNegotiateDelegateWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de" 
}
bash$ sudo chmod o+rx /etc/opt/chrome/policies/managed/kerberos.json