Blog

le 27/08/2012
Thomas Bordet
Archives blog-arkzoyd @fr

S'authentifier à Oracle à l'aide de Kerberos

Si Oracle Enterprise User Security est une solution peu coûteuse au problème de l’authentification et des mots de passe des bases de données Oracle, sa relative simplicité souffre de 2 limites et d’une contrainte…

Limite n°1 : Enterprise User Security est une solution dîte de « Shared Authentification Schemes ». Autrement dit, elle permet de s’appuyer sur un référentiel commun de mots de passe : votre annuaire d’enterprise. Contrairement aux solutions de « Single Sign-On » qui permettent de s’authentifier une fois pour toutes les bases de données, EUS permet « seulement » d’avoir le même mot de passe sur toutes vos bases de données. Evidemment, EUS permet aussi de gérer identité, autorisations et délégations de manière centralisée ; et ça, c’est déjà une autre histoire…

Limite n°2 : Avec Enterprise User Security, c’est la forme hash du mot de passe qui est validée par l’instance de base de données dans l’annuaire ; EUS implique donc qu’Oracle ait accès à l’algorithme de hash de votre annuaire et, si ça fonctionne sans aucune modification dans le cas de Novell, Sun/ODSEE ou Unified Directory, la solution ne fonctionne pas aussi facilement avec Active Directory ! En effet, l’algorithme de la solution de Microsoft est propriétaire et, à ce titre, il ne peut pas être embarqué dans les logiciels Oracle contrairement à S-SHA par exemple. Pour contourner ce problème, la plugin EUS pour Active Directory implémente un contournement. Elle installe une bibliothèque (.dll) sur le serveur Active Directory. Celle-ci, qui fonctionne sur le même principe que Password Filter DLL. Elle intercepte les modifications de mot de passe sur AD et stocke le résultat sous la forme d’un hash connu par Oracle.

La contrainte, quant à elle, tient dans le fait que certaines informations (e.g. une chaine de connexion) utilisent des classes et attributs spécifiques disponibles dans l’extension du schéma LDAP pour Oracle. Vous me direz que c’est assez logique qu’un annuaire permette de stocker des informations spécialisées avec des attributs et des classes spécifiques (Non?). Enfin ce qui est une opération normale dans tous les annuaires, ressemble à une contrainte dans le cas d’Active Directory… Quelqu’un m’expliquera pourquoi !

Alors voilà : utiliser Kerberos pour se connecter aux bases de données Oracle, y compris en complément de Enterprise User Security, permet de lever tout ou partie de ces limites et contraintes. Elle permet en particulier de créer un lien entre vos configurations Windows et le monde Oracle/*Nix. Cet article illustre une utilisation de ce type de configuration avec un serveur Kerberos sous Linux ; l’utilisation avec un domaine Windows n’est pas plus compliquée…

Remarques:
L’utilisation de Kerberos, comme celle d’une infrastructure à clé publique ou des certificats SSL, nécessite une licence Advanced Security Option (ASO). La documentation associée à cette mise en oeuvre est donc logiquement disponible dans « Advanced Security Administrator’s Guide – 11g Release 2 (11.2) – 7 Configuring Kerberos Authentication« . Cet exemple utilise Kerberos seul ; si vous voulez combiner cette utilisation à cette de EUS, reportez-vous également à « Enterprise User Security Administrator’s Guide – 11g Release 2 (11.2) – 4.5.2 Configuring Enterprise User Security for Kerberos Authentication« .

Installation et configuration d’un serveur Kerberos

Si vous utilisez un serveur Redhat ou Oracle Enterprise Linux 5 ou 6, l’installation d’un serveur Kerberos suppose l’installation du package krb5-server comme ci-dessous :

yum install krb5-server

Une fois le serveur installé, vous modifierez le fichier /etc/krb5.conf comme ci-dessous ; en particulier vous spécifierez :

le nom du realm (royaume), obligatoirement en majuscule et si possible qui correspond au nom de votre domaine réseau ; ici ARKZOYD.COM
le nom du contrôleur de domaine ou kdc et du serveur d’administration Kerberos ; il s’agit du nom de serveur sur lequel Kerberos est installé, ici blue.easyteam.fr
la correspondance entre les extensions DNS et le realm.

Voici ci-dessous un exemple du contenu du fichier /etc/krb5.conf après modifications :

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = ARKZOYD.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 ARKZOYD.COM = {
  kdc = blue.easyteam.fr
  admin_server = blue.easyteam.fr
 }

[domain_realm]
 .easyteam.fr = ARKZOYD.COM
 easyteam.fr = ARKZOYD.COM

Une fois le fichier de configuration modifié, vous pouvez créer la base du serveur Kerberos à l’aide de la commande qui suit ; un mot de passe vous est demandé pour protéger cette base de données :

kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'ARKZOYD.COM',
master key name 'K/M@ARKZOYD.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 
kdb5_util: File exists while creating database '/var/kerberos/krb5kdc/principal'

Modifiez ensuite le fichier kadm5.acl qui définit les administrateurs Kerberos; Dans la règle ci-dessous, un principal dont l’instance est admin et le realm ARKZOYD.COM sera un administrateur Kerberos :

sudo cat /var/kerberos/krb5kdc/kadm5.acl
*/admin@ARKZOYD.COM    *

