Compliance Intune sur Android et F5 Access VPN 3.0.8

F5 a publié la version 3.0.8 de son client VPN pour Android en octobre 2021. Cela crée des problèmes dans le cas où la connexion au VPN dans F5 vérifie l’état de compliance de périphérique Android dans Intune (voir Configuring Access Policy Manager for MDM applications pour la documentation F5 à ce sujet).

Depuis cette mise à jour sur Android, en préparation d’Android 12 où il y aura des restrictions pour accéder au Serial Number et IMEI des périphériques Android 12, l’identifiant envoyé avec une configuration par défaut d’un profile F5 dans Intune (via Device Configuration Profile) n’est en fait plus envoyé au serveur F5, et celui-ci ne peut donc plus vérifier la compliance du périphérique.

Microsoft en parle dans TechCommunity et indique qu’il faut créer un App Configuration Policy au lieu du Device Configuration Profile afin d’envoyer dans le ficheir JSON le paramètre mdmDeviceUniqueId.

Appliquer ce changement n’a pas fonctionné dans un cas que j’ai rencontré. Après analyse, le serveur F5 (en version majeure 15 – je ne sais pas si c’est le même comportement en version majeure 16, je suppose que c’est surtout lié à un problème de gestion de l’information dans le serveur F5 et que ce sera résolu dans une prochaine mise à jour du serveur F5) n’utilise pas le paramètre mdmDeviceUniqueId pour effectuer le test de compliance mais le paramètre mdmAssignedId.

Cette configuration JSON a montré dans les logs F5 que le Device ID Intune du périphérique Android était bien reçu :

{
    "kind": "androidenterprise#managedConfiguration",
    "productId": "app:com.f5.edge.client_ics",
    "managedProperty": [
        {
            "key": "disallowUserConfig",
            "valueBool": false
        },
        {
            "key": "vpnConfigurations",
            "valueBundleArray": [
                {
                    "managedProperty": [
                        {
                            "key": "name",
                            "valueString": "F5 VPN"
                        },
                        {
                            "key": "server",
                            "valueString": "vpn.lab.stefanplizga.net"
                        },
                        {
                            "key": "weblogonMode",
                            "valueBool": false
                        },
                        {
                            "key": "fipsMode",
                            "valueBool": false
                        },
                        {
                            "key": "mdmAssignedId",
                            "valueString": "{{deviceid}}"
                        },
                        {
                            "key": "allowBypass",
                            "valueBool": false
                        }
                    ]
                }
            ]
        }
    ]
}

Cependant, la vérification de compliance sur Android ne passait toujours pas. Et pour cause : il semblerait que le module de vérification dans F5 ne soit pas prévu pour traiter comme device ID le Device ID Intune qui contient des tirets, car le module s’attend à avoir un Device ID Intune formatté en Base64.

Afin de permettre aux périphériques Android de se connecter au VPN tout en ayant la compliance vérifiée, il faut donc agir côté F5, dans l’Access Policy, pour applique une modification qui va convertir le Device ID Intune (qui est un GUID) en Base64.

Pour se faire, il faut modifier l’Access Policy pour faire cette opération. On part de ce type de configuration (on fait une vérification de la compliance pour les mobiles iOS et Android par exemple) :

On ajoute une action pour modifier la variable mdmAssignedId en Base64 si le périphérique est un Android :

Pour information, le boite « Convert Android Device ID to Base64 » est une action de type Variable Assign, avec une expression qui vérifie si l’OS est Android et effectue la conversion en Base64, et sinon (iOS donc) le laisse tel quel :

Voici le code en texte pour réutilisation :

if { [mcget {session.client.platform}] == "Android" } { 
  binary scan [mcget {session.client.mdm_assigned_id}] B* bits; switch [expr {[string length $bits]%6}] { 0 {set tail {}} 2 {append bits 0000; set tail ==} 4 {append bits 00; set tail =}}; return [string map { 000000 A 000001 B 000010 C 000011 D 000100 E 000101 F 000110 G 000111 H 001000 I 001001 J 001010 K 001011 L 001100 M 001101 N 001110 O 001111 P 010000 Q 010001 R 010010 S 010011 T 010100 U 010101 V 010110 W 010111 X 011000 Y 011001 Z 011010 a 011011 b 011100 c 011101 d 011110 e 011111 f 100000 g 100001 h 100010 i 100011 j 100100 k 100101 l 100110 m 100111 n 101000 o 101001 p 101010 q 101011 r 101100 s 101101 t 101110 u 101111 v 110000 w 110001 x 110010 y 110011 z 110100 0 110101 1 110110 2 110111 3 111000 4 111001 5 111010 6 111011 7 111100 8 111101 9 111110 + 111111 / } $bits]$tail
}
else {  
  return [mcget {session.client.mdm_assigned_id}]
}

Une fois la configuration appliquée, la vérification de compliance d’un périphérique Android fonctionne correctement avec F5 Access 3.0.8.

J’espère que cette méthode est uniquement un moyen temporaire et que Microsoft va intégrer cela nativement dans les App Configuration Policies pour prendre en compte le NAC (Network Access Control) sur Android afin d’éviter une configuration à la main en JSON et que le besoin de convertir en Base64 sera pris en compte nativement soit côté F5 Access sur Android, soit côté serveur F5.

— Stefan