Per-App-VPN-Profil für die Nutzung mit Apple indigo erstellen

Das Thema Apple indigo ist sicherlich einigen bekannt. Ich hatte vor einiger Zeit hier darübergeschrieben. Da es für die notwendigen Konfigurationseinstellungen nur wenig öffentliche Dokumentation gibt, möchte hier beginnen diese Dokumentation zu erstellen. Da einer der wesentlichen Komponenten einer Apple Indigo-Lösung das VPN ist, beginne ich mit der Dokumentation zur Erstellung des VPN-Profils. Ich zeige, wie ihr am BlackBerry UEM ein passendes VPN-Profil erstellen könnt. Dieses VPN-Profil kann dann dazu genutzt werden, um auf Ressourcen und Dienste im internen Netz zuzugreifen. Dieses VPN-Profil ist für die Nutzung mit BlackBerry UEM in einem Brightsite-Setup gedacht. Auf das VPN-Profil für eine Darksite-MDM-Installation gehe ich nicht ein, weil praktisch keine Organisation bei Apple indigo auf ein Darksite-MDM setzen möchte. Darksite-MDM für Apple indigo bringt einfach zu viele Nachteile und praktisch keine Vorteile.

  1. In der UEM-Konsole unter Richtlinien und Profile-> Netzwerke und Verbindungen->VPN wird über das Plus-Symbol ein neues VPN-Profil angelegt
  2. Im Feld Name muss der Name für das VPN-Profil vergeben werden, z.B. indigo_VPN_Profil
  3. Bei den Gerätetypen ist nur die Auswahlbox für iOS auszuwählen
  4. In der Auswahlliste Verbindungstyp muss IKEv2 ausgewählt werden
  5. Unter Remote-Adresse muss der FQDN des VPN-Gateways eingetragen werden, z.B. vpngw.boui.de
  6. Für Lokale ID wir der VPN-Benutzername benötigt. Da das Profil für mehrere Nutzer verwendet werden soll, tragen wir hier eine Variable ein. Das kann z.B: %username% sein.
  7. Für die Remote-ID wird wieder FQDN des VPN-Gateways eingetragen. Je nach VPN-Lösung muss hier gegebenenfalls ein anderer Wert eingetragen werden
  8. In der Auswahlliste Authentifizierungstyp muss Benutzeranmeldeinformationen ausgewählt werden.
  9. In der Auswahlliste Verknüpftes Profil für Benutzeranmeldeinformationen muss das zuvor angelegte Profil für Benutzeranmeldeinformationen ausgewählt werden. In unserem Beispiel heißt das Profil indigo_VPN_Zertifikat.
    Hinweis: Im Kontext von indigo darf das VPN-Zertifikat nicht über den MDM-Kanal auf das Endgerät gepusht werden. Das VPN-Zertifikat kann z.B. über ein sicheres, internes Netz (Wifi oder Ethernet) über den Safari-Browser auf das Gerät installiert werden.
  10. Den Wert für Keep-alive-Intervall muss auf 10 Minuten gesetzt werden.
  11. Die Haken für MOBIKE deaktivieren und IKVEv2-Umleitung deaktivieren bleiben abgewählt
  12. Der Haken für Perfekte Geheimhaltung bei der Weiterleitung aktivieren muss gesetzt werden
  13. Die Option NAT-Keep-alive aktivieren wird eingeschaltet und der Wert 110 gesetzt
  14. Die Haken für Interne IPv4- und IPv6-IKEv2-Subnetze verwenden, Zertifikatwiderrufprüfung aktivieren und Fallback aktivieren bleiben entfernt
  15. Der Haken für Untergeordnete Sicherheitszuordnungsparameter anwenden wird gesetzt und die Werte wie folgt konfiguriert
    • DH-Gruppe: 19
    • Verschlüsselungsalgorithmus: AES-128-GCM
    • Integritätsalgorithmus: SHA2 256
    • Schlüsseländerungsintervall: 1440
  16. Der Haken für IKE-Sicherheitszuordnungsparameter anwenden wird gesetzt und die Werte wie folgt konfiguriert
    • DH-Gruppe: 19
    • Verschlüsselungsalgorithmus: AES-128
    • Integritätsalgorithmus: SHA2 256
    • Schlüsseländerungsintervall: 1440
  17. Der Wert für MTU kann bei 1280 bleiben
  18. Da wir das Profil für Per App VPN und Per Account VPN nutzen wollen, muss der Haken für Enable per-app VPN gesetzt werden.
  19. Da Safari bei indigo nicht über den VPN-Tunnel auf interne Ressourcen zugreifen darf, dürfen keine Safari Domains eingetragen würden. Das gleiche gilt für die anderen Domain-Listen.
  20. Der Haken für Allow apps to connect automatically muss gesetzt werden.
  21. In der Auswahlliste Traffic Tunneling muss der Wert Application layer ausgewählt werden
  22. Über den Button Hinzufügen wird das neue VPN-Profil gespeichert.
  23. Das fertige VPN-Profil sollte dann wie folgt aussehen