Le programme kadmin.local permet d’administrer la base Kerberos locale. Pour créer un nouveau Principal, ici oracle/admin@ARKZOYD.COM, lancez la commande ci-dessous sous root :

kadmin.local -q "addprinc oracle/admin"
Authenticating as principal root/admin@ARKZOYD.COM with password.
WARNING: no policy specified for oracle/admin@ARKZOYD.COM; defaulting to no policy
Enter password for principal "oracle/admin@ARKZOYD.COM": 
Re-enter password for principal "oracle/admin@ARKZOYD.COM": 
Principal "oracle/admin@ARKZOYD.COM" created.

Pour terminer, configurez et démarrez les services Kerberos :

chkconfig krb5kdc on
chkconfig kadmin on
service krb5kdc start
Starting Kerberos 5 KDC:            [  OK  ]
service kadmin start
Starting Kerberos 5 Admin Server:   [  OK  ]

Vous pourrez vérifier que le serveur d’administration Kerberos est actif avec, par exemple la commande ci-dessous :

kadmin -p oracle/admin@ARKZOYD.COM -q listprincs

Couldn't open log file /var/log/kadmind.log: Permission denied
Authenticating as principal oracle/admin@ARKZOYD.COM with password.
Password for oracle/admin@ARKZOYD.COM: 
K/M@ARKZOYD.COM
kadmin/admin@ARKZOYD.COM
kadmin/blue.easyteam.fr@ARKZOYD.COM
kadmin/changepw@ARKZOYD.C
OM
krbtgt/ARKZOYD.COM@ARKZOYD.COM
oracle/admin@ARKZOYD.COM

Configuration du serveur de base de données

Pour configurer le serveur de base de données, commencez par créer un Principal avec une clé aléatoire dans le realm par défaut. Ce principal a :

Le nom de service que vous voulez ; généralement le nom de la base de données
Comme nom d’instance, le nom du serveur de base de données qui inclut son domaine
Le nom de domaine par défaut

Le script ci-dessous crée ce principal avec une clé aléatoire :

kadmin.local -q "addprinc -randkey ORCL/yellow.easyteam.fr"
Authenticating as principal root/admin@ARKZOYD.COM with password.
WARNING: no policy specified for ORCL/yellow.easyteam.fr@ARKZOYD.COM; defaulting to no policy
Principal "ORCL/yellow.easyteam.fr@ARKZOYD.COM" created.

Une fois le principal créé, faites l’extraction des clés correspondantes dans un fichier temporaire à l’aide de la commande ktadd comme ci-dessous :

kadmin.local -q "ktadd -k /tmp/keytab ORCL/yellow.easyteam.fr@ARKZOYD.COM"
Authenticating as principal root/admin@ARKZOYD.COM with password.
Entry for principal ORCL/yellow.easyteam.fr@ARKZOYD.COM with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/keytab.
Entry for principal ORCL/yellow.easyteam.fr@ARKZOYD.COM with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/keytab.
Entry for principal ORCL/yellow.easyteam.fr@ARKZOYD.COM with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/keytab.
Entry for principal ORCL/yellow.easyteam.fr@ARKZOYD.COM with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/keytab.

Copiez ce fichier sur le serveur de base de données, ici yellow.easyteam.fr dans /etc/v5srvtab (et supprimez le fichier temporaire); copiez également le fichier de configuration du serveur Kerberos sur le serveur de base de données :

