> Tech > Mettre en oeuvre l’authentification Windows pour Oracle

Mettre en oeuvre l’authentification Windows pour Oracle

Tech - Par John Paul Cook - Publié le 24 juin 2010
email

En pratique, le serveur de base de données stocke généralement les mots de passe nécessaires pour accéder à une base de données Oracle. S’il est vrai que ce système est commode pour le DBA (database administrator), le fait de compter sur des mots de passe conservés sur le serveur de base de données présente plusieurs inconvénients. Par exemple, si l’on oublie un mot de passe et qu’on ait besoin de le redéfinir, le DBA doit intervenir. De plus, la synchronisation des mots de passe Windows et des mots de passe de la base de données Oracle est une opération strictement manuelle. En revanche, la fonction de sécurité intégrée de Microsoft SQL Server permet d’utiliser des noms d’utilisateurs et des mots de passe Windows pour sécuriser l’accès à la base de données. Avec cette méthode, quand les utilisateurs doivent réinitialiser leurs mots de passe, le DBA de SQL Server peut déléguer cette tâche aux servants du Help desk. Beaucoup de gens ignorent que l’on peut configurer les serveurs de base de données Oracle pour utiliser l’authentification OS (aussi appelée authentification externe dans Oracle), ce qui est similaire à l’authentification intégrée de SQL Server. Avant de pouvoir utiliser l’authentification Windows avec Oracle, vous devez bien en comprendre les implications sur la sécurité. Comme les détails pour autoriser les utilisateurs Oracle sont très différents selon qu’ils sont connectés au serveur Oracle ou aux clients distants, j’examine les deux scénarios dans cet article.

Quand on installe Oracle sur un serveur Windows, le système crée un groupe Windows ORA_DBA et lui ajoute le compte Windows qui a servi à installer Oracle. Le DBA peut ensuite ajouter au groupe d’autres utilisateurs Windows qui ont besoin de privilèges Oracle DBA complets. Mais, soyez prudents : les utilisateurs locaux et de domaine Windows dans le groupe ORA_DBA ne doivent pas fournir un nom d’utilisateur et un mot de passe Oracle. Comme le dit la propriété Description pour le groupe ORA_DBA, Members can connect to the Oracle database as a DBA without a password (Les membres peuvent se connecter à la base de données Oracle comme un DBA sans mot de passe).

Pour qu’Oracle accepte les utilisateurs dans le groupe ORA_DBA comme utilisateurs authentifiés, vous devez configurer correctement le fichier sqlnet.ora, que montre la figure 1. Pour Oracle9i et Oracle8i, ce fichier se trouve dans le dossier \%ORACLE_HOME%\network\admin, où %ORACLE_ HOME% représente le chemin utilisé pour installer le logiciel serveur Oracle. Le fichier sqlnet.ora permet de configurer les modalités des connexions au serveur Oracle.

Le paramètre NAMES.DIRECTORY_PATH dans le fichier sqlnet.ora indique les méthodes que les clients Oracle utilisent pour résoudre les alias de nom de chaîne de connexion à la base de données. Par exemple, quand je tape sur la ligne de commande

sqlplus /@test9

l’utilitaire SQL*Plus tente de résoudre l’alias test9 en utilisant les entrées NAMES.DIRECTORY_PATH dans le fichier sqlnet.ora. (Pour une description de l’outil SQL*Plus et des informations sur l’obtention de l’outil, voir l’encadré « Manipuler Oracle avec SQL*Plus »). Dans le fichier sqlnet.ora exemple que montre la figure 1, le client essaie d’abord la résolution de nom d’Oracle en utilisant un fichier tnsnames.ora qui peut résider localement ou sur une ressource réseau partagée. Si le fichier tnsnames.ora ne contient pas le nom, le client essaiera de résoudre le nom en utilisant un serveur Oracle Names (Oracle recommande maintenant d’utiliser Lightweight Directory Access Protocol – LDAP – au lieu des serveurs Oracle Names). Finalement, le client essaie de résoudre le nom par une méthode de résolution de nom d’hôte comme DNS ou NIS (Network Information Service).

Le paramètre SQLNET_AUTHENTICATION_SERVICES dans le fichier sqlnet.ora spécifie quel service d’authentification Oracle devrait utiliser quand un utilisateur tente de se connecter au serveur Oracle. Par défaut , Oracle9i et Oracle8i permettent l’authentification Windows au moyen du paramétrage suivant :

SQLNET.AUTHENTICATION_SERVICES=(NTS)

Windows NT utilise toujours l’authentification NTLM (NT LAN Manager). Windows Server 2003, Windows XP et Windows 2000 utilisent tous l’authentification Kerberos quand la machine client Oracle est dans un domaine Windows 2003 ou Win2K. Sinon, ils utilisent l’authentification NTLM. La situation par défaut qui consiste à imposer l’authentification Windows n’est pas compatible avec des applications qui utilisent l’authentification Oracle standard. Et beaucoup de fournisseurs tierce partie ont des applications qui utilisent des noms d’utilisateurs et des mots de passe Oracle standard pour se connecter à Oracle. Pour supporter l’authentification Oracle et Windows, vous pouvez changer le paramètre du service d’authentification dans le fichier sqlnet.ora du serveur de la manière suivante :

SQLNET.AUTHENTICATION_SERVICES=(NONE,NTS)

