Auch Apple kann kompliziert: Mails signieren und verschlüsseln mit iPhone und iPad

Auf die Gefahr hin, dass die letzten Beiträge unseres Blogs ein klein wenig Apple-lastig werden, folgt auf den letzten Beitrag ein weiterer über iGeräte, genauer: Über verschlüsselte E-Mails, und warum die Sache mit der Usability nicht immer so einfach ist, wie man das als User*in gerne hätte.

Haben Sie, liebe Blog-Lesende, schon einmal eine E-Mail verschlüsselt? Nein? Dann gehören Sie wahrscheinlich zur großen Mehrheit von IT-Nutzenden, die das Thema zwar „schon einmal irgendwo gehört oder gelesen“ haben, aber sich selbst noch nie damit befasst haben.

Zumindest könnten Sie einmal darüber nachdenken, Ihre E-Mails mit Hilfe eines S/MIME-Zertifikats zu signieren, was gleichzusetzen ist mit einer Unterschrift. Wie Sie an der Uni Köln ein solches Zertifikat beantragen und wofür das gut ist, können Sie hier nachlesen.

Wie man sein Zertifikat dann auf verschiedenen Geräten einrichtet und nutzt, haben wir an dieser Stelle dokumentiert. Einmal eingerichtet, ist das Ganze sofort lauffähig, und Ihre Mails werden fast unmerklich digital signiert. In diesem Beitrag legen wir den Fokus auf mobile Apple-Geräte. iOS unterstützt S/MIME-Zertifikate und die E-Mail-Verschlüsselung schon seit dem Jahr 2015 – so neu ist das Thema zugegebenermaßen also nicht.

Bildschirmabbild, das das Fenster zum Erstellen einer neuen E-Mail zeigt

Verschlüsselte oder signierte E-Mails zu empfangen ist kinderleicht. Neben dem Absende-Namen taucht bei einer signierten und/oder verschlüsselten E-Mail ein kleines Häkchen und gegebenenfalls ein Schlosssymbol auf.

Jetzt kommt der Teil, der komplizierter ist, als es sein müsste: Spannend wird es, wenn man seine Mails neben dem Signieren auch verschlüsseln möchte. Dazu schweigt sich interessanterweise sogar die Anleitung von Apple selbst aus. Das führt dann dazu, dass man zunächst einmal eine Fehlermeldung erhält, wenn man es mit dem Verschlüsseln versucht (siehe Bild). Wo hakt’s? Die Anleitung von Apple sagt, dass in diesem Fall das Zertifikat der Empfänger*in nicht gefunden wurde. Aber kein Wort darüber, was man nun tun soll, damit das iGerät diesen öffentlichen Schlüssel der anderen Person kennenlernen kann…?

Spoiler: Dazu muss man das Zertifikat tatsächlich „installieren“, sagt die Oberfläche, wenn man ein bisschen danach sucht.

Hat man diese Schritte einmal gefunden, ist es ganz einfach:

1.) Eine E-Mail der Person öffnen,
2.) in der Kopfzeile auf den Namen klicken,
3.) gegebenenfalls nochmals auf den Namen klicken, dann
4.) auf „Zertifikat anzeigen“, und zum Schluss
5.) auf „Installieren“ klicken.


Bildschirmabbild, das die Details eines Mail-Zertifikats anzeigt

Diese Schritte muss man für jede Person vornehmen, der man verschlüsselte E-Mails senden will.

Zusammenfassend kann man sagen: Wenn man einmal weiß, was man tun muss, ist es gar nicht so kompliziert. Aber warum gestaltet man – beziehungsweise Apple – diesen Vorgang so umständlich? Einfacher wäre es wie beim Open-Source-Mail-Programm Mozilla Thunderbird: Hier wird der öffentliche Schlüssel der Absender*in – also der Teil des Zertifikats, der dem iOS-System wie oben genannt zunächst „bekannt gemacht“ werden muss – direkt automatisch gespeichert.

Kurzes Fazit: Weniger ist mehr. Ich würde mir wünschen, dass Apple dieses Prozedere vielleicht etwas einfacher gestaltet und zukünftig weniger Arbeitsschritte nötig sind. Das würde zur Akzeptanz von E-Mail-Zertifikaten und deren Einsatz sicher enorm beitragen.

Wie die iOS-App „Kurzbefehle“ den Alltag erleichtern kann

