目次


Iris Today Archives: パスワード・チェック

Comments

クライアント・サーバー間アクセスのノーツ/ドミノ認証メカニズムは、ユーザー・グループのサーバーへのアクセス権とパブリック・キー(公開鍵)チェックに加えて、パスワード・チェックによって高度化されます。単純なことですが、パスワード・チェックにより、ユーザーは定期的にパスワード変更を要求されることになります。

この強制的なパスワード変更により、認証プロセスはさらに安全になります。たとえば、だれかがあなたのユーザー ID ファイルとそのパスワードを入手したら、その人はその ID のコピーを使って自由にサーバーにアクセスできます。しかし、パスワード・チェックを有効にすることにより、被害者が正規の ID ファイルのパスワードを変更すれば、サーバーはその変更を知ることになります。その結果、盗まれた ID ファイルを使ってアクセスしようとする人は、サーバーにアクセスするのを拒否されることになります。

この記事では、パスワード・チェックがどのようにノーツ/ドミノで実装されているか、そしてパスワード・チェックをともなう認証の複雑さについて検討し、パスワード・チェック・プロセスの管理とトラブル・シューティングのためのヒントを提供します。この記事では、ドミノ サーバー管理およびネットワーク・アーキテクチャーに関する高度な知識を前提とします。

パスワード・チェックの基礎

パスワード・チェックが有効なとき、管理者は、ユーザーに ID ファイルのパスワードを変更させる必要変更間隔(必須変更期間)を日単位で指定できます。ノーツ・クライアントは、パスワードの期限が迫ると、ユーザーにパスワードを変えるように促します。

変更期間に加え、管理者は猶予期間も設定できます。これは、パスワードの期限切れから、何日以内にパスワードを変更しなければならないかを示す日単位の時間です。R5 では、変更期間と猶予期間の合計の分だけ日数が経過すると、管理者がそのユーザーのアカウントをユーザー文書においてリセットするまで、ユーザーはサーバーにアクセスするのを拒否されます(つまり、ロックアウトされます)。(R4.6.7 以前のクライアント動作は若干違っていますので、後ほど説明します。)

ノーツ・クライアントもドミノ サーバーも、パスワード・チェック・プロセスに関与します。(パスワード・チェックに基づく)ドミノ サーバー・ロックアウトの作業と実施の大部分は、実際にはノーツ・クライアント側で実行されます。

ユーザーの ID ファイルはパスワードの期限が切れる日を算出するのに必要な情報を保存しています。 ID ファイルは次の情報を含みます。

  • 最終パスワード変更日
  • パスワード期限切れまでの日数
  • パスワードを変えないままでいられる最大日数
  • 現在のパスワード
  • 最近使われたパスワード 49 個の履歴と各パスワードが無効になった日

サーバーもパスワード・チェック情報をもっています。これは、ドミノ・ディレクトリーに保存されています。各サーバーのサーバー文書は、「パスワード・チェック」フィールドを含みます。これは、サーバー毎にパスワード・チェックを有効、無効に設定するための情報です。これに加え、各ユーザー文書は次のパラメーターを含んでいます。

パラメーター説明
パスワード・チェックこのユーザー ID に対してパスワード・チェックを有効にするか無効にするか
必須変更間隔(必須変更期間)パスワードの有効期間、1つのパスワードが有効である期間
猶予期間「必須変更間隔」後の日数。この期間の間は、まだノーツ・クライアントはユーザーをロックアウトしないので、ユーザーはパスワードを変更できます。
最終変更日ユーザーが最後にパスワードを変更した日付のサーバー側のコピー
パスワード・ダイジェストサーバーが保持する暗号化されたパスワード。ユーザーがサーバーにログインしたときにサーバーのパスワード・チェックが有効なら、クライアントは認証の過程でサーバーに対して一致するパスワードを提供しなければなりません。

パスワード・チェックのセットアップ

パスワード・チェックをセットアップするために、それをサーバー上で有効にし、そしてどのユーザーに適用するかを指定しなければなりません。

