• 【Management】Windows Server 2008 DFS（分散ファイルシステム）でのアクセスベースの列挙 その2

    Posted over 6 years ago
    by junichia}

    前回の続きです。前回はこちら。

    【Management】Windows Server 2008 DFS（分散ファイルシステム）でのアクセスベースの列挙 その１

    「アクセスベースの列挙」により共有フォルダ配下の不必要なフォルダを見せないようにすることができます。

    同じようなことはDFS（分散ファイルシステム）でも可能ですが、方法が異なります。

    例えば、以下のようなDFS名前空間が定義されているとします。

    図2

    図の右側（\\FileSV1）が物理的な共有フォルダの構造です。それぞれのフォルダにはNTFSのアクセス権が設定されており、社員のアクセスが正しく制御されているとします。「一般社員用」フォルダ、「幹部社員用」フォルダともに「アクセスベースの列挙」が設定されていれば、その配下にあるアクセス権の無いフォルダは一覧にも表示されません。

    DFS名前空間にマッピングしたのが、図の左側です。

    一般社員が DFS名前空間  \\Contoso.jp\営業部 にアクセスしたとします。

    デフォルトの状態では、フォルダ一覧には「一般社員用」「幹部社員用」共に表示されますが、NTFSのアクセス権により幹部社員用フォルダにアクセスしようとすれば「アクセスが拒否されました」というエラーが発生します。

    では、DFS名前空間にもアクセスベースの列挙を適用し、「幹部社員用」フォルダが表示されないようにするにはどうしたらよいかといえば、dfsutil.exe コマンドを使用します。

    dfsutil.exe property ABDE enable \\contoso.jp\営業部

    ABDE は、Access Based Directory Enumlation の略であり、Enabled によって DFS名前空間ルート「\\contoso.jp\営業部」のアクセスベースの列挙機能を有効にしています。ちなみに、ABDE Enabled は、DFS名前空間ルートのみに設定できます。

    これに加え、さらに以下のコマンドで DFS名前空間内のアクセス権を設定する必要があります。

    dfsutil.exe property acl deny \\contoso.jp\営業部\幹部社員用 "contoso\一般社員グループ":F

    このコマンドでは、DFS名前空間「営業部」内の「幹部社員用」というエントリに対して、「contosoドメインの一般社員グループに所属するメンバー」からの一切のアクセス権（F）を拒否（Deny）しました。

    これにより、一般社員が \\contoso.jp\営業部 に接続しても、「幹部社員用」フォルダは一覧に表示されなくなります。

    幹部社員がアクセスした場合はどうかといえば、両方のフォルダが参照できます。「幹部社員用」フォルダ配下については、従来通り、NTFSのACLに定義されているアクセス権に沿ってアクセスベースの列挙が適用されます。つまり、dfsutil を使用しなくても、課長には「部長フォルダ」は表示されませんし、部長には「統括部長フォルダ」は表示されません。

  • 【Management】Windows Server 2008 DFS（分散ファイルシステム）でのアクセスベースの列挙 その１

    Posted over 6 years ago
    by junichia}

    「アクセスベースの列挙（Access-Based Enumeration）」という機能はご存知でしょうか？初めての方もいらっしゃるかもしれないので、例を挙げて説明します。

    詳しく知りたい方は、TechNet内のこちら をご覧ください。

    以下のようなフォルダ構成があったとします。Home は共有フォルダです。

    図1

    User01 が Z: ドライブに \\FileServer01\Home を接続した場合、Z:ドライブをエクスプローラーで開くと、おそらく、User02 や User03 など他のユーザーのフォルダも見えてしまいます。見えてしまっても、NTFSアクセス権さえ適切に設定しておけば、実際にアクセスしようとすれば「アクセス拒否」が発生します。よって、ひとまず心配は無いのですが、フォルダが見えてしまうということ自体、気持ち悪いかもしれません。

    Homeディレクトリの場合、その配下に1000人や5000人分のホームディレクトリが存在する可能性もあり、その中から自分のフォルダを探すのもかなり面倒です。一覧が表示されるまでに相当に時間がかかるかもしれません。

    そんなときに「アクセスベースの列挙」という機能を使用すると、アクセス権の無いフォルダは、はなから非表示にすることができるため、利用者を混乱させずにすみます。

    Windows Server 2008 でアクセスベースの列挙を設定するには、「共有と記憶域の管理」スナップインを使用します。サーバーマネージャからも「共有の記憶域の管理」にアクセスできます。

    image

    「共有と記憶域の管理」を開いたら、共有ファオルダの一覧から「アクセスベースの列挙」を有効にする共有フォルダを選択し、コンテキストメニューから[プロパティ]を開きます。

    以下をご覧ください。既定では「無効」に設定されています。

    image

    そこで、[詳細設定] をクリックして、以下のように「アクセスベースの列挙を有効にする」をチェックします。

    image

    これで、この共有フォルダの配下ではアクセスベースの列挙機能が有効になりました。

    今後、アクセス権のないフォルダは一切表示されなくなります。

    さて、同じようなことがDFSでもできるかどうか？

    できます。

    が、ここで紹介した方法では残念ながら実現できません。

    長くなったので、これについては次回の投稿で。

    ちなみに、Windows Server 2003 （SP1以降）での実装方法が、以下に書かれています。

    DFS 環境で Windows Server 2003 アクセス ベースの列挙を実装する方法
    http://support.microsoft.com/kb/907458/ja

  • 【パネリスト決定】 － 1/17 失敗しない分散ID管理 パネルディスカッション

    Posted over 6 years ago
    by junichia}

    多くの方々はクリスマス・イブの夜をさぞかしロマンチックに過ごすのでしょうね。いいですね。せいぜい明日遅刻しないでくださいね。

    さて、既にお知らせしたとおり、1月17日 に開催される Tech Fielders セミナー「失敗しない分散ID管理」では、業界のエキスパートをお呼びしてパネルディスカッションを行います。

    そのパネルディスカッションにご協力いただける各界のエキスパートが決定いたしましたので、自己紹介文と共にご紹介いたします。

    （順不同にて失礼いたします）

    エクスジェン・ネットワークス株式会社 江川 淳一 様

    エクスジェン・ネットワークス は 2000年8月の創業以来、LDAPサーバをID情報のマスタDBとして利用するID統合管理ツール「LDAPManager」を製造、販売している、パッケジソフトメーカーです。「LDAPManager」は、お客様が本当に必要な機能に的を絞り、年一度のバージョンアップによる機能強化を重ねることで、『低価格で、無理がない、無駄がない』、ID統合管理ツールを目指しております。日本で唯一のID統合管理専業パッケジソフトメーカーの代表として当日はID統合管理システム構築のポイントについて、皆様と議論できることを楽しみにしています。

    日本アイ・ビー・エム株式会社 前島 鷹賢（たかまさ） 様

    Microsoft MVP for Data Center Management - System Center Configuration Manager
    日本アイ・ビー・エムにて、IAサーバーを中心としたインフラ環境の設計・構築に従事。近年は特に、Windowsサーバー／クライアント環境のシステム管理・監視、セキュリティ、サーバー仮想化などの分野を専門としている。

    サン・マイクロシステムズ株式会社 佐藤 公理（きみまさ） 様

    サン・マイクロシステムズ株式会社 ソフトウェア・ビジネス統括本部で、アイデンティティ管理製品のプリセールス・エンジニアを担当。
    2001年にサンに入社。ISP をサポートするSEを経て、2002年よりプロフェッショナルサービスにてアイデンティティ管理製品の導入コンサルティング、設計、構築などを行なうコンサルタントとして活動。
    2006年より現職。コンサルタントとしての現場経験を生かして製品プロモーションから顧客への提案に至るまで幅広く活動中。
    私生活では二児の父として子育てに奮闘中。
    今回のセミナーへの参加では、休日を犠牲にしてセミナーに参加する熱意のある方との懇親会が今から楽しみ。

    株式会社野村総合研究所 工藤 達雄 様

    基盤ソリューション事業本部 基盤ソリューション事業一部 主任システムコンサルタント
    1998 年から 2008 年まで、サン・マイクロシステムズ (株) にてアイデンティティ管理分野のプリセールス・エンジニアおよびビジネス開発を歴任。2008 年、(株) 野村総合研究所に入社し、Uni-ID を中心とするアイデンティティ・ソリューションの企画を担当 (現職)。内部統制から OpenID まで、寄稿・講演多数。独立行政法人 情報処理推進機構 情報セキュリティ技術動向調査タスク・グループ委員 (アイデンティティ管理技術)。

    いやー、いまから楽しみで仕方ありません。まさに、お年玉企画といっても過言ではないでしょう。

    参加されるみなさんからもご質問を受けたいと思いますので、当日をお楽しみに！

    あ、そうそう。ライトニング・トークへのお申し込みもお待ちしております！

  • 【IDM】MSMQ を使って確実なユーザー登録を行う その9 ～ スクリプトをルールに登録する

    Posted over 6 years ago
    by junichia}

    今年の営業日も残り少なくなってきました。私がいるオフィスも、心なしか人が少ないような...いや確実に少ない。みなさん、年末年始は休めそうですか？私は...うーん...びみょーです。

    ＃これまでの投稿一覧は、この投稿の最下段に掲載してあります。

    ということで、今回は、その7 で完成させたスクリプトをルールに登録しましょう。

    MSMQのインストールと環境設定がまだという方は、その2、その3 をご覧ください。

    以下のような構成になっていればOKです。[Inputキュー] と [Errorキュー] が作成してあり、トリガーは [Inputキュー] のみに関連付けられています。

    msmq_settings13

    msmq_settings14

    msmq_settings15 

    スクリプトをルールに登録するには、規則のプロパティから [規則の操作] タブを開きます。今回は、事前に rule1 という規則が作成してありますので、こいつのプロパティを開きます。

    [規則の操作] タブの中にある [スタンドアロンの実行可能ファイル（EXE）を起動する] をチェックし、実行可能ファイルのパスとして、VBSファイルのホストプログラムである CScript.exe をフルパスで指定します。

    C:\Windows\System32\cscript.exe

    msmq_settings11

    次に、[パラメータ] ボタンをクリックし、起動パラメータを指定します。

    既に何らかのパラメータが指定されている場合には、すべて削除してしまってください。今回は使いません。ここでは、CScript.exe のパラメータとして、作成したVBSファイルを指定します。

    このとき、パラメータの種類として、「文字列リテラル」を選択し、VBSファイルのフルパスを「リテラル値」に記載します。今回は、作成したスクリプトをReceiveInputQueue.vbs という名前で保存してあります。

    以下の図を参考にしてください。

    msmq_settings12

    これで、ルールの設定は完了です。

    以降、新しいメッセージがInputキューに入ってくるたびに、ここで指定したルールが起動されます。

    そして、ADへのユーザー登録に問題が発生すれば、メッセージは Errorキュー に移動されます。

    次回は、Errorキュー に移動されたメッセージを定期的に Inputキューに戻す処理について考察してみます。

    ---

    これまでの投稿は以下の通りです。

  • 【IDM】MSMQ を使って確実なユーザー登録を行う その8 ～ MSMQトリガーのクセを理解する

    Posted over 6 years ago
    by junichia}

    さてもう一息ですね。第8回です。

    ＃これまでの投稿一覧はこの投稿の最下段に書いておきます。

    前回作成したスクリプトをキューのルールとして登録する前に、MSMQ運用に必要な知識について書いておきます。知識というよりも、クセですね。

    具体的には、何らかの原因によってスタックしてしまったメッセージを処理する方法です。これを知らないと、MSMQトリガーの運用は、結構困ります。

    -----

    MSMQトリガーに何らかの問題が発生したためルールが実行されなかったとします。

    この場合、メッセージはスクリプトによって処理されず、いつまでも以下のような状態でキューに残ってしまう可能性があります。

    例えば、スクリプトに不備があり、メッセージの送信が正常に行われなかった、などといったことが考えられます。

    msmq_custom01

    赤でくくった部分に注目してください。testuser001 ～ testuser020 までのユーザーが Inputキューに登録されていることがわかります。

    この状態で、MSMQが正常に戻った、もしくはスクリプトの不備修正が完了したとします。つまり、トリガーが正常に動作する状態になったと仮定します。

    ここに新たなメッセージが5件（testuser021 - 025）入ってきました。さて、どうなるでしょう？？？

    Receive の処理を理解していればわかりますよね。以下のように、古いものから処理され、後から入ってきたキューは後回しにされます。

    msmq_custom02

    このことから、「新しいメッセージが入ってこない限りトリガーが起動しない」ということが容易に想像できます。

    ＃古いメッセージから処理するかどうかは、環境設定およびスクリプトの作り方次第です。
    ＃今回はReceiveを使用したので古いものから順番に処理されています。

    これでは困るのでなんとかしたい。そんなときは、サービス一覧にある Message Queue Triggers サービスを再起動すれば、最も古いメッセージから順番にルールが実行されます。

    ここで覚えておいていただきたいのは、Message Queue Triggers サービスは Message Queue サービスとは分離されているので、停止してもメッセージが一時的に受け取れなくなるといった弊害は発生しません。

    これを知っていると、例えば、「実際の登録は明日の午前0時に開始したい」なんてことが実現できます。つまり、事前に Message Queue Triggers サービス停止した状態でメッセージを登録しておき、午前0時に起動してあげればよいわけです。

    もう一つ、スタックしたメッセージを処理する方法として、スクリプトを手動で実行するという手も考えられます。

    まとめると、以下の通りです。

    スタックしたメッセージを処理するには、

    • 新しいメッセージを登録してトリガーを起動する
    • Message Queue Triggers サービスを再起動する
    • メッセージを処理するスクリプトを手動で実行する

    のいずれかを実行する必要があります。

    是非とも覚えておいてください。

    ----

    これまでの投稿は以下の通りです。