Die Anwendung, die ich heute vorstellen möchte, ist ein wirklich mächtiger Helfer, der an das Mac Programm „Automator“ angelehnt ist. Mit diesem lassen sich lästige Aufgaben zu Routinen zusammenfassen und mit einem einzigen Klick ausführen. Eine abgewandelte Form gibt es seit iOS 12 auch auf iPhone und iPad.
Die App gehört nicht zu den standardmäßig vorinstallierten Apps und muss erst aus dem App Store geladen werden. Aber dafür ist sie Apple-typisch natürlich kostenlos. Öffnet man die App zum ersten Mal ist die Oberfläche ein wenig gewöhnungsbedürftig und es wird schnell klar, dass sich die Anwendung eher an Erfahrene richtet. Möglicherweise ist es hilfreich erst einmal in der Galerie zu stöbern und ein paar der Tools dort unter die Lupe zu nehmen. Der Trinkgeldrechner zum Beispiel ist sehr praktisch oder auch der Wäschetimer, der eine Erinnerung sendet, wenn die Waschmaschine fertig ist. Das erspart zum einen das Warten in der ungemütlichen Waschküche, bis nach 10 Minuten endlich die letzte Minute des Waschgangs abgeschlossen ist und zum anderen vergisst man die Wäsche nicht, wenn man unterwegs ist.
Wenn man sich einmal in die App reingedacht hat, ist das Erstellen eigener Routinen aber gar nicht so schwer. Als Beispiel habe ich eine Morgenroutine erstellt, weil mir aufgefallen ist, dass ich jeden Morgen die gleichen Apps brauche. Über das Plus in der Bibliothek lege ich also nun eine neue Routine an. Vom Grundprinzip her lege ich in der Mitte alle Aktionen ab, die ablaufen sollen. Das iPhone spielt diese dann eine nach der anderen ab. Eigentlich ein simples Prinzip.
Zunächst möchte ich also, dass mein iPhone morgens das WLAN einschaltet. Über die Suche gebe ich deshalb einfach „WLAN“ ein und es erscheint die Aktion „WLAN konfigurieren“ – genau das will ich. Es erscheint die Aktion, daneben befindet sich ein Kippschalter, der auf grün steht. Das WLAN wird also eingeschaltet. Als nächstes möchte ich das Wetter angezeigt bekommen. Ich tippe also in die Suche „Wetter“ ein und schon erscheint die Aktion „Wetter am aktuellen Standort anzeigen“. Perfekt.

Und nun meine E-Mails! Damit ich genug Zeit habe mir zu überlegen, was ich heute anziehe, bevor sich die E-Mail-App öffnet, füge ich die Aktion „Warten“ hinzu. Fünf Sekunden sollten genügen, im Zweifelsfalle lässt sich die Routine nachher jederzeit anpassen und die Zeit hoch oder runter setzen. Nun also zu den E-Mails. Dazu müssen wir einen kleinen Umweg gehen, und zwar über die Aktion „App öffnen“. Nachdem die Aktion unter den anderen erscheint, wählt man dann die E-Mail App seiner Wahl aus. Tada!Übrigens, wen es auch ärgert, dass sich WLAN und Bluetooth über das Kontrollzentrum nicht mehr vollständig abschalten lassen, der sollte sich dafür eine Routine zusammenstellen. Die Aktionen „WLAN konfigurieren“ und „Bluetooth konfigurieren“ schalten WLAN und Bluetooth nämlich mit einem Klick komplett aus.
Alle Helfer lassen sich entweder im Widget anzeigen oder als App auf dem Home Bildschirm ablegen. Mehr Konfigurationsmöglichkeiten findet man in der erstellten Routine oben rechts, wenn man auf das Symbol der beiden Kippschalter tippt. Mit einem eigenen Hotword lassen sich die Routinen sogar zu Siri hinzufügen.

 

Streaming auf AppleTV über Subnetzgrenzen hinweg

airplay_appletvMit dem Update auf Softwareversion 6.1 bekam das AppleTV in Verbindung mit iOS 7.1 und höher ein neues Feature: AirPlay Discovery via Bluetooth. Dies ermöglicht nun viel einfacher die Verbindung zwischen AppleTV und AirPlay-Klienten, wenn sich diese nicht im selben IP-Subnetz befinden. Einrichtungen mit vielen IT-Anwendern sind gezwungen, einzelnen Abteilungen oder Arbeitsgruppen eigene getrennte IP-Subnetze zuzuordnen. Oft wird dem WLAN-Netz auch ein eigener IP-Bereich zugewiesen. Befindet sich das AppleTV dann netztechnisch im IP-Bereich einer Arbeitsgruppe, müssen die Klienten einige Barrieren überwinden.

Haben beide Geräte Bluetooth aktiviert und die aktuelle Softwareversion installiert, wird auf dem iPad/iPod/iPhone das AppleTV angezeigt. Unter Umständen ist jedoch keine Kommunikation zwischen den Klienten möglich. AirPlay erfordert, dass vom AppleTV eine neue TCP/UDP-Session zum Endgerät aufgebaut werden kann, obwohl die ursprüngliche Session vom Endgerät initiiert wurde.

Damit schließt AirPlay Umgebungen aus, die NAT mittels Port-Addresstranslation durchführen. Diese Hürde kann man jedoch durch Aufbau einer VPN-Verbindung überwinden. Verteilt das VPN-Gateway jedem Endgerät eine eigene IP, kann so doch AirPlay eingesetzt werden.

