test

Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

第 9 章 LDAP 基本コンポーネントおよび概念 (概要)

この章の内容は次のとおりです。

LDAP データ交換フォーマット (LDIF)

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

LDAP での完全指定ドメイン名の使用

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 になる可能性があります。

デフォルトのディレクトリ情報ツリー (DIT)

Solaris LDAP クライアントはデフォルトで、DIT がある特定の構造を持っていると想定して情報にアクセスします。LDAP サーバーがサポートするドメインごとに、想定された構造を持つサブツリーがあります。ただしこのデフォルト構造は、サービス検索記述子 (Service Search Descriptor、SSD) を指定することで上書きできます。指定されたドメインでは、デフォルト DIT がベースコンテナを保持し、ベースコンテナに特定の情報タイプのエントリを含む既知のコンテナが多数含まれます。これらのサブツリー名については次の表を参照してください。(この情報は RFC 2307 などで確認できます)。

表 9–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 ディレクトリ内にエントリとして格納可能な情報タイプの定義です。LDAP ネームサービスクライアントをサポートするために、ディレクトリサーバースキーマの拡張が必要な場合があります。IETF および Solaris 固有のスキーマの詳細については、第 14 章LDAP の一般的なリファレンスを参照してください。IETF Web サイト http://www.ietf.org で、さまざまな RFC にアクセスできます。

サービス検索記述子 (SSD) とスキーママッピング

注 –

スキーママッピングは、注意深くかつ一貫した方法で使用する必要があります。マッピングされた属性の構文が、マッピング先の属性との一貫性を保持していることを確認してください。つまり、単一値の属性が単一値の属性にマッピングされ、属性の構文が一致しており、マッピングされたオブジェクトクラスが適正な必須 (通常はマッピングされた) 属性を保持することを確認します。

前述したように、LDAP ネームサービスはデフォルトで、DIT が特定の方法で構築されているという想定のもとに動作します。必要に応じて、DIT 内のデフォルト以外の場所を検索するように Solaris LDAP ネームサービスに指示することができます。また、デフォルトのスキーマで指定された属性やオブジェクトクラスの代わりに、別の属性やオブジェクトクラスを指定して使用することもできます。デフォルトフィルタの詳細については、「LDAP ネームサービスで使用されるデフォルトフィルタ」を参照してください。

SSD の説明

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 クライアントは、第 14 章LDAP の一般的なリファレンスに記載されているよく知られている属性を使用します)。属性を対応づける場合、その属性が元の属性と同じ意味および構文を必ず保持するようにしてください。userPassword 属性を対応づけると、問題が発生する場合があります。

スキーママッピングを使用する理由として、次の 2 つが挙げられます。

この属性の書式は、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 属性値のリストに対応づけられます。

objectClass マップ

Solaris LDAP ネームサービスを使用すると、オブジェクトクラスを任意のサービス用に対応づけしなおすことができます。特定のサービス用に複数のオブジェクトクラスを対応づける場合、複数の objectclassMap 属性を定義できます。次の例では、posixAccount オブジェクトクラスを使用する場合、常に myUnixAccount オブジェクトクラスが使用されます。


objectclassMap: passwd:posixAccount=myUnixAccount

LDAP クライアントプロファイル

Solaris クライアントのセットアップを容易にし、各クライアントに同じ情報を再入力する手間を省くために、ディレクトリサーバー上に単一のクライアントプロファイルを作成します。この単一のプロファイルに、使用するすべてのクライアントの構成を定義します。プロファイル属性への以降の変更はすべて、定義されたリフレッシュ頻度でクライアントに送信されます。

これらのクライアントプロファイルは、LDAP サーバー上のよく知られた位置に格納されます。指定されたドメインのルート DN は、nisDomainObject のオブジェクトクラス、およびクライアントのドメインを含む nisDomain 属性を保持する必要があります。すべてのプロファイルは、このコンテナと相対的な関係にある ou=profile コンテナ内に配置されます。これらのプロファイルは、匿名で読み取り可能にする必要があります。

クライアントのプロファイル属性

次の表に、Solaris LDAP クライアントのプロファイル属性を示します。このプロファイル属性は、idsconfig の実行時に自動的に設定されます。クライアントプロファイルを手動で設定する方法については、「クライアントを手動で初期設定する」と idsconfig(1M) のマニュアルページを参照してください。

表 9–2 クライアントのプロファイル属性

属性 

説明 

cn

