| Oracle® Fusion Middleware Enterprise Single Sign-On Suiteの管理 11g リリース2 (11.1.2.3) E61949-01 |
|
 前 |
| Oracle® Fusion Middleware Enterprise Single Sign-On Suiteの管理 11g リリース2 (11.1.2.3) E61949-01 |
|
前 |
この項では、Oracle Enterprise Single Sign-On Suiteをインストール、構成、およびデプロイするときに発生する、最も一般的な問題の解決策について説明します。スイートの管理に関するベスト・プラクティスの詳細は、『Oracle Enterprise Single Sign-On Suiteインストレーション・ガイド』、『ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ』および『Logon Managerアプリケーション・テンプレートの構成と診断』を参照してください。
最も一般的なインストール・シナリオ問題の解決策は、次のとおりです。
オーセンティケータを選択しても、インストールされません。
デフォルトでは、インストーラはシステムで機能しないオーセンティケータをインストールしません。たとえば、Entrust Entelligenceクライアントがインストールされていない場合、Entrust PKI用のオーセンティケータはインストールされません(Entrust Entelligenceは認証マネージャでのみ使用できます)。
Microsoft Active Directory拡張を選択しても、インストールされません。
デフォルトでは、インストーラはシステムで機能しないシンクロナイザ拡張をインストールしません。たとえば、Microsoft Active Directoryクライアントがインストールされていない場合、Microsoft Active Directory Server用のシンクロナイザ拡張はインストールされません。
アンインストール後、ユーザー資格証明が残ります。
標準のアンインストールでは、現在のユーザーの資格証明のみを削除できます。単純なバッチ・ファイルで、他の資格証明の削除を処理できます。次に例を示します。
CD /D %UsersProfile%
CD .
/D %Z in (*.*)では、Del /F/S/Q "%Z\Application Data\SSO"を実行します。
その他のユーザーの場合は、手動でレジストリ・エントリを削除する必要があります。これは、RegEditまたはRegEdit32 (RegEdt32.exe)で行うか、次の*.regファイルを各ユーザーに送信して実行できます。
Windows Registry Editor Version 5.00
HKey_Current_User\Software\Passlogix]
エージェントの実行中は、エージェントの応答速度が遅くなるか、アプリケーションの速度が遅くなるか、アプリケーション内の特定の機能の処理が遅くなります。
一部のアンチウィルス・ソフトウェア・プログラムでは、エージェント・モジュールが過度にチェックされます。この問題を解決するには、ssoshell.exeまたは%ProgramFiles%\Passlogix\v-GO SSOディレクトリ・ツリー(あるいはその両方)のチェックを無効にします。
一部のアンチウィルス・ソフトウェア・プログラムでは、*.iniファイルが過度にチェックされます。エージェントは、ユーザー資格証明を*.iniファイルに格納します。この問題を解決するには、*.iniファイル、%UserName% aml.iniファイル、または%AppData%\Passlogixディレクトリのファイル(あるいはそのすべて)のチェックを無効にします。
特に認証に関連した問題の解決策は、次のとおりです。
ユーザーは異なるドメイン/ワークグループ・アカウントでコンピュータにログオンしますが、同じ資格証明が表示されます。
問題は、ローカル・コンピュータのWindowsアカウントが、ドメイン/ワークグループ・アカウントではなく、ユーザーのレジストリ・ハイブ(HKCU)を提供することです。解決策として、CleanupOnShutdown機能を使用することや、各ドメイン/ワークグループ・ログオンに異なるWindowsアカウントを使用することがあります。
ユーザーが再認証を求められません。
Extensions\AccessManager:AutoLoginを目的の値に設定していることを確認します。この値はミリ秒単位であり、値が900000の場合(クライアント側のインストールのデフォルト)は15分になります。
ユーザーが頻繁に再認証を受ける必要があります。
Extensions\AccessManager:AutoLoginを目的の値に設定していることを確認します。この値はミリ秒単位であり、値が900000の場合(クライアント側のインストールのデフォルト)は15分になります。
その他の再認証強制設定が適切に設定されていることを確認します。これらの設定には次のものがあります。
オーバーライド設定: Extensions\AccessManager:ReauthOnReveal.
アプリケーション構成設定: ForceReauth.
特にLogon Managerのアプリケーション用テンプレートの構成に関連した解決策は、次のとおりです。
アップグレード後は、エージェントは既存のログオン資格証明を認識しません。
エージェントのアップグレード後、ユーザーが以前に資格証明を提供したアプリケーションが機能しないという報告がユーザーから行われます。かわりに、構成されたログオンに資格証明が対応していないことを通知するメッセージ・ボックスが表示されます。アプリケーションは、Logon Managerにグレーのイタリック体のテキストで表示されます。
バルク追加リストを作成し、ユーザーのentlist.iniを更新します。また、Logon Managerでは、WindowsおよびWebアプリケーション用の事前構成されたログオンが、エージェントのapplist.iniではなく、管理コンソール・テンプレートで提供されることに注意してください。テンプレートを使用して、必要なアプリケーション・ログオンを作成し、次にバルク追加リストを作成して、ユーザーのentlist.iniを更新します。
資格証明を追加すると、事前定義されたアプリケーションのリストのアプリケーションが使用できなくなります。
エージェントを停止し、ssoshell.exeプロセスが実行中でないことを確認し、エージェントを再起動します。
ユーザー認証なしでエージェントを起動し、Logon Managerを開くことができます。
エージェントを停止し、実行中のssoshell.exeまたはSSObho.exeプロセスを強制終了し、エージェントを再起動します。
エージェントがパスワード変更ウィンドウを認識しません。または、エージェントがアプリケーションの構成済パスワード変更ダイアログに応答しません。
この問題は、パスワード変更フォームのウィンドウ・タイトルをメイン・ログオン・フォームのウィンドウ・タイトル一致リストに追加することで改善できます。
管理コンソールで、左側のペインでアプリケーションを選択し、「General」タブをクリックします。アプリケーションのパスワード変更フォームをダブルクリックしてフォーム構成ダイアログを開きます。フォームのウィンドウ・タイトルに注意し、「Cancel」をクリックします。アプリケーションのログオン・フォームをダブルクリックし、「Window Titles」で「Add」をクリックします。パスワード変更フォームのウィンドウ・タイトルを入力して「OK」をクリックした後、「OK」をクリックしてフォーム構成ダイアログ・ボックスを閉じます。
ログオンの重複または誤ったウィンドウ
エージェントがアプリケーションに2回応答するか、以前は表示されていなかったウィンドウまたは誤ったウィンドウに応答します。
1つ以上の(追加の)一致セクションおよびフィールド・キーを使用して、より正確な一致基準を指定します。
アプリケーション構成の「Miscellaneous」タブの「Ignore this Window Class」で、無視する必要があるウィンドウ・クラスを指定します。
エージェントが、いずれのWindowsアプリケーションにも応答しません。
エージェントを停止し、実行中のssoshell.exeまたはSSObho.exeプロセスを強制終了し、エージェントを再起動します。
エージェントが、特定のWindowsアプリケーションに応答しません。
使用する一致基準を少なくします。
数字のアプリケーション構成値が、16進数ではなく、10進数であることを確認します。
文字列のアプリケーション構成値が、アプリケーション・ダイアログ内の正確な文字列であることを確認します。
複数のセクションを使用する場合は、1つのセクションでテストを行ってみます。
エージェントは資格証明を提供しますが、送信はしません。
アプリケーション構成の「Miscellaneous」タブで「Auto Submit」が設定され、特定の資格証明のセットで「AutoOK」が設定されていることを確認します。
|
注意: Logon ManagerがActiveXベースのログオン・フォームに対して正確に応答するには、Webブラウザ・ウィンドウを対象としたテンプレートを使用して、これらのフォームをWindowsアプリケーションとして構成する必要があります。詳細は、Logon Managerアプリケーション・テンプレートの構成と診断のマニュアルを参照してください。 |
エージェントが特定のWebページを検出しない、または応答しません。
ページにパスワード・フィールド(パスワードのフィールド・タイプ)があることを確認します。パスワード・フィールドがない場合、エージェントはそのページを無視します。
SSObho.exeが実行していることを確認します。
Java、JavaScriptまたはActiveX(あるいはそのすべて)のサポートを無効にしてみます。
特定のWebページに対してエージェントの応答速度が遅くなります。
ページへのロードが終了していることを確認します。エージェントは、ページへのロードが完全に終了するまでそのページに応答しません。
イメージをオフにします。
Java、JavaScriptまたはActiveX(あるいはそのすべて)のサポートを無効にしてみます。
エージェントがロードしたWebアプリケーションに応答しません。
エージェントを起動し、タイトル・バーのボタンからエージェントをトリガーします。
Logon Managerを使用してログオンします。
ブラウザ・ページをリフレッシュします。
エージェントがLogon Managerを使用して選択したログオンに応答しません。
このようにWebアプリケーションに応答しないというエージェントの既知の問題があります。この場合、エージェントは他のトリガーを介して応答します。
|
注意: ブラウザが別のアプリケーションに組み込まれている場合、エージェントはそのブラウザがWindowsアプリケーションであるかのように応答することがあります。 |
SSObho.exeが実行されません。
エージェントがWebページを適切に認識しない場合は、SSObho.exeが実行中であることを確認します。実行中でない場合、エージェントはユーザーがTerminal Servicesセッション中であると認識することがあります。この問題を修正するには、次のようにします。
エージェントを停止します。(Task ManagerでSSO*タスクが実行中でないことを確認します。)
エージェントをアンインストールします。
次のファイルがユーザーのコンピュータにないことを確認します。
SSOwts.exe
SSOwts.exe
SSOwts.exe
レジストリのシステム・ハイブのRegEdit (HKEY_CURRENT_USERやHKEY_USERSのNOTなど)を使用して、SSO、vGOおよびPasslogixへの参照を検索します。すべての不適切な参照(特に次の参照)を削除します。
HKEY_LOCAL_MACHINE\SOFTWARE\Passlogixとその子
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{04EB19CE-B3B3-11D2-8A09-006008C7059E}とその子
HKEY_CLASSES_ROOT\CLSID\{04EB19CE-B3B3-11D2-8A09-006008C7059E}とその子
HKEY_CLASSES_ROOT\AppID\SSO WTS.EXEとその子
HKEY_CLASSES_ROOT\AppID\{6B9E3EFF-C54A-472C-821B-6FC464B58235}とその子
HKEY_CLASSES_ROOT\SSObho.HelperObjectとその子
HKEY_CLASSES_ROOT\SSObho.HelperObject.1とその子
エージェントを再インストールします。
エージェントは資格証明を提供しますが、送信はしません。
「Submit」フィールドがイメージ・タイプの場合は、プロトコルを含めてURLが正確であることを確認します。
「Submit」フィールドが存在しない場合は追加します。
エージェントは、ページを送信するのではなく、別のページへのリンクまたはそれ以外のアクション(取消し/消去など)をトリガーします。
アプリケーション構成に「Submit」フィールドを追加します。
Webページで4つ以上のフィールドが使用されます(たとえば、3つのフィールドとしての社会保険番号およびパスワード)。
ログオンを2つ(以上)のログオンに分割します。次に、ユーザーは(ログオン・チューザで)パスワードがない資格証明を選択し(自動送信を無効にして)、パスワードがある資格証明を選択します。
エージェントは資格証明を提供しますが、送信はしません。
資格証明を要求しているウィンドウにシステムのフォーカスを置き続けます。別のウィンドウに切り替えた場合、エージェントは資格証明を提供しますが、ページに送信の指示を出すことは行いません。
エージェントは、ページを送信するのではなく、別のページへのリンクまたはそれ以外のアクション(取消し/消去など)をトリガーします。
資格証明の自動送信をオフにして、ページ送信を手動でトリガーします。
ページを事前定義し、「Submit」フィールドを指定します。
資格証明の追加時、URLではなくウィンドウ・タイトルが格納されます。
SSObho.exeが実行していることを確認します。(前述の説明を参照してください。)
ホスト/メインフレーム・アプリケーションへのLogon Managerのレスポンスに特定の問題の解決策は、次のとおりです。
エージェントが、いずれのホスト・アプリケーションにも応答しません。
エージェントを停止し、実行中のssoshell.exeまたはSSObho.exeプロセスを強制終了し、エージェントを再起動します。
ホスト・コンピュータでHLLAPIが正しく有効になっていることを確認します。
MFEnable=1であることを確認します。
座標が左上隅を基準としていることを確認します。左上隅とは(1,1)(行1、列1)です。
エージェントが、いずれのTelnetアプリケーションにも応答しません。
ホスト・エミュレータで、HLLAPIまたはスクリプト言語によるTelnetがサポートされていることを確認します。
|
注意: エージェントでは、HLLAPIによるTelnetは、Scanpak AvivaおよびNetManage Rumbaに対してのみサポートされています。 |
1つ以上の資格証明フィールドが挿入されていないか、一部のみ挿入されています。
座標が左上隅を基準としていることを確認します。左上隅とは(1,1)(行1、列1)です。
アプリケーション構成座標が、資格証明が挿入される正確な場所と一致していることを確認します。通常、フィールド・プロンプトの後にスペースがあり(ユーザー名:スペースなど)、スペースの後に資格証明フィールドを挿入する必要があります。
フィールド間に特殊文字列が使用されている場合は、文字列が有効であること、および「Delay Field」が十分大きい値に設定されていることを確認します。
エージェントが特定のホスト・アプリケーションに応答しません。
座標が左上隅を基準としていることを確認します。左上隅とは(1,1)(行1、列1)です。
使用する一致基準を少なくします。
エージェントが特定のTelnetアプリケーションに応答しません。
すべてのフィールドの座標が(1,1)に設定されていることを確認します。
拡張したイベント・ロギングに関連した問題の解決策は、次のとおりです。
イベントが記録されません
フィルタが設定されていません。0xFFFFFFFFを設定(すべてのイベントを記録)し、エージェントを再起動してテストします。
エージェントは再試行設定(デフォルトは30分)に達していません。デフォルトから値を変更するには、Extensions\EventManager:RetryまたはExtensions\EventManager\%Extension%:Retryをより小さい値に設定します。イベント・ロギングが行われていることを確認するには、ユーザーの%UserName% AML.iniファイルを開き、SSOSection列で、CacheItemで始まる名前を持つエントリ(CacheItem1など)を検索します。これらの項目はイベントで、再試行時間に達するまでキャッシュされます。キャッシュされたイベントは、再試行時に拡張に送信されます。
誤ったイベントが記録されます。
フィルタの設定が正しくありません。イベント・ロギング・フィルタを確認し、正確なビット順序およびバイナリから16進/10進への変換に注意します。
資格証明がサーバーに到達しません。
サーバー名が正しく設定されていません。先頭に\\文字を使用しないでください。適切なNetBIOS名(TCP/IP名ではなく)を指定してください。
サーバー上の資格証明が欠落しています。カテゴリおよびイベント・ラベルは数字のみで、次のような説明が表示されます。「ソース(Logon Manager)内のイベントID (###)の説明が見つかりません。
ローカル・コンピュータに、必要なレジストリ情報、またはリモート・コンピュータからのメッセージを表示するメッセージDLLファイルがない可能性があります。次の情報はイベントの一部です。」
サーバーが正しく構成されていません。サーバーの構成方法については、第2.17.11.1項「Windowsイベント・ロギング・サーバーの構成」を参照してください。
資格証明共有グループが機能しません。
Extensions\AccessManager:PWSEnable=1であることを確認します。
ドメインまたはLDAPグループのアプリケーション内でパスワードが変更されても、その変更については、オーセンティケータに通知されません。
AUI:ShareToAuth=1であることを確認します。
任意のタイプのディレクトリに同期化するときに経験する問題の解決策は、次のとおりです。
SSL経由で接続できません。
ディレクトリ接続がSSLなしで機能することを確認します。
ユーザーがディレクトリにオブジェクトを作成できません。
ユーザーがディレクトリに接続していることを確認します。
UserPathsが有効な場所を指していることを確認します。
ユーザーの専用またはデフォルト・オブジェクトとしてのSSOlocatorオブジェクトが存在しません。デフォルト・オブジェクトをUserPathsが指す場所に置きます。うまく配置できた場合は、デフォルト・オブジェクトをツリーの上の方へ移動したり、ユーザー固有のオブジェクトをツリーに置くことができます。
管理オブジェクト(vGOAdminOverride、vGOentlist、vGOftulist)を変更できません。
既存のオブジェクトは上書きできません。かわりに、古いオブジェクトを削除し、新しいオブジェクトをプッシュします。
ユーザーがディレクトリにオブジェクトを作成できません。
ユーザーがファイル・システム共有に(エクスプローラなどで)直接接続できることを確認します。
スキーマを拡張するとき、次のエラー・メッセージが表示されます。
「Connect to Repository」ダイアログで、「OpenLDAP Directory Server」が「Repository Type」として選択され、Extend Schema Statusステータス・エラーが表示された場合は、スキーマを手動で拡張する必要があります。
表示されるエラー・メッセージは、次のとおりです。
このエラーが表示された場合、手動でスキーマを拡張するために、次の手順を実行します。
sso.schemaファイルをOpenLDAPサーバーにコピーします。sso.schemaファイルは次の場所に置くことができます。C:\Program Files\Passlogix\v-GO SSO Console\DirectorySchema\vgo\OLDAP\sso.schema
sso.schemaファイルを次のディレクトリ(またはOpenLDAP構成のその他のスキーマ・ディレクトリ)に置きます。/usr/local/etc/openldap/schema
新しいスキーマ・ファイルを含むようにOpenLDAP構成ファイルを変更する必要があります。ファイルを開き、次の行を追加します。include <path>/sso.schema<path>は前の手順で指定したパスです。
|
注意: UNIXマシンでは、このファイルをslapd.confと呼びます。 |
この項では、Universal Authentication Managerを使用するときに発生する可能性のある問題の解決策について説明します。
Universal Authentication Managerサービス・アカウントは、ネットワーク上のすべてのUniversal Authentication Managerインスタンスによって、リポジトリにセキュアにアクセスしてデータの読取りと書込みを行うために使用されます。サービス・アカウントが削除されるか使用不可になっていると、すべてのインスタンスがリポジトリと同期がとれなくなり、コンピュータの再起動時にUniversal Authentication Managerの認証サービスを開始できないため、ユーザーがログオンできなくなる可能性があります。ログオンして手動の構成手順を実行できない場合は、Windowsのセーフ・モードでログオンする必要があります。このアカウントが保護されていることを確認することが重要です。
Universal Authentication Managerのサービス・アカウントを危険にさらさないために、パスワードが期限切れにならないように設定し、強いパスワードを使用し、だれも削除または変更できないことを確認します。なんらかの理由でサービス・アカウントを削除または変更した場合は、次のいずれかの手順でシステムをリカバリします。
サービス・アカウントを削除した場合は、別の名前でアカウントを再作成し、第5.2.2.5項「Universal Authentication Manager記憶域の初期化」の手順に従って、Universal Authentication Managerを再構成して再作成したアカウントを使用します。
エンタープライズ・モードで作業していて、Universal Authentication Manager認証サービスにUniversal Authentication Managerサービス・アカウントとしてログオンするようワークステーションが構成されていた場合、インストールの修復を試行すると次のエラー・メッセージが表示されることがあります。
「Fatal error during installation.」
修復は正常に終了しません。
修復を完了するには、次の手順を実行します。
Universal Authentication Manager認証サービスを停止します。「コントロールパネル」で「管理ツール」を開きます。「サービス」の下で、「ESSO-UAM Authentication Service」を右クリックして「停止」をクリックします。
「ESSO-UAM Authentication Service」を右クリックして「プロパティ」をクリックします。「ログオン」タブで、「ログオン」の値を、Universal Authentication Managerサービス・アカウント・ユーザーからローカル・システム・アカウントに変更します。
「コントロールパネル」の「プログラムの追加と削除」または「プログラムと機能」に移動して、Universal Authentication Managerのインストーラを実行し、「修復」オプションを選択してインストールを修復します。
「ログオン」の値をUniversal Authentication Managerサービス・アカウント・ユーザーに戻します。「コントロールパネル」で「管理ツール」を開きます。「サービス」の下で、「ESSO-UAM Authentication Service」を右クリックして「プロパティ」をクリックします。「ログオン」タブで、「ログオン」の値を、ローカル・システム・アカウントからUniversal Authentication Managerサービス・アカウント・ユーザーに変更します。
Universal Authentication Manager認証サービスを再起動します。「コントロールパネル」で「管理ツール」を起動します。「サービス」の下で、「ESSO-UAM Authentication Service」を右クリックして「開始」をクリックします。
自動ログオン条件を有効にしているが、構成が誤っている場合、ユーザーがログオンすると、Universal Authentication Managerログオン・アプリケーションではなく、Microsoftのログオン・ダイアログが表示されます。ユーザーがWindowsパスワードを使用してワークステーションにログオンする場合、ログオン方法の登録は求められません。PINプロンプトも、エラー・メッセージも表示されません。ただし、ワークステーションのロックを解除するときには、Universal Authentication Managerのログオン・ダイアログが表示されます。自動ログオンはログオン動作のみに関係し、ワークステーションのロック解除には関係しないためです。ForceAutoLogonが実施されていない場合、ログオフ時にはMicrosoftのログオン・ダイアログが表示されます。
自動ログオンの構成方法の詳細は、次のMicrosoftサポートを参照してください。
両用カードとは、スマート・カードとしても近接型カードとしても機能するカードです。両用リーダーは、スマート・カードと近接型カードの両方を認識できるリーダーです。両用リーダーで両用カードを使用することは推奨しません。このようなカードは、Universal Authentication Managerによって、同時にスマート・カードと近接型カードの両方として認識されるためです。この場合、Universal Authentication Managerは、ユーザーがどちらのテクノロジを登録に使用したいのか判断できません。
たとえば、近接型チップを埋め込んだスマート・カードなどの両用デバイスを、両用リーダーで使用した場合、カードをリーダーに完全に挿入してスマート・カードの機能を使用できるようになる前に、リーダーの近接機能がカードの近接要素を読み取ります。よりよいプラクティスは、両用カードを専用リーダーで使用するか、または専用カードを両用リーダーで使用することです。
Universal Authentication Managerは、Windowsのデフォルトのドメイン・ポリシーを実施します。Universal Authentication Managerは、システムのネイティブのWindowsログオン動作を拡張します。Microsoft WindowsおよびActive Directoryには、Windowsのログオンとロック解除のフローに影響する様々なセキュリティ・ポリシーと設定が含まれていて、Universal Authentication Managerはこれらのポリシーに準拠しています。たとえば、ユーザーのパスワードが有効期限に達した場合、Universal Authentication Managerは、ログオンを許可する前にパスワードの変更を求めます。
Universal Authentication Managerは、自動ログオンをサポートします。エンド・ユーザーのワークステーションで自動ログオンを構成する方法の詳細は、次のMicrosoftサポートを参照してください。
Universal Authentication ManagerのWindowsログオンは、ネイティブのWindowsパスワードによるログオンおよびロック解除のすべてのフローを再現します。
Universal Authentication Managerは、(Windows XPのGINAテクノロジと、Windows 7以上の資格証明プロバイダに基づく)WindowsのWinlogonメカニズムを統合し拡張します。Microsoft WindowsおよびActive Directoryには、Windowsのログオンとロック解除のフローに影響する様々なセキュリティ・ポリシーと設定が含まれています。インストールすると、Universal Authentication Managerは、すべてのMicrosoft Active Directoryセキュリティ・ポリシーに準拠します。
|
注意: セキュリティ・ポリシーで、ログオンにスマート・カードを必要とするように設定されていないことを確認してください。Universal Authentication Managerのスマート・カード認証はPKI Kerberos認証に基づいていませんが、Windowsのグループ・ポリシーではスマート・カード・ログオンにPKI Kerberos認証を必要とするためです。このポリシーを有効にすると、Universal Authentication ManagerのWindowsログオンが失敗します。 |
このポリシー・グループは、Active Directoryのパスワード制約およびパスワード有効期限を管理するために使用され、パスワード変更プロンプトと有効期限切れの背後にあるロジックを動作させます。たとえば、ユーザーのパスワードがActive Directoryで指定された有効期限に達した場合、Universal Authentication Managerのログオン・アプリケーションは、ログオンを許可する前にパスワードの変更を求めます。
Universal Authentication Managerは、無効なログオンの試行回数の管理をサポートします。この回数によって、ユーザーのアカウントは、一時的または永久に使用不可になります。アカウントのロックアウトを強制するポリシーが有効になっていると、Universal Authentication Managerのログオン・アプリケーションは、サポートされるすべての方式について、失敗したログオンおよびロック解除の試行を追跡して数え上げます。アカウント・ロックアウトのしきい値を超えたアカウントは、オペレーティング・システムによってロックされます。
管理者としてユーザーのパスワードを変更した場合、そのユーザーがUniversal Authentication Manager資格証明を使用してログオンを試みると、キャッシュされたパスワードが不正であることを示すエラー・ダイアログが表示されます。ユーザーは新しいパスワードを入力する必要があるため、ユーザーに新しいパスワードを知らせたことを確認してください。
|
注意: キャッシュされたパスワードの不正は、失敗したログオン試行の1回としてカウントされ、Windowsパスワード・ポリシーの設定によっては、Windowsアカウントのロックアウトのしきい値をトリガーする可能性があります。 |
