| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 でのネームサービスおよびディレクトリサービスの作業 Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 でのネームサービスおよびディレクトリサービスの作業 Oracle Solaris 11.1 Information Library (日本語) |
4. Oracle Solaris Active Directory クライアントの設定 (タスク)
11. LDAP クライアントと Oracle Directory Server Enterprise Edition の設定 (タスク)
LDAP ネームサービスは、LDAP リポジトリを 2 つの異なる方法で使用できます。1 つは、ネームサービスと認証サービスの両方のソースとして使用する方法です。もう 1 つは、厳密にネームデータのソースとして使用する方法です。このセクションでは、クライアント識別情報の概念、認証方法、pam_ldap モジュールと pam_unix_* モジュール、および LDAP リポジトリがネームサービスと認証サービスの両方として使用される場合のアカウント管理について説明します。このセクションではまた、LDAP ネームサービスを Kerberos 環境 (『Oracle Solaris 11.1 の管理: セキュリティーサービス』のパート VI「Kerberos サービス」) および pam_krb5(5) モジュールと組み合わせて使用する方法についても説明します。
注 - 以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、ssh などのツールを使用した、パスワードに基づかないログインは失敗します。
アカウント管理を実行し、ユーザーがログインしているときに Directory Server への認証を行わずにユーザーのアカウントステータスを取得します。Directory Server 上の新しい制御は 1.3.6.1.4.1.42.2.27.9.5.8 です。これはデフォルトで有効になっています。
この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable";
allow (read, search, compare, proxy)
(groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
注 - Kerberos を認証システムとして使用し、LDAP ネームシステムに統合する場合は、Kerberos を利用して企業内でシングルサインオン (SSO) 環境を実現できます。また、ユーザーまたはホストごとに LDAP ネームデータのクエリー検索を実行する際にも、同じ識別システムを使用できます。
LDAP リポジトリ内の情報にアクセスするには、クライアントはまず、ディレクトリサーバーに識別情報を確立できます。この識別情報は匿名にすることも、LDAP サーバーによって認識されたホストまたはユーザーとして指定することもできます。クライアントの識別情報とサーバーのアクセス制御情報 (ACI) に基づいて、LDAP サーバーは、クライアントによるディレクトリ情報の読み取りを許可します。ACI の詳細については、使用しているバージョンの Oracle Directory Server Enterprise Edition の『管理者ガイド』を参照してください。
識別情報がリクエストの送信元のホストに基づいている場合は、プロキシ認証を使用しています。ホストが認証されると、そのホスト上のすべてのユーザーがアクセスを取得します。識別情報がユーザーに基づいている場合は、ユーザー別の認証を使用しています。アクセスを取得するには、ホスト上の各ユーザーが認証される必要があります。
特定の要求に関して匿名以外で接続している場合、クライアントは、クライアントとサーバーの両方がサポートする認証方式でサーバーに識別情報を証明する必要があります。クライアントは識別情報を確立後に、さまざまな LDAP 要求を実行できます。
システムにログインすると、PAM サービスはログインの試行を成功させるかどうかを決定するために、ローカルマシンからの情報、LDAP サービスからの情報、Kerberos サーバーからの情報、またはこれらの 3 つのいずれかの組み合わせを使用できます。pam_kerb モジュールが使用されている場合、アクセスを許可する決定は Kerberos サーバーによって行われます。pam_ldap モジュールが使用されている場合、この決定の半分は LDAP サーバーから来る必要があり、残りの半分はローカルホストから来ます。ローカルホストからの情報の場合、pam_unix_* モジュールを使用して、決定はローカルに行われます。
LDAP サービスを使用して pam_ldap でログインする場合、ネームサービスと認証サービス (pam_ldap) がディレクトリにアクセスする方法には違いがあります。ネームサービスは、事前定義された識別情報に基づくディレクトリから、さまざまなエントリおよびその属性を読み取ります。認証サービスは、ユーザーの名前とパスワードを使用して LDAP サーバーへの認証を行い、ユーザーが適正なパスワードを入力したかどうかを確認します。認証サービスについての詳細は、pam_ldap(5) のマニュアルページを参照してください。
Kerberos を認証に使用する場合、および LDAP ネームサービス内の認証も有効にする場合 (ユーザー別の認証方式で必要)、Kerberos は二重の機能を提供できます。ディレクトリへの認証に、サーバーへの Kerberos 認証、および主体 (ユーザーまたはホスト) に対する Kerberos 識別情報が使用されます。これにより、システムの認証に使用されるのと同じユーザー識別情報がディレクトリの認証にも使用され、検索と更新が実行されます。管理者は、必要に応じ、アクセス制御情報 (ACI) をディレクトリ内で使用して、ネームサービスで得られる結果を制限できます。
TLS (Transport Layer Security) プロトコルを使用すると、LDAP クライアントとディレクトリサーバーの間の通信をセキュリティー保護して、プライバシとデータの完全性の両方を提供することができます。TLS プロトコルは、Secure Sockets Layer (SSL) プロトコルのスーパーセットです。LDAP ネームサービスは、TLS 接続をサポートしています。SSL を使用すると、ディレクトリサーバーおよびクライアントに負荷がかかることに留意してください。
SSL 対応のディレクトリサーバーを設定する必要があります。SSL 対応の Oracle Directory Server Enterprise Edition の設定方法の詳細については、使用しているバージョンの Oracle Directory Server Enterprise Edition の『管理者ガイド』を参照してください。SSL 対応の LDAP クライアントも設定する必要があります。
TLS を使用する場合は、必要なセキュリティーデータベースをインストールしなければなりません。具体的には証明書ファイルと鍵データベースファイルが必要です。たとえば、Netscape Communicator のより古いデータベースフォーマットを採用する場合は、cert7.db と key3.db の 2 つのファイルが必要です。または、Mozilla の新しいデータベースフォーマットを使用する場合は、cert8.db、key3.db、secmod.db の 3 つのファイルが必要です。cert7.db または cert8.db ファイルには、信頼できる証明書が含まれています。key3.db ファイルには、クライアントの鍵が含まれています。LDAP ネームサービスクライアントがクライアントの鍵を使用しない場合でも、このファイルは必要です。secmod.db ファイルには、PKCS#11 などのセキュリティーモジュールが入ります。このファイルは、古いフォーマットを使用する場合には必要ありません。
詳細については、「TLS のセキュリティーの設定」を参照してください。
LDAP ネームサービスクライアントは、クライアントの資格レベルに従って LDAP サーバーへの認証を行います。LDAP クライアントには、ディレクトリサーバーへの認証を行うための複数のレベルを割り当てることができます。
匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。匿名モードでは、LDAP BIND 操作は実行されません。また、セキュリティーの問題も考慮する必要があります。ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するすべてのユーザーが読み取りアクセスを保持することになります。資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。
 | 注意 - ディレクトリへの anonymous 書き込みを決して許可してはいけません。すべてのユーザーが、書き込みアクセス権を持っている DIT 内の情報 (別のユーザーのパスワードやそれらのユーザー独自の識別情報を含む) を変更できてしまうためです。 |
注 - Oracle Directory Server Enterprise Edition を使用すると、IP アドレス、DNS 名、認証方式、および時間に基づいてアクセスを制限できます。さらに指定を加えて、アクセスを制限することもできます。詳細については、使用しているバージョンの Oracle Directory Server Enterprise Edition の『管理者ガイド』のアクセス権の管理に関する章を参照してください。
クライアントは、LDAP バインド資格の単一の共有セット (プロキシアカウントとも呼ばれます) への認証またはバインドを行います。このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。プロキシアカウントは、システムごとに共有されるリソースです。つまり、root ユーザーを含む、プロキシアクセスを使ってシステムにログインした各ユーザーには、そのシステム内のほかのすべてのユーザーと同じ結果が表示されます。proxy 資格レベルを使用して、すべてのクライアント上で proxyDN と proxyPassword を構成する必要があります。暗号化された proxyPassword はローカルのクライアントに格納されます。別のクライアントグループに対しては別のプロキシを設定できます。たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。もっとも極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。一般的な LDAP 配備はこの両極端の中間に位置します。選択は慎重に行なってください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって異なります。どの認証方法が構成にもっとも適しているかを判定する方法については、「LDAP クライアントの資格ストレージ」を参照してください。
プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。
注 - プロキシ資格レベルは、指定されたシステムのすべてのユーザーおよびプロセスに適用されます。2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用するか、ユーザー別の認証モデルを使用する必要があります。
さらに、クライアントが proxy 資格を使用して認証を行う場合は、すべてのサーバー上で proxyDN の proxyPassword が同じである必要があります。
proxy anonymous は、複数の資格レベルが定義されているという点で複数値のエントリです。匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。
ユーザー別 (self) の認証では、ディレクトリサーバーの認証時に Kerberos 識別情報 (主体) を使用して各ユーザーまたは各システムの検索が実行されます。ユーザー別の認証では、システム管理者は、アクセス制御情報 (ACI)、アクセス制御リスト (ACL)、役割、グループ、またはその他のディレクトリアクセス制御メカニズムを使用して、特定のユーザーまたはシステムの特定のネームサービスデータへのアクセスを許可または拒否できます。
注 - ユーザー別のモードを構成する場合は、このモードを表す構成値「self」を使用します。
ユーザー別の認証モデルを使用するには、Kerberos シングルサインオンサービスを配備する必要があります。また、配備に使用する 1 つ以上のディレクトリサーバーで SASL および SASL/GSSAPI 認証メカニズムをサポートする必要があります。Kerberos では、ホスト名の検索に LDAP ではなく、ファイルおよび DNS を使用することを前提としているため、この環境には DNS を配備するようにしてください。また、ユーザー別の認証を使用するには、nscd を有効にする必要があります。この構成では、nscd デーモンはオプションのコンポーネントではありません。
クライアント上で enableShadowUpdate スイッチが true に設定されている場合は、シャドウデータを更新するために管理者資格が使用されます。シャドウデータは、ディレクトリサーバー上の shadowAccount オブジェクトクラス内に格納されます。管理者資格は、「ローカルの LDAP クライアント属性」で説明されている adminDN および adminPassword 属性の値によって定義されます。これらの管理者資格は、それ以外の目的には使用されません。
管理者資格のプロパティーは Proxy 資格のプロパティと類似しています。管理者資格の場合、シャドウデータを読み取ったり更新するには、ユーザーはゾーンのすべての特権を持つか、root の有効な UID を持っている必要があるという例外があります。管理者資格は、ディレクトリへのバインドが許可されるエントリに割り当てることができます。ただし、LDAP サーバーの同じディレクトリマネージャー識別情報 (cn=Directory Manager) を使用しないでください。
管理者資格が設定されたこのエントリは、ディレクトリ内のシャドウデータに対する十分な読み取りおよび書き込みアクセスを持っている必要があります。このエントリはシステムごとに共有されるリソースであるため、すべてのクライアント上で adminDN および adminPassword 属性を構成する必要があります。暗号化された adminPassword はローカルのクライアントに格納されます。パスワードには、クライアント用に構成された認証方式と同じ方式が使用されます。管理者資格は、シャドウデータの読み取りと更新を行うために、特定のシステムのすべてのユーザーおよびプロセスによって使用されます。
プロキシ識別情報を使用するようにクライアントを構成した場合、そのクライアントは、プロキシ情報を svc:/network/ldap/client サービス内に保存します。現在の LDAP 実装では、プロキシ資格がクライアントのプロファイル内に格納されません。初期化中に ldapclient を使用して設定されたプロキシ資格はすべて、SMF リポジトリ内に格納されます。このため、プロキシの DN およびパスワード情報に関するセキュリティーが向上します。クライアントプロファイルの設定方法の詳細については、第 12 章LDAP クライアントの設定 (タスク)を参照してください。
同様に、シャドウデータの更新を有効にするようにクライアントを構成し、クライアントの資格レベルが self でない場合、そのクライアントは自身の情報を svc:/network/ldap/client サービス内に保存します。
ユーザー別の認証を使用するようクライアントを構成している場合、認証時に各主体 (各ユーザーまたはホスト) 用の Kerberos 識別情報および Kerberos チケット情報が使用されます。この環境では、ディレクトリサーバーは Kerberos 主体を DN にマッピングします。この DN の認証には、Kerberos 資格が使用されます。次に、ディレクトリサーバーは、必要に応じアクセス制御情報 (ACI) メカニズムを使用して、ネームサービスデータへのアクセスを許可または拒否します。この状況では、ディレクトリサーバーの認証に Kerberos チケット情報が使用されます。システムが、認証 DN またはパスワードをシステムに保存することはありません。そのため、このタイプの構成の場合、クライアントが ldapclient コマンドで初期化されるときに adminDN および adminPassword 属性を指定する必要はありません。
クライアントに proxy または proxy-anonymous 資格レベルを割り当てる場合は、プロキシがディレクトリサーバーへの認証を行う方法も選択する必要があります。デフォルトの認証方式は none (匿名によるアクセス) です。認証方式には、関連するトランスポートセキュリティーオプションも含まれます。
この認証方法は、資格レベルと同様に、複数値にすることができます。たとえば、クライアントプロファイルを設定することにより、クライアントが TLS でセキュリティー保護された simple メソッドを最初に使用してバインドを試みるようにできます。これが成功しない場合、クライアントは sasl/digest-MD5 メソッドを使用してバインドを試みます。それにより、authenticationMethod は tls:simple;sasl/digest-MD5 になります。
LDAP ネームサービスは、いくつかの Simple Authentication and Security Layer (SASL) メカニズムをサポートします。これらのメカニズムを使用すると、TLS なしでセキュリティー保護されたパスワードを交換できます。ただし、これらのメカニズムはデータの完全性や機密性を保証するものではありません。SASL の詳細については、RFC 2222 を参照してください。
次の認証メカニズムがサポートされています。
クライアントは、ディレクトリへの認証を行いません。これは、anonymous 資格レベルと等価です。
認証方式 simple を使用する場合、クライアントシステムはユーザーのパスワードを平文で送信してサーバーへのバインドを実行します。このため、セッションが IPsec により保護されていない限り、パスワードが漏洩しやすくなります。simple 認証方法を使用する主な利点は、すべてのディレクトリサーバーでサポートされていることと、設定が容易なことです。
認証時にクライアントのパスワードは保護されますが、セッションは暗号化されません。Oracle Directory Server Enterprise Edition を含む一部のディレクトリサーバーも sasl/digest-MD5 認証方法をサポートしています。digest-MD5 の主な利点は、認証中にパスワードが平文で転送されないことと、そのために simple 認証方法よりセキュアなことです。digest-MD5 については、RFC 2831 を参照してください。digest-MD5 は、セキュリティーが強化されるため、cram-MD5 に対する機能強化と見なされています。
sasl/digest-MD5 を使用する場合、認証はセキュリティー保護されますがセッションは保護されません。
注 - Oracle Directory Server Enterprise Edition を使用している場合、パスワードをディレクトリ内に「平文」で格納する必要があります。
sasl/cram-MD5
この場合、LDAP セッションは暗号化されませんが、sasl/cram-MD5 を使用して認証が実行されるため、認証中にクライアントのパスワードが保護されます。この認証方法は廃止されているため、使用しないでください。
sasl/GSSAPI
この認証方式は、ユーザー別の検索を有効にする場合に、self 資格モードとともに使用されます。クライアントの資格を使用するために割り当てられたユーザー別の nscd は、sasl/GSSAPI 方式およびクライアントの Kerberos 資格を使用して、ディレクトリサーバーへのバインドを実行します。ディレクトリサーバーでは、アクセスをユーザー別に制御できます。
クライアントは、simple を使用してバインドを行い、セッションは暗号化されます。パスワードは保護されます。
tls:sasl/cram-MD5
sasl/cram-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
tls:sasl/digest-MD5
sasl/digest-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
| 注意 - Oracle Directory Server Enterprise Edition で digest-MD5 を使用する場合、パスワードを平文で格納する必要があります。認証方法が sasl/digest-MD5 または tls:sasl/digest-MD5 に設定されている場合は、プロキシユーザーのパスワードを平文で格納する必要があります。userPassword 属性を平文で格納する場合は、適切な ACI を設定することによって、この属性が読み取り不可になるように特に注意してください。 |
次の表に、さまざまな認証方式およびその特性の概要を示します。
表 9-4 認証方法
|
特定のサービスの認証方法は、serviceAuthenticationMethod 属性で指定できます。次のサービスでは、認証方法を選択できます。
このサービスは、ログインパスワードとパスワード属性を変更するために、passwd(1) によって使用されます。
このサービスは、ユーザーの Diffie-Hellman 鍵ペアを作成および変更するために、chkey(1) および newkey(1M) ユーティリティーによって使用されます。
このサービスは、pam_ldap(5) でユーザーを認証するために使用されます。
pam_ldap は、アカウントの管理をサポートします。
注 - サービスで serviceAuthenticationMethod が設定されていない場合は、デフォルトで authenticationMethod 属性の値が使用されます。
注 - ユーザー別モードでは、「Kerberos サービスモジュール」 (pam Kerberos) が認証サービスとして使用されます。この動作モードでは、ServiceAuthenticationMethod は必要ありません。
注 - enableShadowUpdate スイッチが true に設定されている場合、ldap_cachemgr デーモンは、passwd-cmd の serviceAuthenticationMethod パラメータで定義されている認証方法を使用して LDAP サーバーにバインドします (この方法が定義されている場合)。このパラメータが存在しない場合、authenticationMethod が使用されます。このデーモンは、none 認証方法を使用しません。
次に示す例は、クライアントプロファイルの 1 セクションです。ここで、ユーザーはディレクトリサーバーへの認証に sasl/digest-MD5 を使用しますが、パスワードの変更には SSL セッションを使用します。
serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5 serviceAuthenticationMethod=passwd-cmd:tls:simple
PAM フレームワークを使用すると、pam_unix_*、pam_krb5、および pam_ldap_* モジュールを含む複数の認証サービスから選択できます。
ユーザー別の認証方式を使用する場合、上記の 3 つの認証サービスの中でもっとも強力な pam_krb5 を有効にする必要があります。pam_krb5(5) および『Oracle Solaris 11.1 の管理: セキュリティーサービス』を参照してください。
ユーザー別の認証が有効でない場合でも、pam_krb5 認証システムを使用できます。プロキシまたは匿名の資格レベルを使用してディレクトリサーバーのデータにアクセスする場合、ディレクトリデータへのアクセスをユーザーごとに制限することはできません。
匿名またはプロキシ認証方法が使用される場合は、pam_unix_* モジュールの使用よりも、より高い柔軟性、より強力な認証方法のサポート、およびアカウント管理を使用する機能を備えた pam_ldap モジュールの使用をお勧めします。
/etc/pam.conf ファイルを変更していない場合は、デフォルトで UNIX 認証が有効になります。
注 - pam_unix モジュールは削除されており、Oracle Solaris リリースではサポートされなくなりました。その他のサービスモジュールによって、同等またはそれ以上の機能が提供されます。したがって、このガイドでは、pam_unix は pam_unix モジュールではなくその同等の機能を指します。
次に示すのは、元の pam_unix モジュールと同等の機能を提供するモジュールの一覧です。
pam_unix_* モジュールは、次に説明されている従来の UNIX 認証モデルに従います。
クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。
ユーザーは、ユーザーパスワードの入力を求められます。
ユーザーのパスワードが暗号化されます。
クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。
さらに、pam_unix_* モジュールを使用する場合は 2 つの制限事項があります。
パスワードは、平文を含むほかの暗号化方式ではなく、UNIX crypt 形式で格納する必要があります。
userPassword 属性は、ネームサービスから読み取り可能でなければなりません。
たとえば、資格レベルを anonymous に設定した場合は、すべてのユーザーが userPassword 属性を読み取れる必要があります。同様に、資格レベルを proxy に設定した場合は、プロキシユーザーが userPassword 属性を読み取れる必要があります。
注 - Oracle Directory Server Enterprise Edition で digest-MD5 を使用するにはパスワードを平文で格納する必要があるため、UNIX 認証は sasl 認証方法の digest-MD5 と互換性がありません。UNIX 認証では、パスワードを crypt 形式で格納する必要があります。
注 - pam_unix_account モジュールは、enableShadowUpdate スイッチが true に設定されている場合はアカウント管理をサポートします。リモート LDAP ユーザーアカウントに対する制御は、passwd および shadow ファイルで定義されたローカルユーザーアカウントに適用される制御と同じように適用されます。enableShadowUpdate モードでは、LDAP アカウントについてはシステムが更新を行い、パスワードの有効期限管理とアカウントのロックのために LDAP サーバー上のシャドウデータを使用します。ローカルアカウントのシャドウデータはローカルクライアントシステムに適用されるのに対して、LDAP ユーザーアカウントのシャドウデータはすべてのクライアントシステムのユーザーに適用されます。
パスワードの履歴チェックは、ローカルクライアントに対してのみサポートされ、LDAP ユーザーアカウントに対してはサポートされません。
pam_krb5(5) のマニュアルページおよび『Oracle Solaris 11.1 の管理: セキュリティーサービス』を参照してください。
LDAP 認証を実装する場合、ユーザーは、pam_ldap の serviceAuthenticationMethod パラメータで定義されている認証方法を使用して LDAP サーバーにバインドします (このパラメータが存在する場合)。このパラメータが存在しない場合、authenticationMethod が使用されます。
pam_ldap が、ユーザーの識別情報および指定されたパスワードでサーバーにバインドできれば、ユーザーが認証されたことになります。
注 - 以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、ssh などのツールを使用した、パスワードに基づかないログインは失敗します。
アカウント管理を実行し、ユーザーがログインしているときに Directory Server への認証を行わずにユーザーのアカウントステータスを取得します。Directory Server 上の新しい制御は 1.3.6.1.4.1.42.2.27.9.5.8 です。これはデフォルトで有効になっています。
この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable";
allow (read, search, compare, proxy)
(groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
pam_ldap は、userPassword 属性を読み取りません。そのため、UNIX 認証を使用しているほかのクライアントが存在しないかぎり、userPassword 属性を読み取るためのアクセス権を付与する必要はありません。また、pam_ldap は none 認証方法もサポートしていません。そのため、クライアントが pam_ldap を使用できるように、serviceAuthenticationMethod または authenticationMethod 属性を定義する必要があります。詳細は、pam_ldap(5) のマニュアルページを参照してください。
| 注意 - 認証方式 simple を使用する場合、第三者がネットワーク上で userPassword 属性を読み取ることができます。 |
表 9-5 LDAP での認証動作
|
パスワードを変更するには、passwd コマンドを使用します。enableShadowUpdate スイッチが true に設定されていない場合、userPassword 属性がユーザーによって書き込み可能である必要があります。enableShadowUpdate スイッチが true に設定されている場合、管理者資格で userPassword 属性を更新できる必要があります。passwd-cmd の serviceAuthenticationMethod によって、この操作のための authenticationMethod がオーバーライドされることに注意してください。使用する認証方式によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。
UNIX 認証の場合は、新しい userPassword 属性が UNIX crypt 形式を使用して暗号化され、タグ付けされてから LDAP に書き込まれます。このため、新規パスワードは、サーバーへのバインドに使用される認証方式に関係なく、ネットワーク上で暗号化されます。詳細は、pam_authtok_store(5) のマニュアルページを参照してください。
enableShadowUpdate スイッチが true に設定されている場合は、ユーザーパスワードが変更されると、pam_unix_* モジュールも関連するシャドウ情報を更新します。pam_unix_* モジュールは、ローカルのユーザーパスワードが変更されたときにこれらのモジュールが更新するローカルの shadow ファイル内の同じ shadow フィールドを更新します。
pam_ldap では、パスワード更新がサポートされなくなりました。pam_ldap のパスワード更新機能は現在、server_policy オプションを指定した pam_authtok_store によって置き換えられています。pam_authtok_store を使用した場合、新しいパスワードは平文で LDAP サーバーに送信されます。このため、機密性を保つために TLS を使用する必要があります。TLS が使用されていない場合は、新しい userPassword が漏洩する危険性があります。Oracle Directory Server Enterprise Edition でタグなしパスワードを設定すると、ソフトウェアは、passwordStorageScheme 属性を使用してパスワードを暗号化します。passwordStorageScheme の詳細については、使用しているバージョンの Oracle Directory Server Enterprise Edition の『管理者ガイド』のユーザーアカウントの管理に関するセクションを参照してください。
注 - passwordStorageScheme 属性を設定する際、次の構成上の問題を考慮する必要があります。NIS や、UNIX 認証を使用している別のクライアントが LDAP をリポジトリとして使用している場合は、passwordStorageScheme を crypt にする必要があります。また、Oracle Directory Server Enterprise Edition で sasl/digest-MD5 の LDAP 認証を使用している場合は、passwordStorageScheme を平文に設定する必要があります。
アカウントおよびパスワードの管理システムとして pam_krb5 を選択すると、アカウント、パスワード、アカウントロックアウト、およびアカウント管理のその他の詳細情報がすべて Kerberos 環境により管理されます。pam_krb5(5) および『Oracle Solaris 11.1 の管理: セキュリティーサービス』を参照してください。
pam_krb5 を使用しない場合は、LDAP ネームサービスを構成して、Oracle Directory Server Enterprise Edition のパスワードおよびアカウントロックアウトポリシーのサポートを活用できます。ユーザーアカウント管理をサポートするように pam_ldap(5) を構成できます。passwd(1) を適切な PAM 構成で使用すると、Oracle Directory Server Enterprise Edition パスワードポリシーによって設定されたパスワードの構文規則が適用されます。
pam_ldap(5) によって、次のアカウント管理機能がサポートされます。これらの機能は、Oracle Directory Server Enterprise Edition のパスワードとアカウントのロックアウトポリシー構成を利用しています。必要な機能を必要な数だけ利用できます。
古くなったり、有効期限の切れたパスワードを通知する
パスワードは、予定にしたがって変更する必要があります。構成された期間内にパスワードを変更しないとそのパスワードは無効になります。期限切れのパスワードでは、ユーザーが認証されません。
期限切れの警告期間内のログイン時には、常に警告メッセージを表示します。メッセージには期限切れまでの日数と時間が表示されます。
パスワードの構文チェック
新規パスワードは、最小文字数の条件を満たしている必要があります。さらに、パスワードを、ユーザーのディレクトリエントリ内の uid、cn、sn、または mail 属性の値に一致させることはできません。
パスワードの履歴チェック
パスワードの再利用はできません。ユーザーがパスワードを以前使用されていたものに変更しようとすると、passwd(1) は失敗します。LDAP 管理者は、サーバーの履歴リストに保持するパスワードの数を構成することができます。
ユーザーアカウントのロックアウト
認証の失敗が設定された回数に達すると、そのユーザーアカウントはロックアウトされます。管理者がアカウントを非アクティブにした場合も、そのユーザーはロックアウトされます。アカウントのロックアウト期間が経過するか、管理者が再びアカウントをアクティブにするまで、認証は成功しません。
注 - 以上のアカウント管理機能は、Oracle Directory Server Enterprise Edition だけで有効です。サーバー上のパスワードとアカウントのロックアウトポリシーの構成についての詳細は、使用しているバージョンの Oracle Directory Server Enterprise Edition の『管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。「アカウント管理に pam_ldap モジュールを使用した pam_conf ファイルの例」も参照してください。proxy アカウントに対するアカウント管理を有効にしないでください。
Oracle Directory Server Enterprise Edition でパスワードとアカウントのロックアウトポリシーを構成する前に、すべてのホストで pam_ldap アカウント管理による「最新の」LDAP クライアントが使用されていることを必ず確認してください。
さらに、クライアントに、正しく構成された pam.conf(4) ファイルが存在することも確認してください。正しい構成ファイルを保持していない場合、 LDAP ネームサービスは proxy やユーザーパスワードが期限切れの時に動作しません。
注 - 以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、ssh などのツールを使用した、パスワードに基づかないログインは失敗します。
アカウント管理を実行し、ユーザーがログインしているときに Directory Server への認証を行わずにユーザーのアカウントステータスを取得します。Directory Server 上の新しい制御は 1.3.6.1.4.1.42.2.27.9.5.8 です。これはデフォルトで有効になっています。
この制御をデフォルト以外に変更する場合は、Directory Server 上でアクセス制御情報 (ACI) を追加します。
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable";
allow (read, search, compare, proxy)
(groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
クライアント上で enableShadowUpdate スイッチが true に設定されている場合は、ローカルアカウントに使用可能なアカウント管理機能が LDAP アカウントにも使用できます。この機能には、パスワードの有効期限管理、アカウントの有効期限管理および通知、ログインに失敗したアカウントのロックなどが含まれます。また、passwd コマンドの -dluNfnwx オプションが LDAP でサポートされるようになりました。これにより、ファイルネームサービスでの passwd コマンドと pam_unix_* モジュールのすべての機能が LDAP ネームサービスでサポートされます。enableShadowUpdate スイッチは、ファイルと LDAP スコープの両方で定義されているユーザーのための一貫性のあるアカウント管理を実装する方法を提供します。
ユーザーが自身のアカウント管理データを変更するのを防ぐため、また、パスワードポリシーを回避するために、LDAP サーバーは、サーバー上にあるユーザー自身のシャドウデータに対するユーザーの書き込みアクセスを防止するように構成されています。管理者資格を持つ管理者は、クライアントシステムに対してシャドウデータの更新を実行します。しかし、この構成は、ユーザーによるパスワードの変更が必要な pam_ldap モジュールと競合してしまいます。そのため、pam_ldap と pam_unix_* モジュールによるアカウント管理には互換性がありません。
| 注意 - 同じ LDAP ネームドメイン内で pam_ldap モジュールと pam_unix_* モジュールの両方を使用しないでください。すべてのクライアントが pam_ldap モジュールを使用するか、またはすべてのクライアントが pam_unix_* モジュールを使用するかのどちらかです。この制限により、専用の LDAP サーバーが必要になる場合があります。たとえば、Web または電子メールアプリケーションでは、ユーザーが LDAP サーバー上にあるパスワードを変更する必要がある場合があります。 |
enableShadowUpdate の実装にはまた、管理者資格 (adminDN および adminPassword) がすべてのクライアント上でローカルに格納されていることも必要です。この情報は、svc:/network/ldap/client サービス内に格納されます。
アカウント管理に pam_ldap を使用する場合とは異なり、アカウント管理に pam_unix_* モジュールを使用する場合は /etc/pam.conf ファイルへの変更は必要ありません。デフォルトの /etc/pam.conf ファイルで十分です。
|