プロファイル名。デフォルト値はありません。必ず指定する必要があります。 

preferredServerList

優先使用されるサーバーのホストアドレスの、空白で区切られたリスト。(ホスト名は使用しない)。defaultServerList 内のサーバーより「前に」、接続が成功するまで、このリスト内のサーバーへの接続が順番に試みられます。デフォルト値はありません。preferredServerList または defaultServerList に 1 つ以上のサーバーを指定する必要があります。

defaultServerList

デフォルトサーバーのホストアドレスの、空白で区切られたリスト。(ホスト名は使用しない)。preferredServerlist 内のサーバーへの接続試行後に、接続が確立されるまで、クライアントのサブネット上のデフォルトサーバーへの接続、続いて残りのデフォルトサーバーへの接続が試みられます。preferredServerList または defaultServerList に 1 つ以上のサーバーを指定する必要があります。このリスト内のサーバーへの接続は、優先サーバーリストのサーバーへの接続試行後に試みられます。デフォルト値はありません。

defaultSearchBase

よく知られたコンテナの検索に使用する相対識別名。デフォルト値はありません。ただしこの値は、serviceSearchDescriptor 属性で指定されたサービスで置き換えることが可能です。

defaultSearchScope

クライアントによるデータベース検索の適用範囲を定義します。この値は、serviceSearchDescriptor 属性で置き換えることが可能です。指定可能な値は one または sub です。デフォルト値は 1 レベルの検索 (値はone) です。

authenticationMethod

クライアントが使用する認証方式を示します。デフォルト値は none (匿名) です。詳細については、「認証方式の選択」を参照してください。

credentialLevel

クライアントが認証に使用する証明書タイプを示します。anonymous、proxy、または self (「ユーザー別」とも呼ばれる) を選択できます。デフォルトは anonymous です。

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) のマニュアルページを参照してください。

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。詳細は、「enableShadowUpdate スイッチ」を参照してください。

表 9–3 ローカルのクライアント属性

属性 

説明 

adminDN

管理者資格の管理者エントリの識別名を指定します。クライアントシステムの enableShadowUpdate スイッチの値が true で、credentialLevel の値が self 以外の場合、adminDN を指定する必要があります。

adminPassword

管理者資格の管理者エントリのパスワードを指定します。クライアントシステムの enableShadowUpdate スイッチの値が true で、credentialLevel の値が self 以外の場合、adminPassword を定義する必要があります。

domainName

クライアントのドメイン名 (クライアントシステムのデフォルトドメインになる) を指定します。デフォルト値はなく、必ず指定する必要があります。 

proxyDN

プロキシの識別名。proxy の credentialLevel を使用してクライアントシステムを構成する場合、proxyDN を指定する必要があります。

proxyPassword

プロキシのパスワード。プロキシの credentialLevel を使用してクライアントシステムを構成する場合、proxyPassword を定義する必要があります。

certificatePath

証明書データベースを含む、ローカルファイルシステム上のディレクトリ。TLS を使用し、authenticationMethod または serviceAuthenticationMethod を指定してクライアントシステムを構成する場合、この属性が使用されます。デフォルト値は /var/ldap です。

注 –

SSD 内の BaseDN に「末尾のコンマが含まれる」場合、defaultSearchBase の相対値として処理されます。検索実行前に、defaultSearchBase の値が BaseDN に付加されます。

ldap_cachemgr デーモン

ldap_cachemgr は、LDAP クライアントマシン上で稼働するデーモンです。LDAP クライアントを起動すると、ldap_cachemgr デーモンが起動されます。このデーモンは、次の主要機能を実行します。

注 –

LDAP ネームサービスを機能させるには、ldap_cachemgr が常に実行されている必要があります。

詳細については、ldap_cachemgr(1M) のマニュアルページを参照してください。

LDAP ネームサービスのセキュリティーモデル

はじめに

Solaris LDAP ネームサービスは、LDAP リポジトリを 2 つの異なる方法で使用できます。1 つは、ネームサービスと認証サービスの両方のソースとして使用する方法です。もう 1 つは、厳密にネームデータのソースとして使用する方法です。この節では、LDAP リポジトリをネームサービスと認証サービスの両方のソースとして使用する場合の、クライアント識別情報、認証方式、pam_ldap と pam_unix モジュール、およびアカウント管理の概念について説明します。また、LDAP ネームサービスを Kerberos 環境 (『Solaris のシステム管理 (セキュリティサービス)』のパート VI「Kerberos サービス」) および pam_krb5(5) モジュールと組み合わせて使用する方法についても説明します。

