Das Network Time Protocol (NTP) ist ein Internetdienst, um Computeruhren in einem Netzwerk zu synchronisieren. NTP verwendet ein hierarchisches System unterschiedlicher Referenzuhren, die über das verbindungslose Transportprotokoll UDP (Port 123) miteinander Zeitangaben austauschen.

Das Rechenzentrum betreibt als primäre Referenz (Stratum 0) einen lokalen Funkempfänger und für die Bedienung des universitären Datennetzes vier NTP- oder Time Server. Die Hostnamen und IP-Adressen der vier Time Server des Rechenzentrums sind:

• ntp4.uni-augsburg.de (IP 137.250.1.40)
• ntp1.uni-augsburg.de (IP 137.250.2.254)
• ntp2.uni-augsburg.de (IP 137.250.2.253)
• ntp3.uni-augsburg.de (IP 137.250.1.41)

Der Domain Name Service (DNS) ist ein Internetdienst, um die für Menschen leicht verständlichen und einfach zu merkenden Hostnamen auf computerlesbare IP-Adressen abzubilden. Hostnamen bestehen aus Buchstaben und Ziffern. Bindestriche sind zugelassen, der Unterstrich nicht. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

Ein vollqualifizierter Hostname (FQDN) besteht aus dem Hostnamen und der Domäne. Beipiele hierfür sind:

• yams.rz.uni-augsburg.de
  Hostname: yams
  Domäne: rz.uni-augsburg.de
• www.uni-augsburg.de
  Hostname: www
  Domäne: uni-augsburg.de

Der Teil des Domain Name Service, der auf dem Client die Anfragen stellt, z.B. Wie lautet die IP-Adresse von www.uni-augsburg.de?, heißt Resolver. Die Antworten, in unserem Fall Die IP-Adresse lautet 137.250.2.227, liefern DNS- oder Domain Name Server.

Das Rechenzentrum betreibt für das universitäre Datennetzes vier Domain Name Server. Die IP-Adressen dieser vier Domain Name Server sind:

• 137.250.1.254
• 137.250.1.29
• 137.250.1.30
• 137.250.1.253

Um die Installation und die Aktualisierung von Debian- und Ubuntu-Linux-Rechnern zu beschleunigen, betreibt das Rechenzentrum einen Server ("APT-Proxy"), der die benötigten Installationspakete zwischenspeichert. Der APT-Proxy ist ein HTTP-Proxy und kann daher einfach in /etc/apt/apt.conf eingetragen werden:

Acquire::http::Proxy "http://apt.rz.uni-augsburg.de:8000";

Bei Rechnern, die per SUSI installiert wurden, ist dies bereits der Fall. An der sources.list müssen keine Änderungen vorgenommen werden. Bei Ubuntu ist es jedoch empfehlenswert, die gleichen Server einzutragen, die auch bei SUSI verwendet werden (de.archive.ubuntu.com bzw. security.ubuntu.com).

Das Rechenzentrum betreibt eine Datenbank, in der zu jeder RZ-Benutzerkennung Informationen wie UID-Nummer, Gruppenzugehörigkeit und Name gespeichert sind. Diese Datenbank kann per LDAP abgefragt werden und ermöglicht somit, daß diese Benutzerkennungen und Gruppen auf beliebigen Rechnern an der Universität verwendet werden können.

Diese Anleitung beschreibt, wie man die Datenbank abfragen kann und wie man sie für die Auflösung von Benutzer- und Gruppennamen unter Linux (am Beispiel von Ubuntu) verwendet.

Benutzer- und Gruppeninformationen abfragen

Die LDAP-Server sind unter folgenden Namen erreichbar:

• ldap2.rz.uni-augsburg.de
• ldap3.rz.uni-augsburg.de

Die Portnummern sind 389 (unverschlüsselt) bzw. 636 (TLS).

Beide Server enthalten die selben Informationen. Diese sind dort — ähnlich wie man es von Dateisystemen kennt — in einer hierarchischen Struktur gespeichert. Die Pfadkomponenten werden jedoch in umgekehrter Reihenfolge angegeben, d.h. ein Unterverzeichnis steht links von seinem übergeordneten Verzeichnis. Als Trennzeichen zwischen den Pfadkomponenten wird das Komma verwendet.

