Sécurité

La gestion des mots de passe et des certificats est au cœur des fonctionnalités de de Jamf Connect. Jamf Connect utilise des technologies basées sur des normes pour se connecter à Active Directory ou à l’authentification par signature unique (Single Sign-on ou SSO). Ces interactions sont complétées par Kerberos, LDAP et des connexions de session URL sécurisées avec votre fournisseur d’identité dans le cloud (IdP). Jamf Connect utilise les versions de ces outils incluses avec macOS.

Afin de mieux comprendre ces interactions et vous assurer que vos informations sont protégées, consultez les mesures de sécurité suivantes dans Jamf Connect.

Limitation de responsabilité :

Il arrive que Jamf Connect permette aux utilisateurs ayant le même nom d’utilisateur et le même mot de passe de se connecter au compte local incorrect. Afin de garantir que les utilisateurs ne puissent se connecter qu’à leur compte, il est recommandé d’utiliser une méthode d’authentification multifacteur (MFA). Jamf ne pourra être tenu pour responsable en cas de dommages ou de failles de sécurité dus à des identifiants de compte identiques

Mots de passe

Lorsqu’un utilisateur se connecte avec Jamf Connect, son mot de passe est entré dans un champ texte sécurisé et n’est jamais écrit sur un disque en dehors du trousseau macOS.

Lorsque Kerberos est utilisé, le mot de passe est utilisé avec l’appel d’API gss_aapl_initial_cred(), qui authentifie l’utilisateur et obtient un ticket d’octroi de tickets (Ticket Granting Ticket ou TGT). Lorsque vous changez de mot de passe, le même processus est appliqué avec l’appel d’API gss_aapl_change_password(). Ces deux appels d’API tirent parti de l’implémentation de Heimdal Kerberos par Apple.

Remarque :

Toutes les actions Kerberos sont effectuées avec les API d’Apple. Le mot de passe n’est jamais mis en cache avec un « kinit » ou d’autres outils de l’interface de ligne de commande (CLI) Kerberos.

Lorsqu’il est intégré à Okta en tant que fournisseur d’identité (IdP), Jamf Connect utilise l’API d’authentification Okta. Pour plus d’informations sur l’API d’authentification Okta, reportez-vous à la documentation pour développeur d’Okta Authentication API (API d’authentification).

Lorsqu’il est intégré à d’autres IdP, Jamf Connect utilise le protocole d’authentification OpenID Connect pour communiquer avec l’IdP.

Remarque :

Toutes les connexions réseau sont effectuées à l’aide de l’API de chargement d’URL macOS, URLSession. Toutes les communications sont sécurisées avec TLS pour s’assurer qu’elles ne sont pas corrompues.

Lorsque l’authentification directe est activée avec la fenêtre d’ouverture de session, les mots de passe des utilisateurs saisis dans la vue web de la fenêtre d’ouverture de session sont temporairement écrits en mémoire et utilisés pour se connecter ou créer un compte local sur les ordinateurs. Lorsque Jamf Connect a terminé d’utiliser le mot de passe de l’utilisateur, la valeur est immédiatement remplacée par nil puis supprimée de la mémoire.

Pour plus d’informations sur OpenID Connect, consultez la documentation FAQ suivante de l’OpenID Foundation.

Utilisation du trousseau

Sur instruction, Jamf Connect stocke le mot de passe de l’utilisateur dans son trousseau local en utilisant SecKeychainAddGenericPassword() et d’autres appels d’API SecKeychain. Le mot de passe est stocké dans le trousseau par défaut de l’utilisateur.

Si un mot de passe est stocké dans le trousseau de l’utilisateur et que Kerberos est activé, Jamf Connect utilisera ce mot de passe au lancement. Si le mot de passe ne peut pas authentifier l’utilisateur, Jamf Connect supprime le mot de passe du trousseau pour éviter tout verrouillage. L’utilisateur est alors invité à saisir à nouveau un mot de passe valide.

Sécurité d’Active Directory

Jamf Connect ne nécessite aucune modification des réglages de sécurité dans Active Directory. Jamf Connect n’utilise que des liens authentifiés par SASL lors de l’interaction avec Active Directory. Par défaut, Jamf Connect utilise le ticket Kerberos de l’utilisateur pour chiffrer tout trafic LDAP avec Active Directory. Jamf Connect peut être configuré pour utiliser SSL en plus des connexions LDAP vers Active Directory.

Certificats

Jamf Connect n’envoie aucun secret d’utilisateur à aucun service. La clé privée qui génère votre demande de signature de certificat (CSR) ne quitte jamais le trousseau. Le processus n’est finalisé qu’au sein de Jamf Connect en utilisant les appels d’API SecKeychain et SecCertificate fournis par Apple.

Remarque :

Les clés privées sont marquées par défaut comme non exportables ; toutefois, vous pouvez utiliser une clé de préférence pour modifier ce réglage.

Lors de l’envoi de la demande de signature de certificat (CSR) à une autorité de certification Windows (CA), l’authentification Kerberos est utilisée et la CSR est transmise via SSL. La clé publique signée qui en résulte est récupérée à l’aide de Kerberos et de SSL, puis comparée à la clé privée stockée dans le trousseau.

Connexions réseau

Jamf Connect ne recherche pas les connexions entrantes. Toutes les communications provenant de Jamf Connect sont sortantes et utilisent le plus haut niveau de sécurité de transport disponible.

Espace utilisateur

Tenez compte des informations suivantes :

  • Jamf Connect fonctionne dans l’espace utilisateur et non en tant que root. Par conséquent, il n’a pas plus de privilèges que l’utilisateur actuellement connecté.

  • La fonctionnalité de de Jamf Connect est la même pour les utilisateurs admin et macOS standard locaux.