注 –

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に 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 の詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』を参照してください。

特定の要求に関して匿名以外で接続している場合、クライアントは、クライアントとサーバーの両方がサポートする認証方式でサーバーに識別情報を証明する必要があります。クライアントは識別情報を確立後に、さまざまな LDAP 要求を実行できます。

pam_ldap を使用する場合、ネームサービスと認証サービス(pam_ldap) がディレクトリにアクセスする方法には違いがあります。ネームサービスは、事前定義された識別情報に基づくディレクトリから、さまざまなエントリおよびその属性を読み取ります。認証サービスは、ユーザーの名前とパスワードを使用して LDAP サーバーへの認証を行い、ユーザーが適正なパスワードを入力したかどうかを確認します。認証サービスについての詳細は、pam_ldap(5) のマニュアルページを参照してください。

Kerberos を認証に使用する場合、および LDAP ネームサービス内の認証も有効にする場合 (ユーザー別の認証方式で必要)、Kerberos は二重の機能を提供できます。ディレクトリへの認証に、サーバーへの Kerberos 認証、および主体 (ユーザーまたはホスト) に対する Kerberos 識別情報が使用されます。これにより、システムの認証に使用されるのと同じユーザー識別情報がディレクトリの認証にも使用され、検索と更新が実行されます。管理者は、必要に応じ、アクセス制御情報 (ACI) をディレクトリ内で使用して、ネームサービスで得られる結果を制限できます。

Transport Layer Security (TLS)

注 –

Solaris LDAP ネームサービス用の TLS を使用する場合、ディレクトリサーバーは、LDAP および SSL 用にデフォルトポート 389 および 636 をそれぞれ使用する必要があります。ディレクトリサーバーがこれらのポートを使用しない場合、TLS を使用することはできません。

TLS を LDAP クライアントとディレクトリサーバー間の通信のセキュリティー保護に使用すると、機密性とデータ整合性を確保することができます。TLS プロトコルは、Secure Sockets Layer (SSL) プロトコルのスーパーセットです。Solaris LDAP ネームサービスは、TLS 接続をサポートします。SSL を使用すると、ディレクトリサーバーおよびクライアントに負荷がかかることに留意してください。

SSL 対応のディレクトリサーバーを設定する必要があります。SSL 対応の Sun Java System Directory Server の設定方法の詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』を参照してください。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 クライアントには、次の 4 つの資格レベルの 1 つを割り当てて、ディレクトリサーバーの認証を行うことができます。

匿名 (anonymous)

匿名でのアクセスを利用する場合、すべてのユーザーが使用可能なデータだけにアクセスできます。匿名モードでは、LDAP BIND 操作は実行されません。また、セキュリティーの問題も考慮する必要があります。ディレクトリの特定部分に匿名アクセスを許可する場合、そのディレクトリへのアクセス権を保持するすべてのユーザーが読み取りアクセスを保持することになります。資格レベルとして anonymous を使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。

注意 – 注意 –

匿名でのディレクトリへの書き込みは、決して許可してはなりません。この書き込みを許可すると、どのユーザーでも書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) を変更することが可能になります。

注 –

Sun Java System Directory Server を使用すると、IP アドレス、DNS 名、認証方式、および時刻に基づいてアクセスを制限できます。さらに指定を加えて、アクセスを制限することもできます。詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』のアクセス権の管理に関する章を参照してください。

プロキシ (Proxy)

クライアントは、単一のプロキシアカウントを使用して、ディレクトリへの認証またはバインドを行います。このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、LDAP サーバー上でネームサービス機能を実行するのに十分のアクセス権を必要とします。プロキシアカウントは、システムごとに共有されるリソースです。つまり、root ユーザーを含む、プロキシアクセスを使ってシステムにログインした各ユーザーには、そのシステム内のほかのすべてのユーザーと同じ結果が表示されます。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を構成する必要があります。暗号化された proxyPassword はローカルのクライアントに格納されます。別のクライアントグループに対しては別のプロキシを設定できます。たとえば全営業クライアント用のプロキシを構成する場合、企業全体からアクセス可能なディレクトリと営業ディレクトリの両方へのアクセスを許可しつつ、給与情報を保持する人事ディレクトリへのアクセスを許可しない、という方法が可能です。最も極端な例として、各クライアントに別個のプロキシを割り当てることや、すべてのクライアントに同じプロキシを割り当てることも可能です。一般的な LDAP 配備はこの両極端の中間に位置します。選択は慎重に行なってください。プロキシエージェントが不足していると、リソースへのユーザーアクセスを制御する能力が制限されます。ただし、プロキシが多過ぎる場合、システムの設定および保守が困難になります。適切な権限をプロキシユーザーに付与する必要がありますが、その程度は環境によって異なります。使用する構成に最適の認証方式を決定するための情報については、「資格の保存」を参照してください。

