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
Authentification Windows du serveur sans un groupe
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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- L’IA amplifie les risques sur les API
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Nomios accélère sur la cybersécurité industrielle avec un SOC renforcé et une Factory OT immersive
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