パスワード・チェックをサーバー上で有効にする
サーバー文書を使ってパスワード・チェックを有効にします。

  1. 該当するサーバーのサーバー文書を開く。
  2. [セキュリティ] タブで、「パスワードチェック」フィールドを有効にする。
    Enabling password checking
    Enabling password checking
    Enabling password checking
  3. サーバー文書を保存して閉じる。
  4. サーバーを再起動させる。

再起動後、ノーツ・クライアントがこのドミノ サーバーとのセッションを開くときに、ノーツ・クライアントはこのフィールドを読み込みます。このフィールドが有効であれば、クライアント側のパスワード・チェック機能はこのサーバー接続についても有効です。このフィールドが無効に設定されていれば、サーバーは、ユーザー文書で有効に設定されていても、認証するどのクライアントに対してもパスワード・チェックを実行することはありません。簡単に言えば、サーバー文書の設定は、サーバー側のパスワード・チェックに対する大元の On/Off のスイッチになっているのです。

ユーザーに対するパスワード・チェックを有効にする
ドミノ サーバーが有効になっていれば、次のステップは、どのユーザーに対してパスワード・チェックを有効にするかを決定することです。ユーザーのユーザー文書を使って行います。

  1. 管理者 ID を使って、ドミノ・ディレクトリーの [ユーザー] ビューでユーザー文書を選択します。
  2. [アクション] - [パスワードフィールドの設定] を選択します。確認のメッセージが現れます。
  3. 選択したユーザー文書でパスワード・フィールドを設定することの確認として [はい] をクリックします。続いて、別のダイアログ・ボックスが現れます。
    Check password dialog box
    Check password dialog box
    Check password dialog box
  4. パスワード・チェックのリスト・ボックスには3つの選択肢、[パスワードをチェックする]、[パスワードをチェックしない]、[ID をロックアウトする] があります。[パスワードをチェックする] を選択します。([パスワードをチェックしない] は、一度ユーザーに対して有効にされたパスワード・チェックを無効にするために利用します。これについては、後述の「あるユーザーに対するパスワード・チェックを無効にする」で説明します。[ID をロックアウトする] を使えば、管理者は手動でユーザーを、サーバーからロックアウトして、パスワードが正しくてもログインできないようにできます。後述の「特定のユーザーをロックアウトする」で説明します。)
  5. 必須変更間隔と猶予期間を日単位で入力します。たとえば、変更期間を 90 日、猶予期間を 30 日と入力します。これは、ユーザーが 90 日ごとにパスワード変更を要求されること意味します。この 90 日が過ぎたら、ユーザーはサーバーにアクセスすることはできませんが、さらにパスワードを変えるために 30 日間の猶予があります。これを過ぎるとアカウントのロックアウトを管理者に解除してもらわなければなりません。
  6. OK をクリックしてください。直後に、システム管理プロセス(Adminp)要求はドミノ サーバーのシステム管理要求データベース(admin4.nsf)に書き込まれ、承認メッセージが現れます。
    acknowledgement message
    acknowledgement message
    acknowledgement message

プロセスの完了まで
システム管理要求データベースを開けば、パスワード情報の設定に関する要求を[動作場所別要求] ビューなどで見ることができます。

View of request
View of request
View of request

実際のシステム管理プロセス要求文書は、アクション、アクションを実行するサーバー、実行するアクションの名前、アクションの要求者、行われる変更などの情報を含んでいます。

Administration Process Request document
Administration Process Request document
Administration Process Request document

一度、 Adminp が変更要求を処理すると、確認文書がシステム管理要求データベースに現れます。この時点では、プロセスは一部が完了したにすぎません。設定の内容はすでに「あるべき場所」にありますが、パスワード・ダイジェストのデータがサーバーへ正しく返送されることを確認するために、ユーザーがサーバーにログインすることが必要です。

View with confirmation document
View with confirmation document
View with confirmation document

また、ユーザー文書にある [管理] タブには、[パスワードチェック] フィールド、[必須変更間隔] フィールド、[猶予期間] フィールドがありますので、ここでも確認できます。ユーザーがサーバーで認証するまで、[パスワードダイジェスト] フィールドは空白ですので、気をつけてください。

