7.1. Fonctionnalité RPC sur HTTP dans IDERI note

Le serveur IDERI note utilise MS RPC (Microsoft Remote Procedure Calls) comme intergiciel permettant à des applications telles que le client IDERI note ou l’administrateur IDERI note de s’y connecter de manière sécurisée et authentifiée. L’utilisation de RPC permet de choisir entre une variété de protocoles qui sont à la fois historiques (IPX/SPX orienté connexion et orienté datagramme, NetBEUI, NetBIOS sur TCP) et d’usage quotidien dans un DAD typique (Named Pipes, TCP, HTTP). Jusqu’à la version 3.11 de IDERI note, seuls les canaux nommés et les ports TCP dédiés étaient utilisés comme protocoles dans la couche intergicielle de IDERI note. À partir de la version 4.0 de IDERI note, HTTP est ajouté à cette suite de protocoles qui permet aux applications de se connecter au serveur IDERI note. L’utilisation du terme « HTTP » peut être trompeuse dans ce contexte, car ce qui est réellement utilisé aujourd’hui pour RPC sur HTTP n’est pas HTTP mais plutôt HTTPS, protégeant ainsi le trafic qui quitte les ordinateurs utilisant RPC sur HTTP avec la sécurité de la couche de transport (TLS). Néanmoins, le terme RPC sur HTTP sera utilisé tout au long de cette documentation car il a été établi historiquement. Deux versions de RPC sur HTTP ont été publiées pour MS RPC : La version 1 et la version 2. IDERI note ne prend en charge que la version la plus récente, à savoir la version 2.

Outre le serveur IDERI note lui-même, IDERI note prend en charge deux composants essentiels de la suite de produits IDERI note avec la fonctionnalité RPC sur HTTP : Le client IDERI note et l’administrateur IDERI note. La prise en charge de ce protocole est cependant un peu différente pour les deux composants. Après un paragraphe d’introduction qui couvre l’architecture de base de RPC sur HTTP et la façon dont il s’intègre dans la suite de produits IDERI note, les paragraphes suivants de cette section mettront en évidence les différences entre l’utilisation de RPC sur HTTP dans ces deux composants. Le reste de cette section aborde les recommandations relatives aux paramètres de la stratégie de groupe qui pourraient affecter cette fonctionnalité et les limitations que cette fonctionnalité impose à d’autres fonctions de IDERI note.

7.1.1. RPC sur HTTP Vue d’ensemble de l’architecture

Alors que les autres protocoles RPC utilisent une connexion réseau directe entre un client et un serveur, RPC sur HTTP nécessite un serveur spécial qui agit en tant qu’intermédiaire entre ces deux rôles dans les communications client-serveur. Ce serveur spécial est appelé proxy RPC sur HTTP. Un proxy RPC sur HTTP est typiquement une installation de Windows Server qui a à la fois IIS (Internet Information Services) et la fonctionnalité du système d’exploitation RPC sur HTTP activée, par exemple à travers l’assistant « Ajouter des rôles et des fonctionnalités » qui peut être lancé à partir du tableau de bord du Gestionnaire de serveur.

La figure 7.1 montre une vue d’ensemble du flux de messages dans IDERI note entre une application client (administrateur IDERI note ou client IDERI note) et le serveur IDERI note lors de l’utilisation de RPC sur HTTP comme protocole.

La partie gauche de la figure 7.1 montre un ordinateur client qui réside dans un réseau connecté à l’internet public par l’intermédiaire d’un pare-feu ou d’un routeur. Il peut s’agir du réseau domestique d’un employé ou d’un point d’accès Internet public. Sur le côté droit de ce diagramme, le réseau d’entreprise avec le serveur IDERI note et un serveur proxy RPC sur HTTP est représenté dans un grand triangle. Le flux de messages entre l’ordinateur client et le serveur IDERI note peut être décrit comme suit :

