Lotus Notes/Domino (R) をこよなく愛して。。。。

ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、メーカーとは全く関係はありません。

また、メーカーのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>

Policyの不可解な動作

皆さんの環境でもPolicyを使ってユーザ登録やNotes、iNotesメールのプリファレンスの制御などを行っておられるのではないかと思います。

 

皆さんご存知のように、Policyには認証階層に適用する組織的Policy、個人やグループに個別に適用する明示的(動的)Policyがあります。

 

この明示的Policyですが、バージョンは幾つから搭載されたのか不明ですが、Policyを適用する個人やグループをPolicy文書内に保存する方法が新しく提供されています。

 

まず、このPolicy文書に適用先を保存した場合、以下のフィールドに保存が行われます。

 

フィールド名: AssignedUsrGrpNames
データ形式の種類: テキストリスト
データのサイズ: 25 バイト
シーケンス番号: 8
重複アイテム ID: 0
フィールドフラグ: SUMMARY NAMES

"Archive Enabled Users"

 

Administratorで「ユーザとグループ」タブを開き、動的ポリシーの「ユーザ/グループ別」ビューを見ると、どのグループやユーザに明示的Policyが適用されているかが参照できるようになっています。

ところが、このフィールドですが、明示的Policyの適用を解除しても、最初のEntryのみ残ってしまった状態となり、適切に判断が出来ない状態になってしまいます。

回避策は、Policy文書を直接編集して、フィールドの中身を削除するしか無いようですが、ミスの元となってしまいます。

 

更に不可解なのは、Policyの適用優先順位です。

例えば、組織的PolicyでiNotesのArchiveを完全に禁止する設定文書を適用します。

この設定文書では、「強制先:子ポリシー」のチェックを入れておきます。

このPolicyを適用すると、当然のことながら、全てのUserがiNotesでArchiveを利用することが出来なくなり、Menuすら表示されなくなります。

一方、明示的PolicyでiNotesのArchiveを許可する設定文書を適用します。

この設定文書では、「強制先:子ポリシー」のチェックを外しておきます。

このPolicyを個別のUserまたはGroupに適用した際に、適用先をPolicy文書に保存すると組織Policyの値が優先され、適用先をユーザ文書にすると正常に適用されると言う全く異なる動きとなるのです。

 

組織的Policyで設定した設定文書で、「強制先:子ポリシー」のチェックを外すと正常に適用されます。

 

AdministratorのUIから操作する際に、この違いは全く分かりませんし、通常は推奨されているPolicy文書への適用先保存を選択してしまうのではないでしょうか?

 

そもそも、「強制先:子ポリシー」の項目は、Policyを作成する際に子Policyを作成した場合に、親Policyの値を強制するための設定であり、上記の種類の異なるPolicy間で強制が働くと言うのは理解に苦しむ状況なのです。

 

HCLはいつものように、現在動いている動作が仕様であるかのように言いますが、本当にそうなんでしょうかね??

 

ちなみに、ヘルプには以下のように記載されています。

 

有効ポリシーは、次の手順で特定されます。

  1. 最初に、組織ポリシーが特定されて、適用されます。
  2. 次に、動的ポリシー割り当てに対応した明示的ポリシーが解決されて、適用されます。
  3. 最後に、動的ポリシー割り当てに対応していない明示的ポリシーが解決されて、適用されます。

前述のシーケンスでは、ユーザーのユーザー文書の明示的ポリシーが動的ポリシーよりも優先され、動的ポリシーが組織ポリシーよりも優先されます。

 

 

DJXユーザ登録で登録Policy設定でMail File不要のユーザの登録がErrorする

DJX管理ツールからユーザ登録する際、Policyでユーザ登録設定をOやOUで定義されている場合があるかと思いますが、このユーザ登録設定でメールDBが不要と設定されている場合に、ユーザ登録がErrorすることがあります。

 

エラーメッセージは以下のようになります。

 

処理結果 エラー
メッセージ メールテンプレート mailxx.ntf が、登録サーバー CN=<ServerName>/O=<Domain Name> にありません
ユーザーの登録は行われますが、メールファイルは作成されません
ユーザー ID ファイルは以下のファイル名で作成されました
xxxxxxxx.id

 

エラーに記述されている通り、Mail TemplateがServerに無い場合に発生するのですが、Version Upを行い、古いMail Templateは不要になり削除した場合に問題となります。

 

DJXのユーザ登録ロジックでは、以下のように、Mail DB不要のユーザでもTemplateの存在をチェックしているために発生します。

MailFileCreationが1で無い場合も、CreateMailDBのフラグを立てており、後のStepでMail Templateの存在チェックが行われ、エラーするのです。

 

        If doc.MailServer(0) <> "" And doc.MailFile(0) <> "" Then
            If PolicyDoc.MailFileCreation(0) ="1" Then
                reg.CreateMailDb = True
            Else
                reg.CreateMailDb = True
                reg.UseAdminProcess = True
            End If

・・・・・・

DO_CHECK_MAILTEMPLATE:
    ' Is the Template file Exist?
    On Error 4060 GoTo NO_ACCESSEXT2 ' No access privilege
    If reg.CreateMailDb = True Then
        Set mdb = thisSession.GetDatabase(doc.MailServer(0), reg.MailTemplateName)
        If mdb Is Nothing Then
            Call ErrorLogging(ERR_NO_MAILTEMPLATE, doc,  reg.MailTemplateName, doc.MailServer(0),"","")
            reg.CreateMailDb = False
            MAILFAIL = True
        Else
            If Not mdb.IsOpen Then
                Call ErrorLogging(ERR_NO_MAILTEMPLATE, doc,  reg.MailTemplateName, doc.MailServer(0),"","")
                reg.CreateMailDb = False
                MAILFAIL = True
            End If
        End If        
    End If

 