プロキシユーザーのパスワードを変更した場合、そのプロキシユーザーを使用するすべてのクライアントで情報を更新する必要があります。LDAP アカウントのパスワード有効期間を設定する場合、プロキシユーザーに関してはこの設定を解除してください。

注 –

プロキシ資格レベルは、指定されたシステムのすべてのユーザーおよびプロセスに適用されます。2 人のユーザーが異なるネーミングポリシーを使用する場合は、別個のマシンを使用するか、ユーザー別の認証モデルを使用する必要があります。

また、クライアントが認証にプロキシ資格を使用する場合、proxyDN はすべてのサーバーで同じ proxyPassword を保持する必要があります。

匿名プロキシ(proxy anonymous)

匿名プロキシは複数値のエントリで、複数の資格レベルが内部に定義されています。匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウト、パスワードの有効期限切れなどの何らかの理由でクライアントがプロキシユーザーとしての認証ができなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成に応じて、別のサービスレベルに移行する可能性があります。

ユーザー別 (Per User)

ユーザー別 (self) の認証では、ディレクトリサーバーの認証時に Kerberos 識別情報 (主体) を使用して各ユーザーまたは各システムの検索が実行されます。ユーザー別の認証では、システム管理者は、アクセス制御情報 (ACI)、アクセス制御リスト (ACL)、役割、グループ、またはその他のディレクトリアクセス制御機構を使用して、特定のユーザーまたはシステムの特定のネームサービスデータへのアクセスを許可または拒否できます。

注 –

ユーザー別のモードを設定する場合は、このモードを表す設定値「self」を使用します。

ユーザー別の認証モデルを使用するには、Kerberos シングルサインオンサービスを配備する必要があります。また、配備に使用する 1 つ以上のディレクトリサーバーで SASL および SASL/GSSAPI 認証機構をサポートする必要があります。Kerberos では、ホスト名の検索に LDAP ではなく、ファイルおよび DNS を使用することを前提としているため、この環境には DNS を配備するようにしてください。また、ユーザー別の認証を使用するには、nscd を有効にする必要があります。この構成では、nscd デーモンはオプションの構成要素ではありません。

enableShadowUpdate スイッチ

Solaris 10 10/09 リリース以降では、クライアントで enableShadowUpdate スイッチが true に設定されている場合、管理者資格がシャドウデータの更新に使用されます。シャドウデータは、ディレクトリサーバーの shadowAccount オブジェクトクラスに格納されます。管理者資格は、「ローカルのクライアント属性」で説明しているように、adminDN および adminPassword 属性の値によって定義されます。これらの管理者資格は、それ以外の目的には使用されません。

管理者資格のプロパティーは Proxy 資格のプロパティと類似しています。管理者資格の場合、シャドウデータを読み取ったり更新するには、ユーザーはゾーンのすべての特権を持つか、root の有効な UID を持っている必要があるという例外があります。管理者資格は、ディレクトリへのバインドが許可されるエントリに割り当てることができます。ただし、LDAP サーバーのディレクトリマネージャー識別情報 (cn=Directory Manager) には同じものを使用しないでください。

管理者資格が設定されたこのエントリは、ディレクトリ内のシャドウデータに対する十分な読み取りおよび書き込みアクセスを持っている必要があります。エントリはシステムごとに共有されるリソースであるため、adminDN および adminPassword 属性はクライアントごとに構成する必要があります。暗号化された adminPassword はローカルのクライアントに格納されます。パスワードには、クライアント用に構成された認証方式と同じ方式が使用されます。管理者資格は、シャドウデータの読み取りと更新を行うために、特定のシステムのすべてのユーザーおよびプロセスによって使用されます。

資格の保存

