必要最小限のTCPポートしか開いていないWindows Serverとファイルをやり取りする方法(Windows Server 2012 ServerをWebDavサーバー/クライアントにする方法)

最近はクラウドサービスなども多くなり、必要最小限のTCPポートしか開いていないWindows Server同士でファイルのやり取りをする必要が発生することが増えました。単純にエクスプローラーで「\\ServerName」などと入力すればアクセスできる同一LAN内とは違って色々と工夫が必要です。 リモートデスクトップ接続でドライブをマウントする 個人的に一番お手軽だと思うのはリモートデスクトップ接続時にローカルディスクを接続する方法です。 たったこれだけで、マイコンピューターから簡単にコピー出来ます。必要なポートもRDPのポートのみなのでお手軽ですね。 ただし、この方法だとリモートデスクトップ接続をしている時にしかアクセスできませんし、手動でコピーするのはいいとしても自動化するのは厳しいです。 WebDavを使う方法 何かいい方法はないかなぁと考えたのですがあまりいい物が思い浮かびませんでした。ftpでもsshでも自動化可能ですが、少々構成が手間です。そこで比較的構成しやすい方法としてWebDavなんてどうでしょうか? サーバー側でIISを動作させないといけないのですが、OSの標準機能で完結するので比較的構成しやすいのではとおもいます。WebDavサーバーとして構成する手順としては以下が簡単にまとまっています。 - [Deploy a File Server in the Cloud ( WebDav on Windows Azure ) - My Thoughts On IT…](http://mythoughtsonit.com/2013/05/deploy-a-file-server-in-the-cloud-webdav-on-windows-azure/) 例としてサイトのルートからWebDavを有効にしています。私の環境ではサブディレクトリからWebDavを有効にしてもそれだけではアクセス出来ず、やはりルートからWebDavを有効にしてあげる必要がありました。それにもならず、サブディレクトリで有効化した後、ルートでも有効化すると、サブディレクトリの設定がエラーで正常に開けなくもなってしまったので、現状サブディレクトリからの有効化はやってはいけない操作であるようにも見えます。 さて、これでサーバー側はOKです。クライアントからはnet useでドライブマップすることができます。昔はエクスプローラーのアドレスの部分にhttp://~とアドレスを入力すればアクセスできたOSもあったのですが、どうやらWindows8, Windows Server 2012ではnet useあるいはドライブマップをGUIから行うことでのみアクセスできるようです。 ここで規定の状態ではWindows 8からはアクセスできるのにWindows Server 2012からはアクセスできなくて困りました。結局調べたところ、WebDavクライアントとして動作するためには「WebClient」というサービスが動作している必要がある、ということがわかりました。このサービスがWindows 8は規定の状態で動作しているが、Windows Server 2012では動作していないので動かなかった、というわけです。 WebClientサービスのWindows Server 2012への導入方法 Windows Server 2012にWebClientサービスを導入するには「デスクトップエクスペリエンス」機能を導入してあげる必要があります。 機能を追加して再起動するとWebClientサービスが導入されます。 これでドライブマップを正常に行えるようになります。具体的には以下のようにコマンドを入力すれば良いです。 net use x: http://hogehoge/hoge password /USER:domain\username これでWebDav経由でファイルコピーを行う処理を全自動化できますね。

August 11, 2013 · 1 min · 胡田昌彦

ファイルサーバーのデザインについてのあれこれ

ファイルサーバーのデザインについて質問を受けて、色々要素があって一応説明したけれどもあまり伝わらなかった気がするのでブログに書いておいてみます。 注意というか前提 何に関してもそうなのですが「どうするのがベストなのか?」という問いにはたいていの場合答えはありません。「いや、ベストってのはなかなかないよね。お客さんの使い方にあわせてベターな選択肢がいくつかあるという話であって、例外が無いなんていうことはあり得ないし…ごにょごにょ……」というのが本音であり、紳士的な回答だと思います。 #だいたい、何かにおいて「こたえはこれです!こうしておけば間違いない!」なんてのは騙そうとしているか、その人自身盲目になっちゃってるかですよね。 #怪しい宗教とか怪しいビジネスとか疑似科学なら断言するでしょうけどね! とはいえ、技術要素を抑えた上で「こうすればこうなる。一方こうすればこうなる。こういう前提ならこの選択肢がいいんじゃない?」ということは言えるし、お客さんの前では「お客様の環境や使い方を考慮すると、私としてはこのようなデザインと進め方をお勧めします。」ということはやっぱりプロとして言わなくちゃいけないですよね。それをするためには技術的なことを抑えた上でお客さんの希望や使い方を良く聞いて、自分の頭で考えてアイデアを出さなくちゃいけないです。 特にファイルサーバーのデザインや運用に関してははっきりいって「うまくいってる!」「こうすれば成功確実!」というようなものは聞いたことがありません。ファイルサーバーの権限管理は破綻し、ゴミファイルが散乱し、慢性的に容量不足で、組織変更の度にアクセス権設定とフォルダ構成変更とで多大な工数が必要となり…となってしまっている環境も多数あると思います。 そういう分野であるという認識の元、以下を読んでもらえればと思います。 抑えておくべき技術的な事 まず抑えておくべきは以下の事項です。 - [アクセス権の理解(NTFSアクセス権と共有アクセス権) - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/04/15/%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%ae%e7%90%86%e8%a7%a3ntfs%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%a8%e5%85%b1%e6%9c%89%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9/) - [コピー&ペーストとカット&ペーストではNTFSアクセス権が異なる - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2008/10/30/%e3%82%b3%e3%83%94%e3%83%bc%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a8%e3%82%ab%e3%83%83%e3%83%88%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a7%e3%81%afntfs%e3%82%a2%e3%82%af%e3%82%bb/) アクセス権の設定個所は「NTFSアクセス権」「共有のアクセス権」の2つがあるので(Windows Server 2012ではさらにもう1つ増えましたがここでは触れない事にします。すぐに使われそうも無いので。)どちらかあるいは両方のパターンについてきちんと検討が必要です。 NTFSアクセス権を使ってアクセス権をコントロールすることに決めた場合にはそのファイルをコピー、移動した時のアクセス権の動きに付いても考慮が必要です。 その他にも知っておいた方がよい事柄を紹介します。 NTFSのアクセス権を維持したままファイルをコピーする方法はある - NTFSのアクセス権はxcopy, robocopy等のコマンドでオプションを適切につければ、コピーであってもアクセス権を維持することができる。 これについてはヘルプを見てもらえば一発で分かるかと思います。xcopyなら/oオプション、robocopyなら/SECオプションあたりで実現できます。 フォルダがネストしていて、別階層が共有されている場合ユーザーが混乱するかもしれない - 共有フォルダの作成方法によっては「同一のファイルに複数のUNCパスが存在する」という状況が起きる。しかもその際に共有のアクセス権の設定方法によっては「ある人は複数のUNCパスで同一のファイルを開けるのに、別の人はこちらのパスでは開けるけれども、別のパスでは開けない」ということが起きる。 これについてはちょっと補足説明があった方がいいでしょうか。例えば以下のパスがあるとします。 - D:¥Share →Shareとして共有(¥¥Server¥Share, 管理者のみフルコントロール) - D:¥Share¥Share2 →Share2として共有(¥¥Server¥Share2, Everyoneフルコントロール) さてここでD:¥Share¥Share2¥folder¥file1.txtというファイルがあったとします。このファイルは1の共有からたどると 「¥¥Server¥Share¥Share2¥folder¥file1.txt」というUNCパスになります。一方2の共有からだと 「¥¥Server¥Share2¥folder¥file1.txt」というUNCパスになります。 管理者であればどちらのUNCパスからでも同じファイルにアクセスする事ができます。一方管理者以外の人は1の共有からのパスにはアクセスできません(共有のアクセス権を持たないので)。しかし、2の共有からのパスにはアクセスする事ができます。 エンドユーザーがこの事を理解して「あの人はこの共有にはアクセス権を持たないからこっちの共有からのUNCパスを伝えてあげないとな」と、気を利かせてくれたりする……ということはかなり難しいと思いますし、それを期待してはいけないと思います。 また、この場合でも、NTFSのアクセス権のみで制御し、共有のアクセス権はだれでも何でもできるような権限設定の場合にはアクセス自体には何も問題が発生しない事になります。ユーザーさんはちょっと混乱するかもしれませんけどね……。 組織毎にフォルダ作成、権限設定をすると組織変更時に泣きたくなる 決行スタンダードなファイルサーバーの設計として、「組織毎に管理する」というのはあると思います。組織毎にセキュリティグループがあり、ファイルサーバーにも組織毎のフォルダがあり、その組織に所属する人はその中にアクセスできる(つまり、組織のフォルダに組織のセキュリティグループでのアクセス権が設定してある。共有アクセス権か、NTFSアクセス権かはここでは問わない)。 一見なんの問題もなさそうな、スタンダードな設計に思えますが以下の場合には悲惨な事になります。 - 組織が頻繁に変わる 組織変更の度にファイルサーバーの中のファイルやフォルダを移動して回らないといけなくなります。1つの組織が2つに分割したら?どのフォルダ、ファイルがどちらの組織に所属すべきなのかを全部担当者に聞いて回らないといけない事になります…。 - 別の部署と共有したいファイルが出てくる 別の部署と共有したいばあい共有用に別の場所をつくってそこに移動してもらうか、その特定のファイル、フォルダだけアクセス権を変更してしまうか…というようなイレギュラーな対応をする必要が出てくると思います。別の場所に移動するとその場所のアクセス権の設定はどうしても緩くなり、そうするとそこの使い勝手がいい物だからみんなそこにファイルを作るようになり…と当初の構成が無意味になってしまう事が良くあります。 かといって特定のファイル、フォルダだけアクセス権を変更すると、都度管理者が特別対応をしなくてはいけないので管理者の負荷が上がる上に、出来上がった特別ファイル、フォルダは次の部署移動の際にどう扱っていいのか分からない事に……。 ユーザーにフルコントロールを与えてしまうとデザインを維持できない ユーザーが自分で好き勝手できるようにフルコントロールを与えてしまうケースがあります。そうするとそのユーザーはそのフォルダ以下すべて完全に好き勝手できちゃいます。アクセス権も変更できてしまうので、ある程度の枠組みを決めてあったとしても事実上破綻します。もちろんそのフォルダ以下は完全に権限移譲するのと引き換えに管理責任もきちんと引き取ってもらえるのならいいのかもしれません。…が、部署毎のフォルダ構造があるなかに勝手に別部署用のフォルダを作られたりなどもできちゃうのでやはりフルコントロールは危ないと思います。 アクセス権はグループでつけておき、ユーザーはグループへの追加、削除で権限管理するのが大抵うまくいく これはかなり常識的な感じですが、アクセス権のエントリに個人名を出してしまうのは良くない方法だと思います。 - 個人で付与すると、アクセス権を追加、削除したいときにすべての場所に個別に設定を行う必要が出てくる。 - 個人にしておくと、その個人アカウントを削除したときにアクセス権のゴミが残ってしまう。(生SIDが見えちゃうやつですね。) - 「XXさんの後任なので同じ権限で」と言われても、くまなく見て回って個別にアクセス権をつけるしか無くなってしまう。 このようになってしまうので、まず、グループを作成し、グループで権限をつけ、そのグループメンバの追加削除でアクセス権のコントロールをするとうまくいきます。 ...

August 30, 2012 · 1 min · 胡田昌彦

アクセス権の理解(NTFSアクセス権と共有アクセス権)

今回はアクセス権の話です。主にファイルサーバーの運用時のお話になると思いますが、ファイル共有はいつでもどこでも(クライアントOSでも)簡単にできますので、すべてに関連するお話ですのでしっかり押さえておきましょう。 NTFSアクセス権 まずはNTFSアクセス権です。これはNTFSでフォーマットされたドライブであれば、すべてのフォルダ、ファイルが持っています。逆に言うと、FATでフォーマットされている場合にはファイルシステムとしてのアクセス権は設定できません。なので、この点だけをみてもNTFSアクセス権を採用すべきなわけです。 適当にファイルやフォルダのプロパティを開くと、「セキュリティ」タブがあります。 ここで、誰がどのような権限を持つかということを詳細に設定できます。エントリを追加するには[追加]を押して、エントリを追加し、アクセス権を設定することができます。 NTFSアクセス権の継承 新しいエントリは追加できますが、すでに登録されているエントリ(上記の例だとAdministratorsの権限)に関してはグレーアウトされていて編集できません。これはNTFSアクセス権が”継承”されているためです。継承の様子は[詳細設定]の中で確認できます。 つまり、上の階層で設定されたセキュリティの設定は基本的に子供は受け継ぐようにできているのです。自由に編集できるようにするためには明示的に継承をしないようにさせる必要があります。 この操作は[詳細設定]の中の[親からの継承可能なアクセス許可をこのオブジェクトと子オブジェクトすべてに伝達できるようにし、それらをここで明示的に定義されているものに含める]という長ったらしいチェックボックスを外すことで実現できます。 チェックボックスを外そうとすると上記のように説明がなされて、現在の設定をコピーするのか、一度すべて削除するのかを選択することができます。どちらを選んでも最終的に設定したいことに変化があるわけではないので、つど、効率の良い方を選べばよいです。 上記の画像は[コピー]を選んだ場合ですが、継承元がすべて[継承なし]になり今まで編集できなかったエントリも編集できるようになっていることがわかります。 自由にアクセス権をつけるためにはバンバン継承を切る必要があり、そうすればいくらでも自由に設定できるのですが、はたしてそれで管理上良いのか?という問題が残ります。場合にもよりますが、たいていの場合はあまり良いことではないでしょう。 このあたりの話はファイルサーバーの設計の話にもつながってくるので詳細は別のエントリで書きたいと思います。 所有者 [詳細設定]ボタンの中に[所有者]というタブがあります。 ここではフォルダ、ファイルの現在の所有者の確認と、所有者の変更が行えます。つまり、他の人が作ったフォルダ、ファイルを自分のものにしてしまえるわけです。 何のためにこのような機能があるのかというと、管理者がきちんと全てのフォルダ、ファイルを管理できるようにするためです。この機能がないと、誰かが誰も触れないようなセキュリティ設定をしてしまった後で、そのアカウントすら(退社などで)消してしまったような時に打つ手がなくなってしまうからです。 共有のアクセス権 共有のアクセス権はフォルダのプロパティの[共有]タブ内の[アクセス許可]から設定できます。 NTFSのアクセス権と比べるとはるかにシンプルです。権限も3種類しかありませんし、継承という概念もありません。 共有のアクセス権とNTFSのアクセス権の適用タイミング それぞれの設定がどのように適用されるのか、というと、以下のようなルールになっています。 ファイル共有を経由したアクセスの時にのみ共有のアクセス権が適用される 同じファイル、フォルダへのアクセスであっても、別のファイル共有を経由してアクセスした場合には、異なる共有アクセス権が適用される NTFSのアクセス権は常に適用される(「別経路」が存在しないから) 共有のアクセス件とNTFSのアクセス権で異なるアクセス権の場合には、両方で許可されていることのみが行える 一番気をつけなくてはいけないのは、「共有のアクセス権でアクセス制限しているのでNTFSのアクセス権は制限していない」場合に、「直接コンソールでログインされるとアクセスできてしまう」ということです。気をつけましょう。 また、それぞれの特徴として以下のようなものがあります。 NTFSのアクセス権はファイル、フォルダ単位の設定であるため、半永久的に残る。場所を移動した場合でも残る。(※例外あり。詳細は「コピー&ペーストとカット&ペーストではNTFSアクセス権が異なる」参照。) 共有のアクセス権は共有を解除するときれいに無くなる。 共有のアクセス権に細かくエントリを追加していると、それを意図せず解除してしまった場合には、同じ設定を再度行うことが困難になりますので、気をつけましょう。 どのようにアクセス制御すべきか 「で、結局どうしたらいいの?」という問いに関しては色々な答えが考えられるでしょうが、私の方針は以下のようなものです。 共有のアクセス権は常にEveryoneフルコントロール NTFSのアクセス権でのみ制御する 共有のアクセス権とNTFSアクセス権の2重管理は嫌ですし、共有のアクセス権だけでコントロールしようとするのは抜け道があるので嫌です。そうすると必然的にこのような方針になると思います。 「いや、それだとこういった問題がある」「もっとこうしたほうがいい」などコメントありましたら、是非いただければと思います。

April 15, 2009 · 1 min · 胡田昌彦