Changeset 525

Show
Ignore:
Timestamp:
12/13/06 10:53:13 (2 years ago)
Author:
sas
Message:

Relu
fix #31
close #31

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/client-auth.xml

    r520 r525  
    413413  </para> 
    414414 
    415 <!-- ICI --> 
    416415  <para> 
    417416   Les enregistrements du fichier <filename>pg_hba.conf</filename> sont 
    418417   examinés séquentiellement pour chaque tentative de connexion, l'ordre des 
    419    enregistrements est significatif. Généralement, les premiers enregistrements 
    420    ont des paramètres d'interception de connexions plus stricts alors que les 
     418   enregistrements est donc significatif. Généralement, les premiers enregistrements 
     419   ont des paramètres d'interception de connexions stricts et des méthodes 
     420   d'authentification peu restrictives tandis que les 
    421421   enregistrements suivants ont des paramètres plus larges et des méthodes 
    422422   d'authentification plus fortes. Par exemple, on peut souhaiter utiliser 
    …… 
    429429  </para> 
    430430 
    431   <para>Le fichier <filename>pg_hba.conf</filename> est lu au démarrage et 
    432 lorsque le processus serveur principal reçoit un signal 
    433 <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>. 
    434 Si le fichier est édité sur un système actif, on peut signaler au 
    435 serveur (en utilisant <literal>pg_ctl reload</literal> ou <literal>kill 
    436 -HUP</literal>) de relire le fichier.  </para> 
    437  
    438 <!-- ICI --> 
     431  <para> 
     432   Le fichier <filename>pg_hba.conf</filename> est lu au démarrage et 
     433   lorsque le processus serveur principal reçoit un signal 
     434   <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>. 
     435   Si le fichier est édité sur un système actif, on peut signaler au 
     436   serveur (en utilisant <literal>pg_ctl reload</literal> ou  
     437   <literal>kill -HUP</literal>) de relire le fichier. 
     438  </para> 
     439 
    439440  <tip> 
    440441   <para> 
    441     Pour se connecter à une base particulière, un utilisateur doit déjà réussir 
    442     à passer les vérifications de <filename>pg_hba.conf</filename> mais doit 
    443     il doit aussi avoir le droit <literal>CONNECT</literal> sur cette base. Si 
    444     vous souhaitez restreindre les utilisateurs pouvant se connecter à une base, 
    445     il est habituellement plus facile de le faire en contrôlant ceci en 
    446     donnant et en retirant le droit <literal>CONNECT</literal> plutôt qu'en 
     442    Pour se connecter à une base particulière, un utilisateur doit non 
     443    seulement passer les vérifications de <filename>pg_hba.conf</filename> mais doit 
     444    également avoir le droit <literal>CONNECT</literal> sur cette base. Pour 
     445    contrôler qui peut se connecter à quelles bases, il est en général plus 
     446    facile de le faire en donnant ou retirant le privilège  
     447    <literal>CONNECT</literal> plutôt qu'en 
    447448    plaçant des règles dans le fichier <filename>pg_hba.conf</filename>. 
    448449   </para> 
    449450  </tip> 
    450451 
    451   <para>Quelques exemples des entrées de <filename>pg_hba.conf</filename> sont décrit 
    452 ci-dessous dans l'<xref linkend="example-pg-hba.conf"/>. Voir la section suivante pour 
    453 les détails des méthodes d'authentification.  </para> 
    454  
    455    <example id="example-pg-hba.conf"> <title>Exemple d'entrées de 
    456 <filename>pg_hba.conf</filename></title> 
    457 <programlisting># Permet à n'importe quel utilisateur du système local de se connecter à la base 
    458 # de données sous n'importe quel nom d'utilisateur de la base de données en 
    459 # utilisant les sockets du domaine Unix. (par défaut pour les connexions locales) 
     452  <para> 
     453   Quelques exemples d'entrées de <filename>pg_hba.conf</filename> sont 
     454   donnés ci-dessous dans l'<xref linkend="example-pg-hba.conf"/>. Voir la 
     455   section suivante pour les détails des méthodes d'authentification.  </para> 
     456 
     457   <example id="example-pg-hba.conf"> 
     458   <title>Exemple d'entrées de <filename>pg_hba.conf</filename></title> 
     459<programlisting># Permettre à n'importe quel utilisateur du système local de se connecter 
     460# à la base de données sous n'importe quel nom d'utilisateur au travers 
     461# des sockets de domaine Unix (par défaut pour les connexions locales). 
    460462# 
    461463# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD 
    462464local   all         all                             trust 
    463465 
    464 # Identique à ci-dessus mais utilise les connexions TCP/IP locales loopback. 
     466# La même chose en utilisant les connexions TCP/IP locales loopback. 
    465467# 
    466468# TYPE  DATABASE    USER        CIDR-ADDRESS        METHOD 
    467469host    all         all         127.0.0.1/32        trust 
    468470 
    469 # Identique à la dernière ligne mais en utilisant une colonne netmask séparée CDIR. 
     471# Pareil mais en utilisant une colonne netmask distincte. 
    470472# 
    471473# TYPE  DATABASE    USER        IP-ADDRESS          IP-mask              METHOD 
    472474host    all         all         127.0.0.1           255.255.255.255      trust 
    473475 
    474 # Permet à n'importe que utilisateur de n'importe quel hôte avec l'adresse IP 
    475 # 192.168.93.x de se connecter à la base de données "postgres" sous le même nom 
    476 # d'utilisateur que l'identification le signale à la connexion (généralement le 
     476# Permettre à n'importe quel utilisateur de n'importe quel hôte avec l'adresse IP 
     477# 192.168.93.x de se connecter à la base de données "postgres" sous le nom 
     478# d'utilisateur qu'ident signale à la connexion (généralement le 
    477479# nom utilisateur Unix). 
    478480#  
    …… 
    481483 
    482484# Permet à un utilisateur de l'hôte 192.168.12.10 de se connecter à la base de 
    483 # données "postgres" si le mot de passe de l'utilisateur est fourni sans 
    484 # erreur. 
     485# données "postgres" si le mot de passe de l'utilisateur est correctement fourni. 
    485486#  
    486487# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD 
    487488host    postgres    all         192.168.12.10/32      md5 
    488489 
    489 # En l'absence de lignes "host" antérieures, ces deux lignes rejetteront toutes 
    490 # les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenchera 
    491 # en premier), mais autorisera les connexions Kerberos 5 de n'importe où 
    492 # ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit sur l'ip de 
     490# Si aucune ligne "host" ne précède, ces deux lignes rejettent toutes 
     491# les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenche 
     492# en premier), mais autorisent les connexions Kerberos 5 de n'importe où 
     493# ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit de l'ip de 
    493494# l'hôte n'est considéré, de sorte à correspondre à tous les hôtes. 
    494495#  
    …… 
    497498host    all         all         0.0.0.0/0             krb5 
    498499 
    499 # Permet à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe 
    500 # quelle base de données si ils passent la verification d'identification. Si, 
    501 # par exemple, l'identification indique que l'utilisateur est "bryanh" et qu'il 
     500# Permettre à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe 
     501# quelle base de données s'ils passent la verification d'identification. Si, 
     502# par exemple, ident indique que l'utilisateur est "bryanh" et qu'il 
    502503# demande à se connecter en tant qu'utilisateur PostgreSQL "guest1", la 
    503504# connexion n'est permise que s'il existe une entrée dans pg_ident.conf pour la 
    …… 
    508509host    all         all         192.168.0.0/16        ident omicron 
    509510 
    510 # Si ce sont les trois seules lignes traitant les connexions locales, elles 
    511 # autoriseront les utilisateurs locaux à se connecter uniquement à leur propre 
    512 # base de données (bases de données ayant le même nom que leur nom 
    513 # d'utilisateur de la base de données) exception faite pour les administrateurs 
     511# Si ces trois lignes traitant seules les connexions locales, elles 
     512# n'autorisent les utilisateurs locaux qu'à se connecter à leur propre 
     513# base de données (bases ayant le même nom que leur nom 
     514# d'utilisateur) exception faite pour les administrateurs 
    514515# et les membres du rôle "support" qui peuvent se connecter à toutes les bases 
    515516# de données. Le fichier $PGDATA/admins contient une liste de noms 
    …… 
    521522local   all         +support                          md5 
    522523 
    523 # Les deux dernières lignes ci-dessus peuvent être combinées en une seule ligne: 
    524 local   all         @admins,+support                                md5 
     524# Les deux dernières lignes ci-dessus peuvent être combinées en une seule ligne : 
     525local   all         @admins,+support                  md5 
    525526 
    526527# La colonne database peut aussi utiliser des listes et des noms de fichiers : 
    527 local   db1,db2,@demodbs  all                                       md5</programlisting> </example> </sect1> 
     528local   db1,db2,@demodbs  all                         md5</programlisting> </example> </sect1> 
    528529 
    529530 <sect1 id="auth-methods"> 
    530531 <title>Méthodes d'authentification</title> 
    531532 <para> 
    532   Les sous-sections suivantes décrivent les méthodes d'authentification plus en détail.  </para> 
     533  Les sous-sections suivantes décrivent les méthodes d'authentification en détail. 
     534 </para> 
    533535 
    534536  <sect2 id="auth-trust"> 
    …… 
    536538 
    537539   <para> 
    538     Quand l'authentification <literal>trust</literal> est spécifiée, 
    539     <productname>PostgreSQL</productname> suppose que n'importe qui pouvant se 
     540    Quand l'authentification <literal>trust</literal> est utilisée, 
     541    <productname>PostgreSQL</productname> considère que quiconque peut se 
    540542    connecter au serveur est autorisé à accéder à la base de données quel que 
    541     soit le nom d'utilisateur de base de données qu'il fournisse (incluant le 
    542     super-utilisateur de la base de données). Bien sûr, les restrictions 
    543     apportées dans les colonnes <literal>database</literal> et <literal>user</literal> 
    544     s'appliquent toujours. Cette méthode ne devrait être utilisée que s'il 
    545     existe des protections au niveau système portant sur les connexions au 
    546     serveur. 
    547    </para> 
    548  
    549    <para>L'authentification <literal>trust</literal> est appropriée et très pratique 
    550 lors de connexions locales sur une station de travail mono-utilisateur. Elle 
    551 n'est généralement <emphasis>pas</emphasis> appropriée en soi sur une machine 
    552 multi-utilisateur. Cependant, vous pouvez utiliser <literal>trust</literal> même sur 
    553 une machine multi-utilisateur, si vous restreignez l'accès au fichier socket du 
    554 domaine Unix en utilisant les permissions du système de fichiers. Pour ce faire, 
    555 positionnez les paramètres de configuration 
    556 <varname>unix_socket_permissions</varname> (et si besoin 
    557 <varname>unix_socket_group</varname>) comme décrit dans la <xref 
    558 linkend="runtime-config-connection"/>.  Vous pouvez aussi positionner le 
    559 paramètre de configuration <varname>unix_socket_directory</varname> de façon à 
    560 placer le fichier de socket dans un répertoire à l'accès convenablement 
    561 restreint.  </para> 
    562  
    563    <para>Utiliser les droits du système de fichiers n'est utile que dans 
    564 le cas de connexions utilisant des sockets Unix. Cela ne restreint pas les 
    565 connexions TCP/IP locales&nbsp;; ainsi, si vous voulez utiliser les droits du 
    566 système de fichiers pour assurer la sécurité locale, supprimez la ligne 
    567 <literal>host ...127.0.0.1 ...</literal> de <filename>pg_hba.conf</filename> ou changez-la 
    568 - indiquer une méthode d'authentification différente de <literal>trust</literal>. 
    569 </para> 
    570  
    571    <para>L'authentification <literal>trust</literal> n'est utile pour les connexions 
    572 TCP/IP que si chaque utilisateur de chaque machine autorisée à se connecter au 
    573 serveur par les lignes <filename>pg_hba.conf</filename> indiquant <literal>trust</literal> est 
    574 digne de confiance. Il est rarement raisonnable d'utiliser <literal>trust</literal> 
    575 pour une connexion autre que celles issues de <systemitem>localhost</systemitem> 
    576 (127.0.0.1).  </para> 
     543    soit le nom d'utilisateur de base de données qu'il fournit (ce qui 
     544    inclut les super-utilisateurs). Les restrictions apportées dans les 
     545    colonnes <literal>database</literal> et <literal>user</literal> 
     546    continuent évidemment de s'appliquer. Cette méthode ne doit être utilisée 
     547    que si le système assure un contrôle adéquat des connexions au serveur. 
     548   </para> 
     549 
     550   <para> 
     551    L'authentification <literal>trust</literal> est appropriée et très pratique 
     552    pour les connexions locales sur une station de travail mono-utilisateur. Elle 
     553    n'est généralement <emphasis>pas</emphasis> appropriée en soi sur une machine 
     554    multi-utilisateur. Cependant, <literal>trust</literal> peut tout de même  
     555    être utilisé sur une machine multi-utilisateur, si l'accès au fichier 
     556    socket de domaine Unix est restreint par les permissions du système de 
     557    fichiers. Pour ce faire, on peut positionner les paramètres de configuration 
     558    <varname>unix_socket_permissions</varname> (et au besoin 
     559    <varname>unix_socket_group</varname>) comme cela est décrit dans la 
     560    <xref linkend="runtime-config-connection"/>.  
     561    On peut également positionner le paramètre de configuration 
     562    <varname>unix_socket_directory</varname> pour placer le fichier de socket 
     563    dans un répertoire à l'accès convenablement restreint. 
     564   </para> 
     565 
     566   <para> 
     567    Le réglage des droits du système de fichiers n'a d'intérêt que le cas de 
     568    connexions par les sockets Unix. Cela ne restreint pas les connexions 
     569    TCP/IP locales&nbsp;; ainsi, pour utiliser les droits du système de 
     570    fichiers pour assurer la sécurité locale, il faut supprimer la ligne 
     571    <literal>host ...127.0.0.1 ...</literal> de 
     572    <filename>pg_hba.conf</filename> ou la modifier pour utiliser une méthode 
     573    d'authentification différente de <literal>trust</literal>. 
     574   </para> 
     575 
     576   <para> 
     577    L'authentification <literal>trust</literal> n'est valable pour les 
     578    connexions TCP/IP que si chaque utilisateur de chaque machine autorisée 
     579    à se connecter au serveur par les lignes <literal>trust</literal> du 
     580    fichier <filename>pg_hba.conf</filename> est digne de confiance. Il est 
     581    rarement raisonnable d'utiliser <literal>trust</literal> pour les 
     582    connexions autres que celles issues de 
     583    <systemitem>localhost</systemitem> (127.0.0.1). 
     584   </para> 
    577585 
    578586  </sect2> 
    …… 
    588596   </indexterm> 
    589597   <indexterm> 
    590      <primary>mot de passe</primary> 
     598     <primary>password</primary> 
    591599     <secondary>authentification</secondary> 
    592600   </indexterm> 
    593  
    594    <para> 
    595     Les méthodes basées sur une authentification par mot de passe sont 
    596     <literal>md5</literal>, <literal>crypt</literal> et <literal>password</literal>. Ces méthodes 
    597     fonctionnent de façon analogue sauf pour le mode d'envoi du mot de passe 
    598     au travers de la connexion&nbsp;: respectivement, hachage MD5, chiffrement via 
     601   <indexterm> 
     602    <primary>mot de passe</primary> 
     603    <secondary>authentification</secondary> 
     604   </indexterm> 
     605 
     606   <para> 
     607    Les méthodes fondées sur une authentification par mot de passe sont 
     608    <literal>md5</literal>, <literal>crypt</literal> et 
     609    <literal>password</literal>. Ces méthodes 
     610    fonctionnent de façon analogue à l'exception du mode d'envoi du mot de passe 
     611    à travers la connexion&nbsp;: respectivement, hachage MD5, chiffrement via 
    599612    crypt et texte en clair. Une limitation de la méthode <literal>crypt</literal> est 
    600613    qu'elle ne fonctionne pas avec les mots de passe chiffrés dans 
    …… 
    603616 
    604617   <para> 
    605     Si vous êtes préoccupé par les attaques par <quote>interception 
    606     (sniffing)</quote> de mot de passe, alors <literal>md5</literal> est préférable, avec 
    607     <literal>crypt</literal> à n'utiliser que si vous devez supporter les client pré 
    608     7.2. Le simple <literal>password</literal> devrait particulièrement être 
    609     évité pour les connexions ouvertes sur l'Internet (à moins d'utiliser 
    610     <acronym>SSL</acronym>, <acronym>SSH</acronym> ou d'autres systèmes de sécurité par 
    611     encapsulation de connexion). 
    612    </para> 
    613  
    614    <para> 
    615     Les mots de passe de bases de données <productname>PostgreSQL</productname> 
     618    S'il existe un risque d'attaque par <quote>interception (sniffing)</quote> 
     619    des mots de passe, il est préférable d'utiliser <literal>md5</literal>, 
     620    <literal>crypt</literal> devant être limité aux client pré-7.2. 
     621    L'utilisation de <literal>password</literal>, en clair, est tout 
     622    particulièrement à éviter lors de connexions ouvertes sur l'Internet 
     623    (à moins d'utiliser <acronym>SSL</acronym>, <acronym>SSH</acronym> ou 
     624    tout autre système de sécurisation par encapsulation de la connexion). 
     625   </para> 
     626 
     627   <para> 
     628    Les mots de passe <productname>PostgreSQL</productname> 
    616629    sont distincts des mots de passe du système d'exploitation. Le mot de passe 
    617630    de chaque utilisateur est enregistré dans le catalogue système 
    618     <literal>pg_authid</literal>. Les mots de passe peuvent être gérés avec les 
     631    <literal>pg_authid</literal>. Ils peuvent être gérés avec les 
    619632    commandes SQL <xref linkend="sql-createuser" endterm="sql-createuser-title"/> 
    620     et <xref linkend="sql-alteruser" endterm="sql-alteruser-title"/>, par 
    621     exemple <userinput>CREATE USER foo WITH PASSWORD 'secret';</userinput>. Par 
    622     défaut, si aucun mot de passe n'a été indiqué, le mot de passe enregistré sera 
    623     nul et l'authentification par mot de passe échouera systématiquement pour 
     633    et <xref linkend="sql-alteruser" endterm="sql-alteruser-title"/>. Ainsi, par 
     634    exemple, <userinput>CREATE USER foo WITH PASSWORD 'secret';</userinput>. Par 
     635    défaut, c'est à dire si aucun mot de passe n'est indiqué, le mot de passe enregistré 
     636    est nul et l'authentification par mot de passe échoue systématiquement pour 
    624637    cet utilisateur. 
    625638   </para> 
    …… 
    634647    <productname>Kerberos</productname> est un système d'authentification 
    635648    sécurisé de standard industriel destiné à l'informatique distribuée sur un 
    636     réseau public. Une description du système 
    637     <productname>Kerberos</productname> est bien au-delà des objectifs de ce 
    638     document&nbsp; c'est généralement assez complexe (bien que puissant). La 
     649    réseau public. La description de <productname>Kerberos</productname> 
     650    dépasse largement les objectifs de ce document&nbsp; même dans les 
     651    généralités, c'est assez complexe (bien que puissant). La 
    639652    <ulink url="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html"> 
    640     <acronym>FAQ</acronym> Kerberos</ulink> ou la <ulink 
    641     url="http://web.mit.edu/kerberos/www/">page Kerberos du MIT</ulink> peuvent 
    642     être un bon point de départ pour une exploration. Il existe plusieurs 
     653    <acronym>FAQ</acronym> Kerberos</ulink> ou la 
     654    <ulink url="http://web.mit.edu/kerberos/www/">page Kerberos du 
     655    MIT</ulink> sont un bon point de départ à l'exploration. Il existe plusieurs 
    643656    sources de distribution <productname>Kerberos</productname>. 
    644657    <productname>Kerberos</productname> fournit une authentification sécurisée 
    645658    mais ne chiffre pas les requêtes ou les données passées sur le réseau&nbsp;; 
    646     pour cela, utilisez <acronym>SSL</acronym>. 
     659    pour cela, on <acronym>SSL</acronym> doit être utilisé. 
    647660   </para> 
    648661 
    649662   <para> 
    650663    <productname>PostgreSQL</productname> supporte Kerberos version 5. Le 
    651     support de Kerberos doit avoir été activé lors de la construction de 
    652     <productname>PostgreSQL</productname>&nbsp;; voir le <xref 
    653     linkend="installation"/> pour plus d'informations. 
     664    support de Kerberos doit être activé lors de la construction de 
     665    <productname>PostgreSQL</productname>&nbsp;; voir le 
     666    <xref linkend="installation"/> pour plus d'informations. 
    654667   </para> 
    655668 
    …… 
    664677    le paramètre de configuration <xref linkend="guc-krb-srvname"/> (voir 
    665678    aussi <xref linkend="libpq-connect"/>). La valeur par défaut à 
    666     l'installation, <literal>postgres</literal>, peut être modifié au moment 
    667     de la construction en utilisant <literal>./configure 
    668     --with-krb-srvnam=quelquechose</literal>. Dans la plupart des environnements, 
    669     ce paramètre n'a jamais besoin d'être modifié. Néanmoins, pour supporter 
     679    l'installation, <literal>postgres</literal>, peut être modifiée lors 
     680    de la construction avec 
     681    <literal>./configure --with-krb-srvnam=quelquechose</literal>. Dans la 
     682    plupart des environnements, il est inutile de modifier cette valeur. 
     683    Néanmoins, pour supporter 
    670684    plusieurs installations de <productname>PostgreSQL</productname> sur le même hôte, 
    671     cela devient nécessaire. Quelques implémentations de Kerberos pourraient 
    672     aussi réclamer un nom de service différent, comme Microsoft Active 
    673     Directory qui réclame que le nom du service soit en majuscule 
     685    cela devient nécessaire. Quelques implantations de Kerberos peuvent 
     686    imposer un nom de service différent, comme Microsoft Active 
     687    Directory qui réclame un nom du service en majuscules 
    674688    (<literal>POSTGRES</literal>). 
    675689   </para> 
    676690 
    677691   <para> 
    678     <replaceable>nom_hote</replaceable> est le nom de l'hôte pleinement qualifié (fully 
    679     qualified host name) de la machine serveur. Le domaine principal du service 
     692    <replaceable>nom_hote</replaceable> est le nom de l'hôte pleinement 
     693    qualifié (<foreignphrase>fully qualified host name</foreignphrase>) 
     694    de la machine serveur. Le domaine principal du service 
    680695    est le domaine préféré du serveur. 
    681696   </para> 
    682697 
    683    <para>Les principaux clients doivent avoir leur nom d'utilisateur de la base 
    684 de données <productname>PostgreSQL</productname> comme premier composant, par exemple 
    685 <literal>nomutilisateurpg/autreschoses@domaine</literal>. Actuellement, le domaine du client 
    686 n'est pas vérifié par <productname>PostgreSQL</productname>&nbsp;; ainsi si vous avez activé 
    687 l'authentification "cross-realm", chaque "principal" de chaque domaine qui peut 
    688 communiquer avec le vôtre sera accepté.  </para> 
    689  
    690    <para>Assurez-vous que le fichier de clés du serveur est en lecture (et de 
    691 préférence en lecture seule) pour le compte serveur 
    692 <productname>PostgreSQL</productname> (voir aussi la <xref 
    693 linkend="postgres-user"/>). L'emplacement du fichier de clés est indiqué grâce au 
    694 paramètre de configuration <xref linkend="guc-krb-server-keyfile"/> fourni à l'exécution. 
    695 La valeur par défaut est 
    696 <filename>/etc/srvtab</filename> si vous utilisez Kerberos 4 et 
    697 <filename>/usr/local/pgsql/etc/krb5.keytab</filename> (ou quel que soit le 
    698 répertoire spécifié par <varname>sysconfdir</varname> à la compilation).  </para> 
    699  
    700    <para> 
    701     Le fichier de clés est généré par le logiciel Kerberos&nbsp;; voir la 
    702     documentation de Kerberos pour les détails. L'exemple suivant corresponds 
    703     à des implémentations de Kerberos 5 compatibles avec MIT&nbsp;: 
     698   <para> 
     699    Les principaux des clients doivent contenir le nom de leur utilisateur 
     700    <productname>PostgreSQL</productname> comme premier composant, 
     701    <literal>nomutilisateurpg/autreschoses@domaine</literal>, par exemple. 
     702    Actuellement, le domaine du client n'est pas vérifié par 
     703    <productname>PostgreSQL</productname>&nbsp;; de ce fait, si 
     704    l'authentification inter-domaine 
     705    (<foreignphrase>cross-realm</foreignphrase>) est activée, tout 
     706    "principal" de domaine qui peut communiquer avec celui considéré est accepté. 
     707   </para> 
     708 
     709   <para> 
     710    Le fichier de clés du serveur doit être lisible (et de préférence 
     711    uniquement lisible) par le compte serveur 
     712    <productname>PostgreSQL</productname> (voir aussi la 
     713    <xref linkend="postgres-user"/>). L'emplacement du fichier de clés est 
     714    indiqué grâce au paramètre de configuration 
     715    <xref linkend="guc-krb-server-keyfile"/> fourni à l'exécution. La valeur 
     716    par défaut est <filename>/etc/srvtab</filename>, si Kerberos 4 est 
     717    utilisé, et <filename>/usr/local/pgsql/etc/krb5.keytab</filename> sinon 
     718    (ou tout autre répertoire indiqué comme <varname>sysconfdir</varname> à 
     719    la compilation). 
     720   </para> 
     721 
     722   <para> 
     723    Le fichier de clés est engendré par le logiciel Kerberos&nbsp;; voir la 
     724    documentation de Kerberos pour les détails. L'exemple suivant correspond 
     725    à des implantations de Kerberos 5 compatibles avec MIT&nbsp;: 
    704726<screen><prompt>kadmin% </prompt><userinput>ank -randkey postgres/server.my.domain.org</userinput> 
    705727<prompt>kadmin% </prompt><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</userinput></screen> 
    706728   </para> 
    707729 
    708    <para>Lors de la connexion à la base de données, assurez-vous que vous avez 
    709 un ticket pour un "principal" correspondant au nom d'utilisateur de la base de 
    710 données demandé. Un exemple&nbsp;: pour le nom d'utilisateur de la base 
    711 <literal>fred</literal>, les "principal" <literal>fred@EXAMPLE.COM</literal> et 
    712 <literal>fred/users.exemple.com@EXAMPLE.COM</literal> devraient être utilisés pour 
    713 authentifier le serveur de bases de données.  </para> 
    714  
    715    <para>Si vous utilisez <ulink 
    716 url="http://modauthkerb.sf.net">mod_auth_kerb</ulink> et 
    717 <application>mod_perl</application> sur votre serveur web 
    718 <productname>Apache</productname>, vous pouvez utiliser <literal>AuthType 
    719 KerberosV5SaveCredentials</literal> avec un script 
    720 <application>mod_perl</application>. Cela fournit un accès sûr aux bases de 
    721 données, sans demander de mots de passe supplémentaires.  </para> 
     730   <para> 
     731    Lors de la connexion à la base de données, il faut s'assurer de posséder 
     732    un ticket pour le "principal" correspondant au nom d'utilisateur de base 
     733    de données souhaité. Par exemple, pour le nom d'utilisateur 
     734    <literal>fred</literal>, les deux 
     735    <foreignphrase>principal</foreignphrase> <literal>fred@EXAMPLE.COM</literal> 
     736    et <literal>fred/users.exemple.com@EXAMPLE.COM</literal> peuvent être utilisés 
     737    pour authentifier le serveur de bases de données. 
     738   </para> 
     739 
     740   <para> 
     741    Si <ulink url="http://modauthkerb.sf.net">mod_auth_kerb</ulink> et 
     742    <application>mod_perl</application> sont utilisés sur le serveur web 
     743    <productname>Apache</productname>,  
     744    <literal>AuthType KerberosV5SaveCredentials</literal> peut être utilisé 
     745    avec un script <application>mod_perl</application>. Cela fournit un accès 
     746    sûr aux bases de données, sans demander de mot de passe supplémentaire. 
     747   </para> 
    722748 
    723749  </sect2> 
    724750 
    725   <sect2 id="auth-ident"> <title>Authentification basée sur 
    726 l'identification</title> 
     751  <sect2 id="auth-ident"> <title>Authentification basée sur ident</title> 
    727752 
    728753   <indexterm> <primary>ident</primary> </indexterm> 
    729754 
    730    <para>La méthode d'authentification par identification fonctionne en 
    731 obtenant les noms d'utilisateurs du système d'exploitation, puis en déterminant 
    732 les noms d'utilisateurs de bases de données autorisés, en utilisant un fichier 
    733 de correspondance qui liste les paires d'utilisateurs correspondants. 
    734 Déterminer le nom d'utilisateur du client est le point critique en matière de 
    735 sécurité, et il fonctionne différemment selon le type de connexion.  </para> 
    736  
    737    <sect3> <title>Authentification par identification sur TCP/IP</title> 
    738  
    739    <para>Le <quote>protocole d'identification</quote> est décrit dans la 
    740 <citetitle>RFC 1413</citetitle>. Théoriquement, chaque système d'exploitation de 
    741 type Unix contient un serveur d'identification qui écoute par défaut le port TCP 
    742 113. La fonctionnalité basique d'un serveur d'identification est la réponse aux 
    743 questions telles que <quote>Quel utilisateur a initié la connexion qui sort de 
    744 votre port <replaceable>X</replaceable> et se connecte à mon port 
    745 <replaceable>Y</replaceable>?</quote>. <productname>PostgreSQL</productname> connaissant 
    746 <replaceable>X</replaceable> et <replaceable>Y</replaceable> quand une connexion physique est établie, 
    747 il peut interroger le serveur d'identification de l'hôte du client qui se 
    748 connecte et peut ainsi théoriquement déterminer quel est l'utilisateur du 
    749 système d'exploitation pour n'importe quelle connexion.  </para> 
    750  
    751    <para>Le défaut de cette procédure est qu'elle dépend de l'intégrité du 
    752 client&nbsp;: si la machine client est douteuse ou compromise, un attaquant peut 
    753 lancer n'importe quel programme sur le port 113 et renvoyer un nom d'utilisateur 
    754 de son choix. Cette méthode d'authentification n'est par conséquent appropriée 
    755 que dans le cas de réseaux fermés dans lesquels chaque machine client est 
    756 soumise à un contrôle strict et dans lesquels les administrateurs du système et 
    757 des bases de données opèrent en proche collaboration. En d'autres mots, vous 
    758 devez pouvoir faire confiance à la machine hébergeant le serveur 
    759 d'identification.  Considérez cet avertissement: <blockquote> <attribution>RFC 
    760 1413</attribution> <para>Le protocole d'identification n'a pas vocation à être 
    761 un protocole d'autorisation ou de contrôle d'accès.  </para> </blockquote> 
    762 </para> 
    763  
    764    <para> 
    765     Quelques serveurs ident ont une option non standard qui font que le nom de 
    766     l'utilisateur est renvoyé non chiffré en utilisant une clé que seul 
    767     l'administrateur de la machine d'origine connaît. Cette option <emphasis>ne 
    768     doit pas</emphasis> être utilisée lors de l'utilisation du serveur ident avec 
    769     <productname>PostgreSQL</productname> car <productname>PostgreSQL</productname> n'a aucun moyen 
    770     de décrire la chaîne renvoyée pour déterminer le nom réel de l'utilisateur. 
     755   <para> 
     756    La méthode d'authentification par ident fonctionne en obtenant les noms 
     757    d'utilisateurs du système d'exploitation, puis en déterminant les noms 
     758    d'utilisateurs de bases de données autorisés à l'aide d'un fichier 
     759    de correspondance qui liste les paires autorisées de concordance de 
     760    noms. La résolution du nom d'utilisateur du client est le point de sécurité 
     761    critique. Elle fonctionne différemment selon le type de connexion. 
     762   </para> 
     763 
     764   <sect3> <title>Authentification par ident en TCP/IP</title> 
     765 
     766   <para> 
     767    Le <quote>protocole d'identification</quote> est décrit dans la 
     768    <citetitle>RFC 1413</citetitle>. Théoriquement, chaque système 
     769    d'exploitation de type Unix contient un serveur ident 
     770    qui écoute par défaut sur le port TCP 113. La fonctionnalité basique 
     771    d'un serveur ident est de répondre aux questions telles que&nbsp;: 
     772    <quote>Quel utilisateur a initié la connexion qui sort du port 
     773    <replaceable>X</replaceable> et se connecte à mon port 
     774    <replaceable>Y</replaceable>?</quote>. 
     775    Puisque <productname>PostgreSQL</productname> connaît 
     776    <replaceable>X</replaceable> et <replaceable>Y</replaceable> dès lors 
     777    qu'une connexion physique est établie, il peut interroger le serveur 
     778    ident de l'hôte du client qui se connecte et peut ainsi théoriquement 
     779    déterminer l'utilisateur du système d'exploitation pour n'importe quelle 
     780    connexion. 
     781   </para> 
     782 
     783   <para> 
     784    Le revers de cette procédure est qu'elle dépend de l'intégrité du 
     785    client&nbsp;: si la machine cliente est douteuse ou compromise, un attaquant 
     786    peut lancer n'importe quel programme sur le port 113 et retourner un nom 
     787    d'utilisateur de son choix. Cette méthode d'authentification n'est, par 
     788    conséquent, appropriée que dans le cas de réseaux fermés dans lesquels 
     789    chaque machine cliente est soumise à un contrôle strict et dans lesquels 
     790    les administrateurs système et bases de données opèrent en étroite 
     791    collaboration. En d'autres mots, il faut pouvoir faire confiance à la 
     792    machine hébergeant le serveur d'identification. Cet avertissement doit 
     793    être gardé à l'esprit&nbsp;: 
     794    <blockquote> 
     795     <attribution>RFC 1413</attribution> 
     796     <para> 
     797      Le protocole d'identification n'a pas vocation à être un protocole 
     798      d'autorisation ou de contrôle d'accès. 
     799     </para> 
     800    </blockquote> 
     801   </para> 
     802 
     803   <para> 
     804    Certains serveurs ident ont une option non standard qui chiffre le nom de 
     805    l'utilisateur retourné à l'aide d'une clé connue du seul administrateur 
     806    de la machine dont émane la connexion. Cette option <emphasis>ne 
     807    doit pas</emphasis> être employée lorsque le serveur ident est utilisé avec 
     808    <productname>PostgreSQL</productname> car <productname>PostgreSQL</productname> 
     809    n'a aucun moyen de déchiffré la chaîne renvoyée pour déterminer le nom réel 
     810    de l'utilisateur. 
    771811   </para> 
    772812 
    773813</sect3> 
    774814 
    775    <sect3> <title>Authentification par l'identification sur sockets 
    776 locaux</title> 
    777  
    778    <para>Sur les systèmes supportant les requêtes <symbol>SO_PEERCRED</symbol> 
    779 pour les sockets du domaine Unix (actuellement <systemitem 
    780 class="osname">Linux</systemitem>, <systemitem class="osname">FreeBSD</systemitem>, <systemitem 
    781 class="osname">NetBSD</systemitem>, <systemitem class="osname">OpenBSD</systemitem> et <systemitem 
    782 class="osname">BSD/OS</systemitem>), l'authentification par identification peut aussi être 
    783 appliquée aux connexions locales. Dans ce cas, l'utilisation de 
    784 l'authentification par identification n'ajoute aucun risque lié à la sécurité. 
    785 </para> 
     815   <sect3> <title>Authentification par ident sur sockets locaux</title> 
     816 
     817   <para> 
     818    Sur les systèmes qui supportent les requêtes <symbol>SO_PEERCRED</symbol> 
     819    pour les sockets de domaine Unix (actuellement 
     820    <systemitem class="osname">Linux</systemitem>, 
     821    <systemitem class="osname">FreeBSD</systemitem>, 
     822    <systemitem class="osname">NetBSD</systemitem>, 
     823    <systemitem class="osname">OpenBSD</systemitem> et 
     824    <systemitem class="osname">BSD/OS</systemitem>), l'authentification par 
     825    ident peut aussi être appliquée aux connexions locales. Dans ce cas, 
     826    l'utilisation de l'authentification par ident n'ajoute aucun risque de 
     827    sécurité&nbsp; en fait, c'est même un chois préférable sur ce genre de 
     828    système. 
     829   </para> 
    786830 
    787831    <para> 
    788832     Sur les systèmes sans requêtes <symbol>SO_PEERCRED</symbol>, l'authentification 
    789      par identification n'est disponible que pour les connexions TCP/IP. En 
    790      complément, il est possible de préciser  <systemitem 
    791      class="systemname">l'adresse localhost</systemitem> <systemitem 
    792      class="systemname">127.0.0.1</systemitem> et d'établir une connexion à cette 
    793      adresse. Vous pouvez avoir confiance en cette méthode si vous avez 
    794      confiance dans le serveur ident local. 
     833     par ident n'est disponible que pour les connexions TCP/IP. Pour pallier 
     834     ceci, il est possible de préciser l'adresse 
     835     <systemitem class="systemname">localhost</systemitem> 
     836     <systemitem class="systemname">127.0.0.1</systemitem> et d'établir une 
     837     connexion à cette adresse. Si le serveur ident local est digne de 
     838     confiance, alors cette méthode l'est aussi. 
    795839    </para> 
    796840   </sect3> 
    797841 
    798842   <sect3 id="auth-ident-maps"> 
    799     <title>Correspondance d'identité</title> 
    800  
    801    <para>Lorsque vous utilisez l'authentification basée sur l'identification, 
    802 après avoir déterminé le nom de l'utilisateur du système d'exploitation qui a 
    803 initié la connexion, <productname>PostgreSQL</productname> vérifie si cet 
    804 utilisateur est autorisé à se connecter par le nom d'utilisateur de base de 
    805 données qu'il demande. Ceci est contrôlé par l'argument ident map qui suit le 
    806 mot clé <literal>ident</literal> dans le fichier <filename>pg_hba.conf</filename>. Il 
    807 existe une correspondance d'identité prédéfinie, <literal>sameuser</literal>, 
    808 qui permet à n'importe quel utilisateur du système d'exploitation de se 
    809 connecter en tant qu'utilisateur de base de données du même nom (si ce dernier 
    810 existe). Les autres correspondances doivent être créées manuellement.  </para> 
     843    <title>Correspondances d'identité</title> 
     844 
     845   <para> 
     846    Lorsque l'authentification par ident est utilisée, après avoir déterminé 
     847    le nom de l'utilisateur du système d'exploitation qui a initié la 
     848    connexion, <productname>PostgreSQL</productname> vérifie si cet utilisateur 
     849    est autorisé à se connecter avec le nom d'utilisateur de base de données 
     850    souhaité. Ceci est contrôlé par l'argument ident map qui suit le mot clé 
     851    <literal>ident</literal> dans le fichier <filename>pg_hba.conf</filename>. 
     852    Il existe une correspondance d'identité prédéfinie, 
     853    <literal>sameuser</literal>, qui permet à n'importe quel utilisateur du 
     854    système d'exploitation de se connecter en tant qu'utilisateur de la base de 
     855    données du même nom (si cette dernière existe). Les autres correspondances 
     856    doivent être créées manuellement. 
     857   </para>  
    811858 
    812859   <para> 
    813860    Les correspondances d'identité autres que <literal>sameuser</literal> 
    814     sont définies dans le fichier nommé 
    815     par défaut <filename>pg_ident.conf</filename> 
     861    sont définies dans le fichier de concordance, par défaut nommé 
     862    <filename>pg_ident.conf</filename> 
    816863    <indexterm><primary>pg_ident.conf</primary></indexterm> et stocké 
    817     par défaut dans le répertoire data (il est possible de placer le fichier 
    818     de correspondance ailleurs&nbsp;; voir le paramètre de configuration 
    819     <xref linkend="guc-ident-file"/>). Ce fichier contient des lignes de la forme 
    820     suivante&nbsp;: 
     864    dans le répertoire data (il est possible de placer ce fichier 
     865    ailleurs&nbsp;; voir le paramètre de configuration 
     866    <xref linkend="guc-ident-file"/>). Ce fichier contient des lignes de 
     867    la forme&nbsp;: 
    821868<synopsis><replaceable>nom-correspondance</replaceable> <replaceable>nomutilisateur-ident</replaceable> <replaceable>base-donnee-utilisateur</replaceable></synopsis> 
    822     Les commentaires et les espaces sont gérés de la façon habituelle dans le 
     869    Les commentaires et les espaces sont gérés comme dans le 
    823870    fichier <filename>pg_hba.conf</filename>. Le 
    824871    <replaceable>nom-correspondance</replaceable> est un 
    825872    nom arbitraire utilisé pour se référer à cette correspondance dans 
    826     <filename>pg_hba.conf</filename>. Les deux autres champs spécifient quel 
    827     utilisateur du système d'exploitation est autorisé à se connecter sous quel nom 
    828     d'utilisateur de base de données. Le même <replaceable>nom-correspondance</replaceable> 
    829     peut être répété pour spécifier plusieurs correspondances d'utilisateurs au sein 
     873    <filename>pg_hba.conf</filename>. Les deux autres champs indiquent le 
     874    nom de l'utilisateur du système d'exploitation et le nom de 
     875    l'utilisateur de base avec lequel il 
     876    est autorisé à se connecter. Le même <replaceable>nom-correspondance</replaceable> 
     877    peut être répété pour indiquer plusieurs correspondances d'utilisateurs au sein 
    830878    d'une même table de correspondance. Il n'y a pas de restriction sur le nombre 
    831879    d'utilisateurs de bases de données auxquels un utilisateur de système 
    832     d'exploitation donné peut correspondre et vice-versa.  </para> 
    833  
    834   <para>Le fichier <filename>pg_ident.conf</filename> est lu au démarrage et 
    835 quand le processus serveur principal reçoit un signal 
    836 <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>. 
    837 Si vous éditez le fichier sur un système actif, vous aurez besoin de signaler au 
    838 serveur (en utilisant <literal>pg_ctl reload</literal> ou <literal>kill 
    839 -HUP</literal>) qu'il doit relire le fichier.  </para> 
    840  
    841    <para>L'<xref linkend="example-pg-ident.conf"/> montre un fichier 
    842 <filename>pg_ident.conf</filename> pouvant être utilisé conjointement avec le 
    843 fichier <filename>pg_hba.conf</filename> de l'<xref linkend="example-pg-hba.conf"/>. Dans 
    844 cette configuration d'exemple, n'importe qui connecté sur une machine du réseau 
    845 192.168 qui n'a pas de nom utilisateur Unix <literal>bryanh</literal>, <literal>ann</literal>, 
    846 ou <literal>robert</literal> ne pourra obtenir d'accès. L'utilisateur Unix 
    847 <literal>robert</literal> ne sera autorisé à se connecter que lorsqu'il se connecte 
    848 sous l'utilisateur <productname>PostgreSQL</productname> <literal>bob</literal> et non 
    849 <literal>robert</literal> ni n'importe qui d'autre. <literal>ann</literal> ne sera autorisée 
    850 à se connecter qu'en tant que <literal>ann</literal>. L'utilisateur <literal>bryanh</literal> 
    851 ne sera autorisé à se connecter qu'en tant que <literal>bryanh</literal> lui-même ou 
    852 comme <literal>guest1</literal>.  </para> 
     880    d'exploitation donné peut correspondre et vice-versa. 
     881   </para> 
     882 
     883   <para> 
     884    Le fichier <filename>pg_ident.conf</filename> est lu au démarrage et 
     885    à chaque fois que le processus serveur principal reçoit un signal 
     886    <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>. 
     887    Si le fichier est édité sur un système actif, il est nécessaire de signaler 
     888    au serveur (à l'aide de la commande <literal>pg_ctl reload</literal> 
     889    ou <literal>kill -HUP</literal>) qu'il doit relire le fichier. 
     890   </para> 
     891  
     892   <para> 
     893    L'<xref linkend="example-pg-ident.conf"/> présente un fichier 
     894    <filename>pg_ident.conf</filename> utilisable conjointement avec 
     895    le fichier <filename>pg_hba.conf</filename> de 
     896    l'<xref linkend="example-pg-hba.conf"/>. Dans cette configuration, 
     897    quiconque est connecté sur une machine du réseau 192.168 et n'a pas pour nom 
     898    d'utilisateur Unix <literal>bryanh</literal>, <literal>ann</literal> ou 
     899    <literal>robert</literal> ne peut obtenir d'accès. L'utilisateur Unix 
     900    <literal>robert</literal> n'est autorisé à se connecter que sous 
     901    l'utilisateur <productname>PostgreSQL</productname> 
     902    <literal>bob</literal> et non <literal>robert</literal> ou n'importe 
     903    quel autre utilisateur. <literal>ann</literal> n'est autorisée à se 
     904    connecter qu'en tant que <literal>ann</literal>. L'utilisateur 
     905    <literal>bryanh</literal> n'est autorisé à se connecter qu'en tant que 
     906    <literal>bryanh</literal> lui-même ou <literal>guest1</literal>. 
     907   </para> 
    853908 
    854909   <example id="example-pg-ident.conf"> 
    …… 
    863918omicron              bryanh                  guest1 </programlisting> 
    864919    </example> 
    865 </sect3> </sect2> 
     920   </sect3> 
     921  </sect2> 
    866922 
    867923  <sect2 id="auth-ldap"> 
    …… 
    873929 
    874930   <para> 
    875     Cette méthode d'authentification opère de façon similaire à 
    876     <literal>password</literal> sauf qu'elle utilise LDAP comme méthode 
    877     d'authentification. LDAP est seulement utilisé pour valider des paires 
    878     nom d'utilisateur/mot de passe. Du coup, l'utilisateur doit déjà exister 
    879     dans la base avant que LDAP ne puisse être utilisé pour l'authentification. 
    880     Le serveur et les paramètres utilisés sont indiqués après le mot clé 
     931    Ce mécanisme d'authentification opère de façon similaire à 
     932    <literal>password</literal> à ceci près qu'il utilise LDAP comme 
     933    méthode 
     934    d'authentification. LDAP n'est utilisé que pour valider les paires 
     935    nom d'utilisateur/mot de passe. De ce fait, pour pouvoir utiliser LDAP 
     936    comme méthode d'authentification, l'utilisateur doit préalablement exister 
     937    dans la base. Le serveur et les paramètres utilisés sont indiqués après le mot clé 
    881938    <literal>ldap</literal> dans le fichier <filename>pg_hba.conf</filename>. 
    882939    Le format de ce paramètre est&nbsp;: 
    …… 
    890947   <para> 
    891948    Si <literal>ldaps</literal> est indiqué à la place de <literal>ldap</literal>, 
    892     le chiffrement TLS sera activé pour la connexion. Notez que seule la 
    893     connexion entre le serveur PostgreSQL et le serveur LDAP sera chiffré. La 
     949    le chiffrement TLS est activé pour la connexion. Seule la 
     950    connexion entre le serveur PostgreSQL et le serveur LDAP est chiffrée. La 
    894951    connexion entre le client et le serveur PostgreSQL n'est pas affectée par 
    895     cette configuration. Pour utiliser le chiffrement TLS, vous aurez besoin 
    896     de configurer la bibliothèque LDAP avant de configurer PostgreSQL. Notez 
    897     que le LDAP chiffré est seulement disponible si la bibliothèque LDAP de la 
     952    cette configuration. Pour pouvoir utiliser le chiffrement TLS,  
     953    la bibliothèque LDAP doit être configurée préalablement à la 
     954    configuration de <productname>PostgreSQL</productname>. Le chiffrement 
     955    de LDAP n'est disponible que si la bibliothèque LDAP de la 
    898956    plateforme le supporte. 
    899957   </para> 
    900958   <para> 
    901     Si aucun port n'est indiqué, le port par défaut configuré au niveau de la 
    902     bibliothèque LDAP sera utilisé. 
    903    </para> 
    904    <para> 
    905     Le serveur se liera au nom distingué indiqué comme 
    906     <replaceable>base dn</replaceable> en utilisant le nom utilisateur fourni 
     959    Si aucun port n'est indiqué, le port par défaut tel que configuré au niveau de la 
     960    bibliothèque LDAP est utilisé. 
     961   </para> 
     962   <para> 
     963    Le serveur se lie au nom distingué indiqué comme 
     964    <replaceable>base dn</replaceable> avec le nom d'utilisateur fourni 
    907965    par le client. Si <replaceable>préfixe</replaceable> et 
    908     <replaceable>suffixe</replaceable> sont indiqués, ils seront ajoutés au nom 
    909     de l'utilisateur avant la création du lien. Typiquement, le paramètre préfixe 
    910     est utilisé pour spécifier un <replaceable>cn=</replaceable> ou un 
     966    <replaceable>suffixe</replaceable> sont indiqués, ils sont ajoutés au nom 
     967    de l'utilisateur avant la création du lien. Le paramètre 
     968    <replaceable>préfixe</replaceable> 
     969    est utilisé pour préciser un <replaceable>cn=</replaceable> ou un 
    911970    <replaceable>DOMAIN\</replaceable> dans un environnement Active Directory. 
    912971   </para> 
    …… 
    920979   </indexterm> 
    921980 
    922    <para>Cette méthode d'authentification fonctionne de façon similaire à 
    923     <literal>password</literal> à ceci près qu'elle utilise PAM (Pluggable 
    924     Authentication Modules) comme mécanisme d'authentification. Le nom du 
    925     service PAM par défaut est <literal>postgresql</literal>. Vous pouvez 
    926     éventuellement fournir votre nom de service grâce au mot clé <literal>pam</literal> 
    927     du <filename>pg_hba.conf</filename>. PAM est seulement utilisé pour valider 
    928     des paires nom utilisateur/mot de passe. Du coup, l'utilisateur doit déjà 
    929     exister dans la base de données avant que PAM ne puisse être utilisé pour 
    930     l'authentification. Pour plus d'informations sur PAM, merci de lire la 
     981   <para> 
     982    Ce mécanisme d'authentification fonctionne de façon similaire à 
     983    <literal>password</literal> à ceci près qu'il utilise PAM (Pluggable 
     984    Authentication Modules) comme méthode d'authentification. Le nom du 
     985    service PAM par défaut est <literal>postgresql</literal>. Le nom de 
     986    service personnel peut être fourni grâce au mot clé <literal>pam</literal> 
     987    du <filename>pg_hba.conf</filename>. PAM n'est utilisé que pour valider 
     988    des paires nom utilisateur/mot de passe. De ce fait, avant de pouvoir 
     989    utiliser PAM pour l'authentification, l'utilisateur doit préalablement 
     990    exister dans la base de données. Pour plus d'informations sur PAM, 
     991    merci de lire la 
    931992    <ulink url="http://www.kernel.org/pub/linux/libs/pam/">page 
    932     <productname>Linux-PAM</productname></ulink> et la <ulink 
    933     url="http://www.sun.com/software/solaris/pam/">page PAM <systemitem 
    934     class="osname">Solaris</systemitem></ulink>.</para> 
     993    <productname>Linux-PAM</productname></ulink> et la 
     994    <ulink url="http://www.sun.com/software/solaris/pam/">page PAM 
     995    <systemitem class="osname">Solaris</systemitem></ulink>. 
     996   </para> 
    935997  </sect2> 
    936998 </sect1> 
    937999 
    938   <sect1 id="client-authentication-problems"> <title>Problèmes 
    939 d'authentification</title> 
    940  
    941    <para>Les erreurs et problèmes d'authentification se manifestent 
    942 généralement par des messages d'erreurs tels que ceux qui suivent.  </para> 
     1000  <sect1 id="client-authentication-problems"> <title>Problèmes d'authentification</title> 
     1001 
     1002   <para> 
     1003    Les erreurs et problèmes d'authentification se manifestent 
     1004    généralement par des messages d'erreurs tels que ceux qui suivent. 
     1005   </para> 
    9431006 
    9441007   <para> 
    9451008<programlisting>FATAL:  no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"</programlisting> 
    946     C'est ce que vous risquez le plus d'obtenir si vous parvenez à contacter 
    947     le serveur mais qu'il refuse de vous parler. Comme le suggère le message, 
     1009    ou, en français,  
     1010<programlisting>FATAL:  pas d'entrée pg_hba.conf pour l'hôte "123.123.123.123", utilisateur "andym", base "testdb"</programlisting> 
     1011    C'est le message le plus probable lorsque le contact peut être établi avec le 
     1012    serveur mais qu'il refuse de communiquer. Comme le suggère le message, 
    9481013    le serveur a refusé la demande de connexion parce qu'il n'a trouvé aucune 
    9491014    entrée correspondante dans son fichier de configuration 
    950     <filename>pg_hba.conf</filename>.</para> 
     1015    <filename>pg_hba.conf</filename>. 
     1016   </para> 
    9511017 
    9521018   <para> 
    9531019<programlisting>FATAL:  Password authentication failed for user "andym"</programlisting> 
    954     Les messages de ce type indiquent que vous avez contacté le serveur et 
    955     qu'il veut vous parler mais pas avant que vous n'ayez franchi la méthode 
    956     d'authentification spécifiée dans le fichier 
    957     <filename>pg_hba.conf</filename>.  Vérifiez le mot de passe que vous avez 
    958     fourni ou vérifiez votre logiciel d'identification ou votre logiciel Kerberos 
    959     si les plaintes mentionnent l'un de ces types d'authentification.</para> 
     1020    ou, en français,  
     1021<programlisting>FATAL:  l'authentification par mot de passe a échoué pour l'utilisateur "andym"</programlisting> 
     1022    Les messages de ce type indiquent que le serveur a été contacté et 
     1023    qu'il accepte la communication, mais pas avant que la méthode 
     1024    d'authentification indiquée dans le fichier 
     1025    <filename>pg_hba.conf</filename> n'ait été franchie avec succès. 
     1026    Le mot de passe fourni, le logiciel d'identification ou le logiciel 
     1027    Kerberos doivent être vérifiés en fonction du type d'authentification 
     1028    mentionné dans la plainte. 
     1029   </para> 
    9601030 
    9611031   <para> 
    9621032<programlisting>FATAL:  user "andym" does not exist</programlisting> 
    963     Le nom d'utilisateur indiqué n'a pas été trouvé.  </para> 
     1033    ou, en français,  
     1034<programlisting>FATAL:  l'utilisateur "andym" n'existe pas</programlisting> 
     1035    Le nom d'utilisateur indiqué n'a pas été trouvé. 
     1036   </para> 
    9641037 
    9651038   <para> 
    9661039<programlisting>FATAL:  database "testdb" does not exist</programlisting> 
    967     La base de données à laquelle vous essayez de vous connecter n'existe pas. 
    968     Notez que si vous ne spécifiez pas un nom de base de données, le nom de la 
    969     base par défaut est le nom de l'utilisateur de la base de données, ce qui 
    970     peut être ou pas une bonne chose.</para> 
     1040    ou, en français, 
     1041<programlisting>FATAL:  la base "testdb" n'existe pas