Une application client (administrateur IDERI note ou client IDERI note) sur l’ordinateur client exécute un appel de procédure à distance. Cette requête réseau est acheminée vers le routeur/pare-feu internet du client.
Le routeur/pare-feu Internet du client envoie l’appel de procédure à distance sur l’Internet public jusqu’au réseau du serveur IDERI note.
Le pare-feu du réseau du serveur IDERI note reçoit l’appel de procédure à distance.
Le pare-feu réseau envoie l’appel au serveur IIS fonctionnant sur le proxy RPC sur HTTP.
Le serveur IIS fonctionnant sur le proxy RPC sur HTTP envoie l’appel de procédure à distance au serveur IDERI note.
Le serveur IDERI note exécute l’appel et envoie sa réponse au serveur IIS s’exécutant sur le proxy RPC sur HTTP.
Le serveur IIS fonctionnant sur le proxy RPC sur HTTP transmet la réponse au pare-feu du réseau.
Le pare-feu du réseau du serveur IDERI note transmet la réponse à travers l’internet public au routeur/pare-feu internet du client.
Le routeur/pare-feu internet du client reçoit la réponse.
Le routeur/pare-feu internet du client envoie la réponse du serveur IDERI note à l’application client (l’administrateur IDERI note ou le client IDERI note).

Le paragraphe suivant explique comment configurer correctement le serveur IDERI note et le serveur proxy RPC sur HTTP pour qu’ils puissent interagir avec succès.

7.1.2. Configuration du serveur IDERI note pour RPC sur HTTP

Après une nouvelle installation, le serveur IDERI note n’autorise que les connexions à partir d’applications clientes telles que l’administrateur IDERI note ou le client IDERI note utilisant des canaux nommés comme protocole. De plus, des ports TCP dédiés peuvent être configurés pour l’interface d’administration et l’interface client en utilisant l’applet du panneau de configuration de l’installation du serveur IDERI note. Afin d’autoriser les connexions entrantes via RPC sur HTTP à partir d’un serveur proxy RPC sur HTTP, deux ports supplémentaires doivent être configurés à l’aide de l’applet du panneau de configuration, l’un pour l’accès à l’interface d’administration via RPC sur HTTP et l’autre pour l’accès à l’interface client via RPC sur HTTP.

7.1.3. Configuration du serveur proxy RPC sur HTTP

Il ressort clairement des paragraphes précédents que pour que RPC sur HTTP fonctionne correctement, le composant IIS et la fonctionnalité du système d’exploitation RPC sur HTTP doivent tous deux être installés sur un serveur proxy RPC sur HTTP. Après une installation par défaut des deux composants, deux répertoires virtuels portant les noms « Rpc » et « RpcWithCert » doivent être visibles sous le site web par défaut du serveur dans le snap-in mmc de configuration IIS. Pour que RPC sur HTTP fonctionne avec la sécurité de la couche transport, une liaison supplémentaire pour ce site doit être configurée avec un certificat de serveur qui est considéré comme valide sur l’ordinateur du client. Cette nouvelle liaison pour https (TLS) peut utiliser n’importe quel port libre sur le serveur proxy RPC sur HTTP, mais pour une compatibilité maximale avec les clients qui se connectent à travers des réseaux qui filtrent les ports non standard, 443 est probablement le meilleur choix. Il est également nécessaire d’activer l’authentification intégrée de Windows sur le répertoire virtuel nommé « Rpc » et il est préférable de désactiver l’accès anonyme.

Un autre aspect important de la configuration d’un serveur proxy RPC sur HTTP pour pouvoir se connecter à un serveur IDERI note est l’ajout du serveur IDERI note à la valeur de registre « ValidPorts » dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy sur le serveur proxy RPC sur HTTP. Pour ce faire, le nom du serveur IDERI note et le numéro de port qu’il utilise pour écouter les requêtes entrantes pour RPC sur HTTP, séparés par deux points, sont ajoutés à la liste délimitée par des points-virgules dans cette valeur de registre. Ce port que le serveur IDERI note utilise pour écouter les requêtes entrantes via RPC sur HTTP ne doit pas être confondu avec le port que le serveur IDERI note utilise pour écouter les requêtes entrantes via TCP. Il ne doit pas non plus être confondu avec le port (tel que 443) que le serveur proxy RPC sur HTTP utilise pour écouter les requêtes entrantes en provenance d’Internet.

