この章の内容は次のとおりです。
LDIF は、ディレクトリサービスのエンティティおよびその属性を記述するためのテキストベースのフォーマットです。 LDIF フォーマットを使用することで、ldapadd や ldapmodify などのコマンドを実行して、ディレクトリ間で情報を移動できます。 以下に、各サービスの LDIF フォーマットの例を示します。 この情報を表示するには、-l オプションを指定して、ldaplist(1) を実行してください。
% ldaplist -l hosts myhost
hosts dn: cn=myhost+ipHostNumber=7.7.7.115,ou=Hosts,dc=mydc,dc=mycom,dc=com cn: myhost iphostnumber: 7.7.7.115 objectclass: top objectclass: device objectclass: ipHost description: host 1 - floor 1 - Lab a - building b |
% ldaplist -l passwd user1
passwd dn: uid=user1,ou=People,dc=mydc,dc=mycom,dc=com uid: user1 cn: user1 userpassword: {crypt}duTx91g7PoNzE uidnumber: 199995 gidnumber: 20 gecos: Joe Smith [New York] homedirectory: /home/user1 loginshell: /bin/csh objectclass: top objectclass: shadowAccount objectclass: account objectclass: posixAccount |
% ldaplist -l services name
services dn: cn=name+ipServiceProtocol=udp,ou=Services,dc=mydc,dc=mycom,dc=com cn: name cn: nameserver ipserviceprotocol: udp ipserviceport: 42 objectclass: top objectclass: ipService |
% ldaplist -l group mygroup
group dn: cn=mygroup,ou=Group,dc=mydc,dc=mycom,dc=com cn: mygroup gidnumber: 4441 memberuid: user1 memberuid: user2 memberuid: user3 userpassword: {crypt}duTx91g7PoNzE objectclass: top objectclass: posixGroup |
% ldaplist -l netgroup mynetgroup
netgroup cn=mynetgroup,ou=netgroup,dc=central,dc=sun,dc=com objectclass=nisNetgroup objectclass=top cn=mynetgroup nisnetgrouptriple=(user1..mydc.mycom.com,-,) nisnetgrouptriple=(user1.,-,) membernisnetgroup=mylab |
% ldaplist -l networks 200.20.20.0
networks dn: ipNetworkNumber=200.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com cn: mynet-200-20-20 ipnetworknumber: 200.20.20.0 objectclass: top objectclass: ipNetwork description: my Lab Network ipnetmasknumber: 255.255.255.0 |
% ldaplist -l netmasks 201.20.20.0
netmasks dn: ipNetworkNumber=201.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com cn: net-201 ipnetworknumber: 201.20.20.0 objectclass: top objectclass: ipNetwork description: my net 201 ipnetmasknumber: 255.255.255.0 |
% ldaplist -l rpc ypserv
rpc dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com cn: ypserv cn: ypprog oncrpcnumber: 100004 objectclass: top objectclass: oncRpc |
% ldaplist -l protocols tcp
protocols dn: cn=tcp,ou=Protocols,dc=mydc,dc=mycom,dc=com cn: tcp ipprotocolnumber: 6 description: transmission control protocol objectclass: top objectclass: ipProtocol |
% ldaplist -l bootparams myhost
bootparams dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com bootparameter: root=boothost:/export/a/b/c/d/e objectclass: top objectclass: device objectclass: bootableDevice cn: myhost |
% ldaplist -l ethers myhost
ethers dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com macaddress: 8:1:21:71:31:c1 objectclass: top objectclass: device objectclass: ieee802Device cn: myhost |
% ldaplist -l publickey myhost
publickey dn: cn=myhost+ipHostNumber=200.20.20.99,ou=Hosts,dc=mydc,dc=mycom,dc=com cn: myhost iphostnumber: 200.20.20.99 description: Joe Smith nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9 nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99 objectclass: top objectclass: NisKeyObject objectclass: device objectclass: ipHost |
% ldaplist -l aliases myname
aliases dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com cn: myname mail: myname objectclass: top objectclass: mailgroup mgrprfc822mailmember: my.name |
NIS や NIS+ クライアントと違い、 LDAP クライアントは常にホスト名として完全指定のドメイン名 (FQDN、Fully Qualified Domain Name) を返します。 LDAP のFQDN は、DNS によって返される FQDN に似ています。 たとえば、次のドメイン名を考えてみましょう。
west.example.net |
ホスト名 server を検索する場合、gethostbyname() および getnameinfo() はホスト名を FQDN で返します。
server.west.example.net |
また、server-# のようなインタフェース固有のエイリアスを使用した場合も、完全指定ホスト名の長いリストが返されます。 ホスト名を使用してファイルシステムを共有したり他の検査を実行する場合、この点に留意する必要があります。 たとえば、ローカルホストは FQDN ではなく、遠隔 DNS で解決されるホストだけが FQDN であると想定している場合は、その違いに留意する必要があります。 DNS とは違うドメイン名で LDAP を設定する場合、参照先によって同じホストが結果的に2つの異なる FQDN になる可能性があります。
Solaris LDAP クライアントはデフォルトで、DIT がある特定の構造を持って いると想定して情報にアクセスします。 LDAP サーバーがサポートするドメインごとに、想定された構造を持つサブツリーがあります。 ただしこのデフォルト構造は、サービス検索記述子 (Service Search Descriptor、SSD) を指定することで上書きできます。 指定されたドメインでは、デフォルト DIT がベースコンテナを保持し、ベースコンテナに特定の情報タイプのエントリを含む既知のコンテナが多数含まれます。 これらのサブツリー名については次の表を参照してください。 (この情報は RFC 2307 などで確認できます)。
表 13–1 DIT のデフォルト位置
デフォルトコンテナ |
情報タイプ |
---|---|
ou=Ethers |
bootparams(4)、ethers(4) |
ou=Group |
group(4) |
ou=Hosts |
hosts(4)、ipnodes(4)、publickey (ホスト用) |
ou=Aliases |
aliases(4) |
ou=Netgroup |
netgroup(4) |
ou=Networks |
networks(4)、netmasks(4) |
ou=People |
passwd(1)、shadow(4)、user_attr(4)、audit_user(4)、publickey (ユーザー用) |
ou=printers |
printers(4) |
ou=Protocols |
protocols(4) |
ou=Rpc |
rpc(4) |
ou=Services |
services(4) |
ou=SolarisAuthAttr |
auth_attr(4) |
ou=SolarisProfAttr |
prof_attr(4)、exec_attr(4) |
ou=projects |
project |
automountMap=auto_* |
auto_* |
スキーマは、LDAP ディレクトリ内にエントリとして格納可能な情報タイプの定義です。 LDAP ネームサービスクライアントをサポートするために、ディレクトリサーバースキーマの拡張が必要な場合があります。 IETF および Solaris 固有のスキーマの詳細については第 18 章「LDAP の一般的なリファレンス 」を参照してください。 IETF Web サイト http://www.ietf.org で、さまざまな RFC にアクセスできます。
スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。 マッピングされた属性の構文が、マッピング先の属性との一貫性を保持していることを確認してください。 つまり、単一値の属性が単一値の属性にマッピングされ、属性の構文が一致しており、マッピングされたオブジェクトクラスが適正な必須 (通常はマッピングされた) 属性を保持することを確認します。
前述したように、LDAP ネームサービスはデフォルトで、DIT が特定の方法で構築されているという想定のもとに動作します。 必要に応じて、DIT 内のデフォルト以外の場所を検索するように Solaris LDAP ネームサービスに指示することができます。 また、デフォルトスキーマで指定された属性やオブジェクトクラスの代わりに、別の属性やオブジェクトクラスを指定して使用することもできます。 デフォルトフィルタの詳細については、LDAP ネームサービスで使用されるデフォルトフィルタを参照してください。
serviceSearchDescriptor 属性 は、LDAP ネームサービスクライアントが特定のサービスに関する情報を検索する方法および場所を定義します。 serviceSearchDescriptor には、サービス名に続き、1 つ以上のセミコロンで区切られたベース - スコープ - フィルタのセットが含まれます。 これらのベース - スコープ - フィルタのセットは特定のサービス専用の検索定義に使用され、指定された順番で検索されます。 特定のサービスに対して複数のベース - スコープ - フィルタが指定されている場合、このサービスは、特定のエントリを検索する際、指定されたスコープおよびフィルタを保持する各ベースを検索します。
SSD では、デフォルト位置は SSD に含められていない限り、サービス (データベース) の検索対象にはなりません。 サービスに複数の SSD が指定されている場合、予期しない結果になることがあります。
次の例では、Solaris LDAP ネームサービスクライアントが、passwd サービスに対して、ou=west,dc=example,dc=com で 1 レベルの検索を実行し、次に ou=east,dc=example,dc=com で 1 レベルの検索を実行します。 ユーザーの username に対して passwd データを検索する場合、各 BaseDN に対してデフォルトの LDAP フィルタ (&(objectClass=posixAccount)(uid=username)) が使用されます。
serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east, dc=example,dc=com |
次の例では、Solaris LDAP ネームサービスクライアントは、ou=west,dc=example,dc=com 内でpasswd サービスのサブツリー検索を実行します。 ユーザー username の passwd データを検索する場合、LDAP フィルタ (&(fulltimeEmployee=TRUE)(uid=username)) を使用して、サブツリー ou=west,dc=example,dc=com が検索されます。
serviceSearchDescriptor: passwd:ou=west,dc=example, dc=com?sub?fulltimeEmployee=TRUE |
特定のサービスタイプに複数のコンテナを関連付けることも可能です。
たとえば、次のサービス検索記述子は、3 つのコンテナ、ou=myuser,dc=example,dc=com、ou=newuser,dc=example,dc=com、および ou=extuser,dc=example,dc=com でパスワードエントリを検索することを指定しています。 末尾に「,」がある場合には、SSD の相対ベースに defaultSearchBase が付加されることを意味します。
defaultSearchBase: dc=example,dc=com serviceSearchDescriptor: \ passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com |
Solaris LDAP ネームサービスを使用すると、1 つ以上の属性名をいずれかのサービスに再マッピングできます (Solaris LDAP クライアントは、第 18 章「LDAP の一般的なリファレンス 」に記載されているよく知られている属性を使用します)。 属性を対応づける場合、その属性が元の属性と同じ意味および構文を必ず保持するようにしてください。 userPassword 属性を対応づけると、問題が発生する場合があります。
スキーママッピングを使用する理由として、次の 2 つが挙げられます。
既存のディレクトリサーバー内の属性を対応づけしたい
大文字小文字のみが異なるユーザー名を使用する場合、大文字小文字を無視する uid 属性を、大文字小文字を無視しない属性に対応づける必要があります。
この属性の書式は、service:attribute-name=mapped-attribute-name です。
指定されたサービスに対して複数の属性を対応づける場合は、複数の attributeMap 属性を定義できます。
次の例では、uid および homeDirectory 属性を passwd サービスで利用する場合、常に employeeName および home 属性が使用されます。
attributeMap: passwd:uid=employeeName attributeMap: passwd:homeDirectory=home |
passwd サービスの gecos 属性を複数の属性に対応づける場合、特殊なケースが 1 つ存在します。 次に例を示します。
attributemap: gecos=cn sn title |
上の例では、gecos 値が、空白で区切られた cn、sn、および title 属性値のリストに対応づけられます。
Solaris LDAP ネームサービスを使用すると、オブジェクトクラスを任意のサービス用に対応づけしなおすことができます。 特定のサービス用に複数のオブジェクトクラスを対応づける場合、複数の objectclassMap 属性を定義できます。 次の例では、posixAccount オブジェクトクラスを使用する場合、常に myUnixAccount オブジェクトクラスが使用されます。
objectclassMap: passwd:posixAccount=myUnixAccount |
Solaris クライアントのセットアップを容易にし、各クライアントに同じ情報を再入力する手間を省くために、ディレクトリサーバー上に単一のクライアントプロファイルを作成します。 この単一のプロファイルに、使用するすべてのクライアントの構成を定義します。 プロファイル属性への以降の変更はすべて、 定義されたリフレッシュ頻度でクライアントに送信されます。
これらのクライアントプロファイルは、LDAP サーバー上のよく知られた位置に格納されます。 指定されたドメインのルート DN は、nisDomainObject のオブジェクトクラス、およびクライアントのドメインを含む nisDomain 属性を保持する必要があります。 すべてのプロファイルは、このコンテナと相対的な関係にある ou=profile コンテナ内に配置されます。 これらのプロファイルは、匿名で読み取り可能にする必要があります。
次の表に、Solaris LDAP クライアントのプロファイル属性を示します。このプロファイル属性は、idsconfig の実行時に自動的に設定されます。 クライアントプロファイルを手動で設定する方法については、クライアントを手動で初期設定すると idsconfig(1M) のマニュアルページを参照してください。
表 13–2 クライアントのプロファイル属性
属性 |
説明 |
---|---|
cn |
プロファイル名。 デフォルト値なし。 必須 |
preferredServerList |
優先使用されるサーバーのホストアドレスの、空白で区切られたリスト。 (ホスト名は使用しない)。 defaultServerList 内のサーバーより「前に」、接続が成功するまで、このリスト内のサーバーへの接続が順番に試みられる。 デフォルト値なし。 preferredServerList または defaultServerList に 1 つ以上のサーバーを指定する必要がある。 |
defaultServerList |
デフォルトサーバーのホストアドレスの、空白で区切られたリスト (ホスト名は使用しない)。 preferredServerlist 内のサーバーへの接続試行後に、接続が確立されるまで、クライアントのサブネット上のデフォルトサーバーへの接続、続いて残りのデフォルトサーバーへの接続が試みられる。 preferredServerList または defaultServerList に 1 つ以上のサーバーを指定する必要がある。 このリスト内のサーバーへの接続は、優先サーバーリストのサーバーへの接続試行後に試みられる。 デフォルト値なし |
defaultSearchBase |
よく知られたコンテナの検索に使用する相対識別名。 デフォルト値なし。 ただしこの値は、serviceSearchDescriptor 属性で指定されたサービスで置き換えることが可能 |
defaultSearchScope |
クライアントによるデータベース検索の適用範囲を定義する。 この値は、serviceSearchDescriptor 属性で置き換えることが可能。 指定可能な値は one または sub。 デフォルト値は 1 レベルの検索 (値はone) |
authenticationMethod |
クライアントが使用する認証方式を示す。 デフォルト値は none (匿名)。 詳細については、認証方式の選択を参照 |
credentialLevel |
クライアントが認証に使用する証明書タイプを示す。 匿名またはプロキシを選択可能。 デフォルトは匿名。 |
serviceSearchDescriptor |
クライアントがネームデータベースを検索する方法および場所を定義する (例、クライアントが DIT 内の 1 つ以上の場所を検索する)。 デフォルトでは、SSD は定義されていない |
serviceAuthenticationMethod |
クライアントが特定のサービスで使用する認証メソッド。 デフォルトでは、サービス認証メソッドは定義されていない。 サービスで serviceAuthenticationMethod が定義されていない場合、authenticationMethod の値がデフォルトになる |
attributeMap |
クライアントが使用する属性マッピング。 デフォルトでは、attributeMap は定義されていない |
objectclassMap |
クライアントが使用するオブジェクトクラスマッピング。 デフォルトでは、objectclassMap は定義されていない |
searchTimeLimit |
クライアントが許可する、タイムアウトまでの最長検索時間 (秒)。 この値は、LDAP サーバーが許可する、検索完了までの時間に影響を及ぼさない デフォルト値は 30 秒 |
bindTimeLimit |
クライアントがサーバーとのバインドに許可する最長時間 (秒)。 デフォルト値は 30 秒 |
followReferrals |
クライアントが LDAP 参照に準拠するかどうかを指定する。 指定可能な値は TRUE または FALSE。 デフォルト値は TRUE。 |
profileTTL |
ldap_cachemgr(1M) により実行される、LDAP サーバーからのクライアントプロファイルの更新間隔。 デフォルト値は 43200 秒 (12 時間)。 値が 0 の場合、プロファイルは更新されない |
次の表に、ldapclient を使用してローカルに設定可能なクライアント属性を示します。 詳細は、ldapclient(1M) のマニュアルページを参照してください。
表 13–3 ローカルのクライアント属性
属性 |
説明 |
---|---|
domainName |
クライアントのドメイン名 (クライアントマシンのデフォルトドメインになる) を指定します。 デフォルト値なし。必須 |
proxyDN |
プロキシの識別名。 プロキシの credentialLevel を使用してクライアントマシンを構成する場合、proxyDN を指定する必要がある |
proxyPassword |
プロキシのパスワード。 プロキシの credentialLevel を使用してクライアントマシンを構成する場合、proxyPassword を定義する必要がある |
certificatePath |
証明書データベースを含む、ローカルファイルシステム上のディレクトリ。 TLS を使用し、authenticationMethod または serviceAuthenticationMethod を指定してクライアントマシンを構成する場合、この属性が使用される。 デフォルト値は /var/ldap |
SSD 内の BaseDN に「末尾のコンマが含まれる」場合、defaultSearchBase の相対値として処理されます。 検索実行前に、defaultSearchBase の値が BaseDN に付加されます。
ldap_cachemgr は、LDAP クライアントマシン上で稼働するデーモンです。 このデーモンは、次の主要機能を実行します。
サーバー上のプロファイルに格納されたクライアント構成情報を更新して、クライアントからこのデータを引き出す
使用可能な LDAP サーバーのソート済みリストを管理
さまざまなクライアントから送信される一般的な検索要求をキャッシュして、検索効率を向上させる
ホスト検索の効率を向上させる
LDAP ネームサービスを機能させるには、ldap_cachemgr が常に実行されている必要があります。
詳細については、ldap_cachemgr(1M) のマニュアルページを参照してください。
Solaris LDAP ネームサービスは、LDAP リポジトリをネームサービスと認証サービスの両方のソースとして使用します。 この節では、クライアント認証、認証方式、pam_ldap(5) と pam_unix(5) モジュール、およびパスワード管理の概念について説明します。
LDAP リポジトリ内の情報にアクセスする場合、クライアントは最初にディレクトリサーバーで識別情報を確立できます。 この識別情報は、匿名にも、LDAP サーバーの認識するオブジェクトにもできます。 クライアントの識別情報およびサーバーのアクセス制御情報(ACI) に基づいて、LDAP サーバーはクライアントに対してディレクトリ情報の読み取りまたは書き込みを許可します。 ACI の詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。
特定の要求に関して匿名以外で接続している場合、クライアントは、クライアントとサーバーの両方がサポートする認証方式でサーバーに識別情報を証明する必要があります。 クライアントは識別情報を確立後に、さまざまな LDAP 要求を実行できます。
ネームサービスと認証サービス(pam_ldap) がディレクトリにアクセスする方法には違いがあります。 ネームサービスは、事前定義された識別情報に基づくディレクトリから、さまざまなエントリおよびその属性を読み取ります。 認証サービスは、ユーザーの名前とパスワードを使用して LDAP サーバーへの認証を行い、ユーザーが適正なパスワードを入力したかどうかを確認します。 認証サービスについての詳細は、pam_ldap(5) のマニュアルページを参照してください。
TLS をLDAP クライアントとディレクトリサーバー間の通信のセキュリティ保護に使用すると、機密性とデータ整合性を確保することができます。 TLS プロトコルは、Secure Sockets Layer (SSL) プロトコルのスーパーセットです。 Solaris LDAP ネームサービスは、TLS 接続をサポートします。 SSL を使用すると、ディレクトリサーバーおよびクライアントに負荷がかかることに留意してください。
SSL 対応のディレクトリサーバーを設定する必要があります。 SSL 対応の Sun ONE Directory Server の設定方法の詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』を参照してください。 SSL 対応の LDAP クライアントも設定する必要があります。
Solaris LDAP ネームサービス用の TLS を使用する場合、ディレクトリサーバーは、LDAP および SSL 用にデフォルトポート 389 および 636 をそれぞれ使用する必要があります。 ディレクトリサーバーがこれらのポートを使用しない場合、TLS を使用することはできません。
詳細については、TLS のセキュリティの設定を参照してください。
LDAP ネームサービス クライアントは、クライアントの資格レベルに従って LDAP サーバーを認証します。 LDAP クライアントには、次の 3 つの資格レベルの 1 つを割り当てて、ディレクトリサーバーへの認証を行うことができます。
匿名 (anonymous)
匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。 また、セキュリティの問題も考慮する必要があります。 ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するすべてのユーザーが読み取りアクセスを保持することになります。 資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。
匿名でのディレクトリへの書き込みは、決して許可してはなりません。この書き込みを許可すると、どのユーザーでも書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) を変更することが可能になります。
Sun ONE Directory Server を使用すると、IP アドレス、DNS 名、認証方式、および時刻に基づいてアクセスを制限できます。 さらに指定を加えて、アクセスを制限することもできます。 詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』のアクセス権の管理に関する章を参照してください。
プロキシ (proxy)
クライアントは、プロキシアカウントを使用して、ディレクトリへの認証またはバインドを行います。 このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。 このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。 プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を構成する必要があります。 暗号化された proxyPassword はローカルのクライアントに格納されます。 別のクライアントグループに対しては別のプロキシを設定できます。 たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。 最も極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。 一般的な LDAP 配備はこの両極端の中間に位置します。 選択は慎重に行なってください。 プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。 ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。 適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって異なります。 使用する構成に最適の認証方式を決定するための情報については、資格の保存を参照してください。
プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。 LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。
プロキシ資格レベルは、指定されたマシンのすべてのユーザーおよびプロセスに適用されます。 2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用する必要があります。
また、クライアントが認証にプロキシ資格を使用する場合、proxyDN はすべてのサーバーで同じ proxyPassword を保持する必要があります。
匿名プロキシ (anonymous proxy)
匿名プロキシは複数値のエントリで、複数の資格レベルが内部に定義されています。 匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。 ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。 この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。
プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは proxyDN および proxyPassword を /var/ldap/ldap_client_cred 内に保存します。 セキュリティ保護のため、このファイルへのアクセスは root のみに許可され、proxyPassword の値は暗号化されます。 過去の LDAP 実装ではプロキシ資格はクライアントのプロファイル内に格納されましたが、Solaris 9 LDAP ネームサービスではこれは行われません。 初期化時に ldapclient を使用して設定されたプロキシ資格は、すべてローカルに保存されます。 このため、プロキシの DN およびパスワード情報に関するセキュリティが向上します。 クライアントプロファイルの設定方法の詳細については、第 16 章「クライアントの設定 (手順)」を参照してください。
プロキシ資格または匿名プロキシ資格を割り当てる場合、プロキシによるディレクトリサーバーへの認証方式も選択する必要があります。 デフォルトの認証方式は none (匿名によるアクセス) です。 認証方式には、関連するトランスポートセキュリティオプションも含まれます。
認証方式には、資格レベルと同様、複数値を指定できます。 たとえば、クライアントプロファイルを設定することにより、クライアントが TLS でセキュリティ保護された simple メソッドを最初に使用してバインドを試みるようにできます。 これが成功しない場合、クライアントは sasl/digest-MD5 メソッドを使用してバインドを試みます。 その後、authenticationMethod は tls:simple;sasl/digest-MD5 になります。
LDAP ネームサービスは、いくつかの Simple Authentication and Security Layer (SASL) 機構をサポートします。 これらの機構を使用すると、TLS なしでセキュリティ保護されたパスワードを交換できます。 ただし、これらの機構はデータの完全性や機密性を保証するものではありません。 SASL の詳細については、RFC 2222 を参照してください。
次の認証機構がサポートされています。
none
クライアントは、ディレクトリへの認証を行いません。 これは、anonymous 資格レベルと等価です。
認証方式 simple を使用する場合、クライアントマシンはユーザーのパスワードを平文 (clear) で送信してサーバーへのバインドを実行します。 このため、セッションが ipsec(7) により保護されていない限り、パスワードが漏洩しやすくなります。認証方式 simple を使用する主な利点は、すべてのディレクトリ サーバーがこの方式をサポートしていること、および設定が容易であるという点です。
認証時にクライアントのパスワードは保護されますが、セッションは暗号化されません。 Sun ONE Directory Server を含むいくつかのディレクトリサーバーは、sasl/digest-MD5 認証方式もサポートします。 digest-MD5 の主な利点は、認証時にパスワードが平文のままネットワーク上を流れないため、simple よりも安全であるという点です。 digest-MD5 の詳細については、RFC 2831 を参照してください。 digest-MD5 は、cram-MD5 のセキュリティが改善されたものと見なされます。
sasl/digest-MD5 を使用する場合、認証はセキュリティ保護されますがセッションは保護されません。
Sun ONE Directory Server を使用している場合、パスワードをディレクトリ内に「平文」で格納する必要があります。
sasl/cram-MD5
この場合、LDAP セッションは暗号化されませんが、sasl/cram-MD5 を使用して認証が行われるため、認証時にクライアントのパスワードが保護されます。
cram-MD5 認証方式の詳細については、RFC 2195 を参照してください。 すべてのディレクトリサーバーが cram-MD5 をサポートしているわけではありません。 たとえば、Sun ONE Directory Server は cram-MD5 をサポートしません。
tls:simple
クライアントは、simple を使用してバインドを行い、セッションは暗号化されます。 パスワードは保護されます。
tls:sasl/cram-MD5
sasl/cram-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
tls:sasl/digest-MD5
sasl/digest-MD5 を使用して、LDAP セッションの暗号化およびクライアントによるディレクトリサーバーへの認証が行われます。
Sun ONE Directory Server で digest-MD5 を使用する場合、パスワードを平文で格納する必要があります。 認証方式を sasl/digest-MD5 または tls:sasl/digest-MD5 に設定する場合、プロキシユーザーのパスワードを平文で格納する必要があります。 平文で格納する場合には、userPassword 属性が適切な ACI を保持するようにして読み取り不可にするよう、特に注意してください。
次の表に、さまざまな認証方式およびその特性の概要を示します。
表 13–4 認証方式
|
バインド |
セッション |
通信時のパスワード |
Sun ONE Directory Server でのパスワード |
セッション |
---|---|---|---|---|---|
none |
任意 |
暗号化しない |
なし |
なし |
暗号化しない |
simple |
必須 |
暗号化しない |
平文 |
任意 |
任意 |
sasl/digest-MD5 |
必須 |
暗号化しない |
暗号化 |
平文 |
任意 |
sasl/cram-MD5 |
必須 |
暗号化しない |
暗号化 |
なし |
任意 |
tls_simple |
必須 |
暗号化しない |
暗号化 |
任意 |
暗号化 |
tls:sasl/cram-MD5 |
必須 |
暗号化 |
暗号化 |
なし |
暗号化 |
tls:sasl/digest-MD5 |
必須 |
暗号化 |
暗号化 |
平文 |
暗号化 |
認証方式を特定のサービスに対して serviceAuthenticationMethod 属性に指定できます。 現在この機能をサポートしているサービスを次に示します。
passwd-cmd
このサービスは、passwd(1) により、ログインパスワードおよびパスワード属性の変更に使用されます。
keyserv
このサービスは、chkey(1) および newkey(1M) ユーティリティにより、ユーザーの Diffie-Hellman 鍵ペアの作成および変更に使用されます。
pam_ldap
このサービスは、pam_ldap(5) を使用したユーザーの認証に使用されます。
pam_ldap は、アカウントの管理をサポートします。
サービスが serviceAuthenticationMethod セットを保持しない場合、authenticationMethod 属性の値がデフォルトになります。
次に示す例は、クライアントプロファイルの 1 セクションです。ここで、ユーザーはディレクトリサーバーへの認証に sasl/digest-MD5 を使用しますが、パスワードの変更には SSL セッションを使用します。
serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5 serviceAuthenticationMethod=passwd-cmd:tls:simple |
PAM フレームワークを使用することにより、いくつかの認証サービスの中から選択できます。 LDAP とともに pam_unix(5) または pam_ldap(5) を使用できます。
より高い柔軟性とより強力な認証方式をサポートしていること、およびアカウント管理を使用できることから、pam_ldap の使用をお勧めします。
pam_unix
pam.conf(4) ファイルを変更していない場合、デフォルトで pam_unix が有効になっています。 pam_unix は従来の UNIX 認証モデルに従い、次のように動作します。
クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。
ユーザーは、パスワードの入力を求められます。
ユーザーのパスワードが暗号化されます。
クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。
pam_unix を使用する場合、次の 2 つの制限が存在します。
パスワードは、平文を含む他の暗号化方式ではなく、UNIX crypt 形式で格納する必要がある
userPassword 属性は、ネームサービスから読み取り可能でなければならない
たとえば、資格レベルを匿名に設定する場合、すべてのユーザーに対してuserPassword 属性を読み取り可能にする必要があります。 同様に、資格レベルを proxy に設定する場合、userPassword 属性の読み取りをプロキシユーザーに許可する必要があります。
pam_unix は、sasl 認証方式 digest-MD5 と互換性がありません。これは、Sun ONE Directory Server では digest-MD5 を使用するためにパスワードを平文で格納する必要があるのに対し、pam_unix ではパスワードを crypt 形式で格納する必要があるためです。
詳細については、pam_unix(5) のマニュアルページを参照してください。
pam_ldap
使用する場合、ユーザーは pam_ldap の serviceAuthenticationMethod パラメータに定義された認証方式を使用して LDAP サーバーにバインドします (このパラメータが存在する場合)。 それ以外の場合、authenticationMethod がデフォルトで使用されます。
pam_ldap が、ユーザーの識別情報および指定されたパスワードでサーバーにバインドできれば、ユーザーが認証されたことになります。
pam_ldap は、userPassword 属性を読み取りません。 このため、pam_ldap を使用する他のクライアントが存在しない限り、userPassword 属性の読み取りアクセス権を付与する必要はありません。 pam_ldap は、認証方式 none をサポートしません。 このため、クライアントが pam_ldap を使用できるように、serviceAuthenticationMethod または authenticationMethod 属性を定義する必要があります。 詳細は、pam_ldap(5) のマニュアルページを参照してください。
認証方式 simple を使用する場合、第三者がネットワーク上で userPassword 属性を読み取ることができます。
詳細については、pam_ldap に対応した pam.conf ファイルの例 を参照してください。
以下の表に、pam_unix と pam_ldap の主な相違点を示します。 詳細は、pam_unix(5) と pam_ldap(5) のマニュアルページを参照してください。
表 13–5 pam_unix と pam_ldap
|
pam_unix |
pam_ldap |
---|---|---|
パスワードの送信 |
passwd サービス認証方式を使用 |
passwd サービス認証方式を使用 |
新規パスワードの送信 |
暗号化する |
暗号化しない (TLS を使用しない場合) |
新規パスワードの格納 |
crypt 形式 |
Sun ONE Directory Server でのデフォルト passwd 格納スキーマによる定義に従う |
パスワードの読み取り |
必須 |
任意 |
パスワード変更後の sasl/digestMD5 の互換性 |
なし。パスワードは平文では格納されない。 ユーザーを認証できない |
あり。 デフォルトのストレージスキーマが平文 (clear) に設定されていれば、ユーザーを認証できる |
パスワードを変更するには、passwd(1) を使用してください。 パスワードを変更するには、userPassword 属性をユーザーから書き込み可能にする必要があります。 passwd-cmd 用の serviceAuthenticationMethod が、この操作の authenticationMethod を無効にすることに留意してください。 使用する認証によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。
pam_unix(5) の場合、UNIX crypt 形式を使用して新規 userPassword 属性が暗号化されタグ付けされてから、LDAP への書き込みが行われます。 このため、新規パスワードは、サーバーへのバインドに使用される認証方式に関係なく、ネットワーク上で暗号化されます。
pam_ldap の場合、パスワードの変更時に新規パスワードの暗号化解除が行われます。 このため、機密性を保つために TLS を使用する必要があります。 TLSを使用しない場合、userPassword が漏洩する危険性があります。
Sun ONE Directory Server で pam_ldap(5) を使用してパスワードを設定する場合、パスワードは passwordStorageScheme (タグ付けされていない状態) を使用して暗号化されます。 passwordStorageScheme 属性の詳細については、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』のユーザーアカウントの管理に関する章を参照してください。
passwordStorageScheme 属性を設定する際、以下の点を考慮する必要があります。 pam_unix を使用する NIS、NIS+、または他のクライアントがリポジトリとして LDAP を使用する場合、passwordStorageScheme に対して crypt を実行する必要があります。 また、Sun ONE Directory Server で sasl/digest-MD5 に対して pam_ldap を使用する場合、passwordStorageScheme を平文に設定する必要があります。 詳細は、次の節を参照してください。
Sun ONE Directory Server を digest-MD5 で使用する場合は、パスワードを変更するユーザーが何らかのパスワード管理上の理由で変更に失敗すると、変更後のパスワードを使用してログインできなくなります。
たとえば、サーバーでパスワード履歴が有効である場合、ユーザーが以前に使用していたパスワードに変更しようとすると、制約違反 (この場合は以前に使用していたパスワードを使用すること) のために pam_ldap はパスワードの変更に失敗します。 pam は pam_ldap を無視して、pam_unix に行き着きます。 結果として、パスワードが平文ではなく、暗号化形式で格納されます。 このため、次にユーザーが変更後のパスワードを使用してログインを試みると、ログインは失敗します。
pam_ldap が pam_unix に行き着くことを防ぐには、「すべての」クライアントの pam.conf ファイルで次の構成を使用する必要があります。
other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_authtok_store.so.1 server_policy |
上記の構成には、pam_ldap.so.1 が存在しないことに留意してください。 server_policy は、pam_authtok_store.so.1 が「常に」 LDAP アカウントの平文テキストをディレクトリサーバーに送信することを指定し、サーバーが独自のパスワード暗号化スキーマに従ってパスワードを格納することを許可します。 ただし、上記の構成を使用する場合、これと適合した認証構成も必要になります。 たとえば、次の構成を使用します。
login auth binding pam_unix_auth.so.1 server_policy login auth required pam_ldap.so.1 |
および
passwd auth binding pam_passwd_auth.so.1 server_policy passwd auth required pam_ldap.so.1 |
同じディレクトリネーミングドメイン内のすべてのクライアントが、上記の構成を使用するようにしてください。 1 つのクライアントで別の pam.conf を使用している場合でも、ユーザーがそのシステム上でパスワードを変更すると、残りのクライアントでログイン認証が失敗します。
LDAP ネームサービスは、Sun ONE Directory Server でパスワードとアカウントのロックアウトポリシーをサポートする利点を有効に活用しています。 pam_ldap(5) を構成して、ユーザアカウント管理をサポートすることが可能です。 passwd(1) を正しい PAM 構成で使用すると、Sun ONE Directory Server パスワードポリシーによるパスワードの構文規則を強化します。
pam_ldap(5) により、以下のパスワード管理機能がサポートされています。 これらの機能は、Sun ONE Directory Server のパスワードとアカウントのロックアウトポリシー構成を利用しています。 必要な機能を必要な数だけ利用できます。
古くなったり、有効期限の切れたパスワードを通知する
パスワードは、予定にしたがって変更する必要があります。 パスワードを定められた期間内に変更しないとそのパスワードは無効になります。 期限切れのパスワードでは、ユーザーが認証されません。
期限切れの警告期間内のログイン時には、常に警告メッセージを表示します。 メッセージには期限切れまでの日数と時間が表示されます。
パスワードの構文チェック
新規パスワードは、最小文字数の条件を満たしている必要があります。 また、ユーザーのディレクトリエントリにある uid、cn、sn、および mail と同じ値をパスワードに設定することはできません。
パスワードの履歴チェック
パスワードの再利用はできません。 以前使われていたパスワードに変更しようとすると、passwd(1) コマンドは失敗します。 LDAP 管理者は、サーバーの履歴リストに保持するパスワードの数を設定することができます。
ユーザーアカウントのロックアウト
認証の失敗が設定された回数に達すると、そのユーザーアカウントはロックアウトされます。 管理者がアカウントを非アクティブにした場合も、そのユーザーはロックアウトされます。 アカウントのロックアウト期間が経過するか、管理者が再びアカウントをアクティブにするまで、認証は成功しません。
以上のパスワード管理機能は、Solaris 9 にバンドルされたSun ONE Directory Server のバージョンでのみ有効です。サーバー上のパスワードとアカウントのロックアウトポリシーの構成についての詳細は、ご使用のバージョンの Sun ONE Directory Server の『管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。 また、パスワード管理のために pam_ldap を構成した pam.conf ファイル例 も参照してください。 proxy アカウントでは、パスワード管理を有効にしないでください。
Sun ONE Directory Server 上でパスワードとアカウントのロックアウトポリシーを構成する前に、すべてのホスト上で pam_ldap パスワード管理に基づいた「最新の」 LDAP クライアントが使われていることを確認します。
さらに、クライアントが正しい構成の pam.conf(4) ファイルを保持していることを確認します。 正しい構成ファイルを保持していない場合、 LDAP ネームサービスは proxy やユーザーパスワードが期限切れの時に動作しません。