scp /tmp/keytab root@yellow.easyteam.fr:/etc/v5srvtab
rm /tmp/keytab
scp /etc/krb5.conf root@yellow.easyteam.fr:/etc/krb5.conf

Sur le serveur de base de données, changez les droits pour que seul le propriétaire du logiciel puisse accéder au fichier /etc/v5srvtab en lecture :

chown oracle:root /etc/v5srvtab
chmod 400 /etc/v5srvtab

Vous pourrez vérifier le contenu du fichier à l’aide de la commande okinit qui n’est autre que kinit selon Oracle:

oklist -k -t /etc/v5srvtab

Kerberos Utilities for Linux: Version 11.2.0.3.0 - Production on 26-AUG-2012 23:55:43
Copyright (c) 1996, 2011 Oracle.  All rights reserved.
Service Key Table: /etc/v5srvtab

Ver      Timestamp                    Principal
 2  26-Aug-2012 23:53:31  ORCL/yellow.easyteam.fr@ARKZOYD.COM
 2  26-Aug-2012 23:53:31  ORCL/yellow.easyteam.fr@ARKZOYD.COM
 2  26-Aug-2012 23:53:31  ORCL/yellow.easyteam.fr@ARKZOYD.COM
 2  26-Aug-2012 23:53:31  ORCL/yellow.easyteam.fr@ARKZOYD.COM

Le dernier élément de configuration concerne les paramètres de configuration du fichier sqlnet.ora, à savoir :

SQLNET.AUTHENTICATION_SERVICES pour d’utiliser KERBEROS comme méthode d’authentification
SQLNET.KERBEROS5_CONF pour indiquer le fichier de configuration et en particulier l’adresse du serveur de domaine
SQLNET.KERBEROS5_REALMS pour indiquer le domaine par défaut
SQLNET.KERBEROS5_CONF_MIT=TRUE pour un serveur de domaine Windows et les versions récentes de Kerberos
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE pour indiquer le nom de service du principal qui correspond à la base de données dans le serveur Kerberos.

Voici un exemple qui correspond à la configuration mise en oeuvre :

SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5)

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

SQLNET.KERBEROS5_CONF = /etc/krb5.conf
SQLNET.KERBEROS5_REALMS = ARKZOYD.COM
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORCL

ADR_BASE = /u01/app/oracle

Identité et autorisations des utilisateurs

Une fois l’instance de base de données connectée au serveur Kerberos, et capable de valider une session, il faut faire connaître au serveur Kerberos notre utilisateur. La procédure dépend évidemment du serveur ; dans le cas d’Active Directory, on enregistrera l’utilisateur dans le domaine. Dans notre exemple, on ajoute un Principal correspondant à votre utilisateur sur le serveur comme ci-dessous pour scott@ARKZOYD.COM :

sudo kadmin.local -q "addprinc scott"
Authenticating as principal root/admin@ARKZOYD.COM with password.
WARNING: no policy specified for scott@ARKZOYD.COM; defaulting to no policy
Enter password for principal "scott@ARKZOYD.COM": 
Re-enter password for principal "scott@ARKZOYD.COM": 
Principal "scott@ARKZOYD.COM" created.

Il reste à faire le lien entre une connexion Kerberos et un schéma de connexion à la base de données et les autorisations associées à cet utilisateur. Enterprise User Security conserve tout son sens puisqu’il permet de gérer ces informations directement dans l’annuaire. Dans notre exemple, nous allons stocker ces informations dans la base de données elle-même à l’aide des commandes CREATE USER et GRANT :

sqlplus / as sysdba
create user scott 
   identified externally as 'scott@ARKZOYD.COM';
grant connect to scott;

Pour terminer, vous positionnerez le paramètre os_authent_prefix à vide au lieu de OPS$ et vous laisserez évidemment remote_os_authent à FALSE :

sqlplus / as sysdba
alter system set os_authent_prefix='' scope=spfile;
startup force;
exit

Remarque:
Le paramètre os_authent_prefix n’est pas dynamique et nécessite un arrêt/démarrage de l’instance.

Configuration du client Oracle

Pour utiliser une connexion Kerberos depuis un client OCI sous Unix et Linux, vous devez indiquer à l’aide d’un fichier de configuration où est situé le serveur. Vous copierez donc le fichier /etc/krb5.conf du serveur ou de la base de données :