プロキシ識別情報を使用するようクライアントを設定する場合、クライアントは proxyDN および proxyPassword を /var/ldap/ldap_client_cred 内に保存します。セキュリティー保護のため、このファイルへのアクセスは root のみに許可され、proxyPassword の値は暗号化されます。過去の LDAP 実装ではプロキシ資格はクライアントのプロファイル内に格納されましたが、Solaris 9 LDAP ネームサービスではこれは行われません。初期化時に ldapclient を使用して設定されたプロキシ資格は、すべてローカルに保存されます。このため、プロキシの DN およびパスワード情報に関するセキュリティーが向上します。クライアントプロファイルの設定方法の詳細については、第 12 章LDAP クライアントの設定 (手順)を参照してください。

同様に、シャドウデータの更新が有効になるようにクライアントを構成し、クライアント資格レベルが self ではない場合、クライアントは adminDN および adminPassword 属性を /var/ldap/ldap_client_cred ファイルに保存します。adminPassword の値も暗号化され、ldap_cachemgr デーモンプロセスによってのみ使用されます。

ユーザー別の認証を使用するようクライアントを構成している場合、認証時に各主体 (各ユーザーまたはホスト) 用の Kerberos 識別情報および Kerberos チケット情報が使用されます。この環境では、ディレクトリサーバーは Kerberos 主体を DN にマッピングします。この DN の認証には、Kerberos 資格が使用されます。次に、ディレクトリサーバーは、必要に応じアクセス制御情報 (ACI) 機構を使用して、ネームサービスデータへのアクセスを許可または拒否します。この状況では、ディレクトリサーバーの認証に Kerberos チケット情報が使用されます。システムが、認証 DN またはパスワードをシステムに保存することはありません。したがって、この種類の構成では、クライアントを ldapclient コマンドを使用して初期化するときに、adminDN および adminPassword 属性を指定する必要はありません。

認証方式の選択

プロキシ資格または匿名プロキシ資格を割り当てる場合、プロキシによるディレクトリサーバーへの認証方式も選択する必要があります。デフォルトの認証方式は none (匿名によるアクセス) です。認証方式には、関連するトランスポートセキュリティーオプションも含まれます。

認証方式には、資格レベルと同様、複数値を指定できます。たとえば、クライアントプロファイルを設定することにより、クライアントが TLS でセキュリティー保護された simple メソッドを最初に使用してバインドを試みるようにできます。これが成功しない場合、クライアントは sasl/digest-MD5 メソッドを使用してバインドを試みます。そのあと、authenticationMethod は tls:simple;sasl/digest-MD5 になります。

LDAP ネームサービスは、いくつかの Simple Authentication and Security Layer (SASL) 機構をサポートします。これらの機構を使用すると、TLS なしでセキュリティー保護されたパスワードを交換できます。ただし、これらの機構はデータの完全性や機密性を保証するものではありません。SASL の詳細については、RFC 2222 を参照してください。

次の認証機構がサポートされています。

注意 – 注意 –

Sun Java System Directory Server で digest-MD5 を使用する場合、パスワードを平文で格納する必要があります。認証方式を sasl/digest-MD5 または tls:sasl/digest-MD5 に設定する場合、プロキシユーザーのパスワードを平文で格納する必要があります。平文で格納する場合には、userPassword 属性が適切な ACI を保持するようにして読み取り不可にするよう、特に注意してください。

次の表に、さまざまな認証方式およびその特性の概要を示します。

表 9–4 認証方式

 

バインド 

通信時のパスワード 

Sun Java System Directory Server でのパスワード 

セッション 

none

いいえ 

なし 

なし 

暗号化しない 

simple

はい 

平文 

任意 

暗号化しない 

sasl/digest-MD5

はい 

暗号化 

平文 

暗号化しない 

sasl/cram-MD5

はい 

暗号化 

なし 

暗号化しない 

sasl/GSSAPI

はい 

Kerberos 

Kerberos 

暗号化 

tls:simple

はい 

暗号化 

任意 

暗号化 

tls:sasl/cram-MD5

はい 

暗号化 

なし 

暗号化 

tls:sasl/digest-MD5

はい 

暗号化 

平文 

暗号化 

認証とサービス

認証方式を特定のサービスに対して serviceAuthenticationMethod 属性に指定できます。現在この機能をサポートしているサービスを次に示します。

注 –

サービスが serviceAuthenticationMethod セットを保持しない場合、authenticationMethod 属性の値がデフォルトになります。

注 –

ユーザー別のモードでは、「pam_krb5 サービスモジュール」 (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) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

