当ブログに掲載しているサンプルは、すべて利用者の自己責任という形でお願いします。
ただし、明らかな不具合がある場合、ご連絡いただければ、訂正記事を出します。
また、こちらのサンプルは、別のサイト等への公開、転載は一切禁止しています。
どうしてもと言う場合は、筆者にあらかじめご連絡ください。
記事そのもののリンクについてはご自由に行っていただいてよいです。

テクてく Lotus 技術者 Slack に参加しよう!

2016年7月20日水曜日

認証期限切れのIDを再認証しよう

みなさん、こんにちは。

海の日が過ぎたのに、まだ関東は梅雨明けしてないそうです。
毎年、この梅雨入り/梅雨明けはいつだったのか?なんて議論があるので、いっそのことやめてしまえばいいのに・・・なんて思ってる今日この頃です(笑)


さて、今日はNotes IDの認証期限についてのお話です。
本番環境では認証期限が切れることはまずないと思います(事前に通知されますよね)。

ですが、私のように開発環境を複数所持している場合、誤って認証期限を切らせてしまうこともあります(いえ、ほんとはあってはならないことなんですけどね・・・)

さて、そんなときはどうすれば良いのでしょうか?
新しいユーザを作成する?いえいえ、まだ諦めるのは早いですよ。
認証者ID(cert.id)の認証期限さえ切れていなければ、まだ復旧できるのです。

ということで、手順を確認していきましょう。
※環境の都合上、 Lotus Domino 8.0.2を使用しますが、8.5.x以降も同様の操作での復旧が可能です。


まずは、シナリオの確認です。

1.シナリオ

  • 管理者ユーザ(Domino Administrator/Win2008R2)の認証期限が切れている
  • 管理者ユーザのパスワードは覚えており、ログインは可能
  • Dominoサーバは稼働可能(サーバーIDの認証期限は切れていない)
  • 認証者ID(cert.id)の認証期限は切れていない 
  • 管理者ユーザはDominoサーバにアクセスできない
  •  上記の状態で、管理者のユーザIDの認証期限を更新して、Dominoサーバにアクセスできるようにする

2.現象の確認

まずは本当にIDの認証期限が切れているのか、Dominoサーバにアクセスできないのかを確認してみます。
DominoサーバのNotes DB(今回は、ドミノディレクトリ)にアクセスしてみます。
・・・思いっきりエラーで弾かれてしまいました。
認証期限切れにより、Notes DBへのアクセス不可

画面では1回しかエラーダイアログが表示されていませんが、なぜか3回ほどこのエラーが表示されました(フレームセットの影響かな?)
次に下のようなダイアログが表示されました。
くどい!と思われるエラーダイアログ

まだNotes/Dominoの攻撃はやみません。
止め!と言わんばかりにステータスバーにもエラーが表示されています。
もう、わかりましたよ・・・ってと心が折れそうなメッセージの表示

3.IDの認証期限の確認

エラーメッセージが表示されましたが、それでも本当に認証期限が切れたのか?と疑ってしまうあなた。
次の手順で認証期限が有効なのか、無効なのかを確認します。
Notesクライアントの
[ファイル][セキュリティ][ユーザーセキュリティ]メニューを実行します。
ユーザーIDの情報を確認するためのメニューを実行

ユーザーIDのパスワードを入力すると、下図のようなダイアログが表示されます。
画面をよく見ると、「警告」 ということで有効期限が切れていることが通知されています(画面赤枠内)。
確かに有効期限が切れている・・・

ここは[キャンセル]をクリックして元の画面に戻ります。

4.IDの復旧

では、実際にユーザーIDの認証期限を延長してみます。
Domino Administrator(管理者クライアント)を起動します。

一番右にある[設定]タブを開きます。
画面右側にある「ツール」をクリックしてメニューを展開します(すでに展開していたら何もしない)。
さらに[認証]メニューをクリックして展開します。そこに[認証]というめにゅーがあるので、そこをクリックします(下図参照)。
認証メニューを実行します

すると、認証者の選択というダイアログが表示されるので、サーバーをLocalに変更します。
※[サーバー]というボタンをクリックすることで変更可能です(バージョンによっては、ローカルと表示されることがあります)。
認証場所をサーバーからLocalに変更します

認証者IDの欄には、認証者IDのファイル名が指定されていることを確認します。
※これが誤っていたら復旧できません!
変更したら、[OK]をクリックします。

次に認証者IDのパスワードを入力して[ログイン]をクリックします。

今度は、認証したいユーザーIDの選択画面になるので、3.で確認したユーザーIDのファイルを選択します。
認証期限が切れているユーザーIDを選択します

ユーザーのパスワード入力画面になるので、パスワードを入力して[ログイン]をクリックします。
パスワード入力画面、わかりますよね?

すると、認証場所をLocalにしているせいなのか、「エントリが索引に見つかりません」というエラーを表示してきます。
しかし、そんなのはわかってやっているので、[はい]をクリックします。
ドミノディレクトリでも検索してるのかな?