iPhone season is getting closer

In a few weeks’ time Apple will launch new iPhones and a new OS version: iOS 18. We should also see an iPadOS 18 update. As usual, many users will immediately jump onto the new iOS version as soon as it is available to the public. If you are an organisation that issues iPhones and iPads to their end users through Apple Business Manager and an MDM solution, I would recommend to not immediately do the upgrade to the new iOS version. Through your MDM solution Apple allows you to delay the update on supervised devices for up to 90 days. This gives you ample time to test all your business applications and confirm that they work properly with iOS 18 and iPadOS 18. When the tests are finished successfully, your users can safely do the upgrade to iOS 18 and iPadOS 18. And you can rest assured that you will not be flooded with support requests related to the upgrade.

My recommendation is to delay the updates for 30 days and then go through your test plan. Should you encounter issues during the testing that need to be addressed by Apple, your MDM supplier or any 3rd party app developer, you can easily extend the 30 days as required and work on having the issues resolved.

With BlackBerry UEM delaying the software updates is easy and simple. All you need to do is modify the IT policy assigned to your users or their devices and enable “Delay software updates (supervised)” and set a value for “Software update delay period (supervised only)”. The screenshot below shows an “IT Policy” with the delay enabled for 30 days. Other MDM solutions usually give you similar options to configure the software update delay. Good luck with your testing!

Requirements for Apple software updates

Most of my customers who are issuing smartphones and tablets to their employees, usually give their users iPhones and iPads. As I have outlined in my previous post, a big challenge is to keep these devices up to date. I often get asked which requirements need to be met for the OS software updates to be done automatically or manually by the user. Until recently, there was not much public information from Apple on this topic for iOS and iPadOS devices. This support article was recently updated by Apple and now includes helpful details on the criteria that need to be met for the iOS updates to work, e.g. network requirements and power requirements. For a user-initiated update, the device needs to have a battery percentage of at least 20%. Rapid Security Response updates can be installed while the battery percentage is at 5% and the device is connected to power. If you are managing iPhones and iPads, I recommend you to read the support article. Previously most of the information was only available on Apple’s AppleSeed portal and covered under NDA.

USB-Sticks ans iPhone und iPad anschließen

Die App „Dateien“ auf dem iPad und iPhone hat ein praktisches Feature, das gerne übersehen wird: Man kann USB-Sticks anschließen und auf die dort liegenden Dateien direkt zugreifen. Ganz praktisch ist das auf iPhones und iPads mit USB-C-Port. Dort benötigt man keine weiteren Adapter. Es reicht ein Stick mit USB C-Stecker. Bei Geräten mit Lightning-Port benötigt man Apples Lightning auf USB 3 Kamera-Adapter. Je nach USB-Stick muss man bei dem Kamera-Adapter ein Netzteil einstecken. Das iPhone bzw. iPhone weisen darauf hin, falls das notwendig ist. Laut Apple werden folgende Dateisysteme auf den USB-Sticks unterstützt: “APFS, APFS (verschlüsselt), macOS Extendet (HFS+) exFAT (FAT64) oder FAT”. So lassen sich einfach auch größere Dateien von und zum iPhone oder iPad übertragen. Dies funktioniert auch mit externen SSDs bzw. Festplatten und SD-Karten. Verfügbar ist diese Funktion für Geräte ab iOS 13 und iPadOS 13.

Apple traut sich (noch) nicht

Seit ich das iPad Pro mit Tastatur und Trackpad als Laptop nutze, wünsche ich mir eine bessere Unterstützung dieses Modus. Mit iPadOS 16 geht Apple endlich einige kleine Schritte in diese Richtung, aber traut sich bisher noch nicht so richtig.

