リファレンス ガイド › ユーティリティ › サービスおよびデーモンの詳細 › CA Access Control Policy Model サービス（sepmdd）

CA Access Control Policy Model サービス（sepmdd）

Windows で有効

CA Access Control Policy Model サービス（sepmdd）は PMDB サービスです。 sepmdd は以下の機能を実行します。

• Policy Model の CA Access Control データベースおよび Windows データベースの管理
• サブスクライバのデータベースの管理
• PMDB からサブスクライバ データベースへの変更の伝達

sepmdd サービスは、SeOSAgent によって開始されます。 sepmdd を明示的に実行する必要はありません。 各 Policy Model は、起動済みまたは停止済みのいずれかの状態です。

PMDB は共通ディレクトリに格納されます。 HKLM¥Software¥ComputerAssociates¥AccessControl¥Pmd サブキーのレジストリ値 _pmd_directory_ で、共通ディレクトリの名前を指定します。 各 Policy Model は、共通ディレクトリ内の別々のサブディレクトリに格納されます。 Policy Model の名前は、Policy Model が格納されているサブディレクトリの名前と同じです。

sepmdd の起動時、更新の必要があるサブスクライバ データベースの有無が確認され、必要に応じてサブスクライバ データベースが更新されます。 このスタートアップ プロセスの後、sepmdd サービスはユーザからの要求を待機します。 ユーザからの要求は、Policy Model 管理ユーティリティの sepmd によって送信されるか、または CA Access Control Agent を使用して selang によって送信されます。

sepmdd は、受け取った要求を PMDB に適用し、ユーザに結果を返します。 要求を伝達する必要がある場合は、サブスクライバ データベースに更新情報を伝達します。

sepmdd サービスは、サブスクライバ データベースの更新を 30 秒間試みます。 30 秒が経過してもサブスクライバを更新できない場合、sepmdd サービスはその特定のサブスクライバの更新処理を省略し、リストに含まれている他のサブスクライバの更新を試みます。 sepmdd は、サブスクライバ リストの 1 回目のスキャンが終了した後、2 回目のスキャンを実行します。2 回目のスキャンでは、1 回目のスキャンで更新できなかったサブスクライバの更新を試みます。 2 回目のスキャンでは、接続システム コールがタイムアウトになるまで（約 90 秒間）サブスクライバの更新を試みます。

2 回目のスキャン時にもサブスクライバを更新できない場合、sepmdd は 30 分間隔で更新情報の送信を試みます。

更新情報は受信したときと同じ順序で送信する必要があるため、sepmdd はサブスクライバ データベースが使用可能になるまで、その後の更新情報を送信しません。

sepmdd がサブスクライバ データベースの更新に失敗するたびに、Policy Model のエラー ログに警告メッセージが書き込まれます。

フィルタ メカニズム

PMDB では、次のように特定のサブスクライバ端末を選択して更新することができます。 サブスクライバ端末に送信するレコードを定義するには、次のレジストリ キーの文字列値をフィルタ ファイルに指定します。 このように設定すると、フィルタ ファイルを通過したレコードのみが更新情報としてサブスクライバ端末に送信されます。

以下に例を示します。

HKEY_LOCAL_MACHINE¥Software¥ComputerAssociates¥AccessControl¥Pmd¥PolicyModelName¥Filter

フィルタ ファイルは、各行に 6 つのフィールドを持つ複数の行で構成されます。 フィールドには以下の情報が格納されます。

許可または禁止されるアクセスの種類

有効な値は、AUTHORIZE_DELETE、AUTHORIZE_MODIFY、CREATE、DELETE、DEPLOY、EDIT、FILESCAN、GET、SEOS_ACCS_READ、JOIN_DELETE、JOIN_MODIFY、MODIFY、READ、START、または UNDEPLOY です。

影響を受ける環境

有効な値は、AC、CONFIG、UNIX、NT、または NATIVE です。

レコードのクラス

有効な値は、ユーザ定義クラスを含む CA Access Control のすべてのクラスです。

ルールが適用されるクラスのオブジェクト

たとえば、User1、AuditGroup、または COM2 になります。

レコードによって許可または取り消されるプロパティ

たとえば、ユーザ レコードのフィルタ行の GROUPS および FULLNAME は、これらのユーザ プロパティを持つコマンドはすべてフィルタ処理されることを意味します。 各プロパティを正確に入力する必要があります。

該当するレコードをサブスクライバ端末に転送するかどうか

有効な値は、PASS、NOPASS です。

注： どのフィールドでも、アスタリスクを使用して「可能なすべての値」を指定することができます。 同じレコードが複数の行に該当する場合は、最初の該当する行が使用されます。

フィルタ ファイルの各行では、フィールドをスペースで区切ります。 フィールドに複数の値がある場合は、値をセミコロンで区切ります。 「#」で始まる行はコメント行とみなされます。 空白行は使用できません。 フィルタ ファイルの行の例を次に示します。

たとえば、上のような行を持つ Printer1_Filter.flt というファイルがあり、レジストリ キー HKEY_LOCAL_MACHINE¥Software¥ComputerAssociates¥AccessControl¥Pmd¥PM‑¥Filter に C:¥Program Files¥CA¥AccessControl ¥data¥Printer1_Filter.flt という行が含まれる場合、Policy Model PM‑1 は FULLNAME および OBJ_TYPE（管理者、監査担当者など）を持つ新しいユーザを作成するレコードを送信しません。 アスタリスクは「すべての名前」を意味します。

各アクセス値に関連する selang のコマンドを次に示します。

注： CA Access Control はルールを検証しません。したがって、ルールに無効な値を入力すると、そのルールは更新トランザクションと一致しなくなります。

レジストリ サブキー

各 PMDB では、以下の独自のレジストリ サブキーが使用されます。

HKEY_LOCAL_MACHINE¥Software¥ComputerAssociates¥AccessControl¥Pmd

このサブキーには、PMDB のアクティビティを定義および決定する値が含まれています。 サブキーが存在しない場合は、sepmdd ユーティリティによって必要最低限のエントリを持つサブキーが作成されます。

Notes

• selang を使用して（hosts pmd@hostname で）ターゲットとして Policy Model を選択した場合、sepmdd に対するクエリは PMDB に適用されますが、さまざまなサブスクライバ データベースには適用されません。
• PMDB がそれ自体のサブスクライバではないことを確認します。 PMDB がそれ自体にサブスクライブされた場合、Policy Model が遮断されるか、ネットワークの負荷が大きくなり、ディスク領域が消費されます。
• UNIX 環境で selang を使用して Policy Model を更新する場合、newusr コマンドに複数のユーザを指定できません。
• UNIX 環境で selang を使用して Policy Model を更新する場合、newgrp コマンドに複数のグループを指定できません。
• selang から UNIX ファイル属性を更新すると、Policy Model はコマンドがサブスクライバに送信されたことを示すメッセージを生成します。
• Policy Model を操作する場合、Windows ファイル属性のステータスのクエリは実行できません。
• sepmdd サービスは、-k オプションを使用して非アクティブ化されるまで、無限にアクティブな状態を維持します。

詳細情報：

seagent デーモン

sepmd ユーティリティ

sepmdadm ユーティリティ - PMDB 定義の作成