UniNow – Bequem durch’s Studium?

UniNow liefert genau das, was viele Studierende sich schon lange wünschen: Eine App fürs Studium, die alles kann, unter einer Oberfläche. Sich nicht mehr an gefühlt tausend unterschiedlichen Systemen anmelden zu müssen, die zudem für eine mobile Ansicht häufig nicht geeignet sind. Toll.

Der Haken an der Sache? Die App stammt von keiner Uni, sondern von einem Drittanbieter. Diesem Anbieter müsst Ihr die Zugangsdaten zu Eurem Studierendenaccount anvertrauen, an dem mittlerweile eine ganze Reihe von Diensten hängen: Mail, Klips, Ilias, Wlan, VPN, Eduroam, SOFS, Softwareshop, lizenzierte Zugänge u.s.w. Dienste also, die sehr persönliche Daten beinhalten bzw. Dienste mit hohem Missbrauchspotenzial. Mit Euren Zugangsdaten wird sich UniNow dann mittels seiner Server bei den unterschiedlichen Diensten der Uni anmelden und Eure Daten abfischen. Dass die Weitergabe der Accountdaten gegen jegliche Benutzungsordnungen verstoßen, eine Exmatrikulation bzw. fristlose Kündigung zur Folge haben kann, soll hier jetzt gar nicht das Thema sein. Vielmehr soll es um den Schutz Eurer Daten gehen und Euren eigenverantwortlichen Umgang mit diesen.

Die Uni Köln betreibt ziemlich viel Aufwand, um Eure Daten vor unberechtigten Zugriffen zu schützen. Es ist zudem penibel reglementiert, was gespeichert werden darf und wer zu welchem Zweck Einsicht in Eure Daten erhält. Sobald an der Uni irgendetwas mit personenbezogenen Daten passieren soll, müssen Datenschutzbeauftragter und ggf. Personalrat in langen Verfahren diesem zustimmen. Ein Beispiel dazu aus dem Tagesgeschäft des Helpdesk: Diesen erreichen häufig Anfragen, Euch Euer Passwort des Studierendenaccounts zuzumailen, da Ihr dieses vergessen habt. Das wird aus vielerlei Gründen nicht passieren: Der Helpdesk hat keine Einsicht auf diese Daten. Selbst wenn, wäre das nutzlos, da das Passwort nur verschlüsselt vorliegt. Und zu guter Letzt würde der Helpdesk solch sensiblen Daten nie über eine ungesicherte Mailverbindung hinauspusten.

All solche Bemühungen um Datenschutz würden natürlich ad absurdum geführt, wenn Ihr freiwillig Eure Daten aus der Hand gebt. Als Ausweg aus diesem Dilemma bliebe letztendlich nur der Rückgriff auf eine „vertrauenswürdige“ App bzw. einer App, die wenigstens den gleichen Datenschutzbestimmungen unterliegt, wie alle anderen Dienste der Uni auch. Eine solche App gibt es aber noch nicht. Die Gründe hierfür sind vielfältig. Positiv ist zu erwähnen, dass die Uni Köln – über das RRZK sowie das Prorektorat für Lehre und Studium – zur Zeit gemeinsam mit anderen Hochschulen am Projekt „StApps“ arbeitet, welches die Erstellung eigener Uni-Apps zum Ziel hat. Mehrere Mitarbeiter wollen dafür sorgen, dass wir Euch diese App möglichst bald bereitstellen können.

Verschlüsselung dank Let’s Encrypt

Dank der Initiative „Let’s Encrypt“ kann nun jede(r) Betreiber(in) von Webseiten diese kostenfrei auch per https bereitstellen, also den Transportweg mit SSL verschlüsseln. Dies war zwar bislang auch mit anderen Anbietern möglich, aber die damit erstellten Zertifikate waren nicht in den gängigen Browsern vertreten, sodass beim ersten Besuch der Seite stets eine Warnmeldung erschien. Bei „Let’s Encrypt“ ist dies nicht mehr so.

