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はいつものように、現在動いている動作が仕様であるかのように言いますが、本当にそうなんでしょうかね？？
ちなみに、ヘルプには以下のように記載されています。
有効ポリシーは、次の手順で特定されます。
- 最初に、組織ポリシーが特定されて、適用されます。
- 次に、動的ポリシー割り当てに対応した明示的ポリシーが解決されて、適用されます。
- 最後に、動的ポリシー割り当てに対応していない明示的ポリシーが解決されて、適用されます。
前述のシーケンスでは、ユーザーのユーザー文書の明示的ポリシーが動的ポリシーよりも優先され、動的ポリシーが組織ポリシーよりも優先されます。
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の引き渡しが実現されました。
ADのGPOのSite Listで、