大量ユーザーに対してダイアルインのプロパティにて「アクセスを許可する」にしたいという要望を受けてスクリプトを作ろうとしてみました。 そのときにユーザーのプロパティ変更に関して思っていたことは以下のような感じでした。
というわけで、今回の望みのものはADユーザーとコンピューターでも、net userでも、dsmod userでもできなかったので、ADSIで対応しようと考えました。
スクリプトセンターで探してみたところ望みのものがあっさり見つかりました。msNPAllowDialinが対象のプロパティのようなので、これをTrueにしてあげればいいだろうということで以下のようなスクリプトを作成しました。特定のパス以下の全ての階層をなめて、ユーザーオブジェクト全てのプロパティを書き換えることを意図しています。
さて実行してみると・・・。処理は正常に完了。GUIで見てみると・・・。・・・。・・・。変更されていません。 おかしい。ldifdeでユーザーの情報を見てみると、確かに意図した属性の変更は行われています。 でも、GUIには反映されていない・・・。
それではということで、GUIで設定を行う前と後をldifdeで取得しておき、fc(Windowsに標準で入っているdiffみたいなツール)で比較してみました。
確かにmsNPAllowDialinの値がGUI上の操作でも変わっています。ここは想定どおり。
むむむ。userParametersという属性も変更されています。しかもこの値を見る限り結構複雑な設定のされ方をされている属性のようです・・・（げんなり
ここで、げんなりして、Google先生に聞いてみました。 すると、みんな同じ問題で悩んでいました（＾＾；
ここではかなり私と同じような状況の方が・・・。ですが最終的には解決策を教えてもらったようです。わくわくしながら解決策を見ようとしたら・・・。1月$9.95との事(涙。こういうところにお金を使う気になれない貧乏性の私なのでした。experts-exchangeめー。
仕方が無いので、もうちょっと探してみました。
このKBにはADSIで作ったユーザーが後から設定を変更できないトラブルの解決策が書かれています。その中に以下の記述あり。 ““この問題は、msNPAllowDialin 設定と userParameters 設定が同期していない場合に発生します。 やっぱり、userParameters属性は他の複数の属性の和でできているような属性で、それがGUIをコントロールしている模様です。なぜそんなことをする必要があるのか??・・・。この属性を渡すことでいちいち全部の属性を個別にチェックしなくて幸せになるプログラムがあるのでしょうかね・・・。完全にあてずっぽうですが・・・。
ここではADSIではいじってはいけない属性だとの記述あり。 ““but be aware, according to the docs, “System Internal: Do not modify this attribute using LDAP. Use RAS MPR API to read and update values.” えー。マイクロソフトのスクリプトセンターのサンプルプログラムでいじっているのに?駄目なの?・・・。でも、RAS MPR APIを使えば良いらしいことが分かりました。
・・・しかし私にはこれが何のことかよく分からず、ググッてもすぐによいページは見つけられませんでした。そこまでやるのもなぁ・・・とちょっと弱気になりました。。。
と、ここまで調査したところの状況。
ADSIのプログラムはGUI表示上の問題のみでうまく動くかもしれないのでテスト
GUIでこのあたりのプロパティをあとからいじらないのなら問題ないかもしれない。
ワークアラウンドで対応
多分問題なしだけども、例外はどうやって対応したらいいんだろう?
・・・。もともと自分の問題じゃないから検証まではやる気になれません。またいつかこの問題に取り組む日があるかもしれないからBlogに記述して気がつかなかったことにしておきましょう・・・。