Die Benutzerobjekte findet man unter dem Pfad

„ou=users,dc=uaux,dc=de“.

Sie enthalten u.a. folgende Attribute:

• uid (Benutzerkennung)
• uidNumber (UID-Nummer)
• gidNumber (GID-Nummer der Primärgruppe)
• homeDirectory (Homeverzeichnis)

Die Informationen zu einer Benutzerkennung kann man beispielsweise mit dem Kommandozeilenprogramm ldapsearch aus dem Paket „ldap-utils“ folgendermaßen abfragen:

ldapsearch -xh ldap2.rz.uni-augsburg.de -b ou=users,dc=uaux,dc=de -s one '(uid=Benutzerkennung)'

Das letzte Argument ist hierbei der sog. Search Filter, d.h. das Kriterium für die Suche in der Datenbank. Hier kann eine Bedingung für ein beliebiges Attribut angegeben werden.

Die Benutzerobjekte liegen unter dem angegebenen Pfad in einer flachen Struktur, d.h. es müssen keine Unterverzeichnisse durchsucht werden. Daher genügt hier eine „one-level“-Suche („-s one“). Die Option „-x“ bewirkt, daß sich ldapsearch ohne Passwort am Server anmeldet. Die LDAP-Server können ohne Authentifizierung abgefragt werden.

Die Gruppeninformationen liegen nach Organisationseinheiten (OUs) strukturiert unter

„ou=idmorg,dc=uaux,dc=de“.

Das Gruppenobjekt „rzserv-m“ beispielsweise hat den Pfad

„cn=rzserv-m,ou=_groups,ou=rzserv,ou=rz,ou=idmorg,dc=uaux,dc=de“,

denn es gehört zur OU „rzserv“, die eine unter-OU von „rz“ ist. Daher ist hier eine „subtree“-Suche notwendig („-s sub“):

ldapsearch -xh ldap2.rz.uni-augsburg.de -b ou=idmorg,dc=uaux,dc=de -s sub '(cn=rzserv-m)'

Ein Gruppenobjekt enthält die folgenden Attribute (memberUid kann beliebig oft vorkommen und enthält jeweils eine einzige Benutzerkennung):

• cn (Name der Gruppe)
• gidNumber (GID-Nummer)
• memberUid (Benutzerkennung eines Mitglieds)

Umsetzung zwischen Benutzer- bzw. Gruppennamen und UID- bzw. GID-Nummern

Um RZ-Benutzerkennungen auf einem Linux-System verwenden zu können, muß der Rechner die Benutzer- und Gruppennamen in die entsprechenden Nummern umsetzen können (und umgekehrt). Unter Ubuntu genügt hierfür die Installation des Pakets „uaux-nss-ldap“ und das Ausführen des Kommandos „uaux-nss-ldap enable“ als root:

apt-get install uaux-nss-ldap uaux-nss-ldap enable

Nun sollten Sie mit „id RZ-Benutzerkennung“ jede RZ-Benutzerkennung auflösen können.

Das Paket „uaux-nss-ldap“ kann aus dem Repository http://apt.rz.uni-augsburg.de/ubuntu/ bezogen werden, welches auf Rechnern, die per SUSI installiert wurden, bereits eingetragen ist.

Um die Namensauflösung zu beschleunigen, können Sie zusätzlich den „Name Service Cache Daemon“ (nscd) installieren, der die Ergebnisse der LDAP-Abfragen zwischenspeichert:

apt-get install nscd

Die Zunahme automatisierter Verfahren für Angriffe gegen Computersysteme fordert ein entschiedenes Vorgehen der für die Sicherheit gespeicherter Daten und genutzter Übertragungswege verantwortlichen Stellen. Eine dieser Maßnahmen bildet die Portfilterung, die von den DV-Betreuern der Fakultäten und zentralen Einrichtungen am 25.6.2003 beschlossen und vom Rechenzentrum am 19.11.2003 umgesetzt wurde. Die Filterung des Datenverkehrs erfolgt über Zugriffslisten am Grenzrouter des Datennetzes der Universität Augsburg zum X-WiN.