Person document
Person document
Person document

ユーザーが自分の ID を使ってサーバーにアクセスしようとするとき、まずサーバーで証明書認証が行われます。それから、ノーツ・クライアントは、サーバーのパスワード・チェックが有効になっているかを確認し、有効ならば、ユーザーのユーザー文書でもパスワード・チェックが有効になっているかを確認します。上で説明したステップを追ってきたなら、どちらも有効になっています。

この例では、パスワード・チェックが要求されてから最初の認証なので、ノーツ・クライアントは未解決の Adminp 要求を発見し、猶予期間、変更期間をユーザーのユーザー文書から ID ファイルへ移します。一度これが受け入れられると、クライアントは、ユーザー文書が更新されるように、システム管理要求データベースに新しい変更要求を作成します。この要求は、ユーザー ID が猶予期間と変更期間の情報を受け取ったことを確認し、最終変更日である今日の日付とともに ID ファイルからの現在のパスワード・ダイジェストを含んでいます。

次に、ユーザー ID ファイルに追加された新しい構造体を示します。

PWD_KEY_HDR
Type: 0000
Version: 0000
LastChanged: TIMEDATE
Innards: 0025 69DC 0039 822B
Text format: 22/01/2001 10:28:08
ExpirationDays: 0000 005A
NextExpirationDays: 0000 005A
NumDomains: 0001
NumOldPwds: 0001
OldPwdTotLen: 0214

Adminp が新しい変更要求を処理するとき、パスワード・ダイジェストは、最終変更日とともにユーザーのユーザー文書へコピーされ、パスワードの初期化を反映します。 Adminp は、このリクエストが処理されると確認文書を作成します。

Confirmation document in the view
Confirmation document in the view
Confirmation document in the view

この時点で、ユーザー文書を確認すると、パスワード・ダイジェストと最終変更日の情報が完全に書き込まれていることがわかります。

Person document with all fields complete
Person document with all fields complete
Person document with all fields complete

ユーザー文書が、ユーザーの現在のパスワードのパスワード・ダイジェストを含んでいますので、この ID のサーバーに対するパスワード・チェックはセットアップされ、有効になっています。

サーバー・ロックアウトを理解する

ユーザーがパスワードを時間通り、つまり変更期間内に変更している限り、なにも問題ありません。しかし、ユーザーがそれにしたがわなかった場合、何が起きるのでしょう。このセクションでは、ロックアウトが迫っていることをいつユーザーが知らされるか、いつユーザーがサーバーからロックアウトされるのかを、決定する基準について見ていきます。

クライアントにおける有効期限のチェック
これまで見てきたとおり、ノーツ・クライアントは、ユーザーが実際にログインする以前からユーザーに関する情報をたくさんもっています。これらの ID ファイルにあるパラメーターは、クライアントでイベントを発生させる引き金として使われたり、パスワード・チェックのサイクルのどの段階にいるかに応じて、ユーザーに対する警告メッセージを表示するために使われたりしています。

NOTES.INI ファイルは、現在クライアントが使用している ID ファイル名およびユーザー ID が最後に使われた日付を決めるための変数 CertificateExpChecked を含んでいます。ノーツがロードすると、この設定値を確認し、CertificateExpChecked の設定に列挙されている日付が今日よりも前であれば、ノーツは ID ファイルに有効期限内の証明書があるかを確認するためにその ID ファイルを調べます。そして、必要ならパスワードが期限切れかもしれないことをユーザーに警告します。期限切れの判定は次の式によって行われます。

有効期限 =(最終変更日 + 変更期間)

IF(有効期限 - 今日の日付)<(変更期間の 25%) THEN 警告を表示

password is expiring warning
password is expiring warning
password is expiring warning

このメッセージは、 IF 文が真である間、パスワード変更期間が過ぎるまで毎日1回現れます。(このメッセージはドミノ サーバーに接続しなくても現れることに注意してください。クライアントは必要な情報をすべてユーザー ID ファイル内にもっているので、ユーザーのユーザー文書を読む必要はないのです。)