7.1.4. Test d’une configuration RPC sur HTTP avec IDERI note et rpcping

Après l’installation et la configuration du serveur IDERI note (voir ci-dessus) et avant le déploiement du client IDERI note ou de l’administrateur IDERI note, la connectivité peut facilement être testée à l’aide d’un outil de ligne de commande intégré au système d’exploitation appelé rpcping. Dans notre cas, supposons que l’utilisateur du domaine notealbert.tross des chapitres précédents soit connecté à une station de travail du domaine et que nous souhaitions tester la connectivité de la station de travail du domaine utilisée par albert.tross avec l’interface client du serveur IDERI note par le biais de RPC sur HTTP. Nous supposons également que le nom du serveur IDERI note est note-srv01.note.local et qu’il écoute sur le port 1027 les connexions entrantes via RPC sur HTTP sur son interface client. Le nom du serveur proxy RPC sur HTTP que nous utilisons est srvrpchttp.example.com et il écoute sur le port 444. Dans ce cas, la commande suivante peut être utilisée par albert.tross pour vérifier le bon fonctionnement de la connexion via RPC sur HTTP au serveur IDERI note (assurez-vous de fournir cette commande sur une seule ligne) :

rpcping /t ncacn_http /s note-srv01.note.local /e 1027 /o RpcProxy=srvrpchttp.example.com:444 /H 2 /u 10 /a privacy /F 3

Si cette commande réussit, elle imprimera quelque chose de similaire à ceci sur stdout, sinon une erreur s’est produite :

1 appels effectués en 12047 ms
0 T/S ou 12047.000 ms/T

À ce stade, il est important de comprendre que le nom du serveur IDERI note, qui est note-srv01.note.local dans cet exemple, n’est pas résolu sur l’ordinateur client pour que l’opération réussisse. Par conséquent, le client n’a pas besoin d’un serveur DNS capable de résoudre note-srv01.note.local, qui est un nom DNS qui ne peut être résolu que par les clients qui se connectent directement au réseau d’entreprise où réside note srv01.note.local. Le seul nom de serveur qui doit être résolu sur l’ordinateur client est celui du serveur proxy RPC sur HTTP, qui est srvrpchttp.example.com dans notre cas. Les informations relatives au serveur IDERI note auquel il faut se connecter sont intégrées dans la requête envoyée au serveur proxy RPC sur HTTP et il incombe à ce dernier de faire résoudre ce nom par son serveur DNS.

L’utilitaire rpcping peut également être utilisé à partir d’un ordinateur client non relié à un domaine, mais pour que cela fonctionne, les informations d’identification de l’utilisateur albert.tross doivent être fournies. Pour tester la connectivité de cette manière, utilisez la ligne de commande suivante (une fois encore, veillez à fournir cette commande sur une seule ligne) :

rpcping /t ncacn_http /s note-srv01.note.local /e 1026 /o RpcProxy=srvrpchttp.example.com:444 /P albert.tross,note,* /H 2 /u 10 /a privacy /F 3 /I albert.tross,note,*

Après avoir tapé cette commande, on vous demandera deux fois le mot de passe d’albert.tross, une première fois pour vous authentifier auprès du serveur IDERI note et une seconde fois pour vous authentifier auprès du proxy RPC sur HTTP.

Notez que le premier exemple de ce paragraphe, dans lequel albert.tross est connecté à un ordinateur de domaine, ne fonctionnera pas si la stratégie de groupe « Sécurité réseau : Restreindre NTLM : trafic NTLM sortant vers des serveurs distants » est définie sur “Refuser tout” pour l’ordinateur client. Pour plus d’informations sur les stratégies de groupe concernant NTLM et RPC sur HTTP, veuillez lire le paragraphe suivant 7.1.7.