次にようやく「IDの認証」ダイアログが表示されます。
ここで初めて、有効期限がいつまでだったのかが表示されます(笑)下図ではなんとまぁ、1年前に切れていましたね(※実際には有効期限は切れていなかったのですが、今回の記事のためにわざわざ有効期限を期限切れにしてみました)
有効期限はいつまで入力可能なのかな?

「有効期限(新)」というフィールドには2年後の日付がセットされています。これはデフォルトの設定です。ただ、開発環境で2年ごとに有効期限の延長なんてやってられません。ここは大きく、延長してみましょう(実際の環境では2-3年にしておくことをお勧めします)。

思い切って、「9999/12/31 23:59:59」にしてみました(笑)絶対に生きてないって・・・
ということで、「有効期限(新)」に新しい認証期限を入力したら[認証]をクリックします。

何事もなく、下図のダイアログが表示されたら成功です。
無事に認証期限は延長されました。[いいえ]をクリックして処理を終了します。
え?成功しました。とか失敗しました。って表示はないの?

5.認証期限の確認

さて、本当に認証期限は延長されたのでしょうか?成功しました!とかのメッセージが何も出ていないので不安で仕方ありませんね(笑)
そこで、ユーザーIDの情報を確認して認証期限がどうなったのかを見てみます。
3.で実施した方法とは別のやり方で確認してみます。


Domino Administrator(管理者クライアント)の画面で、さきほど使用した「設定」タブ内の[ツール][認証][IDのプロパティ]メニューをクリックします(下図参照)。
IDのプロパティ情報を確認するためのメニュー

「調査するIDの選択」というダイアログが表示されるので、ユーザーIDを選択して[開く]をクリックします。
認証期限を延長したユーザーIDを選択します


ユーザーIDのパスワードを入力して[ログイン]をクリックします。

「ID プロパティ」というダイアログが表示されます。そこには認証期限が表示されています。が・・・
認証期限が!

なんと、「2114/09/10」になっています。確かに「9999/12/31 23:59:59」と入力したのですが・・・
どうやら、Notesの認証期限の限界は2114年9月10日のようです(あくまでLotus Notes/Domino 8.0.2の場合)。
といっても、ここまで誰も生き残ってないでしょうから(笑)、確認のしようがありません。でも十分すぎるほどの日付でしょう。

さて、認証期限の確認ができたので、実際にDominoサーバにアクセスできるかどうかを確認してみます。
この画面では[OK]をクリックしてダイアログを閉じます。
さらに、Domino Administrator(管理者クライアント)も終了しておきます。

6.Dominoサーバーへのアクセス確認

Notesクライアントに戻って、DominoサーバのNotes DB(今回は、ドミノディレクトリ)にアクセスしてみます。
エラーにならずにドミノディレクトリが開けたはずです。
無事にDominoサーバにアクセスできましたよ


はい。これで無事にユーザーIDの復旧ができました。
確認作業を入れているため、多くの手順があったように見えますが、実際の復旧手順としては「4.IDの復旧」の箇所だけです。
そう考えると、そんなに大変ではないな。と感じてくれれば幸いです。




なお、同じ内容のドキュメントがIBM様のサイトに出ていますので、こちらもよく読んでおきましょう。
画面ショットがないのでわかりにくいですが、書かれたとおりにやれば復旧できますよ。


(参考)期限切れ ID を手動で再認証する方法

管理者の ID ファイルの有効期限が切れた場合の回復手順について


では今日はこの辺で・・・

2016年7月1日金曜日

Notes/Dominoのアクセス権について

みなさん、こんにちは。
気が付いたら7月です。つまり、公約?が果たせなかった自分がここにいるということです。
なんでしょう、必要に迫られないとやらないという性格がモロにでてしまったという感じです。


さて、気を取り直して今日の話題。
今までNotes DBに対するアクセス権について取得したり設定したりといったサンプルプログラムを紹介してきましたが、
そもそもアクセス権とはなんぞや?ということに触れていませんでした。

ということで初心にかえって、ACLについて確認してみましょう。
(資料は以前に作成したものがあったのでそれを公開する形になります)。


まず、
Notes の文書をアクセスするためには、次の過程を踏まなければなりません。
  1. Notes DBへのアクセス
  2. ビューへのアクセス
  3. 文書へのアクセス
  4. アイテムへのアクセス
上記のそれぞれの中で、アクセス制御が発生します。
それらについて解説していきます。

1.Notes DBへのアクセス

Notes DBはファイルであり、データベース(以下、DB)ごとにアクセス制御が存在します。
アクセス制御は全部で次の7段階に分けられます。   
区分アイコン説明
管理者DBのすべての文書を閲覧することができる。
DBに文書を作成することができる。
DBのすべての文書を編集することができる。
DBの設計を変更することができる。
DBそのものを削除することができる。
設計者DBのすべての文書を閲覧することができる。
DBに文書を作成することができる。
DBのすべての文書を編集することができる。
DBの設計を変更することができる。
編集者DBのすべての文書を閲覧することができる。
DBに文書を作成することができる。
DBのすべての文書を編集することができる。
作成者DBのすべての文書を閲覧することができる。
DBに文書を作成することができる。
自分の作成した文書のみ編集することができる。
読者DBのすべての文書を閲覧することができる。
投稿者DBに文書を作成することができる。
なしDBを開くことはできない。