Eine Zugriffsliste, die den eingehenden Datenverkehr kontrolliert, besteht aus drei Blöcken und wird von einer default-deny Regel abgeschlossen. Jede gewünschte Verbindung muß explizit zugelassen werden (Whitelist). Ein Block gewährleistet den ungehinderten Datenverkehr der Verbindungen, die aus dem universitären Datennetz heraus initiiert werden. Zu diesem Block gehören die Internetdienste, die ohne Einschränkung auf allen Rechnern genutzt werden können. Gegenwärtig handelt es sich nur um das Remote Desktop Protocol (RDP) von Microsoft. Weiterhin sind VPN-Verbindungen nach außen freigegeben, d.h. die TCP/IP Protokolle Internet Key Exchange (IKE), Generic Route Encapsulation (GRE), Encapsulating Security Protocol (ESP) und Authentication Header (AH) unterliegen keiner Einschränkung. Schließlich benennen die DV-Betreuer aus ihrem Zuständigkeitsbereich die Server und deren Dienste, auf die von außerhalb, also aus dem Internet heraus, zugegriffen werden soll.

Die Zugriffsliste für den ausgehenden Datenverkehr besteht aus nur einem Block. In ihm werden die zu unterbindenden Internetdienste aufgeführt. Die Liste wird von einer default-permit Regel abgeschlossen, d.h. nicht ausdrücklich genannte Dienste sind zugelassen (Blacklist). Welche Dienste dies sind, bestimmt das Rechenzentrum in Absprache mit den DV-Betreuern. Der aktuelle Block ist der unten stehenden Tabelle zu entnehmen.

Der Typ 3 des Internet Control Message Protocol (ICMP) wird in beide Richtungen zugelassen. Die Kommandos ping und traceroute (unter Windows tracert) funktionieren unidirektional. Sie können lediglich für die Erreichbarkeit von Rechnern außerhalb des Universitätsnetzes eingesetzt werden. Des Weiteren gibt es Beschränkungen für den freien Datenverkehr beim Domain Name Service (Port 53), dem Simple Network Management Protocol (Ports 161 und 162), den Ports 111 und 1434 sowie dem Simple Service Discovery Protocol (Port 1900/UDP).

Unser Web-Single-Sign-On-System (WebSSO) bildet eine sichere Grundlage für personalisierte Web-Anwendungen, die ihre Nutzer anhand der RZ-Benutzerkennung authentifizieren wollen. Das Webauth genannte WebSSO-System erlaubt den Schutz von Dokumenten und Anwendungen im WWW gegen unberechtigten Zugriff. Erst nach einer erfolgreichen Authentifizierung, d.h. nach erfolgreicher Überprüfung der RZ-Benutzerkennung nebst zugehörigem Passwort, wird der personalisierte Zugriff auf die Dokumente und Anwendungen geprüft und ggf. freigegeben.

Was sind die Vorteile des Webauth-Systems?

1. Webauth ist bequem: Bei der Anmeldung über das Webauth-System handelt es sich um ein sogenanntes Single-Sign-On (SSO), d.h. Sie melden sich pro Sitzung nur einmal am Webauth-Server websso.uni-augsburg.de des Rechenzentrums an und nutzen im Anschluss alle in dieses Web-SSO-Verfahren integrierten Web-Anwendungen, ohne sich dort neu anzumelden.
2. Webauth ist sicher: Das Webauth-System wird vom Rechenzentrum zentral betrieben und die Verarbeitung Ihrer Anmeldedaten (RZ-Benutzerkennung und Passwort) erfolgt an zentraler Stelle auf einem abgesicherten System. Die Datenübertragung erfolgt gesichert (SSL/TLS) und Ihre Anmeldedaten gelangen nicht in die Hände Dritter. Die Web-Anwendung, für die Sie sich über das Webauth-System anmelden, kommt dabei insbesondere nicht(!) in Besitz Ihres persönlichen Passworts.
3. Webauth ist erweiterbar: Je mehr Web-Anwendungen von diesem zentralen Anmeldesystem Gebrauch machen, desto bequemer und sicherer wird deren Nutzung durch die Anwender. Betreiber (oder Entwickler) von Web-Anwendungen, die einen personalisierten Zugang über die RZ-Benutzerkennung der Universität Augsburg erfordern, können sich zur Planung jederzeit gerne an das Rechenzentrum wenden.

