Red Hat Training
A Red Hat training course is available for Red Hat Directory Server
第10章 ディレクトリー設計の例
ディレクトリーサービスの設計は、企業のサイズと性質によって異なります。本章では、さまざまな設定内でディレクトリーを適用する方法のいくつかの例を紹介します。これらの例は、リアルタイムのディレクトリーサービスのデプロイメント計画を開発するためのスタート地点です。
10.1. 設計例： ローカルエンタープライズ
The Corp. example Corp. an automobile parts manufacturer, is a small company that consist of 500 employees.Example Corp. は、自社で使用するディレクトリー対応アプリケーションをサポートするために、Red Hat Directory Server のデプロイを決定しました。
10.1.1. ローカルエンタープライズデータ設計
Corp の例。最初にディレクトリーに保存するデータのタイプを決定します。これを行うには、Example Corp. がサイトサーベイを実行し、ディレクトリーの使用方法を決定するデプロイメントチームを作成します。デプロイメントチームは以下を決定します。
- Corp. のディレクトリーの例は、メッセージングサーバー、Web サーバー、カレンダーサーバー、人的リソースアプリケーション、およびホワイトページアプリケーションによって使用されます。
- メッセージングサーバーは、
uid、mailServerName、およびmailAddressなどの属性に対して正確な検索を実行します。データベースのパフォーマンスを改善するために、Example Corp. は、メッセージングサーバーによる検索をサポートするため、これらの属性のインデックスを維持します。インデックスの使用に関する詳細は、「データベースパフォーマンスを改善するためのインデックスの使用」 を参照してください。 - ホワイトページアプリケーションは、ユーザー名と電話番号を頻繁に検索します。したがって、ディレクトリーは、大量の結果を返す、サブ文字列、ワイルドカード、およびファジーな検索を頻繁に行える必要があります。Example Corp. は、
cn、sn、およびgivenName属性のプレゼンス、等価性、概算、およびサブストリングインデックスと、telephoneNumber属性のプレゼンス、等価性、およびサブストリングインデックスを維持することを決定します。 - Corp. のディレクトリーの例では、ユーザーおよびグループの情報を維持し、組織全体でデプロイされた LDAP サーバーベースのイントラネットをサポートします。ほとんどの Example Corp. のユーザーおよびグループ情報は、ディレクトリー管理者のグループにより集中管理されます。ただし、Example Corp. では、メール管理者の別のグループで電子メール情報を管理するようにします。
- S/MIME メールなど、公開鍵インフラストラクチャー(PKI)アプリケーションをサポートする Corp. 計画の例。そのため、ディレクトリーにユーザーの公開鍵証明書を保存する準備が必要になります。
10.1.2. ローカルエンタープライズスキーマの設計
例 : Corp.'s デプロイメントチームは、inetOrgPerson オブジェクトクラスを使用してディレクトリー内のエントリーを表します。このオブジェクトクラスは、Example Corp. のディレクトリーでサポートされるアプリケーションが必要とする
userCertificate 属性と uid (userID)属性が許可されるため、アプリケーションは機能しません。
Example Corp. は、デフォルトのディレクトリースキーマをカスタマイズしたいとも考えています。例 Corp. は、examplePerson オブジェクトクラスを作成して Example Corp の従業員を表します。このオブジェクトクラスは、inetOrgPerson オブジェクトクラスから派生したものです。
examplePerson オブジェクトクラスでは、1 つの属性 (
exampleID 属性) が許可されます。この属性には、Example Corp. の各従業員に割り当てられた特別な従業員番号が含まれています。
今後、Example Corp. は必要に応じて examplePerson オブジェクトクラスに新しい属性を追加できます。
10.1.3. ローカルエンタープライズのディレクトリーツリー設計
前述のセクションで説明されているデータおよびスキーマ設計に基づいて、Example Corp. は以下のディレクトリーツリーを作成します。
- ディレクトリーツリーの root は、Example Corp. のインターネットドメイン名である
dc=example,dc=comです。 - ディレクトリーツリーには、
ou=people、ou=groups、ou=roles,およびou=resourcesの 4 つのブランチポイントがあります。 - Example Corp. の人のエントリーはすべて
ou=peopleブランチの下に作成されます。人のエントリーはすべて、person、organizationalPerson、inetOrgPerson、および examplePerson オブジェクトクラスのメンバーになります。uid属性は、各エントリーの DN を一意に識別します。たとえば、Example Corp. には Babs Jensen (uid=bjensen)) および Emily Stanton (uid=estanton) のエントリーが含まれます。 - これらは、Example Corp. の営業、マーケティング、会計の各部門に 1 つずつ、3 つのロールを作成します。人のエントリーにはそれぞれ、その人が所属する部門を識別するロール属性が含まれます。Example Corp. は、これらのロールに基づいて、ACI を作成できるようになりました。ロールの詳細は、「ロールの概要」 を参照してください。
ou=groupsブランチの下に、2 つのグループブランチを作成します。最初のグループcn=administratorsには、ディレクトリーの内容を管理するディレクトリー管理者のエントリーが含まれています。2 つ目のグループcn=messaging adminには、メールアカウントを管理するメール管理者のエントリーが含まれています。このグループは、メッセージングサーバーによって使用される管理者グループに対応します。Example Corp. は、メッセージングサーバーに設定するグループが、Directory Server 用に作成するグループとは異なるようにします。ou=resourcesブランチの下に、会議室用 (ou=conference rooms) とオフィス用 (ou=offices) の 2 つのブランチを作成します。- これらは、エントリーが管理グループに属するかどうかに応じて
mailquota属性の値を提供する サービスクラス (CoS) を作成します。この CoS では、管理者には 100GB のメールクォータが与えられ、一般の Example Corp. の従業員には 5GB のメールクォータが与えられます。サービスクラスの詳細は、「サービスクラスについて」 を参照してください。
以下の図は、上記の設計手順から得られるディレクトリーツリーを示しています。
図10.1 Example Corp. のディレクトリーツリー
10.1.4. ローカルエンタープライズのトポロジー設計
この時点で、Example Corp. は、自社のデータベースおよびサーバートポロジーを設計する必要があります。以下のセクションでは、各トポロジーの詳細を説明します。
10.1.4.1. データベーストポロジー
会社は、人のブランチがデータベース(DB1)に格納され、グループブランチが別のデータベース(DB2)に格納され、リソースブランチ、ロールブランチおよび
root suffix 情報は 3 番目のデータベース(DB3)に保存されます。これは 図10.2「Example Corp. のデータベーストポロジー」 で説明されています。
図10.2 Example Corp. のデータベーストポロジー
2 つのサプライヤーサーバーは、それぞれ Directory Server の Example Corp. の 3 つのコンシューマーサーバーをすべて更新します。これらのコンシューマーは、1 つのメッセージングサーバーおよび他の統一されたユーザー管理製品にデータを提供します。
図10.3 Example Corp. のサーバートポロジー
互換性のあるサーバーからの Modify リクエストは、適切なコンシューマーサーバーにルーティングされます。コンシューマーサーバーは、スマート参照を使用して、変更されるデータのマスターコピーを担当するサプライヤーサーバーへのリクエストをルーティングします。
10.1.5. ローカルエンタープライズレプリケーション設計
Example Corp. は、ディレクトリーデータの高可用性を確保するために、マルチマスターのレプリケーション設計を使用することを決定します。マルチマスターレプリケーションの詳細は、「マルチマスターレプリケーション」 を参照してください。
次のセクションでは、サプライヤーサーバーアーキテクチャーおよびサプライヤーコンシューマーサーバートポロジーの詳細を説明します。
10.1.5.1. サプライヤーアーキテクチャー
Example Corp. は、マルチマスターのレプリケーションアーキテクチャーで 2 つのサプライヤーサーバーを使用します。サプライヤーが相互に更新することで、ディレクトリーデータの整合性が保たれます。Example Corp. のサプライヤーアーキテクチャーを以下に説明しています。
図10.4 Example Corp. のサプライヤーアーキテクチャー
10.1.5.2. サプライヤーコンシューマーアーキテクチャー
以下の図は、Example Corp. のディレクトリーのデプロイメントで、サプライヤーサーバーが各コンシューマーに複製する方法を示しています。3 つのコンシューマーサーバーが、それぞれ 2 つのサプライヤーサーバーで更新されます。これにより、サプライヤーサーバーの 1 つに障害が発生しても、コンシューマーは影響を受けなくなります。
図10.5 Example Corp. のサプライヤーとコンシューマーアーキテクチャー
10.1.6. ローカルの企業セキュリティー設計
Example Corp. は以下のセキュリティー設計を決定して、ディレクトリーデータを保護します。
- 従業員が独自のエントリーを変更できるようにする ACI を作成します。ユーザーは、
uid属性、manager属性、およびdepartment属性以外のすべての属性を変更できます。 - 従業員データのプライバシーを保護するために、従業員とそのマネージャーのみが従業員の自宅住所と電話番号を閲覧できる ACI を作成します。
- 2 つの管理者グループに適切なディレクトリー権限を与える ACI をディレクトリーツリーの root に作成します。ディレクトリー管理者グループは、ディレクトリーへのフルアクセスが必要です。メッセージング管理者グループは、mailRecipient および mailGroup オブジェクトクラスと、
mail属性に含まれる属性への書き込みと削除が必要です。Example Corp. は、メッセージング管理者グループwrite、delete、およびaddに、メールグループを作成するためのグループサブディレクトリーへのパーミッションも付与します。 - これらは、ディレクトリーツリーの root で一般的な ACI を作成します。これにより、匿名アクセスを読み取り、検索、および比較できます。この ACI は、パスワード情報への匿名書き込みアクセスを拒否します。
- サーバーをサービス拒否攻撃から保護し、不適切な使用から保護するために、ディレクトリークライアントがバインドする
DNに基づいてリソース制限を設定します。例： Corp. 匿名ユーザーは、検索要求、メッセージング管理者ユーザーが 1,000 エントリーを受け取るためのメッセージ管理ユーザー、およびディレクトリー管理者がエントリーを無制限に受信できるように、一度に 100 エントリーを受け取ることができます。バインド DN に基づいてリソース制限を設定する方法の詳細は、『『Red Hat Directory Server Administrator's Guide』』の「User Account Management」の章を参照してください。 - このパスワードポリシーでは、パスワードは 8 文字以上である必要があり、90 日後に有効期限切れにする必要があります。パスワードポリシーの詳細は、「パスワードポリシーの設計」 を参照してください。
- これらは、アカウンティングロールのメンバーにすべての費用のロールアクセスを付与する ACI を作成します。
10.1.7. ローカルエンタープライズのチューニングと最適化
会社は、以下の tactics を使用して Directory Server のデプロイメントを最適化します。
- dsktune ユーティリティーを実行します。dsktune ユーティリティーは、システムのパッチレベルとカーネルパラメーター設定を簡単にチェックできる、信頼性のある方法を提供します。dsktune の詳細は、『『Red Hat Directory Server インストールガイド』』を参照してください。
- エントリーおよびデータベースキャッシュの最適化Example Corp. はエントリーキャッシュサイズを 2GB に設定し、データベースキャッシュを 250MB に設定し、すべてのインデックスが RAM に適合し、サーバーのパフォーマンスを最適化するようにします。
10.1.8. ローカルエンタープライズ操作の決定
会社は、そのディレクトリーの日常の操作について以下の決定を行います。
- 毎晩、データベースをバックアップします。
- SNMP を使用してサーバーの状態を監視します。SNMP の詳細は、『『Red Hat Directory Server Administrator's Guide』』を参照してください。
- アクセスログとエラーログを自動でローテーションします。
- エラーログを監視し、サーバーが想定どおりに実行されていることを確認します。
- アクセスログを監視して、インデックスを作成すべき検索を選別します。
アクセス、エラー、および監査ログの詳細は、『『Red Hat Directory Server Administrator's Guide』』の「Monitoring Server and Database Activity」の章を参照してください。