Nun müssen gegebenenfalls noch Freigaben eingerichtet werden, wenn die Subnetze durch eigene Firewalls abgesichert sind. Leider verwendet AirPlay dynamische Ports, so dass ganze Bereiche freigegeben werden müssen. Dabei verläuft die Kommunikation von hohen Ports (49152 – 65535) zu hohen Ports.

Folgende Freigaben sollten eingerichtet werden:Firewallregeln

Je nach Firewall-Typ müssen auch die Rückantworten zu den fünf Freigaben eingetragen werden, also Quellnetz/-port und Zielnetz/-port vertauscht.

Mit diesen Freigaben sollte AirPlay funktionieren. Wir konnten mit den gewählten Einstellungen Videos, Musik und den Bildschirminhalt erfolgreich auf das AppleTV streamen.

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.

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.

SoFS-Nutzung von Android Tablets

Bislang gab es nur Hinweise, wie SoFS von Windows und MacOS aus nutzbar ist. Aber auch von Android aus kann man dank Webdav gut auf SoFS zugreifen. Man installiert sich dazu aus dem Google Playstore zunächst den „Total Commander“ und darin dann das Webdav plugin. Dieses dann mit https(!) checken, sofsdav.uni-koeln.de/private/<username> als pfad, username und password konfigurieren und fertig! Dem Hin- und Her-Kopieren von Dateien zwischen Android-Device und SoFS steht nur noch die verfügbare Bandbreite im Wege…

AirPrint-Erfahrungen

Seit einiger Zeit (ab Version 4.2.1) können iOS-Geräte wie z.B. iPads und iPhones drucken. Der offizielle Weg funktioniert aber nur in Heimnetzwerken und mit wenigen Druckermodellen. Im Netz kursieren viele Anleitungen, wie man diese Beschränkung umgehen kann. Was ich hier darstelle, ist nicht neu, sondern nur ein Erfahrungsbericht über die Fallstricke, die einem begegnen können. Der beste Ausgangspunkt für eigene Versuche, den ich gefunden habe, ist dieser Blogeintrag. Insbesondere die dort aufgelisteten Links sind sehr hilfreich.

Auf die grundsätzlichen Dinge, wie die Konfiguration von CUPS und das Erstellen der Servicerecords im DNS, gehe ich hier nicht ein. Das ist an anderer Stelle (s.o.) schon zur Genüge getan. Folgende Probleme hatte ich zunächst:

  • Farbausdruck ging nicht
  • Druck aus Safari ging nicht

Das letztere Problem wurde, wie man im CUPS-Log (mit debug-Logging) sehen konnte, dadurch ausgelöst, dass das zu druckende Dokument als URF-Image geschickt wurde. URF ist ein „raster image format“, für das Apple den MIME-Typ image/urf verwendet, das aber leider nirgends dokumentiert ist. Eigentlich sollte URF in meinem Fall nicht verwendet werden, weil ich (gemäß den Anleitungen) urf=none deklariert hatte. Ich hielt das für ein möglicherweise neues Problem und habe deshalb nach Lösungen zum Drucken von URF gesucht. Es sei hier schon verraten: das war eine falsche Fährte. Dennoch folgt ein kurzer Exkurs zum Drucken von URF.

Frühere Versionen von Mac OS X hatten einen CUPS-Filter namens urf2pdf, mit dem das Drucken von URF möglich war. Mit dem Update auf 10.6.5 hat Apple diesen Filter gelöscht, man findet ihn aber noch im Netz. Wenn man den (mit den richtigen Permissions, also root:wheel als owner/group) installiert, und in den CUPS-Einstellungen den MIME-Type image/urf aktiviert, klappt das tatsächlich – aber nur unter Mac OS X. Ich habe keine Möglichkeit gefunden, CUPS unter Linux beizubringen, mit URF umzugehen.

Das zweite Problem war, dass alle Ausdrucke schwarzweiß waren, obwohl im Servicerecord für den Drucker Farbfähigkeit annonciert war. Wie ich jetzt weiß, war beider Rätsel Lösung offenbar identisch: Tippfehler im Servicerecord. Beim Studium der „Bonjour Printing Specification“ von Apple fiel mir auf, dass ich ein (ganz anderes) Attribut falsch geschrieben hatte. Nachdem ich alles entsprechend angepasst hatte, gingen auf einmal Farb- und Duplexdruck. Es sieht so aus, als ignoriere der Parser alle Attribute nach einem falsch geschriebenen. Deshalb wurde auch mein urf=none nicht ausgewertet. Mit der korrigierten Fassung geht jetzt auch ein CUPS-Server unter Linux, weil die iOS-Geräte jetzt alle Druckjpbs als PDF schicken.

Fazit: wie so oft in der IT können kleine Ursachen große Auswirkungen haben.

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.