scp root@blue.easyteam.fr:/etc/krb5.conf /etc/krb5.conf

Vous devrez ensuite modifier la configuration réseau, c’est à dire le fichier sqlnet.ora pour indiquer que vous permettez au client de se connecter via Kerberos. Voici un exemple de fichier :

SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5)

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

SQLNET.KERBEROS5_CONF = /etc/krb5.conf
SQLNET.KERBEROS5_REALMS = ARKZOYD.COM
SQLNET.KERBEROS5_CONF_MIT=TRUE

ADR_BASE = /u01/app/oracle

Test des connexions

Oracle fournit un utilitaire okinit qui permet de gérer ses connexions au serveur Kerberos. Vous pouvez, également utiliser les outils natifs ; par exemple, sur Oracle ou Redhat Enterprise Linux, vous utiliserez les outils kinit, klist et kdestroy qui viennent avec le rpm krb5-workstation. Pour vous connecter, tapez simplement :

okinit scott

Kerberos Utilities for Linux: Version 11.2.0.3.0 - Production on 27-AUG-2012 00:35:02
Copyright (c) 1996, 2011 Oracle.  All rights reserved.
Password for scott@ARKZOYD.COM: 

oklist

Kerberos Utilities for Linux: Version 11.2.0.3.0 - Production on 27-AUG-2012 00:35:07
Copyright (c) 1996, 2011 Oracle.  All rights reserved.
Ticket cache: /tmp/krb5cc_54321
Default principal: scott@ARKZOYD.COM

   Valid Starting           Expires            Principal
27-Aug-2012 00:35:04  27-Aug-2012 0
8:35:02  krbtgt/ARKZOYD.COM@ARKZOYD.COM

La connexion à la base de données ne nécessite plus alors de mot de passe ; le client et le serveurs de base de données s’assurent auprès du serveur Kerberos que la session est bien ouverte entre celui-ci et le client. Le compte correspondant est alors utilisé pour ouvrir la session Oracle :

sqlplus /@yellow.easyteam.fr:1521/ORCL

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 27 00:38:42 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> select user from dual;

USER
------------------------------
SCOTT

Si vous supprimez la session kerberos avec kdestroy ou okdstry, vous n’arriverez plus à vous connecter :

okdstry

Kerberos Utilities for Linux: Version 11.2.0.3.0 - Production on 27-AUG-2012 00:39:27
Copyright (c) 1996, 2011 Oracle.  All rights reserved.

sqlplus /@yellow.easyteam.fr:1521/ORCL

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 27 00:39:29 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

ERROR:
ORA-12638: Credential retrieval failed

Pour aller plus loin…

Dans le cas d’un client Windows dans un domaine, la connexion Kerberos est automatiquement créée au moment de la connexion au domaine. La connexion à la base de données oracle pour un client est donc largement simplifiée puisqu’il n’y a plus alors aucun paramétrage lié au serveur Kerberos à réaliser. Il ne reste qu’à spécifier la méthode d’authentification dans le fichier sqlnet.ora pour le client OCI et à l’aide de la propriété CONNECTION_PROPERTY_THIN_NET_AUTHENTICATION_SERVICES pour JDBC Thin.

L’existence du serveur Kerberos Windows peut également être utilisées sous Unix/Linux. Vous pourrez utiliser votre identité Windows pour vous connecter à vos bases de données; en fait vous pouvez même utiliser ce serveur pour l’authentification à vos serveurs Linux mais ça n’a plus grand chose à voir.

En fait, le seul réel inconvénient de cette méthode n’est pas technique ; il tient dans la nécessité de prendre une licence ASO pour chaque serveur de base de données (au moins celles critiques en terme de sécurité). Si ça vous intéresse, c’est un sujet très différent : il y a plusieurs leviers pour gérer ce problème. Une fois la solution déployée, et il ne s’agit que de quelques jours pour tout organiser, vous obtenez de fait de nombreux bénéfices vis à vis d’une solution basée uniquement sur Enterprise User Security :

L’impact sur le serveur Active Directory est quasi-nul
Si vous décidez d’augmenter la sécurité de vos mécanismes de vos postes de travail à l’aide d’une authentification par 2 facteurs par exemple, vous héritez de la même amélioration pour vos connexions à Oracle.

Une bonne idée pour savoir enfin qui se connecte à vos bases de données…