[ILM2007FP1] MA 作成時に Forest 指定個所で 80230910 発生（スキーマの補助クラスには top 以外のオブジェクトから継承したものを置いてはいけません）
みなさまこんばんは。いま東京は夜中のおおむね 2 時くらいです。現在アメリカ出張中の同僚から、そろそろ帰りますとメッセンジャーが飛んできました。そんな私は日曜日から大阪出張です。月曜は大阪で将来有望な大学生に向かって「君、いい体してるねえ。うちの会社来ないかい？ 」みたいな感じでうちの部門がどんな仕事をしてるかを語りに行くのです。果たして私のつたない語りで、あの全人口が面白いという大阪で通じるか不安ですが逝ってきます。
【今日のお題】
MA 作成時、特定の Active Directory のフォレストに対し、フォレスト指定個所で “80230910” とだけしかかいてないエラーダイアログがポップアップされて先に行けない。
(だけど telnet:389 でアクセスは可能)
【解決方法 (?) 】
接続対象の AD スキーマに "top" クラスから継承されていない補助クラス(Auxiliary) がある場合に発生します。ちなみに、この動作は障害ではなく、設計上想定された動作です。
この補助クラスを無効化しても、KB 952327 のモジュールを適用しない場合、スキーマ解析時にエラーが発生してしまいます。無効化したのち、952327 を適用してください。
なお、下記の引用では、AD MA が対象のような記載となってますが、実際には AD 接続を行うすべての MA で発生します。
Article ID: 952327 - Last Review: November 10, 2008 - Revision: 2.0
A hotfix rollup package (build 3.3.1067.2) is available for Identity Lifecycle Manager 2007 Feature Pack 1
https://support.microsoft.com/default.aspx?scid=952327
（以下引用）
Active Directory Management Agent does not ignore defunct classes
You add an auxiliary class to Active Directory that inherits from any class other than the top class. However, errors occur in ILM when you create an Active Directory MA or when you update the schema after you add the class.
These errors occur even if the auxiliary class is marked as Inactive in the Active Directory schema. ILM build 3.3.1067.2 ignores defunct Active Directory classes.
【詳細】
今回の詳細は、どんな風に調査をしたのかを説明したいと思います。
いやらしいことに、このエラー、エラーコード以外に何も記述がない、ダイアログというよりメッセージ ボックスしか出ません。
ダイアログが出ている時点にて、Windbg デバッガでダンプをとってみますと以下のような例外が発生してます。
0:013> !dae
(… Snip …)
Number of exceptions of this type: 1
Exception MethodTable: 07ae9b0c
Exception object: 01474198
Exception type: Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
Message: 80230910
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131500
… (以下略) …
0:013> !dumpmt 07ae9b0c
EEClass: 07b2209c
Module: 06eb35f8
Name: Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
mdToken: 02000002
BaseSize: 0x48
ComponentSize: 0x0
Number of IFaces in IFaceMap: 2
Slots in VTable: 18
… (以下略) …
StackTrace (generated):
SP IP Function
0A6EEC50 0794F66A Microsoft.DirectoryServices.MetadirectoryServices.Schema.Schema.Create(System.String, Boolean)
0A6EED68 0794F538 Microsoft.DirectoryServices.MetadirectoryServices.Schema.Schema.Create(System.String)
0A6EED6C 0794EF02
… (以下略) …
StackTraceString: <none>
HResult: 80131500
あとはスタックトレースにあるMicrosoft.DirectoryServices.MetadirectoryServices.Schema.Schema.Create(System.String, Boolean)
あたりを探していって、スキーマ処理に問題があると判断。スタックに残っているオブジェクトを全部ダンプします。
0:013> !dso
OS Thread Id: 0xf7c (13)
ESP/REG Object Name
0916f340 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f38c 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f3a0 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f3a4 013f796c System.Threading.ContextCallback
0916f3d0 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f3d8 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f3e0 013f796c System.Threading.ContextCallback
0916f434 01474198 Microsoft.DirectoryServices.MetadirectoryServices.Schema.SchemaError
0916f4cc 025d8040 System.String
<dsml xmlns="https://www.dsml.org/DSML" xmlns:m="https://www.microsoft.com/MMS/DSML"><directory-schema><attribute-type id="A0"
… (以下略) …
0:013> !do 025d8040
Name: System.String
MethodTable: 790fa3e0
EEClass: 790fa340
Size: 1965032(0x1dfbe8) bytes
GC Generation: 3
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String:
<dsml xmlns="https://www.dsml.org/DSML" xmlns:m="https://www.microsoft.com/MMS/DSML"><directory-schema><attribute-type id="A0"
… (以下略) …
single-value="true"><name>pKIExpirationPeriod</name><syntax>1.3.6.1.4.1.1466.115.121.1.40</syntax></attribute-type><attribute-type id
Fields:
MT Field Offset Type VT Attr Value Name
790fed1c 4000096 4 System.Int32 1 instance 982508 m_arrayLength
790fed1c 4000097 8 System.Int32 1 instance 982507 m_stringLength
790fbefc 4000098 c System.Char 1 instance d m_firstChar
790fa3e0 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00149868:790d6584 <<
79124670 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00149868:013d13e4 <<
これだけだと、データがまるで切れているように見えてしまいますね。データが本当に切れたものをあつかっているのか、デバッガ上の表示の制限なのかわかりません。
そこでデータのオブジェクトにオフセットcの分を加算したところをダンプします。
(ちなみに、デバッガ上の行数にして 3 万行くらいかかりました。死ぬかと思ったです)
0:013> du 025d8040+c
025d804c ".. <dsml xmlns="https://www.dsml"
025d808c ".org/DSML" xmlns:m="https://www.m"
025d80cc "icrosoft.com/MMS/DSML"><director"
… (以下略) …
Unicode なので、データは実際に 2 バイトになります。
m_arrayLength で出ているのが、全体の長さなので、上記のデータのオブジェクト + オフセット c 分から m_arrayLength の 982508 分を足した値 × 2 が終端になります。
0:013> ? 025d8040+c+0n982508*2
Evaluate expression: 41647140 = 027b7c24
上記計算から、終端は 027b7c24 だとわかります。
終端より少し前あたり (-8 した位のあたり) を見てみます。 </dsml> で全体のタグが閉じられていることがわかります。
0:013> du 027b7c04
027b7c04 "hema> </dsml> .. "
ちなみにdu コマンドで、始端から終端までひたすらダンプし続けて、その結果をメモ帳かなんかに保存して、さらに先頭のアドレスとダブルクオートを削除するなどして成形するとスキーマの構成が全部見られる xml ファイルがゲットできます。
この調査の場合、お客様から残念ながら拡張スキーマ情報をいただけなかったので、この方法でXML をつくるという力技でスキーマを解析しました。
すると、以下のような補助クラスを発見しました。(※クラス名は実際の名前ではないです)
- <class id="TEST3" superior="#TEST1" type="auxiliary">
<name>testauxclass</name>
これは、TEST1 から継承された補助クラスです。TEST1 とは何でしょうか。
- <class id="TEST1" superior="#TEST2" type="structural">
<name>person</name>
ここに、person から継承した testauxclass という補助クラスがあります。testauxclass の資料を社内・外で検索してみましたが、何も見つかりませんでした。そのため、これはカスタム スキーマ拡張と予想してお客様に伺ったところ、実際に独自拡張だったそうです。
一方、他の Auxiliary クラスを見た場合、次のようなものがあります。
- <class id="TEST3d" superior="#TEST2" type="auxiliary">
<name>testObj</name>
これは TEST2 から継承されています。では TEST2 は何から継承されてるのでしょう？
- <class id="TEST2" type="abstract">
<name>top</name>
つまり、top から継承されています。
この結果から、問題は testauxclass クラスだと判断した次第です。
さて、そんなこんなで今日は某番組で、宇宙刑事シャイダーの DVD を見ている息子を差し置いて、猪木 vs アリ戦プレイバックを見てたんですが、いやほんといい試合。このころの猪木は特にすばらしいです。私たちサポートは、顧客満足度で最高の評価をいただくために電話一本でお客様のトラブルシュートをしないといけない、毎日がアリ戦のような感じです。見に行けば一発なことも多いのですが、契約上それができなかったり、さまざまな理由で調査が難しいのが基本ですので、なんか見てて勇気出ました。ありがとう猪木！
頑張って学生さん勧誘してきます！
～ういこう@やっぱりカールゴッチだよね～
(補足 : Windbg について)
Windbg はどなたでもダウンロード可能な無償のツールです。
問題が発生して、ダンプファイルが出力されて解析するにはもってこいです。コマンドベースなので大変とっつきにくいですが、こういうの好きな方は楽しいかも。ちなみに Live Search ると、カーネルデバッグ用とかドライバ開発用とか書いてありますが、何でもデバッグできますよ。ライブデバッグもオッケーですし、エクステンションを読み込めば、.NET Framework ベースのアプリもデバッグできます。
Windbg の導入や使い方については、d 先生がくわしいです。
https://blogs.msdn.com/d99/default.aspx
Windows 用デバッグ ツール: 概要
https://www.microsoft.com/japan/whdc/DevTools/Debugging/default.mspx
デバッグ ツールとシンボル: はじめに
https://www.microsoft.com/japan/whdc/DevTools/Debugging/debugstart.mspx