全くもって変な話ですが、これが現状のCodeです。

 

これが質が悪いのは、ユーザ登録Policy設定はかなり初期の段階で設定していると思いますが、設定文書で「他のインターネットメール」を指定していると、Mail Template指定するFieldすら表示されないことです。

このFieldはDefaultで設定され、ユーザ登録Policy設定を作成した時点のVersionに依存します。つまり、Version Up後も古いMail Templateが指定されたままとなっているのです。

 

つまり、サーバー移行とVersion Upを同時に行い、新サーバを新規に立てて、Mail DBなどのデータのみ移行した際にこの問題は発覚します。

こういう意味で、ユーザがなかなか気が付かず、質が悪いErrorということです。

 

回避策は、ユーザ登録Policy設定文書を編集し、一度メールシステムをメールファイルが必要なシステム(NotesやiNotes)に設定し、Mail Template名を最新のMail Templateに更新してから、再度、メールシステムを「他のインターネット」に戻すことです。

 

皆さんも、サーバ移行を伴うVersion Upの際にはご注意ください。

サーバ移行を伴わず、既存環境への上書きVersion Upを行う際には明示的にTemplateを整理しない限り問題はありません。

 

IEサポート終了

皆さんもご存知の通り、IEのサポートが終了します。

 

終了時期はクライアントの契約により異なるようですので注意ください。

 

EdgeにはIE Modeが搭載されていますが、動きとしてはIEモジュールを起動しているような動きで、全く別のBrowserが動作していると言った状態になります。

 

これに伴い、iNotesもIEのサポートを終了し、EdgeのIE Modeもサポートしないと言う状態になります。

 

つまり、Dominoとしては、EdgeをNative Modeで利用する必要が出てくる訳ですが、多くのユーザでは従来のWeb ApplicationはIEを前提に作成されている場合が多く、Regacy Applicationを利用するためには、EdgeのIE Modeを利用する以外無いのが現状です。

 

このEdgeのIE Modeも最も優遇された契約でも2029年に完全にサポート終了し、Edge Native Mode以外無くなってしまいますので、従来のアプリは早急にEdge Native Modeで動くように対応しなければなりません。

 

では、現状どんな影響があるのでしょうか?

 

皆さんの会社では、BrowserにHome Pageを設定し、Browserを起動すると自動的にPortalを表示するようにされていることが多いかと思います。

このPortalがEdge Native対応されていないと、ADのGPOなどでIE Modeで起動するように制御するしかありません。

方や、iNotesはIE Modeをサポートしなくなるので、必然的にGPOでEdge Native Modeで起動するように制御しなければなりません。

ということは、最初のLogin認証画面はIE Modeで表示される訳で、DominoのMulti-Server SSOのLTPAToken CookieはIE Modeに対して発行されます。

この後、Portal画面からiNotesに画面遷移すると、LTPAToken CookieはIE Mode側にしかないため、Edge Native Mode側で再度Login認証を求められてしまうといった事態になるのです。

これは複数Serverの場合だけでなく、単一Server内での画面遷移の場合にも発生します。

恐らく、Domino Single-Server SSO(Session認証)を行っていた場合にも同様の状態になると思われます。

 

ということで、まず、単一ServerでのSSOを行うには、そのServer全体が同じModeで動かなければならなくなるということです。

この状態でも、複数Server環境で、Server間でIE ModeのApplicationやNative ModeのiNotesを画面遷移するような場合、夫々のModeの前の画面が残っていれば、Cookieが保存されている為、SSOは可能と考えますが、画面を閉じてしまった場合は、Cookieが削除され、再度Login認証を求められてしまうのです。

 

これでは、Multi-Server SSOの意味が無い状態ということです。

 

これを解決する方法があるのか?と言われると、現時点では無いと言わざるを得ません。

 

※2022/04/12 追記

MSからEdge V.99以降の新機能として、EdgeのNative Mode/IE Modeの相互でのSession Cookieの引き渡しが実現されました。

これにより、Session Cookieに限られますが、画面遷移の際にCookieを引き継いでSSOが出来るようになります。
V.99までは、Native ModeからIE Modeへの片方向のみのサポートでした。
但し、動的Cookieの変更の反映は出来ないとのことで、画面遷移した際に引き継いだCookieが静的に利用されます。
DominoのLTPAToken Cookieに関しても、LTPATokenの設定上は期限有の状態ですが、URLにCokkieを付けて要求する際はExpire指定は無く、Session Cookieとして機能しているようですので、LTPATokenも両Mode間で引継ぎができます。

ADのGPOのSite Listで、
 
<shared-cookie domain="<LTPAToken Domain>" name="LtpaToken" source-engine="Both"></shared-cookie>
 
を指定することで、実現できます。
 
IEサポート終了目前ですが、DominoのMulti-Server SSOを使われる際は、Edge V.99以降を導入し、上記設定を行うことで回避してください。
※MSの情報にも記載されていますが、Windowsの前提KBもありますので、Windows10/11のFix適用も忘れないでください。
 

 

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>