7.1.5. Prise en charge du protocole RPC sur HTTP dans le client IDERI note

Le client IDERI note dispose de deux modes de prise en charge de RPC sur HTTP :

Utiliser les canaux nommés ou TCP comme protocole principal et RPC sur HTTP comme protocole de secours.
Utiliser RPC sur HTTP comme seul protocole

Dans le premier mode, le client IDERI note essaiera de se connecter à son serveur IDERI note en utilisant soit les canaux nommés, soit TCP comme protocole principal. Si cette méthode de connexion échoue parce que le serveur IDERI note n’est pas accessible, le client tente de se reconnecter au serveur IDERI note en utilisant RPC sur HTTP et maintient cette connexion jusqu’à ce qu’une connexion réussie utilisant le protocole primaire (named pipes ou TCP) soit à nouveau possible. Cela permet à des clients tels que les ordinateurs portables d’entreprise, qui sont connectés au réseau de l’entreprise pendant les heures de travail, de passer en toute transparence de TCP ou de named pipes à RPC sur HTTP une fois que l’ordinateur a quitté le réseau de l’entreprise et qu’il a de nouveau accès à l’internet public.

Dans le second mode, le client n’essaiera d’établir une connexion qu’en utilisant RPC sur HTTP.

Il va sans dire que les deux modes sont contrôlés par les paramètres de la ligne de commande pour inotecln.exe (voir la section 9.1) et les propriétés MSI pour intclnt.msi (voir la section 8.3).

7.1.6. Prise en charge RPC sur HTTP dans l’administrateur IDERI note et le QuickAdmin IDERI note

L’administrateur IDERI note et le QuickAdmin IDERI note QuickAdmin n’utilisent pas de système de secours élaboré comme le client IDERI note. Ces applications permettent à l’utilisateur de choisir entre une connexion locale et une connexion à distance via des canaux nommés, TCP ou RPC sur HTTP. Cela peut être fait soit à partir du dialogue de connexion (voir figure 3.16), soit via les options de la ligne de commande (voir les sections 9.3 et 9.4).

Il est important de noter que pour que RPC sur HTTP fonctionne dans ces applications, le nom du serveur proxy RPC sur HTTP et le port qu’il utilise doivent être fournis en utilisant une concaténation du nom DNS du serveur proxy RPC sur HTTP et de son numéro de port, séparés par deux points.

7.1.7. Paramètres de stratégie de groupe pour RPC sur HTTP and Kerberos/NTLM

Jusqu’à l’introduction de Active Directory® avec Windows 2000, le protocole d’authentification utilisé dans les réseaux Windows NT était NTLM. Windows 2000 a ensuite remplacé NTLM par Kerberos en tant que protocole d’authentification de choix et NTLM a été considéré comme un protocole hérité. NTLM présente un certain nombre d’inconvénients majeurs par rapport à Kerberos, le plus notable étant l’absence d’authentification mutuelle. Avec NTLM, un serveur auquel un client se connecte n’est pas authentifié auprès du client comme dans Kerberos, c’est seulement le client qui s’authentifie auprès du serveur. On pourrait toutefois faire valoir que cet inconvénient est atténué par le fait que RPC sur HTTP, qui est un exemple d’application réseau utilisant NTLM, emploie aujourd’hui la sécurité de la couche transport (TLS), qui assure l’authentification du serveur proxy RPC sur HTTP auprès du client par la nature même de TLS en tant que protocole qui authentifie le serveur auprès du client. NTLM a également connu une certaine évolution au cours de ses années d’existence, aboutissant à la suppression de NTLMv1 dans Windows 11 et Windows Server 2025. Notez que IDERI note fonctionne avec RPC sur HTTP et NTLMv2 sur ces deux systèmes d’exploitation avec des paramètres standard pour les stratégies de groupe.

