-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathauth-methods.html
More file actions
889 lines (889 loc) · 90.4 KB
/
auth-methods.html
File metadata and controls
889 lines (889 loc) · 90.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>20.3. 認証方式</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="auth-username-maps.html" title="20.2. ユーザ名マップ" /><link rel="next" href="client-authentication-problems.html" title="20.4. 認証における問題点" /><meta name="viewport" content="width=device-width,initial-scale=1.0" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="4" align="center"><a accesskey="h" href="index.html">PostgreSQL 10.5文書</a></th></tr><tr><td width="10%" align="left"></td><td width="10%" align="left"></td><td width="60%" align="center"><a href="client-authentication.html" title="第20章 クライアント認証">第20章 クライアント認証</a></td><td width="20%" align="right"><div class="actions"><a class="issue" title="github" href="https://github.com/pgsql-jp/jpug-doc/issues/new?title=version 10.5 auth-methods.html">誤訳等の報告
</a></div></td></tr><tr><td width="10%" align="left"><a accesskey="p" href="auth-username-maps.html" title="20.2. ユーザ名マップ">前へ</a> </td><td width="10%" align="left"><a accesskey="u" href="client-authentication.html" title="第20章 クライアント認証">上へ</a></td><td width="60%" align="center">20.3. 認証方式</td><td width="20%" align="right"> <a accesskey="n" href="client-authentication-problems.html" title="20.4. 認証における問題点">次へ</a></td></tr></table><hr /></div><div class="sect1" id="AUTH-METHODS"><div class="titlepage"><div><div><h2 class="title" style="clear: both">20.3. 認証方式</h2></div></div></div><span class="original">
<title>Authentication Methods</title>
</span><p><span class="original">
The following subsections describe the authentication methods in more detail.
</span> 以下の小節では、認証方式について詳細に説明します。
</p><div class="sect2" id="AUTH-TRUST"><div class="titlepage"><div><div><h3 class="title">20.3.1. trust認証</h3></div></div></div><span class="original">
<title>Trust Authentication</title>
</span><p><span class="original">
When <literal>trust</> authentication is specified,
<productname>PostgreSQL</productname> assumes that anyone who can
connect to the server is authorized to access the database with
whatever database user name they specify (even superuser names).
Of course, restrictions made in the <literal>database</> and
<literal>user</> columns still apply.
This method should only be used when there is adequate
operating-system-level protection on connections to the server.
</span><code class="literal">trust</code>認証が指定されると<span class="productname">PostgreSQL</span>は、サーバに接続できる全ての人に対して
（データベーススーパーユーザさえも）その人が指定する任意のデータベースユーザ名としてのアクセス権限が付与されていると想定します。
当然ながら<code class="literal">database</code>と<code class="literal">user</code>列にある制限は適用されます。
この方式はサーバに接続する際に適切なオペレーティングシステムレベルの保護が掛けられている場合にのみ使用すべきです。
</p><p><span class="original">
<literal>trust</> authentication is appropriate and very
convenient for local connections on a single-user workstation. It
is usually <emphasis>not</> appropriate by itself on a multiuser
machine. However, you might be able to use <literal>trust</> even
on a multiuser machine, if you restrict access to the server's
Unix-domain socket file using file-system permissions. To do this, set the
<varname>unix_socket_permissions</varname> (and possibly
<varname>unix_socket_group</varname>) configuration parameters as
described in <xref linkend="runtime-config-connection">. Or you
could set the <varname>unix_socket_directories</varname>
configuration parameter to place the socket file in a suitably
restricted directory.
</span><code class="literal">trust</code>認証はユーザが1人のみのワークステーション上でローカル接続を行う場合は適切であると同時に非常に便利です。
複数ユーザが存在するマシン上では一般的に適切では<span class="emphasis"><em>ありません</em></span>。
とは言っても、ファイルシステムの許可属性を使ってサーバのUnixドメインソケットファイルへのアクセスを制限すれば<code class="literal">trust</code>認証を複数ユーザのマシン上で使用することも可能です。
その方法は、<a class="xref" href="runtime-config-connection.html" title="19.3. 接続と認証">19.3</a>に記載されているように<code class="varname">unix_socket_permissions</code>（および<code class="varname">unix_socket_group</code>パラメータの可能性もあります）パラメータを設定します。
もしくは、<code class="varname">unix_socket_directories</code>設定パラメータでソケットファイルをそれに相応しく制限されているディレクトリにします。
</p><p><span class="original">
Setting file-system permissions only helps for Unix-socket connections.
Local TCP/IP connections are not restricted by file-system permissions.
Therefore, if you want to use file-system permissions for local security,
remove the <literal>host ... 127.0.0.1 ...</> line from
<filename>pg_hba.conf</>, or change it to a
non-<literal>trust</> authentication method.
</span>Unixソケット接続を行うただ1つの方法は、ファイルシステムの許可を設定することです。
ローカルのTCP/IP接続は、ファイルシステムにより制限はされていません。
よってローカルでファイルシステムの許可を使用したい場合は<code class="filename">pg_hba.conf</code>から
<code class="literal">host ... 127.0.0.1 ...</code>の行を削除するか、<code class="literal">trust</code>認証とは異なる方法に変更する必要があります。
</p><p><span class="original">
<literal>trust</> authentication is only suitable for TCP/IP connections
if you trust every user on every machine that is allowed to connect
to the server by the <filename>pg_hba.conf</> lines that specify
<literal>trust</>. It is seldom reasonable to use <literal>trust</>
for any TCP/IP connections other than those from <systemitem>localhost</> (127.0.0.1).
</span>TCP/IP接続における<code class="literal">trust</code>認証は、<code class="literal">trust</code>を指定する<code class="filename">pg_hba.conf</code>の行によってサーバに接続を許可される全てのマシン上の全てのユーザを信用（trust）できる場合にのみ相応しいものです。
<span class="systemitem">ローカルホスト</span>（127.0.0.1）以外からのTCP/IP接続に<code class="literal">trust</code>認証を用いる理由はほとんど見当たりません。
</p></div><div class="sect2" id="AUTH-PASSWORD"><div class="titlepage"><div><div><h3 class="title">20.3.2. パスワード認証</h3></div></div></div><span class="original">
<title>Password Authentication</title>
</span><a id="id-1.6.7.10.4.2" class="indexterm"></a><a id="id-1.6.7.10.4.3" class="indexterm"></a><a id="id-1.6.7.10.4.4" class="indexterm"></a><p><span class="original">
There are several password-based authentication methods. These methods
operate similarly but differ in how the users' passwords are stored on the
server and how the password provided by a client is sent across the
connection.
</span>複数のパスワードに基づく認証方式があります。
これらは似たような方法で使用されますが、ユーザのパスワードをサーバに格納する方法と、クライアントによって提供されたパスワードが接続を通じて送信される方法が異なります。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">scram-sha-256</code></span></dt><dd><p><span class="original">
The method <literal>scram-sha-256</> performs SCRAM-SHA-256
authentication, as described in
<ulink url="https://tools.ietf.org/html/rfc7677">RFC 7677</ulink>. It
is a challenge-response scheme that prevents password sniffing on
untrusted connections and supports storing passwords on the server in a
cryptographically hashed form that is thought to be secure.
</span><code class="literal">scram-sha-256</code>方式は、<a class="ulink" href="https://tools.ietf.org/html/rfc7677" target="_top">RFC 7677</a>に記述された方法でSCRAM-SHA-256認証を実行します。
これはチャレンジ／レスポンス方式のひとつであり、信頼できない接続におけるパスワードの漏洩を防ぎ、安全だと見なされる暗号学的ハッシュ形式でパスワードをサーバに格納するのを支援します。
</p><p><span class="original">
This is the most secure of the currently provided methods, but it is
not supported by older client libraries.
</span>これは、現在実装されている認証方式の中では最も安全ですが、古いクライアントライブラリではサポートされていません。
</p></dd><dt><span class="term"><code class="literal">md5</code></span></dt><dd><p><span class="original">
The method <literal>md5</> uses a custom less secure challenge-response
mechanism. It prevents password sniffing and avoids storing passwords
on the server in plain text but provides no protection if an attacker
manages to steal the password hash from the server. Also, the MD5 hash
algorithm is nowadays no longer considered secure against determined
attacks.
</span><code class="literal">md5</code>方式は、独自のより安全性の低いチャレンジ／レスポンス機構を使います。
パスワードの漏洩を防ぎ、平文でパスワードをサーバに格納するのを避けることができますが、攻撃者がサーバからパスワードハッシュを盗むことを防ぐのを防ぐことはできません。
また、MD5ハッシュアルゴリズムは、昨今では強い意志をもった攻撃に対しては安全ではないと考えられています。
</p><p><span class="original">
The <literal>md5</literal> method cannot be used with
the <xref linkend="guc-db-user-namespace"> feature.
</span><code class="literal">md5</code>は、<a class="xref" href="runtime-config-connection.html#GUC-DB-USER-NAMESPACE">db_user_namespace</a>機能と一緒に使用することはできません。
</p><p><span class="original">
To ease transition from the <literal>md5</literal> method to the newer
SCRAM method, if <literal>md5</literal> is specified as a method
in <filename>pg_hba.conf</filename> but the user's password on the
server is encrypted for SCRAM (see below), then SCRAM-based
authentication will automatically be chosen instead.
</span><code class="literal">md5</code>方式からより新しいSCRAM方式への移行を容易にするため、<code class="filename">pg_hba.conf</code>で<code class="literal">md5</code>が指定されているにもかかわらず、パスワードがSCRAM（下記参照）で暗号化されている場合には、自動的にSCRAMに基づく認証が代わりに使用されます。
</p></dd><dt><span class="term"><code class="literal">password</code></span></dt><dd><p><span class="original">
The method <literal>password</> sends the password in clear-text and is
therefore vulnerable to password <quote>sniffing</> attacks. It should
always be avoided if possible. If the connection is protected by SSL
encryption then <literal>password</> can be used safely, though.
(Though SSL certificate authentication might be a better choice if one
is depending on using SSL).
</span><code class="literal">password</code>方式は、パスワードを平文で送信するので、パスワード<span class="quote">「<span class="quote">盗聴</span>」</span>攻撃に対して脆弱です。
可能ならば、常に避けるようにしてください。
しかしながら、接続がSSL暗号で保護されていれば、<code class="literal">password</code>は安全に使用できます。
（もっとも、SSLの利用に依存するのであれば、SSL証明書認証がより良い選択かもしれません。）
</p></dd></dl></div><p><span class="original">
<productname>PostgreSQL</productname> database passwords are
separate from operating system user passwords. The password for
each database user is stored in the <literal>pg_authid</> system
catalog. Passwords can be managed with the SQL commands
<xref linkend="sql-createuser"> and
<xref linkend="sql-alterrole">,
e.g., <userinput>CREATE USER foo WITH PASSWORD 'secret'</userinput>,
or the <application>psql</application>
command <literal>\password</literal>.
If no password has been set up for a user, the stored password
is null and password authentication will always fail for that user.
</span><span class="productname">PostgreSQL</span>データベースパスワードはオペレーティングシステムのユーザパスワードとも別のものです。
各データベースユーザのパスワードは<code class="literal">pg_authid</code>システムカタログテーブルの中に格納されます。
<strong class="userinput"><code>CREATE USER foo WITH PASSWORD 'secret';</code></strong>のように、パスワードはSQLコマンド<a class="xref" href="sql-createuser.html" title="CREATE USER"><span class="refentrytitle">CREATE USER</span></a>と<a class="xref" href="sql-alterrole.html" title="ALTER ROLE"><span class="refentrytitle">ALTER ROLE</span></a>を使って管理できます。
あるいは、<span class="application">psql</span>の<code class="literal">\password</code>コマンドでも管理できます。
もしユーザに対してパスワードが設定されない場合、格納されるパスワードはNULLとなり、そのユーザのパスワード認証は常に失敗します。
</p><p><span class="original">
The availability of the different password-based authentication methods
depends on how a user's password on the server is encrypted (or hashed,
more accurately). This is controlled by the configuration
parameter <xref linkend="guc-password-encryption"> at the time the
password is set. If a password was encrypted using
the <literal>scram-sha-256</literal> setting, then it can be used for the
authentication methods <literal>scram-sha-256</literal>
and <literal>password</literal> (but password transmission will be in
plain text in the latter case). The authentication method
specification <literal>md5</literal> will automatically switch to using
the <literal>scram-sha-256</literal> method in this case, as explained
above, so it will also work. If a password was encrypted using
the <literal>md5</literal> setting, then it can be used only for
the <literal>md5</literal> and <literal>password</literal> authentication
method specifications (again, with the password transmitted in plain text
in the latter case). (Previous PostgreSQL releases supported storing the
password on the server in plain text. This is no longer possible.) To
check the currently stored password hashes, see the system
catalog <literal>pg_authid</literal>.
</span>パスワードにもとづく異なる認証方式が利用可能かどうかは、サーバ上でユーザのパスワードがどのように暗号化（正確には、ハッシュ化）されるのかに依存します。
これは、パスワードが設定されたときに、設定パラメータの<a class="xref" href="runtime-config-connection.html#GUC-PASSWORD-ENCRYPTION">password_encryption</a>によって制御されます。
パスワードが<code class="literal">scram-sha-256</code>によって暗号化されていれば、認証方式の<code class="literal">scram-sha-256</code>と<code class="literal">password</code>で利用できます。
（ただし、後者の場合にはパスワードの転送は平文になります。）
前述のように、ここで認証方式の<code class="literal">md5</code>を指定すると、<code class="literal">scram-sha-256</code>方式に自動的に切り替わります。
パスワードが<code class="literal">md5</code>で暗号化されていると、<code class="literal">md5</code>と<code class="literal">password</code>でのみ使用されます。
（ここでも、後者の場合にはパスワードは平文で転送されます。）
（以前のPostgreSQLのリリースでは、パスワードを平文で格納することをサポートしていました。
これはもはや不可能です。）
現在格納されているパスワードのハッシュを確認するには、システムカタログ<code class="literal">pg_authid</code>を参照してください。
</p><p><span class="original">
To upgrade an existing installation from <literal>md5</literal>
to <literal>scram-sha-256</literal>, after having ensured that all client
libraries in use are new enough to support SCRAM,
set <literal>password_encryption = 'scram-sha-256'</literal>
in <filename>postgresql.conf</filename>, make all users set new passwords,
and change the authentication method specifications
in <filename>pg_hba.conf</filename> to <literal>scram-sha-256</literal>.
</span>既存のインストールにおいて、<code class="literal">md5</code>から<code class="literal">scram-sha-256</code>にアップグレードするには、すべてのクライアントライブラリが十分新しく、SCRAMをサポートをできることを確認してから、<code class="filename">postgresql.conf</code>で<code class="literal">password_encryption = 'scram-sha-256'</code>を設定し、すべてのユーザに新しいパスワードを設定してもらい、<code class="filename">pg_hba.conf</code>の認証方式を<code class="literal">scram-sha-256</code>に変更してください。
</p></div><div class="sect2" id="GSSAPI-AUTH"><div class="titlepage"><div><div><h3 class="title">20.3.3. GSSAPI認証</h3></div></div></div><span class="original">
<title>GSSAPI Authentication</title>
</span><a id="id-1.6.7.10.5.2" class="indexterm"></a><p><span class="original">
<productname>GSSAPI</productname> is an industry-standard protocol
for secure authentication defined in RFC 2743.
<productname>PostgreSQL</productname> supports
<productname>GSSAPI</productname> with <productname>Kerberos</productname>
authentication according to RFC 1964. <productname>GSSAPI</productname>
provides automatic authentication (single sign-on) for systems
that support it. The authentication itself is secure, but the
data sent over the database connection will be sent unencrypted unless
<acronym>SSL</acronym> is used.
</span><span class="productname">GSSAPI</span>は、RFC 2743で定義されている安全な認証のための業界標準のプロトコルです。
<span class="productname">PostgreSQL</span>は、RFC 1964により<span class="productname">Kerberos</span>認証での<span class="productname">GSSAPI</span>をサポートします。
<span class="productname">GSSAPI</span>は、<span class="productname">GSSAPI</span>をサポートしているシステムに対して自動認証（シングルサインオン）を提供します。
認証自体は安全ですが、データベース接続を通じて送信されるデータは、<acronym class="acronym">SSL</acronym>が使用されていない場合は平文となります。
</p><p><span class="original">
GSSAPI support has to be enabled when <productname>PostgreSQL</> is built;
see <xref linkend="installation"> for more information.
</span>GSSAPIサポートは、<span class="productname">PostgreSQL</span>を構築する時に有効にしなければなりません。詳細は、<a class="xref" href="installation.html" title="第16章 ソースコードからインストール">第16章</a>を参照してください。
</p><p><span class="original">
When <productname>GSSAPI</productname> uses
<productname>Kerberos</productname>, it uses a standard principal
in the format
<literal><replaceable>servicename</>/<replaceable>hostname</>@<replaceable>realm</></literal>.
The PostgreSQL server will accept any principal that is included in the keytab used by
the server, but care needs to be taken to specify the correct principal details when
making the connection from the client using the <literal>krbsrvname</> connection parameter. (See
also <xref linkend="libpq-paramkeywords">.) The installation default can be
changed from the default <literal>postgres</literal> at build time using
<literal>./configure &#045;-with-krb-srvnam=</><replaceable>whatever</>.
In most environments,
this parameter never needs to be changed.
Some Kerberos implementations might require a different service name,
such as Microsoft Active Directory which requires the service name
to be in upper case (<literal>POSTGRES</literal>).
</span><span class="productname">GSSAPI</span>が<span class="productname">Kerberos</span>を使用しているとき、<span class="productname">GSSAPI</span>は、<code class="literal"><em class="replaceable"><code>servicename</code></em>/<em class="replaceable"><code>hostname</code></em>@<em class="replaceable"><code>realm</code></em></code>という書式の標準のプリンシパルを使用します。
[訳注：プリンシパルとは大雑把に2つのものを指します。1つはサービスを受けるクライアントで、もう1つはサービスを提供するサーバアプリケーションです。どちらも、認証に関してはKerberosのKDCから見るとクライアントになります]
PostgreSQLサーバはサーバにより使われるkeytabに含まれるいかなるプリンシパルも受け付けますが、<code class="literal">krbsrvname</code>接続パラメータを使ってクライアントから接続する場合には、プリンシパルの詳細を正確に指定することに注意を払う必要があります。
(<a class="xref" href="libpq-connect.html#LIBPQ-PARAMKEYWORDS" title="33.1.2. パラメータキーワード">33.1.2</a>も参照してください。)
ビルド時に<code class="literal">./configure --with-krb-srvnam=whatever</code>を使用することで、インストール時のデフォルトはデフォルトの<code class="literal">postgres</code>から変更が可能です。
多くの環境では、このパラメータは変更する必要はないでしょう。
いくつかのKerberosの実装では、異なるサービス名が必要になります。Microsoftアクティブディレクトリではサービス名は（<code class="literal">POSTGRES</code>）のように大文字にする必要があります。
</p><p><span class="original">
<replaceable>hostname</> is the fully qualified host name of the
server machine. The service principal's realm is the preferred realm
of the server machine.
</span><em class="replaceable"><code>hostname</code></em>はサーバマシンの完全修飾されたホスト名です。
サービスプリンシパルのrealmはサーバマシンが提起したrealmです。
</p><p><span class="original">
Client principals can be mapped to different <productname>PostgreSQL</>
database user names with <filename>pg_ident.conf</>. For example,
<literal>pgusername@realm</> could be mapped to just <literal>pgusername</>.
Alternatively, you can use the full <literal>username@realm</> principal as
the role name in <productname>PostgreSQL</> without any mapping.
</span>クライアントのプリンシパルは<code class="filename">pg_ident.conf</code>で異なる<span class="productname">PostgreSQL</span>のデータベースユーザ名にマップできます。
例えば、<code class="literal">pgusername@realm</code>を単なる<code class="literal">pgusername</code>にマップできます。
もう1つの方法として、プリンシパル名全体<code class="literal">username@realm</code>を<span class="productname">PostgreSQL</span>のロール名としてマッピングなしに使うこともできます。
</p><p><span class="original">
<productname>PostgreSQL</> also supports a parameter to strip the realm from
the principal. This method is supported for backwards compatibility and is
strongly discouraged as it is then impossible to distinguish different users
with the same user name but coming from different realms. To enable this,
set <literal>include_realm</> to 0. For simple single-realm
installations, doing that combined with setting the
<literal>krb_realm</> parameter (which checks that the principal's realm
matches exactly what is in the <literal>krb_realm</literal> parameter)
is still secure; but this is a
less capable approach compared to specifying an explicit mapping in
<filename>pg_ident.conf</>.
</span><span class="productname">PostgreSQL</span>はプリンシパルからrealmを外すパラメータもサポートしています。
この方法は後方互換のためにサポートされているものであり、異なるrealmから来た同じユーザ名の異なるユーザを区別することができませんので、使用しないことを強く薦めます。
この方法を有効にするには<code class="literal">include_realm</code>を0に設定してください。
単純な単一realmの設定では、(プリンシパルのrealmが<code class="literal">krb_realm</code>パラメータ内のものと正確に一致するか確認する)<code class="literal">krb_realm</code>パラメータと組み合わせることが安全です。
しかし、これは<code class="filename">pg_ident.conf</code>で明示的なマッピングを指定するのに比べてあまり適切でない選択でしょう。
</p><p><span class="original">
Make sure that your server keytab file is readable (and preferably
only readable, not writable) by the <productname>PostgreSQL</productname>
server account. (See also <xref linkend="postgres-user">.) The location
of the key file is specified by the <xref
linkend="guc-krb-server-keyfile"> configuration
parameter. The default is
<filename>/usr/local/pgsql/etc/krb5.keytab</> (or whatever
directory was specified as <varname>sysconfdir</> at build time).
For security reasons, it is recommended to use a separate keytab
just for the <productname>PostgreSQL</productname> server rather
than opening up permissions on the system keytab file.
</span>サーバ鍵ファイルが<span class="productname">PostgreSQL</span>サーバアカウントによって読み込み可能（そしてできれば読み込み専用で書き込み不可）であることを確認してください。
（<a class="xref" href="postgres-user.html" title="18.1. PostgreSQLユーザアカウント">18.1</a>を参照してください。）
鍵ファイルの保存場所は<a class="xref" href="runtime-config-connection.html#GUC-KRB-SERVER-KEYFILE">krb_server_keyfile</a>設定パラメータで指定されます
デフォルトは、<code class="filename">/usr/local/pgsql/etc/krb5.keytab</code>（もしくはビルド時に<code class="varname">sysconfdir</code>で指定されたディレクトリ）です。
セキュリティ上の理由から、システムkeytabファイルで許可するよりも、<span class="productname">PostgreSQL</span>サーバ用に別のkeytabファイルを使うことをお薦めします。
</p><p><span class="original">
The keytab file is generated by the Kerberos software; see the
Kerberos documentation for details. The following example is
for MIT-compatible Kerberos 5 implementations:
</span>keytabファイルはKerberosのソフトウェアによって作成されます。詳細はKerberosのドキュメントを参照してください。
MIT互換のKerberos5実装の例を以下に示します。
</p><pre class="screen"><code class="prompt">kadmin% </code><strong class="userinput"><code>ank -randkey postgres/server.my.domain.org</code></strong>
<code class="prompt">kadmin% </code><strong class="userinput"><code>ktadd -k krb5.keytab postgres/server.my.domain.org</code></strong></pre><p>
</p><p><span class="original">
When connecting to the database make sure you have a ticket for a
principal matching the requested database user name. For example, for
database user name <literal>fred</>, principal
<literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a user name
map, as described in <xref linkend="auth-username-maps">.
</span>データベースに接続しようとしている時要求されるデータベースユーザ名に一致するプリンシパルのチケットを所有しているか確認してください。
例えば、データベースユーザ名<code class="literal">fred</code>に対し、<code class="literal">fred@EXAMPLE.COM</code>のプリンシパルは接続できるでしょう。
<code class="literal">fred/users.example.com@EXAMPLE.COM</code>のプリンシパルも許可するためには<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>内に記述されているユーザ名マップを使用して下さい。
</p><p><span class="original">
The following configuration options are supported for <productname>GSSAPI</productname>:
</span>次の設定オプションは<span class="productname">GSSAPI</span>のためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">include_realm</code></span></dt><dd><p><span class="original">
If set to 0, the realm name from the authenticated user principal is
stripped off before being passed through the user name mapping
(<xref linkend="auth-username-maps">). This is discouraged and is
primarily available for backwards compatibility, as it is not secure
in multi-realm environments unless <literal>krb_realm</literal> is
also used. It is recommended to
leave <literal>include_realm</literal> set to the default (1) and to
provide an explicit mapping in <filename>pg_ident.conf</> to convert
principal names to <productname>PostgreSQL</> user names.
</span>0に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、ユーザ名マッピング（<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>）で渡されるシステムユーザ名から外されています。
<code class="literal">krb_realm</code>も一緒に使われていない限り、これは複数realm環境で安全ではありませんので、非推奨であり、主に後方互換性のために利用できます。
<code class="literal">include_realm</code>をデフォルト(1)にしたまま、プリンシパル名を<span class="productname">PostgreSQL</span>ユーザ名に変換するために<code class="filename">pg_ident.conf</code>で明示的なマッピングを指定することをお薦めします。
</p></dd><dt><span class="term"><code class="literal">map</code></span></dt><dd><p><span class="original">
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details. For a GSSAPI/Kerberos
principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
user name used for mapping is
<literal>username@EXAMPLE.COM</literal> (or
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
unless <literal>include_realm</literal> has been set to 0, in which case
<literal>username</literal> (or <literal>username/hostbased</literal>)
is what is seen as the system user name when mapping.
</span>システムとデータベースの間のマッピングを許可します。
詳細は<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>を参照してください。
GSSAPI/Kerberosプリンシパル<code class="literal">username@EXAMPLE.COM</code>(もしくは、あまり一般的ではありませんが<code class="literal">username/hostbased@EXAMPLE.COM</code>)に対しては、もし<code class="literal">include_realm</code>が0に設定されていない限り、マッピングに使われるユーザ名は<code class="literal">username@EXAMPLE.COM</code>(もしくは<code class="literal">username/hostbased@EXAMPLE.COM</code>)です。
0に設定されている場合には、<code class="literal">username</code>(もしくは<code class="literal">username/hostbased</code>)がマッピング時のシステムユーザ名です。
</p></dd><dt><span class="term"><code class="literal">krb_realm</code></span></dt><dd><p><span class="original">
Sets the realm to match user principal names against. If this parameter
is set, only users of that realm will be accepted. If it is not set,
users of any realm can connect, subject to whatever user name mapping
is done.
</span>realmをユーザプリンシパル名に一致するように設定します。
もしこのパラメータが設定されている場合はそのrealmのユーザのみが受け付けられます。
もしこれが設定されていない場合は、どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。
</p></dd></dl></div><p>
</p></div><div class="sect2" id="SSPI-AUTH"><div class="titlepage"><div><div><h3 class="title">20.3.4. SSPI認証</h3></div></div></div><span class="original">
<title>SSPI Authentication</title>
</span><a id="id-1.6.7.10.6.2" class="indexterm"></a><p><span class="original">
<productname>SSPI</productname> is a <productname>Windows</productname>
technology for secure authentication with single sign-on.
<productname>PostgreSQL</productname> will use SSPI in
<literal>negotiate</literal> mode, which will use
<productname>Kerberos</productname> when possible and automatically
fall back to <productname>NTLM</productname> in other cases.
<productname>SSPI</productname> authentication only works when both
server and client are running <productname>Windows</productname>,
or, on non-Windows platforms, when <productname>GSSAPI</productname>
is available.
</span><span class="productname">SSPI</span>は、シングルサインオンで安全な認証を行うための<span class="productname">Windows</span>の技術です。
<span class="productname">PostgreSQL</span>は、<code class="literal">negotiate</code>モードにおいてSSPIを使用します。
これは、可能な場合は<span class="productname">Kerberos</span>を使用し、他の場合については自動的に<span class="productname">NTLM</span>を使用することを意味しています。
<span class="productname">SSPI</span>認証は、サーバ、クライアントが共に<span class="productname">Windows</span>上もしくは<span class="productname">GSSAPI</span>が利用可能な場合はWindowsではないプラットフォームで稼動しているときにのみ動作します。
</p><p><span class="original">
When using <productname>Kerberos</productname> authentication,
<productname>SSPI</productname> works the same way
<productname>GSSAPI</productname> does; see <xref linkend="gssapi-auth">
for details.
</span><span class="productname">Kerberos</span>認証を使用しているとき、
<span class="productname">SSPI</span>は、<span class="productname">GSSAPI</span>と同じように動作します。
詳細は<a class="xref" href="auth-methods.html#GSSAPI-AUTH" title="20.3.3. GSSAPI認証">20.3.3</a>を参照してください。
</p><p><span class="original">
The following configuration options are supported for <productname>SSPI</productname>:
</span>次の設定オプションは<span class="productname">SSPI</span>のためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">include_realm</code></span></dt><dd><p><span class="original">
If set to 0, the realm name from the authenticated user principal is
stripped off before being passed through the user name mapping
(<xref linkend="auth-username-maps">). This is discouraged and is
primarily available for backwards compatibility, as it is not secure
in multi-realm environments unless <literal>krb_realm</literal> is
also used. It is recommended to
leave <literal>include_realm</literal> set to the default (1) and to
provide an explicit mapping in <filename>pg_ident.conf</> to convert
principal names to <productname>PostgreSQL</> user names.
</span>0に設定されている場合は、認証されたユーザプリンシパルからのrealm名が、ユーザ名マッピング（<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>）で渡されるシステムユーザ名から外されています。
<code class="literal">krb_realm</code>も一緒に使われていない限り、これは複数realm環境で安全ではありませんので、非推奨であり、主に後方互換性のために利用できます。
<code class="literal">include_realm</code>をデフォルト(1)にしたまま、プリンシパル名を<span class="productname">PostgreSQL</span>ユーザ名に変換するために<code class="filename">pg_ident.conf</code>で明示的なマッピングを指定することをお薦めします。
</p></dd><dt><span class="term"><code class="literal">compat_realm</code></span></dt><dd><p><span class="original">
If set to 1, the domain's SAM-compatible name (also known as the
NetBIOS name) is used for the <literal>include_realm</literal>
option. This is the default. If set to 0, the true realm name from
the Kerberos user principal name is used.
</span>1に設定されている場合は、（NetBIOS名としても知られている）ドメインのSAM互換名が<code class="literal">include_realm</code>オプションのために使用されます。
これはデフォルトの動作です。
0に設定されている場合は、ケルベロスユーザプリンシパル名からの真のrealm名が使用されます。
</p><p><span class="original">
Do not disable this option unless your server runs under a domain
account (this includes virtual service accounts on a domain member
system) and all clients authenticating through SSPI are also using
domain accounts, or authentication will fail.
</span>ドメインアカウント（これはドメインメンバーシステムの仮想サービスアカウントを含みます）にて実行されているサーバで、SSPIで認証されているすべてのクライアントがドメインアカウントを使用してる場合を除き、このオプションを無効にしないでください。
さもなくば認証は失敗します。
</p></dd><dt><span class="term"><code class="literal">upn_username</code></span></dt><dd><p><span class="original">
If this option is enabled along with <literal>compat_realm</literal>,
the user name from the Kerberos UPN is used for authentication. If
it is disabled (the default), the SAM-compatible user name is used.
By default, these two names are identical for new user accounts.
</span><code class="literal">compat_realm</code>と共にこのオプションが有効の場合、認証にはケルベロスUPNからユーザ名が使用されます。
無効（デフォルト）である場合は、SAM互換ユーザ名が使用されます。
デフォルトでは、これらの2つのユーザ名は新しいユーザアカウントでは同じものとなります。
</p><p><span class="original">
Note that <application>libpq</> uses the SAM-compatible name if no
explicit user name is specified. If you use
<application>libpq</> or a driver based on it, you should
leave this option disabled or explicitly specify user name in the
connection string.
</span>明示的なユーザ名が指定されない場合、<span class="application">libpq</span>はSAM互換名を使用することに注意してください。
<span class="application">libpq</span>もしくは<span class="application">libpq</span>を基礎としたドライバを使用する場合は、このオプションを無効のままにするか、明示的なユーザ名を接続文字列にて指定してください。
</p></dd><dt><span class="term"><code class="literal">map</code></span></dt><dd><p><span class="original">
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details. For a SSPI/Kerberos
principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
user name used for mapping is
<literal>username@EXAMPLE.COM</literal> (or
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
unless <literal>include_realm</literal> has been set to 0, in which case
<literal>username</literal> (or <literal>username/hostbased</literal>)
is what is seen as the system user name when mapping.
</span>システムとデータベースユーザ名の間のマッピングを許可します。
詳細は<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>を参照してください。
SSAPI/Kerberosプリンシパル<code class="literal">username@EXAMPLE.COM</code>(もしくは、あまり一般的ではありませんが<code class="literal">username/hostbased@EXAMPLE.COM</code>)に対しては、もし<code class="literal">include_realm</code>が0に設定されていない限り、マッピングに使われるユーザ名は<code class="literal">username@EXAMPLE.COM</code>(もしくは<code class="literal">username/hostbased@EXAMPLE.COM</code>)です。
0に設定されている場合には、<code class="literal">username</code>(もしくは<code class="literal">username/hostbased</code>)がマッピング時のシステムユーザ名です。
</p></dd><dt><span class="term"><code class="literal">krb_realm</code></span></dt><dd><p><span class="original">
Sets the realm to match user principal names against. If this parameter
is set, only users of that realm will be accepted. If it is not set,
users of any realm can connect, subject to whatever user name mapping
is done.
</span>realmをユーザプリンシパル名に一致するように設定します。もしこのパラメータが設定されている場合は
realmのユーザのみが受け付けられます。もしこれが設定されていない場合は、
どのようなrealmのユーザも接続可能で、ユーザ名マッピングが設定されていれば、どれでも影響を受けます。
</p></dd></dl></div><p>
</p></div><div class="sect2" id="AUTH-IDENT"><div class="titlepage"><div><div><h3 class="title">20.3.5. Ident認証</h3></div></div></div><span class="original">
<title>Ident Authentication</title>
</span><a id="id-1.6.7.10.7.2" class="indexterm"></a><p><span class="original">
The ident authentication method works by obtaining the client's
operating system user name from an ident server and using it as
the allowed database user name (with an optional user name mapping).
This is only supported on TCP/IP connections.
</span>ident認証方式は、クライアントのオペレーティングシステムのユーザ名をidentサーバから入手し、それを（オプションのユーザ名マップとともに）許可されているデータベースのユーザ名として使用します。
これはTCP/IP接続のみサポートされます。
</p><div class="note"><h3 class="title">注記</h3><p><span class="original">
When ident is specified for a local (non-TCP/IP) connection,
peer authentication (see <xref linkend="auth-peer">) will be
used instead.
</span>identが（TCP/IPではない）ローカル接続で指定されている場合、
ピア認証（<a class="xref" href="auth-methods.html#AUTH-PEER" title="20.3.6. Peer認証">20.3.6</a>を参照してください）が代わりに使用されます。
</p></div><p><span class="original">
The following configuration options are supported for <productname>ident</productname>:
</span>次の設定オプションは<span class="productname">ident</span>のためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">map</code></span></dt><dd><p><span class="original">
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details.
</span>システムとデータベースユーザ名の間のマッピングを許可します。
詳細は<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>を参照してください。
</p></dd></dl></div><p>
</p><p><span class="original">
The <quote>Identification Protocol</quote> is described in
RFC 1413. Virtually every Unix-like
operating system ships with an ident server that listens on TCP
port 113 by default. The basic functionality of an ident server
is to answer questions like <quote>What user initiated the
connection that goes out of your port <replaceable>X</replaceable>
and connects to my port <replaceable>Y</replaceable>?</quote>.
Since <productname>PostgreSQL</> knows both <replaceable>X</> and
<replaceable>Y</> when a physical connection is established, it
can interrogate the ident server on the host of the connecting
client and can theoretically determine the operating system user
for any given connection.
</span><span class="quote">「<span class="quote">身元特定（Identification）プロトコル</span>」</span>についてはRFC 1413で説明されています。
事実上全てのUnix系のオペレーティングシステムの配布には、デフォルトでTCPポート113を監視するidentサーバが付属しています。
identサーバの基本的な機能は<span class="quote">「<span class="quote">どのユーザがポート<em class="replaceable"><code>X</code></em>からの接続を開始し、自分のポート<em class="replaceable"><code>Y</code></em>への接続を初期化したのか？</span>」</span>というような質問に答えることです。
<span class="productname">PostgreSQL</span>は物理的な接続が確立された時に<em class="replaceable"><code>X</code></em>と<em class="replaceable"><code>Y</code></em>の両方を認識するので、接続するクライアントのホスト上のidentサーバに応答指令信号を送ることができ、理論的には与えられたどの接続にもオペレーティングシステムユーザを決定できます。
</p><p><span class="original">
The drawback of this procedure is that it depends on the integrity
of the client: if the client machine is untrusted or compromised,
an attacker could run just about any program on port 113 and
return any user name they choose. This authentication method is
therefore only appropriate for closed networks where each client
machine is under tight control and where the database and system
administrators operate in close contact. In other words, you must
trust the machine running the ident server.
Heed the warning:
</span>この手続きの欠点は、クライアントの正直さに頼るところが大きいということです。
もしクライアントマシンが信用されない、もしくは危険に晒されている場合、攻撃者はポート113上でほぼどんなプログラムでも実行することができ、どのユーザ名でも好きに選んで返すことができます。
したがってこの認証方式は、各々のクライアントマシンが厳格な管理下にあり、データベースとシステム管理者が密接に連絡を取り合って動作している、外界から閉ざされたネットワークにのみ適していると言えます。
言い換えると、identサーバが稼働しているマシンを信用しなければなりません。
次の警告に注意してください。
</p><div class="blockquote"><table border="0" class="blockquote" style="width: 100%; cellspacing: 0; cellpadding: 0;" summary="Block quote"><tr><td width="10%" valign="top"> </td><td width="80%" valign="top"><p><span class="original">
The Identification Protocol is not intended as an authorization
or access control protocol.
</span> 身元特定プロトコルは、認証、あるいはアクセス管理プロトコルには意図されていません。
</p></td><td width="10%" valign="top"> </td></tr><tr><td width="10%" valign="top"> </td><td colspan="2" align="right" valign="top">--<span class="attribution">RFC 1413</span></td></tr></table></div><p>
</p><p><span class="original">
Some ident servers have a nonstandard option that causes the returned
user name to be encrypted, using a key that only the originating
machine's administrator knows. This option <emphasis>must not</> be
used when using the ident server with <productname>PostgreSQL</>,
since <productname>PostgreSQL</> does not have any way to decrypt the
returned string to determine the actual user name.
</span>いくつかの身元特定サーバは、ユーザ名を（マシンの管理者のみが知っているキーで）暗号化して返すような非標準のオプションを持っています。
このオプションは、身元特定サーバと<span class="productname">PostgreSQL</span>とを一緒に使用する場合には、使用しては<span class="emphasis"><em>いけません</em></span>。
理由は<span class="productname">PostgreSQL</span>は、返された文字列を復号化して本当のユーザを決定するための手段を持っていないためです。
</p></div><div class="sect2" id="AUTH-PEER"><div class="titlepage"><div><div><h3 class="title">20.3.6. Peer認証</h3></div></div></div><span class="original">
<title>Peer Authentication</title>
</span><a id="id-1.6.7.10.8.2" class="indexterm"></a><p><span class="original">
The peer authentication method works by obtaining the client's
operating system user name from the kernel and using it as the
allowed database user name (with optional user name mapping). This
method is only supported on local connections.
</span>peer認証方式はカーネルからクライアント上のオペレーティングシステムのユーザ名を取得し、
それをデータベースユーザ名（オプションのユーザ名マップとともに）として使用することにより動作します。この方法はローカル接続でのみ使用可能です。
</p><p><span class="original">
The following configuration options are supported for <productname>peer</productname>:
</span>次の設定オプションは<span class="productname">peer</span>のためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">map</code></span></dt><dd><p><span class="original">
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details.
</span>システムとデータベースのユーザ名のマッピングを許可します。詳細は<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>を参照してください。
</p></dd></dl></div><p>
</p><p><span class="original">
Peer authentication is only available on operating systems providing
the <function>getpeereid()</> function, the <symbol>SO_PEERCRED</symbol>
socket parameter, or similar mechanisms. Currently that includes
<systemitem class="osname">Linux</>,
most flavors of <systemitem class="osname">BSD</> including
<systemitem class="osname">macOS</>,
and <systemitem class="osname">Solaris</systemitem>.
</span>Peer認証はオペレーティングシステムが、<code class="function">getpeereid()</code>関数、<code class="symbol">SO_PEERCRED</code>のソケットパラメータ、もしくは同じような仕組みを提供しているときにのみ使用可能です。現状では、<span class="systemitem">Linux</span>、<span class="systemitem">OS X</span>を含む<span class="systemitem">BSD</span>系、そして<span class="systemitem">Solaris</span>に含まれています。
</p></div><div class="sect2" id="AUTH-LDAP"><div class="titlepage"><div><div><h3 class="title">20.3.7. LDAP認証</h3></div></div></div><span class="original">
<title>LDAP Authentication</title>
</span><a id="id-1.6.7.10.9.2" class="indexterm"></a><p><span class="original">
This authentication method operates similarly to
<literal>password</literal> except that it uses LDAP
as the password verification method. LDAP is used only to validate
the user name/password pairs. Therefore the user must already
exist in the database before LDAP can be used for
authentication.
</span>この認証方式は<code class="literal">password</code>と似ていますが、パスワード確認にLDAPを使用する点が異なります。
LDAPはユーザの名前とパスワードの組み合わせの検証のみに使用されます。
そのため、LDAPを使用して認証を行うようにする前に、ユーザはデータベースに存在しなければなりません。
</p><p><span class="original">
LDAP authentication can operate in two modes. In the first mode,
which we will call the simple bind mode,
the server will bind to the distinguished name constructed as
<replaceable>prefix</> <replaceable>username</> <replaceable>suffix</>.
Typically, the <replaceable>prefix</> parameter is used to specify
<literal>cn=</>, or <replaceable>DOMAIN</><literal>\</> in an Active
Directory environment. <replaceable>suffix</> is used to specify the
remaining part of the DN in a non-Active Directory environment.
</span>LDAP認証は2つのモードで動作します。1つ目のモードでは、それは単なるバインド・モードを呼び出すものですが、
サーバは<em class="replaceable"><code>prefix</code></em> <em class="replaceable"><code>username</code></em> <em class="replaceable"><code>suffix</code></em>として区別された名前にバインドします。
一般的に、<em class="replaceable"><code>prefix</code></em>パラメータはActive Directory環境での<code class="literal">cn=</code>や<em class="replaceable"><code>DOMAIN</code></em><code class="literal">\</code>を特定するために使用されます。
<em class="replaceable"><code>suffix</code></em>は、Active Directory環境ではない場合でのDNの残りの部分を特定するために使用されます。
</p><p><span class="original">
In the second mode, which we will call the search+bind mode,
the server first binds to the LDAP directory with
a fixed user name and password, specified with <replaceable>ldapbinddn</>
and <replaceable>ldapbindpasswd</>, and performs a search for the user trying
to log in to the database. If no user and password is configured, an
anonymous bind will be attempted to the directory. The search will be
performed over the subtree at <replaceable>ldapbasedn</>, and will try to
do an exact match of the attribute specified in
<replaceable>ldapsearchattribute</>.
Once the user has been found in
this search, the server disconnects and re-binds to the directory as
this user, using the password specified by the client, to verify that the
login is correct. This mode is the same as that used by LDAP authentication
schemes in other software, such as Apache <literal>mod_authnz_ldap</literal> and <literal>pam_ldap</literal>.
This method allows for significantly more flexibility
in where the user objects are located in the directory, but will cause
two separate connections to the LDAP server to be made.
</span>2つ目のモードでは、それはsearch/bindモードを呼び出すもので、サーバは最初に<em class="replaceable"><code>ldapbinddn</code></em>と<em class="replaceable"><code>ldapbindpasswd</code></em>で指定された、
固定されたユーザ名とパスワードを使用してLDAPディレクトリにバインドします。
それからデータベースにログインしようとしているユーザを検索します。
もしユーザとパスワードが指定されていなかった場合は、ディレクトリに対して匿名でバインドします。
検索は<em class="replaceable"><code>ldapbasedn</code></em>のサブツリーまで行われ、<em class="replaceable"><code>ldapsearchattribute</code></em>で指定された属性に正確に一致するかどうかまで行われます。
この検索において、一度ユーザが見つかるとサーバは切断して、クライアントで指定されたパスワードを使用してこのユーザとして再度ディレクトリにバインドします。これはそのログインが正しいかどうかを検証するためです。
このモードはApache <code class="literal">mod_authnz_ldap</code>および<code class="literal">pam_ldap</code>のように他のソフトウェアと同じように、LDAP認証の仕組みで使用されるものと同じです。
この方法は、ユーザオブジェクトがディレクトリに配置されている場合に、かなりの柔軟性があります。
しかし、LDAPサーバへの2つの分離した接続が作成されます。
</p><p><span class="original">
The following configuration options are used in both modes:
</span>次の設定オプションは両方のモードで使用されます。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">ldapserver</code></span></dt><dd><p><span class="original">
Names or IP addresses of LDAP servers to connect to. Multiple
servers may be specified, separated by spaces.
</span>接続するLDAPサーバの名称もしくはIPアドレスの名称。空白で区切ることで複数のサーバを指定できます。
</p></dd><dt><span class="term"><code class="literal">ldapport</code></span></dt><dd><p><span class="original">
Port number on LDAP server to connect to. If no port is specified,
the LDAP library's default port setting will be used.
</span>LDAPサーバに接続するためのポート番号。もしポートが指定されていない場合は
LDAPライブラリ内のデフォルトポート設定が使用されます。
</p></dd><dt><span class="term"><code class="literal">ldaptls</code></span></dt><dd><p><span class="original">
Set to 1 to make the connection between PostgreSQL and the
LDAP server use TLS encryption. Note that this only encrypts
the traffic to the LDAP server &mdash; the connection to the client
will still be unencrypted unless SSL is used.
</span>1に設定すると、PostgreSQLとLDAPサーバ間の接続にTLSによる暗号化を使用します。
これはLDAPサーバへのトラフィックのみを暗号化することに注意してください。—
クライアントへの接続はSSLを使用しない限り暗号化されません。
</p></dd></dl></div><p>
<span class="original">
The following options are used in simple bind mode only:
</span>
以下のオプションは単純バインド・モードのみで使用されます。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">ldapprefix</code></span></dt><dd><p><span class="original">
String to prepend to the user name when forming the DN to bind as,
when doing simple bind authentication.
</span>単純なバインド認証を行う場合のDNを生成する際にユーザ名の前に追加する文字列
</p></dd><dt><span class="term"><code class="literal">ldapsuffix</code></span></dt><dd><p><span class="original">
String to append to the user name when forming the DN to bind as,
when doing simple bind authentication.
</span>単純なバインド認証を行う場合のDNを生成する際にユーザ名の後に追加する文字列
</p></dd></dl></div><p>
<span class="original">
The following options are used in search+bind mode only:
</span>
以下のオプションはsearch/bindモードのみで使用されます。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">ldapbasedn</code></span></dt><dd><p><span class="original">
Root DN to begin the search for the user in, when doing search+bind
authentication.
</span>検索とバインドの認証を行う場合のユーザ名がログインするための検索を始めるためのルートDN
</p></dd><dt><span class="term"><code class="literal">ldapbinddn</code></span></dt><dd><p><span class="original">
DN of user to bind to the directory with to perform the search when
doing search+bind authentication.
</span>検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのDN
</p></dd><dt><span class="term"><code class="literal">ldapbindpasswd</code></span></dt><dd><p><span class="original">
Password for user to bind to the directory with to perform the search
when doing search+bind authentication.
</span>検索とバインドの認証を行う場合のディレクトリと検索をバインドするためのユーザのパスワード
</p></dd><dt><span class="term"><code class="literal">ldapsearchattribute</code></span></dt><dd><p><span class="original">
Attribute to match against the user name in the search when doing
search+bind authentication. If no attribute is specified, the
<literal>uid</> attribute will be used.
</span>検索とバインドの認証を行う場合の検索時のユーザ名に対して一致させる属性。
属性が指定されない場合、属性<code class="literal">uid</code>が使用されます。
</p></dd><dt><span class="term"><code class="literal">ldapurl</code></span></dt><dd><p><span class="original">
An RFC 4516 LDAP URL. This is an alternative way to write some of the
other LDAP options in a more compact and standard form. The format is
</span>RFC 4516 LDAP URL。これはその他いくつかのLDAPオプションをより簡潔、かつ一般的な形式で記述する別の方法です。
フォーマットは以下のようになっています。
</p><pre class="synopsis">ldap://<em class="replaceable"><code>host</code></em>[:<em class="replaceable"><code>port</code></em>]/<em class="replaceable"><code>basedn</code></em>[?[<em class="replaceable"><code>attribute</code></em>][?[<em class="replaceable"><code>scope</code></em>]]]</pre><p><span class="original">
<replaceable>scope</replaceable> must be one
of <literal>base</literal>, <literal>one</literal>, <literal>sub</literal>,
typically the latter. Only one attribute is used, and some other
components of standard LDAP URLs such as filters and extensions are
not supported.
</span>
<em class="replaceable"><code>scope</code></em>は<code class="literal">base</code>、<code class="literal">one</code>,、<code class="literal">sub</code>のいずれかでなくてはならず、一般的には最後のものです。
</p><p><span class="original">
For non-anonymous binds, <literal>ldapbinddn</literal>
and <literal>ldapbindpasswd</literal> must be specified as separate
options.
</span>非匿名バインド（non-anonymous bind）に対し、<code class="literal">ldapbinddn</code>および<code class="literal">ldapbindpasswd</code>は個別のオプションとして指定されなければなりません。
</p><p><span class="original">
To use encrypted LDAP connections, the <literal>ldaptls</literal>
option has to be used in addition to <literal>ldapurl</literal>.
The <literal>ldaps</literal> URL scheme (direct SSL connection) is not
supported.
</span>暗号化されたLDAP接続を使用するには、<code class="literal">ldapurl</code>に加え<code class="literal">ldaptls</code>オプションを使用しなければなりません。<code class="literal">ldaps</code> URLの仕組み（直接SSL接続）はサポートされていません。
</p><p><span class="original">
LDAP URLs are currently only supported with OpenLDAP, not on Windows.
</span>現在の所、LDAP URLはWindows上ではなく、OpenLDAPのみでサポートされています。
</p></dd></dl></div><p>
</p><p><span class="original">
It is an error to mix configuration options for simple bind with options
for search+bind.
</span>seartch/bindオプションと単純バインドに対するオプションの設定を混在させるのはエラーです。
</p><p><span class="original">
Here is an example for a simple-bind LDAP configuration:
</span>以下に単純バインドLDAP設定の例を示します。
</p><pre class="programlisting">host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"</pre><p><span class="original">
When a connection to the database server as database
user <literal>someuser</literal> is requested, PostgreSQL will attempt to
bind to the LDAP server using the DN <literal>cn=someuser, dc=example,
dc=net</literal> and the password provided by the client. If that connection
succeeds, the database access is granted.
</span>
データベースのユーザ、<code class="literal">someuser</code>からデータベースサーバに接続を要求された場合、PostgreSQLはDN <code class="literal">cn=someuser, dc=example, dc=net</code>およびクライアントから提供されたパスワードを用いてLDAPサーバにバインドを試みます。
その接続が成功すればデータベースへのアクセスが認められます。
</p><p><span class="original">
Here is an example for a search+bind configuration:
</span>以下はsearch/bind設定の例です。
</p><pre class="programlisting">host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid</pre><p><span class="original">
When a connection to the database server as database
user <literal>someuser</literal> is requested, PostgreSQL will attempt to
bind anonymously (since <literal>ldapbinddn</literal> was not specified) to
the LDAP server, perform a search for <literal>(uid=someuser)</literal>
under the specified base DN. If an entry is found, it will then attempt to
bind using that found information and the password supplied by the client.
If that second connection succeeds, the database access is granted.
</span>
データベースユーザ<code class="literal">someuser</code>としてデータベースに接続するとき、PostgreSQLは（<code class="literal">ldapbinddn</code>が指定されていないので）匿名的にバインドを試み、指定されたベースDNの基で<code class="literal">(uid=someuser)</code>の検索を行います。あるエントリが見つかると、見つかった情報とクライアントから与えられたパスワードを用いて、その結果バインドを試みます。その二番目の接続が成功するとデータベースアクセスが認められます。
</p><p><span class="original">
Here is the same search+bind configuration written as a URL:
</span>URLとして記述した同じsearch/bind設定の例です。
</p><pre class="programlisting">host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"</pre><p><span class="original">
Some other software that supports authentication against LDAP uses the
same URL format, so it will be easier to share the configuration.
</span>
LDAPに対し認証をサポートする幾つかの他のソフトウェアは同じURLフォーマットを使用します。
従って、設定をより簡易に共有することができます。
</p><div class="tip"><h3 class="title">ヒント</h3><p><span class="original">
Since LDAP often uses commas and spaces to separate the different
parts of a DN, it is often necessary to use double-quoted parameter
values when configuring LDAP options, as shown in the examples.
</span>LDAPはDNの異なる構成要素を区別するため往々にしてコンマとスペースを使用します。
例で示されたように、LDAPオプションを設定する場合、二重引用符で括られたパラメータ値を使用することが必須となることがしばしば必須となります。
</p></div></div><div class="sect2" id="AUTH-RADIUS"><div class="titlepage"><div><div><h3 class="title">20.3.8. RADIUS認証</h3></div></div></div><span class="original">
<title>RADIUS Authentication</title>
</span><a id="id-1.6.7.10.10.2" class="indexterm"></a><p><span class="original">
This authentication method operates similarly to
<literal>password</literal> except that it uses RADIUS
as the password verification method. RADIUS is used only to validate
the user name/password pairs. Therefore the user must already
exist in the database before RADIUS can be used for
authentication.
</span>この認証方法は、RADIUSをパスワード検証として使用するという点を除いて<code class="literal">password</code>と似た動作をします。
RADIUSはユーザ名/パスワードの組のみを検証するために使用されます。
よってユーザはRADIUSが認証に使用される以前にデータベースにすでに存在していなければいけません。
</p><p><span class="original">
When using RADIUS authentication, an Access Request message will be sent
to the configured RADIUS server. This request will be of type
<literal>Authenticate Only</literal>, and include parameters for
<literal>user name</>, <literal>password</> (encrypted) and
<literal>NAS Identifier</>. The request will be encrypted using
a secret shared with the server. The RADIUS server will respond to
this server with either <literal>Access Accept</> or
<literal>Access Reject</>. There is no support for RADIUS accounting.
</span>RADIUS認証を使用する場合に、設定されたRADIUSサーバにアクセスリクエストメッセージが送信されます。
このリクエストは<code class="literal">Authenticate Only</code>の形式になり、<code class="literal">ユーザ名</code>, （暗号化された）<code class="literal">パスワード</code>、<code class="literal">NAS識別子</code>を含んでいます。
リクエストはサーバと共有している秘密を用いて暗号化されます。
RADIUSサーバは、このサーバに対して<code class="literal">Access Accept</code>もしくは<code class="literal">Access Reject</code>を返します。
RADIUSアカウントのサポートはありません。
</p><p><span class="original">
Multiple RADIUS servers can be specified, in which case they will
be tried sequentially. If a negative response is received from
a server, the authentication will fail. If no response is received,
the next server in the list will be tried. To specify multiple
servers, put the names within quotes and separate the server names
with a comma. If multiple servers are specified, all other RADIUS
options can also be given as a comma separate list, to apply
individual values to each server. They can also be specified as
a single value, in which case this value will apply to all servers.
</span>複数のRADIUSサーバを指定することができ、その場合には各々が順に試行されます。
サーバから負の応答があると、認証は失敗します。
サーバから応答がない場合は、リスト内の次のサーバが試されます。
複数のサーバを指定するには、サーバ名を引用符の中に入れ、各々をカンマで区切ってください。
複数のサーバが指定されると、他のすべてのRADIUSオプションもカンマで区切って指定することが可能で、それぞれ各々のサーバに対して適用されます。
オプションは単一の値としても指定でき、その場合にはこの値がすべてのサーバに対して適用されます。
</p><p><span class="original">
The following configuration options are supported for RADIUS:
</span>RADIUSのために次の設定オプションがサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">radiusservers</code></span></dt><dd><p><span class="original">
The name or IP addresses of the RADIUS servers to connect to.
This parameter is required.
</span>接続するRADIUSサーバの名称もしくはIPアドレス。
このパラメータは必須です。
</p></dd><dt><span class="term"><code class="literal">radiussecrets</code></span></dt><dd><p><span class="original">
The shared secrets used when talking securely to the RADIUS
server. This must have exactly the same value on the PostgreSQL
and RADIUS servers. It is recommended that this be a string of
at least 16 characters. This parameter is required.
</span>RADIUSサーバと安全なやり取りに使用される共有の秘密データ。
これはPostgreSQLとRADIUSサーバにおいて厳密に同じ値にする必要があります。
少なくとも16文字以上の文字列が推奨されます。
このパラメータは必須です。
</p><div class="note"><h3 class="title">注記</h3><p><span class="original">
The encryption vector used will only be cryptographically
strong if <productname>PostgreSQL</> is built with support for
<productname>OpenSSL</>. In other cases, the transmission to the
RADIUS server should only be considered obfuscated, not secured, and
external security measures should be applied if necessary.
</span>使用されている暗号化ベクターは<span class="productname">PostgreSQL</span>が<span class="productname">OpenSSL</span>をサポートするよう構築している場合にのみ暗号論的に強力です。
他の場合にはRADIUSサーバへの伝送は難読化されているだけで安全ではなく、必要ならば外部のセキュリティ方法を適用すべきです。
</p></div><p>
</p></dd><dt><span class="term"><code class="literal">radiusports</code></span></dt><dd><p><span class="original">
The port number on the RADIUS servers to connect to. If no port
is specified, the default port <literal>1812</> will be used.
</span>接続するRADIUSサーバのポート番号。
もしポート番号が指定されていない場合は、デフォルトポートである<code class="literal">1812</code>が使用されます。
</p></dd><dt><span class="term"><code class="literal">radiusidentifiers</code></span></dt><dd><p><span class="original">
The string used as <literal>NAS Identifier</> in the RADIUS
requests. This parameter can be used as a second parameter
identifying for example which database user the user is attempting
to authenticate as, which can be used for policy matching on
the RADIUS server. If no identifier is specified, the default
<literal>postgresql</> will be used.
</span>RADIUSリクエスト内で<code class="literal">NAS Identifier</code>として使用されている文字列。
ユーザがどのデータベースユーザに対して認証しようとしているか、RADIUSサーバにおいてポリシーを一致させるために何が使用されるか、
を識別するために、このパラメータは2番目のパラメータとして使用されます。
もし識別子が指定されていない場合は、デフォルトの<code class="literal">postgresql</code>が使用されます。
</p></dd></dl></div><p>
</p></div><div class="sect2" id="AUTH-CERT"><div class="titlepage"><div><div><h3 class="title">20.3.9. 証明書認証</h3></div></div></div><span class="original">
<title>Certificate Authentication</title>
</span><a id="id-1.6.7.10.11.2" class="indexterm"></a><p><span class="original">
This authentication method uses SSL client certificates to perform
authentication. It is therefore only available for SSL connections.
When using this authentication method, the server will require that
the client provide a valid, trusted certificate. No password prompt
will be sent to the client. The <literal>cn</literal> (Common Name)
attribute of the certificate
will be compared to the requested database user name, and if they match
the login will be allowed. User name mapping can be used to allow
<literal>cn</literal> to be different from the database user name.
</span>この認証方法は、認証のためにSSLクライアント証明書を使用します。
よってこの方法は、SSL接続を使用します。
この認証方法を使用する際は、サーバはクライアントが有効かつ信頼された証明書を提供することを要求します。
パスワードのプロンプトはクライアントに送信されません。
証明書の<code class="literal">cn</code>（Common Name）属性は、要求されたデータベースユーザ名と比較されます。
もしそれらが一致した場合はログインが許可されます。
ユーザ名マッピングは、<code class="literal">cn</code>がデータベースユーザ名と異なるものであることを許可するために使用されます。
</p><p><span class="original">
The following configuration options are supported for SSL certificate
authentication:
</span>次の設定オプションはSSL証明書認証のためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">map</code></span></dt><dd><p><span class="original">
Allows for mapping between system and database user names. See
<xref linkend="auth-username-maps"> for details.
</span>システムとデータベースユーザ名の間のマッピングを許可します。
詳細は<a class="xref" href="auth-username-maps.html" title="20.2. ユーザ名マップ">20.2</a>を参照してください。
</p></dd></dl></div><p>
</p><p><span class="original">
In a <filename>pg_hba.conf</> record specifying certificate
authentication, the authentication option <literal>clientcert</> is
assumed to be <literal>1</>, and it cannot be turned off since a client
certificate is necessary for this method. What the <literal>cert</>
method adds to the basic <literal>clientcert</> certificate validity test
is a check that the <literal>cn</literal> attribute matches the database
user name.
</span>証明書認証を指定する<code class="filename">pg_hba.conf</code>のレコードにおいて、認証オプションである<code class="literal">clientcert</code>は<code class="literal">1</code>であるとみなされ、クライアント証明書がこの方式のために必要であるゆえに無効にできません。
<code class="literal">cert</code>方式が基本的な<code class="literal">clientcert</code>証明書の妥当性確認に追加するのは、<code class="literal">cn</code>属性がデータベースユーザ名と合致することの確認となります。
</p></div><div class="sect2" id="AUTH-PAM"><div class="titlepage"><div><div><h3 class="title">20.3.10. PAM認証</h3></div></div></div><span class="original">
<title>PAM Authentication</title>
</span><a id="id-1.6.7.10.12.2" class="indexterm"></a><p><span class="original">
This authentication method operates similarly to
<literal>password</literal> except that it uses PAM (Pluggable
Authentication Modules) as the authentication mechanism. The
default PAM service name is <literal>postgresql</literal>.
PAM is used only to validate user name/password pairs and optionally the
connected remote host name or IP address. Therefore the user must already
exist in the database before PAM can be used for authentication. For more
information about PAM, please read the
<ulink url="http://www.kernel.org/pub/linux/libs/pam/">
<productname>Linux-PAM</> Page</ulink>.
</span>この認証方式は認証機構としてPAM（Pluggable Authentication Modules）を使用することを除いて<code class="literal">password</code>のように動作します。
デフォルトのPAMサービス名は<code class="literal">postgresql</code>です。
PAMはユーザ名/パスワードの組の確認と接続されたリモートホスト名またはIPアドレスを任意に確認するためだけに使用されます。
PAMについての詳細は<a class="ulink" href="http://www.kernel.org/pub/linux/libs/pam/" target="_top"><span class="productname">Linux-PAM</span>ページ</a>を読んでください。
</p><p><span class="original">
The following configuration options are supported for PAM:
</span>次の設定オプションはPAMのためにサポートされています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">pamservice</code></span></dt><dd><p><span class="original">
PAM service name.
</span>PAMサービス名。
</p></dd><dt><span class="term"><code class="literal">pam_use_hostname</code></span></dt><dd><p><span class="original">
Determines whether the remote IP address or the host name is provided
to PAM modules through the <symbol>PAM_RHOST</symbol> item. By
default, the IP address is used. Set this option to 1 to use the
resolved host name instead. Host name resolution can lead to login
delays. (Most PAM configurations don't use this information, so it is
only necessary to consider this setting if a PAM configuration was
specifically created to make use of it.)
</span><code class="symbol">PAM_RHOST</code>アイテムを通じてPAMモジュールに提供されるものがリモートのIPアドレスかホスト名かを決定します。
デフォルトではIPアドレスが使用されます。
ホスト名にて使用するためにはこのオプションを1にセットしてください。
ホスト名の解決はログインの遅延をもたらします。（ほとんどのPAM設定はこの情報を利用せず、PAM設定がホスト名を使用するために明確に作成された場合のみ、この設定値を考慮する必要があります。）
</p></dd></dl></div><p>
</p><div class="note"><h3 class="title">注記</h3><p><span class="original">
If PAM is set up to read <filename>/etc/shadow</>, authentication
will fail because the PostgreSQL server is started by a non-root
user. However, this is not an issue when PAM is configured to use
LDAP or other authentication methods.
</span>PAMが<code class="filename">/etc/shadow</code>を読み取るように設定されている場合は、PostgreSQLがルートユーザで起動されていないため、認証は失敗するでしょう。
しかしPAMがLDAPや他の認証方法を使用するように設定されている場合は、これは問題ではありません。
</p></div></div><div class="sect2" id="AUTH-BSD"><div class="titlepage"><div><div><h3 class="title">20.3.11. BSD認証</h3></div></div></div><span class="original">
<title>BSD Authentication</title>
</span><a id="id-1.6.7.10.13.2" class="indexterm"></a><p><span class="original">
This authentication method operates similarly to
<literal>password</literal> except that it uses BSD Authentication
to verify the password. BSD Authentication is used only
to validate user name/password pairs. Therefore the user's role must
already exist in the database before BSD Authentication can be used
for authentication. The BSD Authentication framework is currently
only available on OpenBSD.
</span>この認証方式は、パスワードを照合するためにBSD認証を使用すること以外は<code class="literal">password</code>と同じように動作します。
BSD認証は、ユーザ名/パスワードの組の確認のみに使用されます。
それゆえ、ユーザのロールはBSD認証が認証に使用可能となる前にデータベースに存在していなければいけません。
BSD認証フレームワークは現在OpenBSDでのみ利用可能です。
</p><p><span class="original">
BSD Authentication in <productname>PostgreSQL</> uses
the <literal>auth-postgresql</literal> login type and authenticates with
the <literal>postgresql</literal> login class if that's defined
in <filename>login.conf</filename>. By default that login class does not
exist, and <productname>PostgreSQL</> will use the default login class.
</span><span class="productname">PostgreSQL</span>でのBSD認証は、<code class="literal">auth-postgresql</code>ログイン型を使用し、<code class="literal">postgresql</code>ログインクラスが<code class="filename">login.conf</code>にて定義されている場合はそれを使った認証を使用します。
デフォルトでは、そのログインクラスは存在せず、<span class="productname">PostgreSQL</span>はデフォルトログインクラスを使用します。
</p><div class="note"><h3 class="title">注記</h3><p><span class="original">
To use BSD Authentication, the PostgreSQL user account (that is, the
operating system user running the server) must first be added to
the <literal>auth</literal> group. The <literal>auth</literal> group
exists by default on OpenBSD systems.
</span>BSD認証を使用するために、PostgreSQLユーザアカウント（サーバを起動しているオペレーティングシステムユーザ）が、まずは<code class="literal">auth</code>グループに追加されていなければいけません。
<code class="literal">auth</code>グループはOpenBSDシステムではデフォルトで存在しています。
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="auth-username-maps.html">前へ</a> </td><td width="20%" align="center"><a accesskey="u" href="client-authentication.html">上へ</a></td><td width="40%" align="right"> <a accesskey="n" href="client-authentication-problems.html">次へ</a></td></tr><tr><td width="40%" align="left" valign="top">20.2. ユーザ名マップ </td><td width="20%" align="center"><a accesskey="h" href="index.html">ホーム</a></td><td width="40%" align="right" valign="top"> 20.4. 認証における問題点</td></tr></table></div></body></html>