Microsoft a apporté, outre son service d’annuaire, de très nombreux changements à son système d’exploitation. Ils concernent les couches réseaux (pile TCP-IP), le système de fichiers et de stockage, ou encore, les services applicatifs ainsi que les mécanismes de sécurité fournis. Son environnement a, lui aussi, évolué puisqu’il passe de DCom(Distributed component object model) à COM+. Afin d’éprouver l’opérabilité de ce nouveau système, les laboratoires d’IBM ont réalisé des tests où, sous la version bêta 3, ils ont pu montrer qu’un objet COM+ de Windows 2000 et un objet MTS (Microsoft Transaction Server), de Windows NT 4.0, ne peuvent pas participer à une transaction commune. “Microsoft supporte JDirect, une version propriétaire de JNI (Java native interface), lequel n’est pas mis en ?”uvre par Microsoft. De plus, Microsoft n’est pas compatible avec JNDI (Java native directory interface), au contraire du standard Java”, indique Pat Gibney, directeur des systèmes Windows 2000 chez IBM.
De même, un double codage Unicode (version évoluée du codage Ascii) est nécessaire à Windows 2000 et à Windows 9.x, pour bénéficier de certaines caractéristiques liées à l’internationalisation des produits. Ainsi, certaines fonctions disponibles sous Windows 2000 sont absentes sous Windows 9.x. Les programmes Unicode sont plus rapides sous Windows 2000 et NT, la base du système étant conçue avec Unicode. En outre, les programmes Unicode 9.x exigent que les paramètres soient d’abord traduits en Ascii. La position d’IBM en ce qui concerne Windows 2000 est intéressante à plus d’un titre. Indépendamment des relations ” passionnelles ” qu’ont eues les deux sociétés dans le passé (notamment avec OS/2), IBM est le seul constructeur à disposer du code source complet de Windows 2000. Il opte pour un engagement très fort dans cet environnement, tout en gardant un ?”il critique. Après tout, ceux qui veulent des serveurs AS/400, des systèmes S/390 et des serveurs AIX ou Linux sont bienvenus chez Big Blue. Son catalogue applicatif devrait être, comme c’est le cas sous Windows NT 4.0, plus étoffé que celui de Microsoft. En outre, l’expérience d’IBM en matière de système d’exploitation est sans équivalent sur le marché.
Sécurité : entre failles et absence d’interopérabilité, des solutions sont à trouver
L’un des volets sur lequel s’est penchée avec attention la firme de Bill Gates est la sécurité. Un domaine où Microsoft a eu des problèmes dans le passé, mais dont un certain nombre a déjà trouvé une réponse avec les Service Pack 4 et 5, de Windows NT 4.0. Parmi toutes les fonctions implémentées, notons la gestion des protocoles IPSec, ISAKMP/Oakley, SSL 3.0(Secure socket layer) et TLS 1.0 (Transport layer security), ainsi que celle des cartes à puce. En outre, Windows 2000 fournit une solution de base d’infrastructure à clé publique (PKI). L’un des éléments majeurs est la mise en ?”uvre de Kerberos, qui, en l’état actuel, cause quelques soucis. Microsoft annonce la prise en compte totale de Kerberos v.5.0, de l’IETF (RFC 1510). Ainsi, les relations d’approbation entre domaines sous Windows 2000 sont des relations Kerberos implicites, transitives et bidirectionnelles. Développé à l’origine par le MIT (Massachusetts Institute of Technology), en septembre 1993, dans le cadre du projet Athena, Kerberos est un protocole d’authentification mutuelle qui n’a pas connu un succès de masse. En effet, cette technologie a surtout touché les grandes structures telles que les banques et les assurances, et des extensions comme la mouture Kerberos DCE (Distributed computing environment). Néanmoins, le fait que Windows 2000 soit parfaitement compatible avec RFC 1510 est insuffisant pour épargner tout ennui. Les tests menés par IBM montrent d’ailleurs une absence d’interopérabilité de Kerberos DCE et de Kerberos Windows 2000. De plus, Microsoft emploie les données d’autorisation définies au sein d’une application dans des tickets Kerberos, pour y glisser le SID (Secure ID) de l’utilisateur, qui lie le ticket à la liste de contrôle d’accès de Windows 2000. Une procédure parfaitement autorisée par le RFC 1510 et ses révisions. Mais la firme n’a pas publié son format des données d’authentification. Résultat : le serveur de Microsoft est indispensable. L’Open Group (auteur de Kerberos DCE) et l’IETF ont publié le format des données, afin que les KDC(Key distribution centers) Kerberos de tout éditeur puissent s’interfacer aisément.
Il faut attendre le produit final pour en évaluer les qualités
Toutefois, l’IETF a laissé le champ d’authentification des données ouvert à l’interprétation des éditeurs. Un regret aujourd’hui, sur lequel il est en train de travailler. De son côté, Microsoft a déclaré que le problème serait corrigé dans la version commercialisée. Mais alors, à quoi servent les versions bêta, dès lors que des tests d’interopérabilité ne peuvent voir le jour que dans le produit final ? Un KDC Unix ne remplace pas l’ensemble des fonctions d’un contrôleur de domaine de Windows 2000. Cela nécessiterait la prise en charge du canal de sécurité Netlogon, des connexions RPC authentifiées, des conventions de nommage NetBios et du protocole LDAP. Ce qui serait aller au-delà des services d’authentification Kerberos. Windows 2000 implémente, pour des raisons de compatibilité descendante, l’authentification NTLM v.2.0, introduite dans le Service Pack 4 de Windows NT 4.0. Toujours sur le plan de la sécurité, une faille a été découverte dans la fonction Autologin de Windows 2000. Elle permet, si le service Telnet est chargé, de connaître, par la commande ” nbtstat “, le nom d’utilisateur ” autologin “, de se connecter ainsi à l’ordinateur et d’en avoir la pleine maîtrise. Le serveur Telnet pouvait alors être activé par un simple script Visual Basic caché dans n’importe quel document HTML. Un problème certes résolu dans le RC2, mais une situation qui n’incite guère à la confiance. Windows 2000 apporte son lot de nouveautés dans les services de terminaux (TSE, Terminal services edition). Si, sous NT 4.0, les TSE n’étaient qu’un ajout, ils deviennent, aujourd’hui, un composant complètement intégré au système d’exploitation, qui simplifiera les mises à jour via les Service Pack et les programmes correctifs Hot Fixes, qui n’ont plus besoin d’être dédiés. Cette meilleure intégration devrait aussi améliorer les performances et la capacité d’évolution. Les TSE deviennent ainsi un service configurable. Les administrateurs peuvent choisir de donner la priorité aux applications ou aux services en arrière-plan.
Une capacité de bande passante augmentée de 15 %
Une autre caractéristique importante pour les multinationales est la gestion multilingue, qui permet à un client RDP (Remote desktop protocol) d’interopérer en mode multilingue avec n’importe quel serveur disposant des TSE. Auparavant, il fallait recourir à des serveurs séparés. Désormais, tout client peut communiquer avec tout serveur. Sur le plan de l’administration, l’outil de configuration de la connexion des services terminaux est dorénavant un snap-in s’inscrivant dans la MMC (Microsoft Management Console). De nouvelles API ont été publiées concernant l’administration du serveur et la configuration des utilisateurs. Sur le plan pratique, on peut annoncer la ” redirection ” de l’imprimante et du clavier, et un contrôle de la session distante. Un aspect qu’apprécieront les services de help desk des entreprises. Par ailleurs, la bande passante est, selon Microsoft, optimisée de 15 % environ par le biais de RDP. Il ne sera cependant pas possible d’effectuer la migration vers les TSE de Windows 2000 à partir des serveurs WinFrame, de Citrix. Le français RTE lance son serveur de fax pour TSE, baptisé Fotowin Fax NT TSE, conçu à la fois pour NT 4.0 et Windows 2000, afin de capter les deux marchés. Une condition indispensable au moins pendant deux ou trois ans. RTE sera suivi, d’ici à la fin de l’année, par Integral Fax, d’Imecom. Après la sortie de Windows 2000 devraient être annoncés, entre autres éléments, un client ActiveX RDP et une offre globale MSI (Microsoft Installer) RDP. Une fois l’infrastructure redéfinie et les questions de sécurité réglées, les développeurs devront résoudre le problème du portage d’applications.
L’annuaire ne facilite pas le portage des applications
“Cela peut être à la fois simple et très compliqué”, indique Daniel House, ingénieur technique d’IBM et auteur de rapports sur l’écriture d’applications pour NT 4 et Windows 2000, et sur le portage d’applications. Simple, lorsque l’application ne dispose pas d’un script d’installation complexe, de dépendance NetBios (un ” pur ” domaine Windows 2000 peut s’affranchir de NetBios), de dépendance de pilotes de périphériques, ou encore, de prérequis de sécurité. Compliqué, lorsqu’il faudra prendre en compte l’ensemble de ces éléments. De plus, lors de l’installation, il faut insérer l’applicatif dans l’annuaire. Il ne sera pas forcément aisé de placer des fichiers dans le répertoire système, qui pourra être verrouillé. Sans oublier le fait qu’il faudra contourner les applications MTS, incapables de partager le contexte transactionnel des applications COM+. Ces paramètres devraient éviter toute précipitation. Le gain d’un portage d’applications devra être bien étudié, en évaluant les changements d’infrastructure qu’il peut occasionner. ;
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