Ainsi, pour que RPC sur HTTP fonctionne, NTLM est toujours nécessaire car il n’y a pas d’option de remplacement de la part de Microsoft à ce jour. Veuillez noter qu’avec les paramètres de configuration standard actuels d’un Active Directory®, la prise en charge de RPC sur HTTP dans IDERI note fonctionne dès le départ. Cependant, pour rendre NTLM et donc RPC sur HTTP fonctionnel dans un environnement entièrement kerberisé, deux paramètres de stratégie de groupe sont importants :

Sécurité réseau : Restreindre NTLM : Trafic NTLM sortant vers des serveurs distants

Si cette option est définie sur « Refuser tout », aucune application client sur l’ordinateur ne peut créer une connexion sortante en utilisant NTLM sauf si des exceptions sont définies. Ainsi, si une connexion client via RPC sur HTTP échoue avec cette politique définie sur « Deny all » et que vous souhaitez utiliser RPC sur HTTP, vous devez définir une exception pour votre serveur IDERI note et votre serveur proxy RPC sur HTTP.
Sécurité réseau : Restreindre NTLM : Ajouter des exceptions de serveurs distants pour l’authentification NTLM

Avec ce paramètre de stratégie, vous pouvez spécifier une liste de serveurs au sein de votre organisation auxquels les clients sont autorisés à se connecter à l’aide de NTLM. Pour IDERI note avec RPC sur HTTP, vous devez spécifier à la fois le serveur IDERI note et le serveur proxy RPC sur HTTP. Dans les exemples ci-dessus pour l’utilitaire rpcping, il s’agit de note-srv01.note.local (le serveur IDERI note) et srvrpchttp.example.com (le serveur proxy RPC sur HTTP).

7.1.8. Limites de RPC sur HTTP dans IDERI note

Puisque RPC sur HTTP utilise NTLM comme protocole d’authentification, les options de configuration intégrées telles que la valeur REG_DWORD « KerberosOnly » (voir la section 10.1) et sa propriété MSI correspondante « FORCE_KERBEROS » (voir la section 8.3) doivent être mises à 0 pour le client IDERI note, sinon le client IDERI note refuse de se connecter à son serveur.

L’envoi d’une alarme aux clients de IDERI note nécessite une connexion entre le serveur IDERI note et le client IDERI note à l’aide de tuyaux nommés. Comme il n’y a généralement pas de connexion directe entre un client IDERI note et son serveur si RPC sur HTTP est utilisé, cette fonctionnalité n’est pas disponible pour les clients qui se connectent via RPC sur HTTP. Pour une raison similaire, la resynchronisation Active Directory (voir la section 7.12) ne fonctionne pas pour les clients qui sont connectés à leur serveur via RPC sur HTTP car cela nécessite une connexion directe du client IDERI note à son contrôleur de domaine afin qu’il puisse purger son cache de tickets Kerberos et se reconnecter au serveur IDERI note en utilisant des informations d’appartenance à des groupes à jour.

Un autre domaine dans lequel RPC sur HTTP ne fonctionne pas est la détection automatique de serveur avec une requête Active Directory® pour un point de connexion de service IDERI note (voir la section 2.3). Une telle requête Active Directory® utilise des tuyaux nommés afin de se connecter à son contrôleur de domaine, ce qui n’est pas possible dans la plupart des circonstances où RPC sur HTTP est applicable.

7.1.9. Exécution d’un serveur proxy RPC sur HTTP sur un serveur passerelle IDERI note

Afin de supporter la connexion des appareils mobiles avec une infrastructure IDERI note, une instance de serveur dédiée est utilisée, où le service de passerelle IDERI note est installé (voir la section 7.33). Ce serveur peut également être configuré pour être utilisé comme serveur proxy RPC sur HTTP. Cependant, lorsque les deux fonctionnalités sont exécutées sur le même serveur, des choix de ports différents doivent être faits pour les deux applications du serveur. Cela signifie que : Vous ne pouvez pas exécuter le service de passerelle IDERI note sur le port standard 443 et configurer le serveur proxy RPC sur HTTP sur le même ordinateur pour qu’il fonctionne également sur le port 443, vous devez choisir un port différent pour la fonctionnalité de serveur proxy RPC sur HTTP.