Dementsprechend habe ich auch die Domains auf meinem eigenen privaten Server nun per https verfügbar gemacht. Eigentlich wollte ich an dieser Stelle eine kleine Anleitung verfassen, da ich mir meinen Erfolgsweg bei diversen Blog- und Foreneinträgen zusammengesucht hatte. Inzwischen habe ich aber einen Beitrag entdeckt, der exakt meine Vorgehensweise beschreibt, incl. mehrerer Domains in einem Server und Auto-Renew per Cronjob. Daher verweise ich unten auf diesen Artikel von Dominic Pratt und ergänze lediglich, dass man inzwischen das Auto-Renew auch einfacher machen kann, nämlich per Crontab-Eintrag á la:

30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log

Zudem sollte man unbedingt darauf achten, ausschließlich sichere Protokolle und Cipher Suites zu aktivieren. Leider unterstützen nicht alle Server und Clients automatisch die neuesten und besten Einstellungen. Ein guter Kompromiss ist derzeit im Apache z.B.:

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4

Damit erreicht man im SSL-Test (https://www.ssllabs.com/ssltest) immerhin Grade A. Besser ginge es noch bspw. mit der Aktivierung von Forward Secrecy.

Hier nun der angesprochene Artikel:

Let’s Encrypt nutzen – eine Anleitung

Passwörter mit Dashlane aufbewahren, einsetzen und synchronisieren

Meine Ausgangspunkt

Mein digitales Leben ist „geschützt“ durch gefühlt Zillionen von Passwörtern – faktisch sind es einige Hundert, aber mit Erinnerungsvermögen ist da nichts mehr zu machen. Bisher nutzte ich meinen Browser sowie eine lokale Anwendung auf meinem Smartphone zur Verwahrung dieser Credentials. Das war mehr schlecht als recht, denn mein Gerätebestand umfasst OS X, Android, Windows7 und iOS — alles in allem ein mittlerer Alptraum.

Dashlane „betritt“ mein digitales Leben

Ein Artikel von David Pogue [1][2] machte mich auf Dashlane aufmerksam. Das Tool behebt mein Problem inzwischen wirklich recht gut. Der „Migrationsaufwand“ war bei mir nicht wirklich vernachlässigbar, weil die Import-Funktion bei mir nicht so genial funktioniert hat – also knapp unter „Do What I Think“-Niveau. Auch das Sortieren der einzelnen Records nach Kategorien nervt (auch wenn es vernünftig ist).

Nach dieser Einstiegshürde ist Dashlane aber wirklich nützlich. Ich nutze die Anwendung nicht lokal, sondern synchronisiere darüber mein gutes halbes Dutzend Devices. Das funktioniert kostenlos für 30 Tage, danach nur mit einer kostenpflichtigen Subscription – Eine schwierige Abwägung zwischen Geiz und Komfort!

Meine Konfiguration ist nun so, dass ich Dashlane auf meinem Notebook, Arbeitsplatzrechner, Android-Smartphone, iPad und den privaten Rechnern nutze. Das Smartphone nutze ich auch als One-Time-Password-Generator (Google Authenticator).

Erfahrungen

Dashlane ist schon sehr pfiffig darin, Formulare richtig auszufüllen, aber David Pogues Beschreibung erscheint mir etwas zu euphorisch. Mir sind schon etliche Seiten untergekommen, bei denen die Logik nicht funktioniert. Bei englischsprachigen Seiten funktioniert das Auto-Ausfüllen aber gut.

Wirklich cool ist, dass man das Ausfüllen auf „Subdomains“ ausdehnen bzw. einschränken kann und die Möglichkeit mit mehreren Accounts für eine Website umgehen zu können. Nett ist auch die Möglichkeit, sichere Passwörter erzeugen zu lassen; nützlich sind die Hinweise auf vermutliche kompomitierte Web-Site, bei denen man Accounts hat. Das Wallet habe ich bisher wenig (aber erfolgreich) genutzt. Die anderen Features wie Nachrichten-Austausch und so nutze ich nicht.

Risiken und Nebenwirkungen

Ach ja, das Synchronisieren geht natürlich über die Server von Dashlane. Das Sicherheitsmodell scheint mir wasserdicht zu sein, solange man auf keinem seiner Endgeräte einen Keylogger eingefangen hat oder sonst irgendwie das Masterpasswort verliert. Im Normalfall geht also „unbrauchbarer“ AES256-Datenschrott über den Austauschpunkt. Für die Sicherheit von AES256 gibt es sogar eine Zusicherung der NSA – super!

Um etwas Schutz gegen die Keylogger-Problematik zu haben, nutze ich die Zwei-Faktor-Authentifizierung. Dann kann niemand ein Endgerät mit meinem Dashlane-Datenaustausch-Account verknüpfen. Wenn ich mein Android-Smartphone UND mein Masterpasswort verliere, wäre das natürlich ganz schlecht.

Nun gut, die Prism-Tempora-Sonstwas-Maschinen wissen nun wirklich ganz genau, welche Endgeräte ich nutze. Vermutlich ist dies ja auch für jene Leute die wirklich interessante Information – Passwörter von Individuen brauchen die eh nicht so dringend. Also: „Ja, man gibt Futter für diese Maschinen“, damit das Korrelieren im Big-Data-Wust dann besser geht.

Zusammenfassung

Angesichts des Nutzens finde ich das Werkzeug sehr interessant und werde es weiterhin einsetzen. Unberührt von der technischen Coolness ist der Umstand, dass beispielsweise eine Unternehmspolicy das Hinterlegen bestimmter Credentials in Password-Manager-Anwendungen untersagen kann.

Prüfung von Sicherheitszertifikaten

Die Prüfung der von Servern verwendeten Zertifikate hinsichtlich ihrer Gültigkeit  und Vertrauenswürdigkeit ist heutzutage ein elementarer Bestandteil der persönlichen Sicherheit im Internet. Viel zu oft werden solche Hinweise zwar einfach weggeklickt, spätestens bei Shops, die die Angabe der Konto- oder Kreditkartendaten erfordern, und erst recht beim Online-Banking sollten aber wirklich alle Internetnutzer misstrauisch werden, sobald der Browser eine entsprechende Warnung anzeigt.

Aus diesem Grund ist auch die Uni Köln seit Jahren einer Certificate Authority angeschlossen, die in allen gängigen Browsern und Mailclients als vertrauenswürdig bekannt ist, namentlich der Root-CA der Deutschen Telekom. Denn auch an der Uni müssen z.T. sehr vertrauliche Daten über das Netz geschickt werden, z.B. Prüfungsergebnisse, Accountdaten oder auch E-Mails.

Umso wichtiger ist es, dass die entsprechende Prüfung der gemeldeten Sicherheitszertifikate möglichst automatisiert und zuverlässig erfolgt. Hierfür gibt es ein eigenes Netzprotokoll, das „Online Certificate Status Protocol“ (OCSP). Es prüft automatisch die Gültigkeit des vom aufgerufenen Server gesendeten Zertifikates. Dies ist leider nicht bei allen Browsern und Mailclients korrekt voreingestellt. Zum Teil wird nur auf den Servernamen geprüft, zum Teil aber auch gar nicht. Wir möchten daher hier für die wichtigsten Programme kurz beschreiben, wo die korrekten Einstellungen vorzunehmen sind.

Mozilla Firefox / Mozilla Thunderbird
Bei den beiden Mozilla-Programmen finden sich die Einstellung in einem übersichtlichen Menü unter „Einstellungen“ → „Zertifikate“ → „Validierung“.

Google Chrome
In Chrome muss unter „Einstellungen“ → „Erweiterte Einstellungen anzeigen“ → „HTTPS/SSL“ ein Häkchen bei „Serverzertifikate auf Sperrung prüfen“ gesetzt werden.

Internet Explorer / Windows Mail / Outlook
Alle drei sind fest mit dem Windows-Zertikatspeicher verbunden, den man im Internet Explorer unter „Extras“ → „Internetoptionen“ → „Inhalte“ → „Zertifikate“ erreicht (die Menüfolge mag in den verschiedenen Versionen etwas anders sein). OCSP wird von Windows erst seit Vista – und damit auch in Windows 7 und 8 – unterstützt, für XP fehlt die Funktion leider. Die Aktivierung erfolgt in „Extras“ → „Internetoptionen“ → „Erweitert“ und umfasst die Einstellungen „Auf gesperrte Zertifikate überprüfen“ und „Auf gesperrte Zertifikate von Herausgebern überprüfen“.

Apple Safari
Safari nutzt den zentralen Schlüsselbund von MacOSX. Diesen erreicht man in der Regel über das Anwendungsmenü im Bereich „Utilities“ oder „Werkzeuge“. Innerhalb des Schlüsselbunds kann man im Menü „Einstellungen“, Karteireiter „Zertifikate“ die passenden Einstellungen wählen. In aller Regel ist dies bei OCSP und CRL jeweils „Bester Versuch“, die Priorität sollte auf OCSP liegen.

Opera
In Opera (ab Version 9) muss man den Umweg über die Seite „about:config“ im Browser gehen. In den „Security Prefs“ kann man den Eintrag bei „OCSP Validate Certificates“ ändern. Da dieser aber standardmäßig aktiviert ist, muss man in der Regel nichts ändern.

Zwei-Faktor-Verifikation für Google-Accounts

Ob das RRZK-Blog ein guter Platz ist, um über ein Feature von Google-Accounts zu schreiben? Ich bin nicht sicher, aber viele an der Uni nutzen ja die Google-Angebote und daher ist es vielleicht für ein paar Leute von Interesse.

Ich selbst nutze einen Google-Account seit 2006 für mein „persönliches digitales Leben“. Die Datenschutz-Problematik ist mir durchaus bewusst, aber die Funktionen sind einfach zu verführerisch, um widerstehen zu können. Schon lange hat mich gestört, dass meine Daten nur durch ein kleines Passwort von der Welt getrennt sind. In einer globalen Cloud können merk- und tippbare Passwörter praktisch nie ein geeigneter Schutzmechanismus sein.

Seit einigen Monaten bietet Google nun eine Authentifizierungsmethode an, die „Two Step Verification“ genannt wird. Das klingt verdächtig nach der klassischen Zwei- bzw. Mehr-Faktor-Authentifizierung. Dies legt auch die Intro-Page nahe, die sagt „Sign in will require something you know and something you have“. Klingt sehr gut.

Der Start ist auch recht simpel; eine kleine Änderung in den Account-Einstellungen und man erhält Einmal-Zugriff-PINs über SMS, Voice Call oder eine recht nette Authenticator-App (für Android, iOS usw.), die zusammen mit dem traditionellen Passwort den Zugriff auf das Konto ermöglichen. Außerdem kann man Geräte nach eigenem Ermessen als „vertrauenswürdig“ einstufen; dann entfällt dort die Eingabe der zusätzlichen PIN. Auch der Desaster-Fall ist bedacht: dafür gibt es Backup-PINs zum Ausdrucken (Natürlich nicht ausdrucken, falls der Drucker ein Gerät mit Festplatte oder Netzwerk-Anschluss ist 😉 ).

Wie immer gibt es in der schönen neuen Welt auch ein paar Relikte aus der hässlichen alten Welt; in diesem Fall sind das die „anwendungsspezifischen Passwörter„. Diese sind zwar nicht „anwendungsspezifisch“, aber Passwörter mit fast allen schlechten Eigenschaften, die Passwörter haben können. Sie sind nicht anwendungsspezifisch, weil sie den Zugriff auf das komplette Google-Konto ermöglichen. Die Terminologie bedeutet, dass sie nur für eine bestimmte Anwendung eingesetzt werden sollen.

Ein zusätzlicher Schutz (im Vergleich zum klassischen Passwort) besteht neben der Länge darin, dass es weniger Risiken gibt, das Passwort zu verlieren oder unabsichtlich offenzulegen (revealing). Faktisch wird es einmal angezeigt und dann nie wieder; schreibt man es nicht auf, sondern kopiert es sofort in die Anwendung der Wahl und vergisst es, so kann man es selbst nicht mehr verlieren. Trotzdem kann in der rauen Wirklichkeit das eigene Google-Konto über diesen Mechanismus „geknackt“ werden. Also: Der Provider kann es noch „für einen verlieren“ – quasi „RaaS, Revealing as a Service“.

Klar, die „anwendungssprezifischen Passwörter“ sind eben Passwörter und daher ist der Authentifizierungsmechanismus auch keine echte Zwei-Faktor-Authentifizierung. Ich vermute, dass Google daher auch von einer „Two Factor Verification“ spricht. Zu dem Mechanismus und seinen potenziellen Schwachstellen gibt es diverse mehr oder weniger technische Erläuterungen.

Alles sinnlos also? Falls das eigene digitale Leben spartanisch ist und sich auf die Browser-Schnittstelle bzw. moderne Android-Systeme (wohl >2.3) beschränkt, sind anwendungsspezifische Passwörter verzichtbar. Dann ist das Niveau des Zugriffschutzes mit Zwei-Faktor-Verifikation deutlich besser als ohne.

Andernfalls muss man halt mit dem kleinen Schönheitsfehler leben. Ein Sicherheitszuwachs bleibt: Falls man doch einmal das gute alte Passwort verlieren sollte oder falls es ein Service-Provider „für einen selbst“ verliert, kann nicht ohne weiteres von jedem Rechner im Internet auf das Konto zugegriffen werden.

Was man auch noch im Auge behalten sollte:

  1. Gut auf die Backup-Codes aufpassen.
  2. Einen kritischen Blick auf die Liste der Sites, Apps und Dienste, denen Zugriff auf die eine oder andere Information des Google-Kontos eingeräumt wird. Sicherheitsvorfälle in diesen Bereichen können auf das Google-Konto übergreifen.

VPN-Unterstützung für Android-Endgeräte – Konfiguration der Klienten

Die letzten Tage habe ich mit der Integration von VPN für Android-Geräte verbracht. An dieser Stelle entschuldige ich mich vorab für mehrere Verbindungsabbrüche bei den Nutzern, die den IPSec-Klienten verwenden, denn durch die Umstellung der Verschlüsselungskonfiguration musste ich mehrmals morgens die IPSec-Verbindungen trennen.

Einige der Android-Smartphones von Samsung haben schon vor einigen Monaten VPN-Unterstützung in Form des AnyConnect-Klienten erhalten. Dieser verwendet als Protokoll SSL-VPN und sollte somit die wenigsten Probleme mit Firewalls etc. haben, da die Kommunikation nur über den Port 443 (TCP und UDP) und alle Sessions nur vom Klienten aufgebaut werden. Ich empfehle daher, diesen weiterhin zu verwenden, wo dieser verfügbar ist.

Um die restlichen Android-Endgeräte ua. auch  Tablets mit VPN zu versorgen, musste ein völlig anderer Typ von VPN aktiviert werden, L2TP-IPSec.  Dabei wird zuerst eine IPSec-Verbindung aufgebaut, in der wiederum ein L2TP-Tunnel erstellt wird.

Wie dies auf den Endgeräten konfiguriert wird habe ich exemplarisch unter http://rrzk.uni-koeln.de/vpnandroid.html dokumentiert. Da die Hersteller teilweise die Bezeichnungen und Menüstruktur verändern, können diese unter Umständen abweichen.

Bei der Verschlüsselung habe ich mich für mehr Sicherheit und damit für AES gegenüber 3DES entschieden. In der Literatur wird AES oft als ressourcenlastiger bezeichnet, was gerade bei den leistungsschwächeren Mobilgeräten in einem höheren Energiebedarf und somit einer kürzeren Batterielaufzeit resultieren könnte. Dazu habe ich aber keine Informationen gefunden und kann die Problematik daher nicht bewerten.

Ich bin gespannt, wie hoch die Nutzung von VPN über Android sein wird. Leider dauert es ja oft, bis sich die Nachricht über die neue Unterstützung von Endgeräten herumspricht.

 

Anleitung zur Einrichtung von L2TP-IPSec unter Android: http://rrzk.uni-koeln.de/vpnandroid.html

Enabling VPN for Android devices – configuration of Cisco ASA

With the new ASA versions 8.3.2.12 or 8.4.1 Cisco announced the support for native VPN on Android devices. Implementing the configuration changes in an existing and running environment can be quite tricky.

For the Android devices the ASA has to offer a L2TP/IPSec tunnel. The IPSec tunnel has to be in transport mode. Since normally the IPSec tunnels are configured in tunnel mode you will encounter the problems of having a mixture of tunnel and transport mode.

The document https://supportforums.cisco.com/docs/DOC-17798 gives a good example on how to configure the tunnel in a new environment.

If you already have an existing crypto-map or dynamic-map for the other IPSec clients and try to add a second one with a higher or lower priority you will end up with an IPSec phase 2 that fails with the error message “All IPSec SA proposals found unacceptable!” for clients using the map with the lower priority.

You can solve this problem only through implementing the two modes via two transform-sets using one single dynamic map.

Example:

crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec ikev1 transform-set l2tptransform-set esp-aes esp-md5-hmac

crypto ipsec ikev1 transform-set l2tptransform-set mode transport

crypto dynamic-map public_dyn_map 30 set ikev1 transform-set ESP-AES-256-SHA l2tptransform-set

The order of the transform-sets in the dynamic-map defines their priority with the highest from the left.

Have in mind that changing the dynamic-map results in disconnection of all IPSec sessions.

OpenAFS 1.7.1 und die Windows-Firewall

Seit heute gibt es die neue OpenAFS-Version 1.7.1, die insbesondere für neuere Windows-Versionen dringend empfohlen ist. Allerdings gab es direkt nach der Installation noch ein paar Probleme:

Man muss leider noch von Hand die Windows-Firewall passend konfigurieren, wenn man als Netzwerkumgebung *nicht* public/öffentlich konfiguriert hat:

Systemsteuerung->
System und Sicherheit->
Windows Firewall->
Ein Programm oder Feature durch die Windows-Firewall zulassen

Dort muss für „AFS CacheManager Callback (UDP)“ das Häkchen bei „Heim/Arbeit (Privat)“ gesetzt sein.

Wenn der lokale Username und das Passwort nicht mit dem im AFS übereinstimmen, muss man sich außerdem auf anderem Weg ein Token besorgen. Dazu öffnet man die Eingabeaufforderung und gibt dort

klog username

an, wobei „username“ durch den Usernamen im AFS zu ersetzen ist.

Perl-Modul SAVI-Perl mit aktueller Sophos-Version für Linux verwenden

Wir betreiben neben Ironport für die zentralen Mailserver noch eine weitere Anti-Spam- und Anti-Viren-Infrastruktur als „Altlast“ für Institute, die keinen LDAP-Server betreiben. Dort wird als Anti-Virus-Software seit vielen Jahren ClamAV und Sophos Antivirus eingesetzt. Für Letzteres musste jetzt ein Update installiert werden, weil die alte Version demnächst nicht mehr unterstützt wird. Sophos wird bei uns mit dem Perl-Modul SAVI-Perl in amavisd-new eingebunden. Das ging nach dem Update zunächst nicht mehr, obwohl ich das Modul gegen die neue Sophosversion gebaut hatte. Die Ursache ist, dass sich der Pfad der .vdl- und .ide-Dateien geändert hat. Zwar kann man SAVI-Perl beim Kommando load_data diesen Pfad übergeben, aber (unsere Version von) amavisd-new unterstützt das nicht. Die einfachste Lösung war deshalb ein symbolischer Link vom aktuellen Pfad /opt/sophos/lib/sav auf den bisherigen Pfad /opt/sophos/sav.

Intranettes Symbian – Nokia Handys mit Cisco VPN verbinden

Dienstag abend, in einem verspäteten Regionalexpress in der Pampa zwischen Pulheim und Stommeln: Ein netter kleiner RRZK-Mitarbeiter nutzt sein hypermodernes Präzisionsinstrument aus Finnland (a.k.a. Nokia E72), um die E-Mails zu lesen, die ihn nach der Bürozeit erreicht haben. Aha, der Herr Professor Hänneschen hat Probleme mit dem Zugriff auf seinen Webspace und hat daraufhin ein Ticket bei uns eröffnet. Der nette kleine RRZK-Mitarbeiter erkennt das Problem und möchte dem armen Professor den Abend retten, also schnell auf das OTRS zugegriffen und – BÄM… „Zugriff verweigert“. Ach ja, das Ticketsystem ist nur aus dem Uninetz erreichbar. Toll, dass die Uni dafür VPN anbietet. Blöd, dass Nokia Handys sich damit nicht verbinden können.

Nun stehen zur Lösung dieses Problems im Netz diverse kostenpflichtige VPN-Clients zur Verfügung. Aber das Schöne: Es geht sogar kostenlos! Eine ganz allgemeine Anleitung dazu findet man auf den Seiten von Mobilfunk-FAQ. Hier beschränke ich mich daher auf eine etwas kürzere Anleitung für diejenigen, die sich speziell mit dem VPN der Uni Köln verbinden möchten. Vorab: Die Nutzung erfolgt auf eigene Gefahr und ohne Support oder Gewährleistung, falls etwas schief geht!

Zunächst benötigt man diese SIS-Datei, also ein Symbian-Installationspaket. Eigentlich wäre das sogar schon alles, aber leider muss die Datei für jedes Handy einzeln signiert werden. Es besteht über die Seite Symbiansigned die Möglichkeit, ein Programm zu signieren. Wichtig ist dabei die IMEI (die Seriennummer des Handys), die über die Eingabe von *#06# auf dem Handy angezeigt werden kann. Nach dem Upload der Datei erhält man per Mail das signierte Programm als Download.

Sobald Sie über die nun signierte SIS-Datei verfügen, laden Sie diese einfach auf Ihr Handy (per OVI, Bluetooth, Speicherkarte etc.) und installieren Sie das Paket. Je nach Handymodell müssen Sie nun einen neuen VPN- oder Intranetzugangspunkt einrichten und dabei die VPN-Richtlinie bzw. -Policy „VPN-Policy“ auswählen. Der Name des Zugangspunktes selbst ist beliebig. Bei der Einrichtung des Zugangspunktes müssen Sie zudem noch auswählen, über welche Netzverbindung Sie sich mit dem VPN verbinden möchten (neuere Modelle bieten praktischerweise den generischen „Internet“-ZP hierfür an). Künftig können Sie sich dann direkt über den erstellten Zugangspunkt im Uninetz anmelden. Anmerkung: Dies funktioniert *nicht* im WLAN der Uni, ist dort ja auch völlig unnötig.