ユーザー別の認証が有効でない場合でも、pam_krb5 認証システムを使用できます。プロキシまたは匿名の資格レベルを使用してディレクトリサーバーのデータにアクセスする場合、ディレクトリデータへのアクセスをユーザーごとに制限することはできません。

匿名またはプロキシ認証方式を使用する場合は、pam_unix を使用するよりも、柔軟性の向上、より強力な認証方式、およびアカウント管理機能を備えた、pam_ldap を使用することをお勧めします。

pam_unix サービスモジュール

pam.conf(4) ファイルを変更していない場合、デフォルトで pam_unix の機能が有効になっています。

注 –

pam_unix モジュールは削除されたので、Solaris ではサポートされていません。その他のサービスモジュールによって、同等またはそれ以上の機能が提供されます。したがって、このマニュアルでは、pam_unix は pam_unix モジュールではなくその同等の機能を指します。

pam_unix と同等の機能を提供するモジュールは、次のとおりです。

pam_authtok_check(5)

pam_authtok_get(5)

pam_authtok_store(5)

pam_dhkeys(5)

pam_passwd_auth(5)

pam_unix_account(5)

pam_unix_auth(5)

pam_unix_cred(5)

pam_unix_session(5)

pam_unix は従来の UNIX 認証モデルに従い、次のように動作します。

  1. クライアントは、ネームサービスからユーザーの暗号化されたパスワードを取得します。

  2. ユーザーは、ユーザーパスワードの入力を求められます。

  3. ユーザーのパスワードが暗号化されます。

  4. クライアントは、暗号化された 2 つのパスワードを比較して、ユーザーを認証するかどうかを決定します。

pam_unix を使用する場合、次の 2 つの制限が存在します。

注 –

pam_unix は、sasl 認証方式 digest-MD5 と互換性がありません。これは、Sun Java System Directory Server では digest-MD5 を使用するためにパスワードを平文で格納する必要があるのに対し、pam_unix ではパスワードを crypt 形式で格納する必要があるためです。

注 –

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが true に設定されていると、pam_unix でアカウント管理がサポートされます。リモート LDAP ユーザーアカウントのコントロールは、passwd および shadow ファイルに定義されたローカルユーザーアカウントに適用されるコントロールと同じように適用されます。enableShadowUpdate モードでは、LDAP アカウントについてはシステムが更新を行い、パスワードの有効期限管理とアカウントのロックのために LDAP サーバー上のシャドウデータを使用します。ローカルアカウントのシャドウデータはローカルクライアントシステムに適用されるのに対して、LDAP ユーザーアカウントのシャドウデータはすべてのクライアントシステムのユーザーに適用されます。

パスワードの履歴チェックは、ローカルクライアントに対してのみサポートされ、LDAP ユーザーアカウントに対してはサポートされません。

pam_krb5 サービスモジュール

pam_krb5(5) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

pam_ldap サービスモジュール

pam_ldap を実装すると、ユーザーは pam_ldap の serviceAuthenticationMethod パラメータに定義された認証方式を使用して LDAP サーバーにバインドします (このパラメータが存在する場合)。このパラメータが存在しない場合、authenticationMethod が使用されます。

pam_ldap が、ユーザーの識別情報および指定されたパスワードでサーバーにバインドできれば、ユーザーが認証されたことになります。

注 –

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に 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 属性を読み取りません。このため、pam_unix を使用するほかのクライアントが存在しない限り、userPassword 属性の読み取りアクセス権を付与する必要はありません。また、pam_ldap は、認証方式 none をサポートしません。このため、クライアントが pam_ldap を使用できるように、serviceAuthenticationMethod または authenticationMethod 属性を定義する必要があります。詳細については、pam_ldap(5) のマニュアルページを参照してください。

注意 – 注意 –

認証方式 simple を使用する場合、第三者がネットワーク上で userPassword 属性を読み取ることができます。

「pam_ldap に対応した pam.conf ファイルの例」を参照してください。

次の表に、pam_unix、pam_ldap、および pam_krb5 の主な相違点を示します。

表 9–5 pam_unix、pam_ldap、および pam_krb5 の使用における LDAP の認証動作

 

pam_unix

pam_ldap

pam_krb5

パスワードの送信  

passwd サービス認証方式を使用します

passwd サービス認証方式を使用します

パスワードではなく、Kerberos シングルサインオンテクノロジを使用します 

新規パスワードの送信 

暗号化します 

