> Tech > Authentification Windows du serveur sans un groupe

Authentification Windows du serveur sans un groupe

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Que se passe-t-il si le DBA est connecté au serveur de base de données mais décide de se connecter à Oracle sans avoir tous les privilèges SYSDBA ? Cette utilisation prudente du moindre privilège réduit les risques dans le cas où le DBA commettrait une erreur. Pour notre exemple, supposons

qu’un utilisateur Windows nommé WinUser dans le domaine PENTON s’est connecté au serveur Windows qui héberge Oracle. Notons qu’avec une installation par défaut, le même utilisateur Windows qui s’est connecté en tant que SYSDBA ne peut pas se connecter avec des privilèges moindres. Par exemple, si je tape

sqlplus /

le système renverra les résultats de la figure 4. La raison de l’échec est simple : le client n’essaie plus de se connecter à la base de données Oracle par l’intermédiaire de l’appartenance au groupe Windows ORA_DBA. Par conséquent, l’utilisateur Windows n’est pas associé automatiquement à un rôle Oracle par le biais de son appartenance au groupe Windows et il n’est donc pas autorisé dans Oracle. Comme nous n’utilisons pas l’appartenance aux groupes pour authentifier l’utilisateur, l’utilisateur Windows réel, WinUser, est transmis à Oracle et a besoin de son autorisation. Il ne la lui accordera que si cet utilisateur correspond à un utilisateur Oracle. Dans notre exemple, le FQDN (Fully Qualified Domain Name) de l’utilisateur est PENTON\WinUser. Pour qu’Oracle autorise cet utilisateur Windows dans la base de données Oracle, nous devons créer un utilisateur Oracle PENTON\WinUser. Quand un utilisateur Windows correspond à un utilisateur Oracle, les privilèges accordés à l’utilisateur Windows sont les mêmes que ceux octroyés à l’utilisateur Oracle. La syntaxe de création de l’utilisateur Oracle exige que le FQDN soit tout en majuscules et entre des guillemets doubles, comme dans l’exemple ci-dessous. En utilisant SQL*Plus ou un autre outil client favori, nous pouvons nous connecter à la base de données Oracle avec des privilèges SYSDBA et exécuter les commandes suivantes :

create user "PENTON\WINUSER" identified
externally;
grand create session to
"PENTION\WINUSER";

Il existe un paramètre Oracle qui influence la manière dont Oracle fait correspondre un nom d’utilisateur Windows à un nom d’utilisateur Oracle, quand on n’utilise pas l’appartenance au groupe Windows. Les anciennes versions d’Oracle utilisaient un préfixe OPS$, que l’on ajoutait au début du nom de l’utilisateur Oracle servant à l’authentification externe. Comme les noms d’utilisateurs Oracle sont limités à 30 caractères, l’utilisation d’un préfixe OPS$ limitait en fait le nom de l’utilisateur aux 26 caractères restants. Pour éviter d’utiliser le préfixe OPS$, le fichier de paramètres de base de données Oracle, le fichier init.ora (dans le dossier \%ORACLE_HOME%\database) devrait avoir le paramétrage suivant (les installations Oracle9i et Oracle8i par défaut sont configurées pour inclure ce paramétrage) :

os_authent_prefix = ""

Le paramètre sert à la rétrocompatibilité. Oracle ne recommande pas d’ajouter un préfixe, aussi le paramétrage vide par défaut est comme illustré. Pour qu’un changement du paramétrage OS_AUTHENT_PREFIX entre en vigueur, il faut arrêter et redémarrer l’instance de base de données Oracle.

Une fois que l’utilisateur Windows a un nom d’utilisateur Oracle correspondant, Windows peut authentifier cet utilisateur et celui-ci peut établir une connexion avec la base de données Oracle. Une technique similaire sert à authentifier les clients à distance.

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 Renaud ROSSET - Publié le 24 juin 2010