サーバーへの接続
ユーザーがサーバーへ接続するとき、クライアントはサーバー文書を調べ、サーバーでパスワード・チェックが有効になっているかを確認します。有効ならば、次にユーザーのユーザー文書で [パスワード・チェック] フィールドが有効かどうかを確認します。

ユーザーは、パスワードを変更するまで、毎日上で示した警告を受けることになります。警告は受けますが、パスワード変更期間が過ぎてパスワード変更の期限がくるまでは、パスワード・チェックが有効なサーバーにもアクセスすることはできます。期限がくると、パスワードが期限切れになったことを説明する別のメッセージが表示されます。先のエラー・メッセージの場合と同じく、このメッセージは、サーバーへ接続する前でもクライアントにおいて発生します。

Change password message
Change password message
Change password message

メッセージに表示される有効期限は、次の式により算出されます。

(最終パスワード変更日)+(ID に保存されている変更期間)

R4 では、この時点で、認証を行うことができ、そして OK をクリックすれば、パスワード・チェックが有効なサーバーへアクセスすることができました。それから、サーバーからロックアウトされる前にパスワードを変更するための、数日間の猶予期間に入ります。しかし、この動作はお客様からの要求に応えて変更になりました。R4.6.7 とそれ以降のクライアント、および R5 クライアントでは、OK をクリックすればメッセージを消すことができますが、パスワード・チェックが有効なサーバーへアクセスすることはできません。その代わりに、別のメッセージが表示されます。

No access message
No access message
No access message

ユーザーは、パスワードを変更するまでサーバーにアクセスできません。ユーザーがあきらめて、パスワード・チェックが有効でないサーバーにアクセスしようとした場合はアクセスできます。しかし、それでもパスワードの期限切れに関する警告は表示されます。

  • どのリリースでも、一度パスワードが期限切れになったら、つまりパスワード変更期間が過ぎてしまったら、クライアントとユーザー ID ファイルは猶予期間の扱いになります。R4.6.7 とそれ以降のクライアント、および R5 クライアントでは、猶予期間はパスワードが期限切れになった後からアカウントがロックされるまでの期間であり、その間にユーザーはパスワードを変更できます。(猶予期間内はパスワード・チェックが有効なサーバーにはログインできません。)
  • R4.6.7 以前のクライアントでは、猶予期間はパスワードを変更できる期間の延長です。ユーザーはすべてのサーバーにまだアクセスできますが、猶予期間の終わりにアカウントが最終的にロックアウトされるまで、さらに強い警告を受けることになります。

ユーザー・ロックアウト
この記事の例では、猶予期間を 30 日にセットして R5 クライアントを使っています。つまり、パスワード・チェックを強制するように設定されているサーバーにアクセスするために、ユーザーがパスワードを変えなくてはならない期間は 30 日間です。この 30 日間の猶予が過ぎた後は、サーバーの管理者が手動でユーザー文書を修正してユーザーのアカウントをリセットしない限りアクセスは回復しません。

通常、猶予期間は 30 日が適しています。例えば、ユーザーが休暇を取った後にパスワードが期限切れになっても、休暇から帰った後に管理者の手を煩わせることなしに、パスワードが変更でき、仕事を再開できるのです(もちろん、休暇が 30 日以下の場合ですが)。

ユーザーがパスワード変更の警告を猶予期間中ずっと無視しつづけた場合、次にパスワード・チェックが有効なサーバーにアクセスする時に、ロックアウトされた旨を表示するメッセージが現れます。

Lock out message
Lock out message
Lock out message

このクライアントの警告に加え、サーバーも同様の警告をログに保存します。

23/05/2001 11:11:21 CN=Mickey User/O=Acme failed to authenticate: Your password expired and your account is locked out; see your system administrator to reset it

この時点で、ノーツ・クライアントはユーザーがサーバーへアクセスできないようにします。ユーザーがパスワードをこの期間の後に変更したとしても、このサーバーへアクセスして Adminp パスワード変更要求を出すことはできません。一度ユーザーがこのエラーにあってしまったら、管理者を呼んで助けてもらうしかないのです。

