Lorsque des appareils gérés se trouvent derrière un pare-feu ou un proxy d'entreprise, certains points de terminaison doivent être accessibles, sinon l'inscription, la livraison des politiques et les notifications push cessent de fonctionner. Cet article liste ce qu'il faut autoriser, par plateforme, et les détails au niveau des routes pour les équipes qui ne peuvent pas autoriser un domaine entier.

Vue d'ensemble

Tout le trafic est HTTPS sortant depuis l'appareil. Aucune règle de pare-feu entrant n'est nécessaire du côté de l'appareil.

Chaque compte a son propre serveur MDM :

```

[company slug].mdm.getprimo.com

```

Les appareils se connectent à cet hôte pour s'inscrire et recevoir des commandes. Autorisez le TCP 443 sortant vers celui-ci.

Windows, Linux et Android n'ont besoin de rien d'autre. Apple en a besoin de plus, car les appareils Apple sont réveillés par le propre service push d'Apple.

La version courte

Comment utiliser — Apple

Le MDM Apple dépend du service de notification push d'Apple pour réveiller un appareil lorsqu'une commande est en attente. Bloquez les APNs et les appareils n'entendent tout simplement jamais parler des commandes.

Autorisez les cinq hôtes Apple dans le tableau ci-dessus, plus votre serveur MDM.

Sur les réseaux plus anciens qui bloquent les ports HTTPS non standards, autorisez également TCP 5223 sortant vers *.push.apple.com. Si vous n'êtes pas sûr que cela soit le cas, autorisez-le.

Apple maintient la liste complète à Utiliser les produits Apple sur des réseaux d'entreprise.

Comment utiliser — Windows, Linux et Android

L'agent communique sortant sur le port 443 vers votre serveur MDM et rien d'autre. Il n'y a pas d'autres points de terminaison.

Autorisation au niveau des routes

Si vous utilisez un proxy inverse ou un pare-feu avec des règles de chemin et que vous préférez ne pas autoriser un domaine entier, autorisez plutôt ces routes.

Les appareils qui se déplacent en dehors du VPN ou de l'intranet n'ont besoin que des points de terminaison osquery :

```

/api/osquery/*

/api/v1/osquery/*

macOS

Windows

iOS et iPadOS

Android

Mutual TLS

Les routes /api//fleet/ prennent en charge mTLS en utilisant le certificat émis lorsque l'agent a été empaqueté. /mdm/apple/mdm et /api/mdm/apple/enroll prennent en charge mTLS en utilisant le certificat SCEP émis par le serveur.

Ces points de terminaison n'utilisent pas mTLS :

```

/mdm/apple/scep

/api/mdm/microsoft/discovery

/api/mdm/microsoft/auth

/api/mdm/microsoft/policy

/api/mdm/microsoft/enroll

/api/mdm/microsoft/management

/api/mdm/microsoft/tos

```

Sur macOS et Windows, le client envoie son certificat dans un en-tête de requête, et le serveur le vérifie indépendamment.

Appareils qui voyagent en dehors du VPN

Si votre flotte n'atteint le réseau que par un VPN ou un intranet, les ordinateurs portables en déplacement restent silencieux. Vous n'avez pas besoin d'ouvrir tout pour résoudre cela : exposez uniquement les points de terminaison osquery, et l'agent continue de rapporter de n'importe où tandis que le reste de la surface reste fermé.

Windows a besoin de ses propres routes

L'inscription et la gestion de Windows ne se déroulent pas sur les mêmes chemins que l'agent. Trois routes les transportent :

Ajoutez Windows Autopilot et vous avez également besoin des propres points de terminaison de Microsoft, qui sont documentés de leur côté et changent selon leur calendrier, pas le nôtre.

Apple et Android tirent de leurs propres fournisseurs

Apple a besoin de ses hôtes de push, d'activation et d'inscription accessibles — notifications push sur 443 et 2197, activation et inscription des appareils sur 443. Bloquez-les et les appareils s'inscrivent mais ne reçoivent plus jamais de commande.

Android n'a pas d'agent du tout. Les appareils sont gérés via Android Enterprise, donc ce dont ils ont besoin, c'est de Google : l'API de gestion, Google Play et Firebase Cloud Messaging. Il n'y a rien de notre part à autoriser.

Dépannage et FAQ

Dépannage

• Les appareils Apple s'inscrivent mais n'agissent jamais sur les commandes. Les APNs sont bloqués. Autorisez *.push.apple.com sur 443 et 2197, et ajoutez 5223 si votre réseau restreint les ports non standards.
• L'inscription échoue sur Apple lors de la configuration de l'appareil. One des hôtes d'inscription est injoignable. Vérifiez deviceenrollment.apple.com, mdmenrollment.apple.com et iprofiles.apple.com.
• Un appareil Windows ou Linux installe l'agent puis ne rapporte rien. L'appareil ne peut pas atteindre votre serveur MDM sur 443. Cet hôte est le seul point de terminaison dont ces plateformes ont besoin, donc commencez par là.
• Les appareils rapportent uniquement depuis le bureau. Les points de terminaison osquery ne sont pas accessibles depuis l'extérieur du réseau. Autorisez /api/osquery/ et /api/v1/osquery/.

FAQ

1. Avons-nous besoin de règles de pare-feu entrant ?
   Non. Chaque connexion est sortante depuis l'appareil.
   
2. Quelle plateforme a besoin du plus de points de terminaison ?
   Apple. Windows, Linux et Android n'ont besoin que de votre serveur MDM.
   
3. Pouvons-nous autoriser des routes au lieu de domaines entiers ?
   Oui — les tableaux de routes ci-dessus le couvrent. Soyez juste conscient que les routes changent au fur et à mesure que le produit évolue.
   
4. Avons-nous toujours besoin du port 5223 ?
   Seulement sur les réseaux plus anciens qui bloquent les ports HTTPS non standards. L'autoriser est inoffensif.