Tout changement apporté aux méthodes d’authentification peut entraîner des défaillances de connexion. Pour détecter ce genre de défaillance, chaque fois que vous changez le paramètre du service d’authentification, utilisez SQL*Plus d’abord pour effectuer un test de connectivité de base, puis testez vos applications client Oracle.

Comme le groupe ORA_DBA est un groupe Windows, le serveur de base de données Oracle ne l’utilise que quand SQLNET.AUTHENTICATE_SERVICES utilise l’authentification Windows. Par exemple, si l’authentification Windows est activée et si je vais sur la ligne de commande et je tape

set oracle_sid=test9
sqlplus "/ as a sysdba"

je peux créer une connexion privilégiée SYSDBA sans fournir un nom d’utilisateur et un mot de passe Oracle.

La valeur ORACLE_SID montrée dans notre exemple dans la première ligne de commande (c’est-à-dire, test9) identifie l’alias de chaîne de connexion à la base de données pour sqlplus. exe à utiliser pour se connecter à une instance de base de données Oracle. la seconde ligne de commande spécifie les références d’authentification. Des guillemets doubles sont nécessaires pour SQL*Plus, pour interpréter la chaîne de connexion entière, y compris les espaces, comme un paramètre ligne de commande. La syntaxe « \as sysdba » indique que le client aimerait se connecter à la base de données Oracle en tant que utilisateur Windows connecté actuellement avec des privilèges SYSDBA. Dès que j’ai entré les deux commandes sur la machine client Oracle, le système a renvoyé les résultats que montre la figure 2. Si un nom d’utilisateur et un mot de passe Oracle sont fournis à SQL*Plus quand on se connecte comme SYSDBA, SQL*Plus les ignore. Cette action n’est pas une faille de sécurité parce que le serveur Oracle a authentifié les références Windows et pas les références Oracle.

l’utilisateur des privilèges SYSDBA sur toutes les instances Oracle sur le serveur parce que le groupe Windows ORA_DBA s’associe au rôle SYSDBA Oracle. Le rôle SYSDBA est équivalent au rôle sa (systems administrator) de SQL Server. Pour plus de granularité, vous pouvez créer des groupes séparés du format général ORA_SID_DBA, où SID est le SID Oracle en majuscules, pour accorder des privilèges SYSDBA par instance au lieu de par serveur. Par exemple, dans la session précédente, le SID est test9, qui signifie que vous pouvez créer un groupe nommé ORA_TEST9_DBA. Ensuite, les utilisateurs Windows que vous ajouterez au groupe ORA_ TEST9_DBA mais pas au groupe ORA_DBA auront des privilèges SYSDBA uniquement pour l’instance de base de données TEST9 Oracle.

De la même manière, vous pouvez utiliser l’appartenance aux groupes ORA_OPER et ORA_SID_OPER, qui s’associent au rôle SYSOPER Oracle, pour accorder des privilèges SYSOPER à certains utilisateurs Windows. (SYSOPER a un sous-ensemble restreint de privilèges SYSDBA, semblable au rôle db_backupoperator de SQL Server.)

En résumé, pour utiliser l’authentification Windows, avec l’autorisation privilégiée (c’est-à-dire SYSDBA, SYSOPER) pour permettre l’accès à Oracle, effectuez les opérations suivantes :

  • Confirmez l’existence des (ou créez les) groupes Windows nécessaires (par exemple, ORA_DBA, ORA_SID_ DBA, ORA_OPER, ORA_ SID_OPER) nécessaires pour le niveau d’accès requis à votre machine serveur de base de données Oracle.
  • Ajoutez des utilisateurs Windows aux groupes appropriés.
  • Assurez-vous que SQLNETAUTHENTICATE_SERVICES utilise l’authentification Windows (c’est-à-dire, NTS) pour l’authentification client et serveur.

Oracle offre une GUI, que montre la figure 3, pour ajouter des utilisateurs aux groupes ORA_DBA et ORA_OPER. Si les groupes n’existent pas, on peut les créer avec la GUI. Pour accéder à la GUI, à partir du bouton Start, naviguez vers All Programs, Oracle – OraHome92, Configuration and Migration Tools, Oracle Administration Assistant for Windows NT. Pour ajouter un utilisateur au groupe ORA_OPERWindows, faites un clic droit sur le noeud OS Database Operators Computer et sélectionnez Add/Remove dans le menu de contexte. Quand la boîte de dialogue OD Database Operators apparaît, sélectionnez le domaine, sélectionnez l’utilisateur et cliquez sur Add, puis cliquez sur OK. Le système crée le groupe ORA_OPER s’il n’existait pas précédemment et lui ajoute l’utilisateur sélectionné.

Avec l’authentification Windows, une précaution s’impose : si à l’avenir vous devez recréer le fichier de mots de passe Oracle (dans le dossier de base de données \%ORACLE_ HOME%\), reportez-vous à la documentation Oracle et vérifiez la valeur de REMOTE_LOGIN_PASSWORD dans le fichier init.ora. Comme l’explique Oracle9i Database Administrator’s Guide, la valeur REMOTE_LOGIN_PASSWORD affecte la manière dont l’authentification Oracle fonctionne, laquelle peut ensuite influencer les applications qui utilisent cette authentification.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par John Paul Cook - Publié le 24 juin 2010