暗号化しません (TLS を使用しない場合) 

Kerberos を使用します。パスワードはネットワークに送信されません 

新規パスワードの格納 

crypt 形式

Sun Java System Directory Server で定義されたパスワード格納スキーマ 

パスワードは Kerberos を使って管理されます 

パスワードの読み取り 

はい 

いいえ 

いいえ 

パスワード変更後の sasl/digestMD5 の互換性

ありません。パスワードは平文では格納されません。ユーザーを認証できません。

あります。デフォルトのストレージスキーマが平文 (clear) に設定されていれば、ユーザーを認証できます。

ありません。sasl/GSSAPI が使用されます。Kerberos kdc を使用して LDAP ディレクトリサーバー内のパスワードデータベースを管理する場合を除き、パスワードがネットワーク上に送信されることも、ディレクトリサーバーに保存されることもありません。

パスワードポリシーのサポート 

あります。enableShadowUpdate を true に設定する必要があります。

はい (構成されている場合)。 

pam_krb5(5)、Kerberos V5 アカウント管理モジュールを参照してください。

PAM およびパスワードの変更

パスワードを変更するには、passwd コマンドを使用します。enableShadowUpdate スイッチが true に設定されていない場合、userPassword 属性がユーザーによって書き込み可能である必要があります。enableShadowUpdate スイッチが true に設定されている場合、管理者資格で userPassword 属性を更新できる必要があります。passwd-cmd 用の serviceAuthenticationMethod が、この操作の authenticationMethod を無効にすることに留意してください。使用する認証方式によっては、現行のパスワードの暗号化解除がネットワーク上で行われる場合があります。

pam_unix の場合、UNIX crypt フォーマットを使用して新しい userPassword 属性が暗号化されタグ付けされてから、LDAP への書き込みが行われます。このため、新規パスワードは、サーバーへのバインドに使用される認証方式に関係なく、ネットワーク上で暗号化されます。詳細は、pam_authtok_store(5) のマニュアルページを参照してください。

enableShadowUpdate スイッチが true に設定されている場合、ユーザーのパスワードが変更されると、pam_unix も関連するシャドウ情報を更新します。pam_unix は、ローカルユーザーのパスワードが変更されたときに pam_unix が更新するローカル shadow ファイル内の同じ shadow フィールドを更新します。

Solaris 10 ソフトウェアリリース以降、pam_ldap ではパスワード更新がサポートされません。pam_ldap パスワード更新機能は、以前に推奨されていた pam_authtok_store と server_policy オプションによって置き換えられます。pam_authtok_store を使用すると、新しいパスワードは平文で LDAP サーバーに送信されます。このため、機密性を保つために TLS を使用する必要があります。TLSを使用しない場合、新しい userPassword が漏洩する危険性があります。Sun Java System Directory Server でタグ付けされていないパスワードを設定すると、passwordStorageScheme 属性を使用してパスワードが暗号化されます。passwordStorageScheme の詳細については、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』のユーザーアカウントの管理に関する節を参照してください。

注 –

passwordStorageScheme 属性を設定する際、次の構成上の問題を考慮する必要があります。pam_unix を使用する NIS、NIS+、またはほかのクライアントがリポジトリとして LDAP を使用する場合、passwordStorageScheme に対して crypt を実行する必要があります。また、Sun Java System Directory Server で sasl/digest-MD5 に対して pam_ldap を使用する場合、passwordStorageScheme を平文に設定する必要があります。

アカウント管理

アカウントおよびパスワードの管理システムとして pam_krb5 を選択すると、アカウント、パスワード、アカウントロックアウト、およびアカウント管理のその他の詳細情報がすべて Kerberos 環境により管理されます。pam_krb5(5) および『Solaris のシステム管理 (セキュリティサービス)』を参照してください。

pam_krb5 を使用しない場合は、LDAP ネームサービスを構成して、Sun Java System Directory Server のパスワードおよびアカウントロックアウトポリシーのサポートを活用できます。pam_ldap(5) を構成して、ユーザーアカウント管理をサポートすることが可能です。passwd(1) を正しい PAM 構成で使用すると、Sun Java System Directory Server パスワードポリシーによるパスワードの構文規則が適用されます。

次のアカウント管理機能が、pam_ldap(5) でサポートされます。 これらの機能は、Sun Java System Directory Server のパスワードとアカウントのロックアウトポリシー構成を利用しています。必要な機能を必要な数だけ利用できます。