Anleitung der Web-Single-Sign-On Client-Installation

Das Web-Single-Sign-On der Universität Augsburg basiert auf WebAuth, welches ein Authentifizierungsmodul für den Webserver Apache zur Verfügung stellt. Diese Anleitung beschreibt Installation und Konfiguration des Moduls und des Webservers.

Vorarbeit

Um auf Ihrem Webserver Benutzer per WebAuth zu authentifizieren, benötigen Sie vom Rechenzentrum einen sog. Principal der Form „webauth/$HOSTNAME“ mit einem zugehörigen Passwort. Hierfür teilen Sie dem Kerberos-Admin ( aai@rz.uni-augsburg.de) im Rechenzentrum mit, auf welchem Rechner Sie einen WebAuth-Client betreiben möchten. Als $HOSTNAME sollte der FQDN des Rechners verwendet werden, insbesondere dann, wenn VirtualHosts mit unterschiedlichen Namen verwendet werden.

Im folgenden wird die Installation für Ubuntu Linux 18.04 am Beispiel des Rechners webauthclient.rz.uni-augsburg.de beschrieben. Da sie nur wenige distributionsspezifische Dinge enthält, sollte sie problemlos auch für andere Linux-Distributionen verwendbar sein.

Benötigte Software-Pakete installieren

root@webauthclient:~# apt-get install libapache2-mod-webauth libwebauth-perl krb5-user

In der Konfigurationsdatei /etc/krb5.conf muss lediglich der Kerberos-Realm eingetragen werden:

root@webauthclient:~# unexpand -a <<EOF >/etc/krb5.conf
[libdefaults]
        default_realm = UAUX.DE
EOF

Anschließend muss für den Principal ein sicheres Passwort gesetzt werden. Ein solches kann beispielsweise mit 'openssl rand -base64 33' generiert werden. Nach dem Setzen des Passworts muss dieses nur noch beim Erstellen der Keytab-Datei eingegeben werden (s.u.) und wird danach nicht mehr benötigt.

root@webauthclient:~# kpasswd webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE
Password for webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE: 
Enter new password: 
Enter it again: 
Password changed.

Jetzt kann ein Kerberos-Login mit dem neuen Passwort durchgeführt werden:

root@webauthclient:~# kinit webauth/webauthclient.rz.uni-augsburg.de
Password for webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE:

Mit „klist“ kann man prüfen, ob der Login erfolgreich war.

root@webauthclient:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE

Valid starting     Expires            Service principal
05/22/13 12:07:15  05/29/13 12:07:15  krbtgt/UAUX.DE@UAUX.DE

Für die nächsten Schritte braucht man die sog. „Key Version Number“, kurz KNVO.

root@webauthclient:~# kvno webauth/webauthclient.rz.uni-augsburg.de
webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE: kvno = 2

Bei einem frisch eingerichteten Rechner ist die KVNO nach der ersten Passwortänderung i. d. R. „2“. Mit dieser Information kann man mit „ktutil“ die Keytab-Datei anlegen. „-password“ ist hierbei ein Parameter, nicht das Passwort! „-k 2“ gibt die zuvor ermittelte KVNO an.

root@webauthclient:~# ktutil
ktutil:  addent -password -p webauth/webauthclient.rz.uni-augsburg.de -k 2 -e aes256-cts
Password for webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE:
ktutil:  l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2 webauth/webauthclient.rz.uni-augsburg.de@UAUX.DE
ktutil:  wkt /etc/webauth/keytab
ktutil:  exit

Der Apache muss die Keytab-Datei lesen können.

root@webauthclient:~# chmod 400 /etc/webauth/keytab
root@webauthclient:~# chown www-data.www-data /etc/webauth/keytab

Falls mehrere Apache-Instanzen unter verschiedenen Benutzern laufen, muss die Keytab-Datei für alle diese Benutzer lesbar gemacht werden.

Konfiguration für das WebAuth-Modul anlegen