2.ビューへのアクセス

DBへアクセスすることが許されたら、ビューへアクセスできるかどうかのチェックが行われます。
ビューは、Notes DBの文書の一覧が表示されているものです。
ビューへのアクセスを禁止されるということは、文書へのアクセスを禁止しているといってもよいでしょう。
※ただし、ビューは入り口のようなものなので、複数のビューがある場合には、別のビューから一覧を表示して、文書へアクセスすることもできるので、厳密なアクセス制御とは言えません。


3.文書へのアクセス

文書は通常、DBへアクセスできるユーザーであれば、DBのアクセス権限に従った形でアクセスできます(「投稿者」以外は閲覧が可能)。
ただし、DBの設計方法によって、このルールを変更することができます。

「読者名」
このフィールドを設定することにより、文書を閲覧することができるユーザーを限定することができるのです。
設定内容説明
*
なし
アクセス制限がかかっていない状態。誰でも閲覧可能。
ユーザー名入力されているユーザーのみ閲覧可能。
グループ名そのグループ(Notesで定義してある)に所属しているユーザーのみ閲覧可能。
ユーザー名とグループ名の混在入力されているユーザー名と、グループに所属しているユーザーのみ閲覧可能。
上記以外グループ名でもないような名前などが入力されていると、誰も閲覧することができなくなる。

「作成者名」
DBに対して、文書を作成することができるのは、「投稿者」および「作成者」以上の権限を持つユーザーです。
この中でさらに、『すでに作成された文書』を編集することができるのは、「作成者」以上の権限を持つユーザーす。
1.DBへのアクセスで、「作成者」は『自分が作成した文書のみ編集することができる』となっていますが、ここでいう「自分が作成した文書」というのが、「作成者」フィールドの内容のことです。
設定内容説明
なし作成者が設定されていない状態。
「編集者」以上のユーザーのみ編集可能。
*「作成者」以上であれば、編集可能。
ユーザー名入力されているユーザーのみ編集可能。
グループ名そのグループ(Notesで定義してある)に所属しているユーザーのみ編集可能。
ユーザー名とグループ名の混在入力されているユーザー名と、グループに所属しているユーザーのみ編集可能。
上記以外「編集者」以上のユーザーのみ編集可能。
※つまり、「編集者」以上の権限を持つユーザーは、「作成者」フィールドの有無の関係なしに、文書を編集することができるのです。
※「作成者」フィールドに入力された内容が、文書の作成者という扱いになるので、実際には自分が作成していない(入力していない)文書でも編集できるようにすることも可能になります。
 →誰が作成したのかを明記しなければならないようなDBの場合、注意が必要です。


4.アイテムへのアクセス

文書へアクセスができると、その内容を閲覧することができますが、IBM Notes/Dominoの場合、さらに細かい設定ができます。

フィールドをいくつも用意することができますが、このフィールドをユーザーによって、編集権限を与えたりなくしたりすることができるのです。
例)→文書のタイトルだけは一度作成したら変更させたくないが、他の内容は変更しても良いという場合など。

アクセスを制限したいフィールドに設定を施すことでできるようになります。
 →この場合、「編集者」以上でないと、そのフィールドの内容を編集することができません。(作成者は、新規作成時に限り、入力が可能)
※この他に、セクション単位で、編集できるユーザーを制限する方法もあります。


5.文書の印刷/コピー

文書単位で、印刷、コピーを不可にすることができます。
あくまでも、文書単位なので、ある特定のユーザーだけが印刷できないようにするなどといった使い方(設定)はできません。
ただし、添付ファイルについては適用されません(起動・保存ができてしまう)。


6.文書の削除

「作成者」以上であれば、文書の削除を行うことができます。
ただし、アクセス権限に「文書の削除を許可する」というチェックがついていることが条件となります。(「作成者」は『自分の作成した文書』に限り、削除をすることができます。)
 →たとえ「管理者」でも、「文書の削除を許可する」にチェックが入っていなければ、文書を削除することはできないということを意味します。
(ただし、「管理者」はDBそのものを削除できてしまうので、そちらのほうが問題かもしれませんが・・・)
ACLの「文書の削除を許可」


※上記の設定は、すべてサーバー上のノーツDBに対して適用されます。
ローカルPC内のデータベースに対しては、有効になりません。
 →ローカルPCでもアクセス制御を適用させる方法はあるが、サーバーで施してもローカルPCにコピーする際に簡単にはずせてしまうので、ここでは記述しません。


いかがでしょうか。ACLについてなんとなくしか理解していなかった方や、IBM Notes/Dominoを最近始めました。という方は是非よく読んでいただきたいです。

では、今日はこの辺で・・・



Notes/Dominoで困ったことがあれば、弊社にお問い合わせください。
IBM Championの私が承ります!
お問い合わせはこちらから→Lotus Notes/Domino カスタマイズとセキュリティ強化 - 株式会社エフ