また、この時点で、ユーザー文書に保存されているダイジェストは暗号化されているので、ユーザー ID に保存されているものとは違っていることに気をつけてください。これは管理者のために、安全を確保する仕組みです。たとえば、あるユーザーが組織を去ったのに、管理者がそのユーザーをアクセス不可グループに加え忘れた場合、パスワード・チェックが有効である限り、ダイジェストが符合することはないので、そのユーザー ID を使ってもサーバーにはアクセスできなくなります(しかし、これはアクセス不可 ACL グループの代わりとして利用できるものではありません。)

アカウントのロック解除
一度ロックアウトしたら、ユーザーのアカウントのロックを解除できるのは、ユーザー文書にアクセスできる管理者のみです。アカウントのロック解除のステップはとてもわかりやすいものです。しかし、管理者が Adminp プロセスを完全に完了しない場合や、間違って違うフィールドを修正した場合には、エラーが起きる可能性があります。

まず、管理者はパスワード・ダイジェストをユーザー文書から削除します。ユーザーが次にサーバーにログオンする時にも、まだアクセスを拒否されます。これは、ユーザー ID ファイルがまだ有効期限の切れた日付を保存しているからです。ユーザーは、ユーザー ID ファイル内のパスワードを変更しなければなりません。これによりユーザー ID ファイル内のパスワード・ダイジェストが更新されます。そしてユーザー文書内にはダイジェストがないので、行うはずのパスワード・ダイジェスト・チェックがなく、ユーザーはアクセスできます。最終変更日がユーザー文書の記録より新しい日付になっているので、クライアントは Adminp 要求を出し、サーバーに新しくパスワードが変わったことを通知します。

Password change request
Password change request
Password change request

Adminp がこの変更要求を処理したら、そのユーザーのユーザー文書には、ユーザー ID ファイルと同じパスワード・ダイジェストおよび、最終変更日が書き込まれます。この要求はクライアントからサーバーへの要求なので、ID ファイルを変更する必要はありません。これで、ユーザーはサーバーにアクセスできるようになりました。

パスワード・チェック・イベントのまとめ

「パスワード・チェック・イベントのフロー・チャート」に、パスワード・チェック・サイクルの概要を示してあります。これは、クライアントとサーバーのイベントや警告を示していて、可能な設定あるいは同期の問題を見分けるのに役立ちます。

これまでに紹介したメッセージの他にも、確実にダイジェストと日付を同期させるためにサーバーが行う確認がいくつかあります。たとえば、クライアントがサーバーにユーザー ID のダイジェストを送ったときに、サーバーの時間より進んだ日付が記載されていたら、クライアントのオペレーティング・システムの時計に何か問題があるに違いありません。この状況では、クライアントに「時間の同期とパスワードの変更間隔の問題で接続に失敗しました。時刻の設定を確認しパスワードを変更するか、システム管理者に問い合わせてください。」というメッセージが表示されます。

ヒント

パスワード・チェックを管理し、トラブルを解決する際に有用な追加的な情報を次に紹介します。

ユーザー文書、サーバー文書を使う
猶予期間とパスワード変更期間を変更するには、 Adminp アクションを使ってください。ユーザー文書内でこれらのフィールドを直接編集すると、 Adminp要求が生成されなくなり、それに伴ってユーザー ID が同期しなくなります。同期しないとユーザーがロックアウトされます。

ユーザー ID のロックを解除して、サーバーに元のようにログオンできるようにするには、ユーザー文書の [最終更新日] フィールドをクリアしただけでは不十分だということを忘れないでください。ユーザーのアカウントのロックを解除する正しい方法は手動でユーザー文書の [パスワード・ダイジェスト] フィールドをクリアすることです。Adminp を使って、ダイジェストをクリアする簡単な方法はありません([アクション] - [パスワード・フィールドの設定] を選択し、[パスワードをチェックしない] を選択して、パスワード・チェックを完全に無効にする方法をとらない限り)。その場合、ユーザー文書を直接編集することが現実的になります。