Normalerweise gebe ich nicht den Beta-Depp, aber dieses Jahr habe ich wie versprochen, sofort die erste Beta von iPadOS 16 installiert. Vor allem interessiert mich Stage Manager, den neuen Fenstermanager für iPad Air und iPad Pro mit M1 Chip. Und der überzeugt mich noch nicht.

Klare Vorteile: Fullscreen ist nicht mehr Pflicht. Man sieht links die letzten vier Apps oder App Groups, unten die Leiste mit den angehefteten Icons und kann direkt neue Fenster neben oder über bereits geöffnete schieben. Fenster lassen sich nur stufenweise verkleinern/vergrößern. Man kann sie nicht über den Rand oder an den Rand schieben, so dass man stets viel Platz verliert. Wenn man rechts unten den kleinen Viertelkreis greift, kann man das Fenster auch zum Vollbild ziehen und aus diesem auch wieder zurück, aber ich kenne noch keine Shortcuts, das mit der Tastatur zu machen. Es fehlen einfach die Window Controls von Windows oder macOS, bzw. sie sind zu gut versteckt. Sie erscheinen erst, wenn man auf die drei Punkte tippt.

iPhone Apps bleiben weiterhin Fullscreen, man kann also nicht mehrere von ihnen nebeneinander auf dem Bildschirm anordnen. Das ist sehr enttäuschend. Positiv ist, dass man nun den Bildschirm in drei Stufen zoomen kann und damit mehr Inhalt anzeigen kann.

Das ist die erste Dev Beta und damit haben wir noch einen weiten Weg vor uns. Die erste Public Beta erscheint erst nächsten Monat und bis dahin können noch viele Funktionen dazukommen. Ich freue mich, dass Apple sich in die richtige Richtung bewegt. Aber aktuell fühlt sich das noch an wie Klavierspielen mit Stäbchen.

WWDC: Ich wünsch mir was

Nein, ich kann nicht voraussehen, was Apple nächste Woche vorstellt. Aber ich kann fast garantieren, dass ich zuallererst mein iPad Pro M1 auf die erste verfügbare Beta von iPadOS updaten werden. Warum? Weil die aktuelle Software so viel vermissen lässt, dass jede Verbesserung hilft. iPhone ist für mich “mission critical”, da kann ich nichts riskieren, aber iPad Pro ist ein Beta-Kandidat.

Ich habe einen großen, einen mittleren und einen kleinen Wunsch:

  1. Der große Wunsch heißt Multitasking. Damit meine ich nicht die vorhandene Fähigkeit, den Bildschirm zu teilen, sondern die Fähigkeit, eine Anwendung in den Hintergrund zu legen, ohne dass sie aufhört zu arbeiten. Warum muss ich ein App Fenster anschauen, weil die App ein Video rendert?
  2. Der mittlere Wunsch heißt Finder. Das ist der Desktop und die Dateiverwaltung von macOS. Ich breche mir jedes Mal die Flügel, wenn ich Dateien organisieren will.
  3. Der kleine Wunsch ist Audio Routing. Ich will die Ausgabe einer App in eine andere App routen können. Pipifax in Windows oder macOS, unmöglich für das iPad Pro.

Mein Surface Pro 8 ist von der Hardware her dem iPad Pro in etwa ebenbürtig. Es hat sogar zwei statt einem Thunderbolt-Port und dazu den Surface Dock Connector. Und nicht zuletzt ist auch die Webcam an der richtigen, langen Seite.

Windows dagegen fliegt Kreise um iPadOS. Support für externe Kameras und Mikros, komplettes Multitasking und Audio Routing, Multi-Monitor-Support, usw. usf.

Bei einfachen Autoren-Workloads wie Text schreiben, Mails beantworten, Instant Messaging, Social Media, Bilder bearbeiten etc. hat das iPad Pro genug Software-Power. Aber alles, was ein bisschen komplizierter wird, lässt mich dann doch wieder zu einem “richtigen” Computer greifen. Und das liegt ausschließlich an iPadOS.

Es ist an der Zeit, dass Apple den iPad Pro ernst nimmt.

Can I undo this iPadOS 15 change?

Multiasking in iPad OS has always been difficult. Now Apple wants to make it simpler by offering a three dot handle at the top of the screen that let’s you drag apps. Unfortunately some apps have another handle right at the top as well, for instance the Apple Music app. If I want to drag down this shade, it was always easy on iPadOS 14. Now I more often than not hit the multitasking control instead of the shade handle.

Is there any way to disable this new control? I would really like to get back to the prior behaviour.