この章では、前述したカテゴリのいずれにも分類されない、Oracle Access Managerアプリケーションの様々なカスタマイズ方法について説明します。
この章の内容は次のとおりです。
アイデンティティ・システムでは、自己登録ワークフローをサポートしています。ユーザー・マネージャ・アプリケーションの場合のみ、このワークフローを使用して自動ログイン機能を提供できます。この機能を拡張して、ワークフローのユーザーが自己登録直後にチャレンジなしで追加のリソースにアクセスすることを許可できます。また、Oracle Access Managerリソースに対して、自己登録後にこれらのユーザーを自動的に認証することもできます。この項では、これを達成するために必要な手順を示します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、少なくとも1つのアクセス・ゲートを追加します。
追加するアクセス・ゲートの「アクセス管理サービス」オプションが、trueに設定されている必要があります。Oracle Access Managerへのアクセスを制御するためには、少なくとも1つのアクセス・ゲートが作成され、構成されている必要があります。このアクセス・ゲートは、この目的でのみ追加するものです。
『Oracle Access Managerアクセス管理ガイド』の説明に従って、アクセス・ゲートを構成します。
Identity_install_dir
/identity/AccessServerSDK/oblix/tools directory
からconfigureAccessGateプログラムを実行して、アクセス・ゲートを構成します。自動ログイン要件を満たすために特別な構成データを指定する必要はありません。
Identity_install_dirは、アイデンティティ・システムがインストールされているディレクトリです。
特定のアイデンティティ・システム・パラメータ・ファイルを使用して、自動ログインを有効化します。
Identity_install_dir/identity/oblix/data/common/basedbparams.xmlファイル内で、表5-1で定義されているとおりに特定のパラメータ値を設定する必要があります。ユーザーが自己登録の直後に移動するページのURLとアクセス・メソッドを知っている必要があります。
表5-1 自動ログインのパラメータ
パラメータ名 | 値 |
---|---|
true |
|
次のページへのアクセス・メソッド |
|
false |
|
true |
|
次のページの場所 |
|
有効なドメイン名(例: example.com) |
|
次のページの場所 |
次に、前述の変更を行った後のこのファイルの内容の例を示します。
<?xml version="1.0"?> <ParamsCtlg xmlns="http://www.oblix.com" CtlgName="basedbparams"> <CompoundList ListName=""> <SimpleList> <NameValPair ParamName="default_policy" Value="false"/> <NameValPair ParamName="doAccessServerFlush" Value="false"/> <NameValPair ParamName="SelfRegGeneratesSSOCookie" Value="true"/> <NameValPair ParamName="SR_SSOCookieMethod" Value="GET"/> <NameValPair ParamName="enableAllowAccessCache" Value="true"/> <NameValPair ParamName="SR_SSOCookieURL" Value="/identity/oblix"/> <NameValPair ParamName="SR_SSOCookieIP" Value="192.168.1.109"/> <NameValPair ParamName="SR_SSOCookiePath" Value="/"/> <NameValPair ParamName="SR_SSOCookieDomain" Value="example.com"/> </SimpleList> </CompoundList> </ParamsCtlg>
<?xml version="1.0"?> <ParamsCtlg xmlns="http://www.oblix.com" CtlgName="basedbparams"> <CompoundList ListName=""> <SimpleList> <NameValPair ParamName="default_policy" Value="false"/> <NameValPair ParamName="doAccessServerFlush" Value="false"/> <NameValPair ParamName="SelfRegGeneratesSSOCookie" Value="true"/> <NameValPair ParamName="SR_SSOCookieMethod" Value="GET"/> <NameValPair ParamName="enableAllowAccessCache" Value="true"/> <NameValPair ParamName="SR_SSOCookieURL" Value="/identity/oblix"/> <NameValPair ParamName="SR_SSOCookieIP" Value="192.168.1.109"/> <NameValPair ParamName="SR_SSOCookiePath" Value="/"/> <NameValPair ParamName="SR_SSOCookieDomain" Value="example.com"/> </SimpleList> </CompoundList> </ParamsCtlg>
アイデンティティ・サーバーのbasedbparams.xmlファイル内のSR_CookieURLパラメータに指定されたURLを、アクセス・システムの「Basic Over LDAP」スキームを使用して保護します。
これ以外のタイプの認証スキームを使用した場合、ユーザーに対してObSSOCookieは作成されず、自動ログインは失敗します。
アイデンティティ・サーバーを停止してから再起動します。
この手順は、後でも構いませんが、パラメータ・ファイルの新しい内容をロードするために必ず必要になります。
アクセス・システム・パラメータ・カタログを使用して、自動ログインを受け入れるようにWebGateを構成します。
WebGateの「アクセス・システム構成」ページで、次のいずれかを実行します。
「IPValidation」フィールドをfalseに設定します。
「IPValidation」をtrueに設定し、「IPValidationException」リストに、IPアドレスに使用されていた値(SR_SSOCookieIP)を入力します。
詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。「IPValidationException」フィールドは、IPアドレス検証から除外されるIPアドレスのリストです。このフィールドは、プロキシによって設定されているIPアドレスを除外するためによく使用されます。「IPValidation」は普遍的に適用されるパラメータですが、IPの検証が必要になる場合もあるため、多くの場合は2番目のオプションを選択します。
変更後、WebGateに関連付けられているWebサーバーを停止してから再起動します。
この手順は、後でも構いませんが、WebGateパラメータの新しい内容をロードするために必ず必要になります。
basedbparams.xml内に指定されているURLがアクセス・システム内でポリシー・ドメインによって保護されていることを確認するには、そのURLをコピーしてアクセス・テスターに貼り付けます。URLが認識されない場合は、適切なホスト識別子を先頭に追加する必要があることがあります。たとえば、/identity/oblixというURLは保護されていなくても、//12345:99/identity/oblixというURLは保護されていることがあります。
最後に、次のようにしてユーザー・マネージャで自己登録ワークフローを構成する必要があります。
『Oracle Access Manager Administration Guide』の説明に従って、ワークフローを作成します。
ワークフローの最初のステップは、自己登録である必要があります。このステップでは、ログインとパスワードのセマンティク・タイプの属性が構成されている必要があります。パスワード属性は、自動ログインを有効にするための自己登録ステップの必須の部分です。
オプションで、外部アクションなどの非対話型ステップを追加できます。ワークフローが完了するまでユーザーはログインしていないとみなされるため、ワークフロー内に対話型ステップを含めることはできません。
最後のステップとして「有効化」を構成します。
このワークフローでは、ワークフローが正常に完了した時点で認証に使用できるSSO Cookieが生成されます。また、新しいユーザーはログインしなくてもOracle Access Managerを使用できます。
必要な場合、IdentityXMLを使用して、自動ログインの一部として生成されたCookieを自動ログイン・ページ出力から取得できます。ObSSOCookie要素の下のCookieを探し、ObValueのデータを抽出します。
該当するXML文字列の部分は次のようになります。
<ObSSOCookie> <ObDisplay obdisplayName="SSOCookie" obdisplayType="textS" obname="ObSSOCookie" obmode="view" obcanRequest="false" obrequired="false"> <ObTextS> <ObValue> ghv6XNmGZefMq8cgIte08alq477M nvaivG+tSaxHRzaOXBcfMkzmf/ UeTrKcg2jJmyo3PpNbLKS+UgmRi/ rg8Ac2LlU9a7rprYjqocs QGQEgymqELZC0VQo6KqGguv7ujrBt9JtzwQ6/ sDJFlVaLDwLs0vJbg5kop5 FASBF9ohGOwQcUtDGlVal DwktElNskHYgtjvjc9pBBGtlU9sGuYA/cTw== </ObValue> </ObTextS> </ObDisplay> </ObSSOCookie>
WebPassがWebGateによって保護されている場合、IDXMLを使用して、自分で登録が可能なユーザーに対して自己登録を設定できます。ロックアウト状況を回避するため、マスター管理者およびパスワードを失ったユーザーに対して自己登録を許可することもできます。
自己登録リクエストには、次のURLを使用します。
/identity/oblix/apps/userservcenter/bin/userservcenter.cgi?/from_prog=workflowSelfRegistration
自己登録用のURLは、通常の/identity/oblix/apps/userservcenter/bin/userservcenter.cgiではありません。
関連資料: 自己登録の詳細は、『Oracle Access Manager Administration Guide』のワークフローに関する項を参照してください。 |
「PresentationXMLを使用したGUIの設計」で説明されているように、各種のスタイルシートを変更することにより、ユーザー・インタフェースをカスタマイズできます。ユーザーが自己登録を完了すると、確認ページが表示されます。
自己登録の確認ページをカスタマイズする手順
次のファイルを開きます。
Identity_install_dir
/oblix/lang/shared/wf_selfregdone.xsl
ここで、identity_install_dirはアイデンティティ・システムがインストールされているディレクトリです。
アイデンティティ・サーバーを再起動して、変更を有効にします。
これらの変更をすべてのアイデンティティ・サーバー・インストールに適用します。
『Oracle Access Managerアクセス管理ガイド』で説明されているように、Oracle Access Managerではシングル・サインオンのログアウトURLを指定することが可能です。Oracle Access Managerは、インストール・プロセスの一部として、このログアウトURLを自動的に設定します。
/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?/from_prog=workflowSelfRegistration
ログアウトURLは、「アクセス・ゲート構成」ページの「LogOutURLs」で構成できます。
logout.htmlファイルによって、実際のログアウトを実行するJavaScriptがアクティブ化されます。ユーザーはこれを別のURLに変更できます。たとえば、ユーザーが作成したHTML、CGIまたはPERLファイルをアクティブ化するようなURLに変更できます。
ログアウト手順を実行するための別個のHTMLファイルまたはCGIファイルを作成します。このファイルの名前の一部にlogout.という文字が含まれている必要があります(例: mybanklogout.cgi)。
このファイルを、定義されている場所に格納します。/access/oblix/apps/common/bin
を使用することをお薦めします。
アクセス・システムの開始ページで、「アクセス・システム・コンソール」→「システム構成」→「SSOログアウトURLの構成」をクリックします。
デフォルトのURLを、新しいログアウト・プロセスの場所を指し示すURLで置き換えます。
アクセス・システム内で、「ポリシー・マネージャ」→「ポリシー・ドメインの作成」にナビゲートします。「匿名」認証スキームを使用して、このログアウト・リソース用に新しいポリシー・ドメインを作成します。「リソース」ページに入力する「URL接頭辞」には、ログアウト・リソース・ファイルまたはその親フォルダを含める必要があります。
アイデンティティ・システムのワークフロー機能を使用すると、ユーザーは、電子メール・メッセージを作成するための標準的なPresentationXML手法を使用して、事前通知または事後通知の電子メールをワークフロー・ステップに関連付けることができます。OutPutXMLデータ・ストリームとスタイルシートが結合されて、論理ファイルが作成されます。このファイルはメール・サーバー・キューに渡され、ここから最終的な宛先に送信されます。
アイデンティティ・システムは、次のディレクトリ内に必要なスタイルシートがあることを期待します。
Identity_install_dir
/identity/oblix/lang/langTag/style0
ここで、Identity_install_dirはアイデンティティ・システムがインストールされているディレクトリ、langTagはRFC 1766形式の言語タグです。
メール・サーバーは、テキストのみまたはHTMLのメール・スタイルを使用するように構成されています。(MHTMLメール・スタイルはカスタマイズできません。)その設定によって、デフォルトのスタイルシートの選択が決まります。メール・スタイルがテキストのみに設定されている場合、デフォルトのスタイルシートはwf_prepostnotification_txtです。メール・スタイルがHTMLに設定されている場合はwf_prepostnotification_htmlです。ワークフロー処理中にエラーが発生した場合、CORE Idは、テキストのみのメール・スタイルにはスタイルシートwf_errornotification_txtを使用し、HTMLのメール・スタイルにはwf_errornotification_htmlを使用します。
ユーザーはこの機能を拡張して、事前通知と事後通知に固有のメッセージ書式を指定し、ワークフロー内のワークフローIDとステップ番号ごとに固有のメッセージ書式を指定できます。これを行うには、ユーザーは新しいスタイルシートをディレクトリに追加します。Oracle Access Managerは最初にこれらのファイルを探し、存在する場合は、デフォルトのファイルではなくこれらのファイルを使用します。
ユーザーが追加したファイル名は、次のネーミング構造に準拠している必要があります。
WfDefId_WfStepDefId_preorpostnotify_mailtype
名前の各部分の意味は次のとおりです。
WfDefId: これは、通知を送るワークフローのIDです。これはワークフローのRDNです。このIDは、ワークフローの作成時に自動的に作成されます。このIDを取得するには、「ワークフロー定義」画面で「表示」機能を使用します。
WfStepDefId: これは、通知を送るワークフロー・ステップです。これは数字です。
preorpostnotify: これは正確なテキスト(prenotifyまたはpostnotify)です。
mailtype: これは正確なテキスト(txtまたはhtml)です。メッセージがテキストで送信されるかHTMLで送信されるかがこの接尾辞によって決まるわけではありませんので注意してください。この接尾辞は、Oracle Access Managerが適切なファイルを見つける方法として使用されるにすぎません。たとえば、メール・サーバーがテキストのみに構成されている場合、Oracle Access Managerは接尾辞がtxtのファイルを探します。この場合は、接尾辞がhtmlのスタイルシートを作成しても、Oracle Access Managerはこのスタイルシートではなくwf_prepostnotification_txtを使用します。
次にファイル名の例をいくつか示します。
次のファイルは、メール・タイプがテキストのみに設定されている場合に、ワークフロー1864aaa89df04422bfd33afcdfb45641のステップ2に対してカスタマイズ済の事前通知電子メール・メッセージを提供します。
1864aaa89df04422bfd33afcdfb45641 _2_prenotify_txt.xsl
次のファイルは、メール・タイプがHTMLに設定されている場合に、ワークフロー1864aaa89df04422bfd33afcdfb45641のステップ4に対してカスタマイズ済の事後通知電子メール・メッセージを提供します。
注意: カスタマイズ済の電子メール・スタイルシートは、style0ディレクトリに格納する必要があります。他のディレクトリをマスター・スタイル・ディレクトリとして設定した場合でも同じです。電子メール処理では、style0ディレクトリ内の電子メール・スタイルシートのみが検索されます。 |
次の3つのタイプの通知電子メールを構成できます。
事前通知
事後通知
エスカレーション通知
これらの電子メール通知の「Subject」行は、次のメッセージ・カタログ・ファイル内で設定します。
Identity_install_dir
/oblix/lang/lang/workflowdbmsg.xml
ここで、Identity_install_dirはアイデンティティ・サーバーのインストール・ディレクトリ、langは言語名(たとえば、en-us、fr-frなど)です。メッセージ・カタログ・ファイル内の次のコード部分が、電子メールの「Subject」行を変更するためにカスタマイズできる文字列です。
<Message MsgTab="WfPreNotifyMailSub" >Pre-notification of workflow step
</Message> <Message MsgTab="WfPostNotifyMailSub" >Post-notification of workflow step
</Message> <Message MsgTab="WfEscallationNotifyMailSub" >Escallation-notification of workflow step</Message>
XMLファイル内の特定の文字は、特定の場合、Oracle Access Managerによって正しく解釈されるために特殊の処理が必要となります。
XML標準の現行バージョンでは、&記号とそれに続く追加のテキストを使用して、特定の文字をエスケープすることが必要です。OutPutXMLはこの要件に準拠しています。ユーザーは、OutPutXMLから読み取るときにこれらの文字を変換するか、OutPutXMLを作成するときに対応するエスケープ値を指定する必要があります。
これらの文字および対応するエスケープ値の表を次に示します。
Oracle Access Managerアプリケーション・レベルでは、オプションで、DN属性の値を検証することにより、managerやuniquememberなどのDNタイプ属性の表示機能と変更機能を制御できます。ログイン・ユーザーが表示または変更できるDNの値は、そのユーザーが(DNのobjectclassのclass属性に対する)表示アクセス権とローカライズ・アクセス権を持っている場合のみです。つまり、このDNは、DNのobjectclassのタイプに関連してユーザーの検索ベースのカテゴリに分類されます。
このDN検証はオプションであり、パラメータ・カタログ変更を介してオンとオフを切り替えることができます。DN検証は負荷が大きい操作なので、セキュリティを非常に堅牢にする場合以外は、この検証はオフにしておくことをお薦めします。ただし、セキュリティが重要な場合は、このDN検証をオンにしてください。
パラメータは次のファイル内にあります。
Identity_install_dir
/identity/oblix/apps/common/bin/oblixappparams.xml
これらのパラメータは各アプリケーションごとに上書きできます。表示モードと変更モードそれぞれに対して2つずつパラメータがあります。表示モード用には、validateAllDnViewModeというブール・パラメータがあります。また、validateDnAttrsViewModeという名前のvallist形式のパラメータもあります。ブール・パラメータがfalseの場合、このパラメータが使用されます。
ブール・パラメータを使用すると、検証のオンとオフをグローバルに切り替えることができます。vallistは、各属性ベースで属性の検証のオン/オフを切り替えるオプションを提供するものです。このため、vallistパラメータは、ブール・パラメータがfalseの場合にのみ使用されます。
同様に、変更モードにも対応する2つのパラメータ(validateAllDnViewModeおよびvalidateDnAttrsModifyMode)があります。出荷時の製品のデフォルトでは、ブール・パラメータのみがリストされており、falseに設定されています。
注意: IdentityXMLコールについては、すべてのDNタイプ属性に対してDN検証が常にオンになっています。 |
Windows NTおよび2000のIIS Webサーバーでは、チャレンジ/レスポンス認証がサポートされています。この認証は、IISがインストールされるとデフォルトでオンに設定されます。これにより、NTユーザーは、IISのリソースをリクエストするときに自分のNTドメイン・ログインを使用できます。このため、Oracle Access Managerの認証と競合することがあります。
たとえば、Internet Explorer(IE)ブラウザから、基本認証を必要とするOracle Access Managerで保護されたIIS上のリソースに対して最初のリクエストが行われると、IEでは、Oracle Access Managerによって提供されたユーザー名とパスワードのログインとともにドメインを要求するログイン・ダイアログ・ボックスが表示されます。
IIS Microsoft Management Consoleを実行します。
左側のパネルの「Internet Information Server」から「Web Server Host」を選択します。
右クリックして「Properties」を選択します。
スクロール・ダウンし、「Edit the Master Properties for WWW Service」を選択します。
「Directory Security」タブを選択します。
「Edit Anonymous Access and Authentication Control」を選択します。
使用しているプラットフォームに適した手順を完了します。
NTの場合: 「Windows NT Challenge/Response」チェック・ボックスの選択を解除します。
Windows 2000の場合: 「Integrate Windows Authentication」チェック・ボックスの選択を解除します。
「OK」をクリックします。
「Windows IIS properties」画面で「OK」をクリックします。
Microsoft Management Consoleを閉じます。
このシナリオでは、ユーザーを認証するためのメソッドが適切に設定されているが、Oracle Access Managerの認可サービスも使用するとします。
解決方法は、このインスタンスで使用する認証スキームを追加することです。LDAPツールを使用して、このスキームのチャレンジ・メソッドを、この状況に対してアクセス・サーバーによって認識される特殊な値に変更します。また、他の認証メソッドが適用された後にOracle Access Manager認証/認可処理を行うようにWebサーバーに指示します。
注意: ここで説明する手法は、iPlanetのWeb Server 4.1およびDirectory Server 4.11にのみ適用されるもので、これらの製品でのみ動作が確認されています。 |
この解決方法の重要な点は、Oracle Access ManagerのGUIを介して提供されるチャレンジ・メソッドextを使用して認証スキームを定義することです。このスキームは、iPlanetの変数auth-userと対応しています。ここでは、認証時に既存の認証メソッドが設定されていることが期待されます。Oracle Access Managerは、検証の試行時にこの変数がすでに設定されていることを認識するため、チャレンジをブラウザに送り返さずに認可の実行を続行します。
認証のみを行うOracle Access Managerをサポートするためには、次のタスクを完了する必要があります。
タスクの概要: Oracle Access Manager認証の実装
ディレクトリ内で、すべてのユーザー・レコードに認証スキームで使用可能な属性が含まれていることを確認します。ユーザー名属性のuidはその一例です。
アクセス・システム・コンソール内で、特殊なチャレンジ・メソッドを使用する新しい認証スキームを追加します。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ディレクトリ・サーバーのobj.confファイル内で、Oracle Access Managerが使用される前に別の認証プロセスが認証結果を設定できるように、処理順序を変更します。認証チェックがすでに完了していれば、Oracle Access Managerは認可処理に進みます。
ディレクトリ内のユーザー・レコードはすべて、既存の認証メソッドの一部としてチェックされる属性のインスタンスを持ちます。これは多くの場合、ユーザー名uidになります。
認可目的のみでOracle Access Managerを使用する手順
外部認証スキームを定義します。
次に例を示します。
アクセス・システム・コンソールにログインします。
「アクセス・システム構成」画面に進み、「認証管理」をクリックし、「追加」をクリックします。
『Oracle Access Managerアクセス管理ガイド』の説明に従って、新しい認証スキームを作成します。次の点に注意してください。
表示の「表示名」と「説明」は、任意のテキストにすることができます。
「レベル」は、使用している他の認証スキームと一貫している必要がありますが、任意の値にすることができます。
「チャレンジ・メソッド」には「外部」を使用します。
「チャレンジ・パラメータ」には、creds:auth_user
を入力して、iPlanetで設定されている内部変数の名前と一致させます。
「SSL必須」には、「いいえ」を使用します。リダイレクションは行われないため、これは使用されません。
同じ理由で、「必須チャレンジ・リダイレクト」も空白のままにします。
「プラグイン」の値は重要です。1つのみ入力してください。
「順序:」は1に設定します。
「プラグイン名」はcredential_mapping
にする必要があります。
「プラグイン・パラメータ」は、カンマで区切った2つの値です。1つ目は、Oracle Access Managerマッピング・ベースの名前です。2つ目は、ディレクトリ内の属性の名前を指定するLDAPフィルタで、その値はauth-user
と一致していることが期待されます。このエントリの例は次のとおりです。
ObMappingBase="o=Company, c=US", obMappingFilter=" (&(objec\]" M NB\=-09876UYT5R4E3tclass=inetOrgPerson) (uid=%auth-user%))"
既存の認証メソッドが最初に実行されるようにiPlanet Obj.conf
内の処理順序を変更し、iPlanetのuser-auth
変数を設定します。
次に例を示します。
Webサーバーのobj.conf
ファイル内で、次の行を見つけます。
AuthTrans fn="OBWebGate_Authent"
先頭に"#"を挿入することにより、この行をコメントアウトします。
この行を、次の行の直後の行に"#"なしでコピーします。
PathCheck fn="check-acl" acl="default"
この新しい行で、AuthTrans
をObjectType
に変更します。
obj.conf
ファイルの内容は次のようになります。
<Object name="default"> #AuthTrans fn="OBWebGate_Authent" NameTrans fn="pfx2dir" from="/oblix/apps/webgate/bin/ webgate.cgi" dir="/" name="web_gate" NameTrans fn="pfx2dir" from="/oberr.cgi" dir="/" name="oberr" . . . PathCheck fn="check-acl" acl="default" ObjectType fn="OBWebGate_Authent" dump="true"
注意: check-acl認証後にWebGateを強制実行するためには、この変更をこの方法どおりに行うことが必要です。認証を含むNetscape ACL処理は、PathCheck check-aclディレクティブ内で行われます。認証メソッドによって値が設定されていることが期待されるauth-user変数を選択するためには、check-aclの後にWebGateを実行する必要があります。check-aclは、obj.conf内に指定されている順序に関係なく常に最後に実行されるPathCheckディレクティブであるため、WebGateのPathCheckディレクティブをcheck-aclディレクティブの後に配置するだけでは機能しません。ここで説明するメソッドは、ObjectTypeディレクティブとしてWebGateを挿入するという方法であり、テストにより動作が実証されています。 |
Webサーバーおよびアクセス・サーバーを停止してから起動して、これらの変更が有効になることを確認します。
Oracle Access Managerは通常、ポリシー・ドメインによって特に保護されていないあらゆるリソースへのアクセスを可能にします。リクエストされたリソースがポリシー・ドメインによって保護されていない場合は、WebGate構成GUIでDenyOnNotProtectedフィールドをtrueに設定することにより、任意のユーザーに対してアクセスを拒否できます。DenyOnNotProtectedフィールドは、デフォルトではfalseに設定されています。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
注意: 必ず、WebGateごとにこのパラメータを変更してください。 |
アクセス・システム・コンソールからアクセス・ゲートを変更する手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」タブをクリックし、左ナビゲーション・ペインで「アクセス・ゲート構成」リンクをクリックします。
「Access Gateの検索」ページが表示されます。
リストから検索属性および条件を選択します。すべてのアクセス・ゲートを検索する場合は、「すべて」を選択します。
「検索」リストは、検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に適した検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
変更するWebGateの名前をクリックします。
アクセス・ゲートの詳細ページが表示されます。
「変更」をクリックします。
「アクセス・ゲートの変更」ページが表示されます。このページに新しい情報を入力できます。
WebGateの名前は変更できません。名前を変更するには、アクセス・システム・コンソールからWebGateを削除してからアンインストールする必要があります。その後、新しいWebGateを作成します。
必要に応じて新しい値を入力します。
「保存」をクリックして変更を保存するか、「取消」をクリックして保存せずにページを閉じます。