クライアント側の警告はユーザーがサーバーへアクセスする前におきるので、そのような警告は、サーバー文書でパスワード・チェックを無効にしてもなくなりません。しかし、無効にしたことにより、パスワードが期限切れになっていても、そのユーザー ID でサーバーへアクセスし続けられるようになります。警告メッセージを消すために、ユーザーは ID に保存されている最終変更日、猶予期間、有効期限にしたがってパスワードを変更していくべきです。

あるユーザーについてパスワード・チェックを無効にする
当然のことながら、管理者はいつでも(パスワード期限が切れていても)パスワード・チェックを無効にすることができます。前述の「ユーザーに対するパスワード・チェックを有効にする」のセクションの手順に沿って設定しますが、その中で [パスワードをチェックしない] を選ぶところだけが違います。これにより適切な Adminp 要求が出ます。しかし、ID のパスワードがすでに期限切れになっていたら、ユーザーはパスワードを変更して、ID ファイルのパスワード構造体をリセットする必要があります。そのときから、クライアント側のパスワード・チェックは、ID で再度パスワード・チェックが有効に設定されるまで、実行されません。

パスワード再使用
ID ファイルには古いパスワードが 49個まで保存されていることに注意してください。ユーザーが、ID に保存されている49のパスワードのいずれかを使おうとすると、違うパスワードを選択するように要求するメッセージが現れます。

Password has been used message
Password has been used message
Password has been used message

特定のユーザーをロックアウトする
サーバーから特定のユーザーをロックアウトする必要が生じた場合、 Adminp 要求を出せば、ロックアウトできます。前述の「ユーザーに対するパスワード・チェックを有効にする」のセクションの手順に沿って設定しますが、ダイアログ・ボックスのパスワード・フィールドで [ID をロックアウトする] を選んでください。

Adminp が要求を処理すると、ユーザー文書は修正され、[パスワード・チェック] フィールドが [ID をロックアウトする] にセットされます。ユーザーが再度、このサーバーにアクセスしようとすると、認証を許可されていないことを示すメッセージが現れます。

Authentication not allowed message
Authentication not allowed message
Authentication not allowed message

複数のサーバーを使う
この記事では、単一のサーバーを使用している場合を取り上げてきました。複数のサーバーがある場合、さらにいくつか注意点があります。変更はすべて管理サーバーのドミノ・ディレクトリー(names.nsf)で行われるため、他のサーバーでも更新が確実に行われるようにドミノは複製を参照します。ユーザー文書を変更して(たとえば、[パスワード・ダイジェスト] フィールドをクリアするなど)、ユーザー・アカウントをあるサーバーでリセットすると、パスワード・チェックが有効な他のすべてのサーバーへのアクセスはユーザーに戻されます。ただし、それはドミノ・ディレクトリーが変更を複製し終えた後だけです。

ユーザーを拡大する前のテスト
ユーザー拡大前のテスト中に、この記事の記述とは違う現象に出会うかもしれません。頻繁に問題が起きるのは、すべてのテストの結果を記録する前に、Adminp 要求が処理されていないときです。各ステップの前に、ユーザーに対する未処理の Adminp 要求が処理されたことを確認する必要があります。たとえば、ユーザーが自分のパスワードを2度変更したら、最終結果を記録する前に、両方の Adminp パスワード変更要求が処理されている必要があります。もし、最初の要求だけが処理されていたら、2番目の変更要求によってユーザー文書が更新されるまで、パスワード・ダイジェスト情報は同期していない状態になります。

これらの理由から、1日、2日程度の猶予期間と変更期間をもつパスワード・チェックをテストすることは推奨いたしません。

Adminp をカスタマイズしていたらv お客様のなかには、 Adminp タスクの代わりに独自の Adminp ツールを使用されている方もいます。この記事では、パスワード・チェックが確実に機能するように、Adminp タスクが実行する作業を強調してきました。カスタマイズされた Adminp は標準とは違う動作をし、その結果、ユーザー ID とユーザー文書との同期がとれなくなる可能性があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=334742
ArticleTitle=Iris Today Archives: パスワード・チェック
publish-date=09042001