注 –

以上のアカウント管理機能は、Sun Java System Directory Server だけで有効です。サーバー上のパスワードとアカウントのロックアウトポリシーの構成についての詳細は、ご使用のバージョンの Sun Java System Directory Server の『管理者ガイド』の「ユーザーアカウントの管理」の章を参照してください。「アカウント管理のために pam_ldap を構成した pam.conf ファイル例」も参照してください。proxy アカウントでは、アカウント管理を有効にしないでください。

Sun Java System Directory Server 上でパスワードとアカウントのロックアウトポリシーを構成する前に、すべてのホスト上で pam_ldap アカウント管理に基づいた「最新の」 LDAP クライアントが使われていることを確認します。

さらに、クライアントが正しい構成の pam.conf(4) ファイルを保持していることを確認します。正しい構成ファイルを保持していない場合、 LDAP ネームサービスは proxy やユーザーパスワードが期限切れの時に動作しません。

注 –

以前は、pam_ldap アカウント管理を有効にすると、システムにログインする際には、常にすべてのユーザーが認証用にログインパスワードを入力する必要がありました。そのため、rsh、rlogin、ssh などのツールによるパスワードを使用しないログインは失敗します。

一方、pam_ldap(5) を Sun Java System Directory Server DS5.2p4 以降のリリースで使用することで、ユーザーはパスワードを入力せずに、rsh、rlogin、rcp、および ssh を使ってログインできるようになりました。

pam_ldap(5) は変更され、ユーザーのログイン時に 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_unix を使用したアカウント管理

Solaris 10 10/09 リリース以降では、enableShadowUpdate スイッチが使用できます。enableShadowUpdate を true に設定すると、LDAP はアカウント管理のファイルネームサービスと同じ機能を提供します。

クライアントで enableShadowUpdate スイッチが true に設定されている場合、ローカルアカウントで使用可能なアカウント管理機能が LDAP アカウントでも使用できます。この機能には、パスワードの有効期限管理、アカウントの有効期限管理および通知、ログインに失敗したアカウントのロックなどが含まれます。また、passwd コマンドの -dluNfnwx オプションが LDAP でサポートされるようになりました。これにより、passwd コマンドの完全な機能と、ファイルネームサービスの pam_unix* モジュールが LDAP ネームサービスでサポートされます。enableShadowUpdate スイッチは、ファイルと LDAP スコープの両方に定義されたユーザーに対して一貫したアカウント管理を実装する 1 つの方法を提供します。

ユーザーが自身のアカウント管理データを変更するのを防ぐため、また、パスワードポリシーを回避するために、LDAP サーバーは、サーバー上にあるユーザー自身のシャドウデータに対するユーザーの書き込みアクセスを防止するように構成されています。管理者資格を持つ管理者は、クライアントシステムに対してシャドウデータの更新を実行します。しかし、この構成は、ユーザーによるパスワードの変更が必要な pam_ldap モジュールと競合してしまいます。したがって、pam_ldap と pam_unix によるアカウント管理には互換性がありません。

注意 – 注意 –

同じ LDAP ネームドメインで pam_ldap と pam_unix の両方を使用しないでください。すべてのクライアントが pam_ldap を使用するか、またはすべてのクライアントが pam_unix を使用します。この制限により、専用の LDAP サーバーが必要になる場合があります。たとえば、Web または電子メールアプリケーションでは、ユーザーが LDAP サーバー上にあるパスワードを変更する必要がある場合があります。

また、enableShadowUpdate の実装では、管理者資格 (adminDN と adminPassword ) が、各クライアント上にローカルで格納されている必要があります。adminPassword は暗号化されており、ldap_cachemgr デーモンによって /var/ldap/ldap_client_cred ファイルからのみ読み取りが可能ですが、管理者資格を保護するために細心の注意が必要です。管理者資格を保護するために、サーバーのディレクトリマネージャー (cn=directory manager) とは異なる情報を使用してください。別の保護方法としては、serviceAuthenticationMethod を構成する際に、passwd-cmd サービスに対して tls:simple またはより保護されたレベルを使用します。このようにすることで、adminPassword の値が平文で送信されず、漏洩に対して脆弱になりません。

pam_ldap をアカウント管理に対して使用するのとは異なり、pam_unix をアカウント管理に対して使用する場合は、/etc/pam.conf ファイルの変更は必要ありません。デフォルトの /etc/pam.conf ファイルで十分です。