root@webauthclient:~# unexpand -a <<EOF >/etc/apache2/mods-available/webauth.conf
WebAuthKeyring /var/lib/webauth/keyring
WebAuthKeytab /etc/webauth/keytab
WebAuthServiceTokenCache /var/lib/webauth/service_token_cache
WebAuthSSLRedirect on
WebAuthLoginURL https://websso.uni-augsburg.de/login
WebAuthWebKdcURL https://websso.uni-augsburg.de/webkdc/
WebAuthWebKdcPrincipal service/webkdc
WebAuthDebug Off
EOF

Apache-Module aktivieren

Um die Authentifizierungsinformationen sicher übertragen zu können, ist SSL erforderlich:

root@webauthclient:~# a2enmod webauth ssl
root@webauthclient:~# a2ensite default-ssl
root@webauthclient:~# ufw allow 443/tcp

Evtl. ist auch das Modul mod_authz_user nötig, z.B. für die Direktiven „Require user“ oder „Require valid-user“:

root@webauthclient:~# a2enmod authz_user

Falls der Zugriff auf eine IdM-Gruppe eingeschränkt werden soll, muss das Modul mod_authz_unixgroup installiert werden:

root@webauthclient:~# apt-get install libapache2-mod-authz-unixgroup
root@webauthclient:~# a2enmod authz_unixgroup

Außerdem muss in diesem Fall der Server die IdM-Gruppen auflösen können. Falls der Rechner per SUSI installiert wurde, lässt sich dies folgendermaßen einrichten:

root@webauthclient:~# apt-get install uaux-nss-ldap
root@webauthclient:~# uaux-nss-ldap enable

Bei anderen Linux-Distributionen müssen Sie die Konfiguration von Hand vornehmen. Am Beispiel von RHEL 7.1 geschieht dies folgendermaßen:

root@webauthclient:~# yum install nss-pam-ldapd nscd
root@webauthclient:~# patch <<EOF /etc/nslcd.conf 
18c18,19
< uri ldap://127.0.0.1/
---
> uri ldap://ldap2.rz.uni-augsburg.de
> uri ldap://ldap3.rz.uni-augsburg.de
143a145,150
>
> bind_timelimit 1
> base  passwd  ou=users,dc=uaux,dc=de
> scope passwd  one
> base  group   ou=idmorg,dc=uaux,dc=de
> scope group   sub
EOF

Nun muss in /etc/nsswitch.conf in den Zeilen, die mit passwd: oder group: beginnen, nach „files“ die Methode „ldap“ eingefügt werden, etwa so:

passwd:     files ldap sss
group:      files ldap sss

Anschließend müssen noch die Daemons nslcd und nscd aktiviert werden:

root@webauthclient:~# systemctl enable nslcd nscd
root@webauthclient:~# systemctl start nslcd nscd

Webseite schützen

Um eine Webseite per WebAuth zu schützen, muss in der Apache-Konfiguration der AuthType auf WebAuth gesetzt werden, beispielsweise folgendermaßen:

<Location /geheim>
  AuthType WebAuth
  Require valid-user
</Location>

Die Direktive „Require valid-user“ bewirkt, dass jeder authentifizierte Benutzer Zugriff erhält. Mit „Require unix-group“ lässt sich der Zugang auf IdM-Gruppen einschränken, z.B.:

  AuthType WebAuth
  Require unix-group rz-m rz-s

Entsprechend können mit „Require user“ auch einzelne Benutzerkennungen angegeben werden.

Alternativ kann man auch eine eigene Gruppe in einem GroupFile definieren. In diesem Fall ist das Modul authz_groupfile erforderlich, und es muss statt „Require unix-group“ die Direktive „Require group“ verwendet werden:

  AuthType WebAuth
  AuthGroupFile /web/groups
  Require group admin

Wahlweise kann WebAuth auch in .htaccess-Dateien konfiguriert werden. Hierfür müssen für die jeweiligen Verzeichnisse Autorisierungsdirektiven in .htaccess-Dateien durch die Apache-Konfiguration erlaubt sein:

  AllowOverride AuthConfig

Anschließend können die entsprechenden Direktiven in die .htaccess-Dateien eingetragen werden, beispielsweise:

  AuthType WebAuth
  Require user fluppi