ICACLSを使用してユーザーディレクトリにアクセス許可を設定する


16

ユーザーディレクトリのアクセス許可をリセットしようとしていますが、スクリプトの最後のステップで少し問題があります。私のスクリプトは基本的にユーザーディレクトリ全体の所有権を取得し、ディレクトリのすべてのファイルとフォルダのアクセス許可をリセットし、必要なアクセス許可を明示的に付与し、親フォルダからのアクセス許可の継承をすべて停止し、すべてのファイルの正当な所有者(指定されたユーザー)を設定しますおよびフォルダを作成し、ファイルに操作できるように自分に与えた許可を削除します。すべてのファイルとサブフォルダーから自分自身を削除するには、この最後の手順が必要ですが、現時点では、%userDir%から自分を削除し、継承されたすべてのアクセス許可を以下に残します。これはICACLSの明らかな欠点です。誰もこれを達成する他の方法を知っていますか?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"

Microsoftによって作成された、サポートされていないXCACLS.vbsスクリプトをいじっていますが、スクリプトの最後の行でそれを採用することができました。このICACLSの代わりに "E:\ Home Directories \%userDir%" / remove "MYDOMAIN \%username%"をcscript.exe xcacls.vbs "e:\ Test" / E / R "MYDOMAIN \%に置き換えましたusername% "これは機能しますが、パフォーマンスに重大な問題があるため、XCACLS.vbsの使用は避けたいと思います。他のアイデアはありますか?
pk。

回答:


18

最初の観察:継承をブロックするたびに、将来の柔軟性から自分を切り離しています。どうしても継承をブロックすることは避けます。

たとえば、ユーザーが最上位の「E:\ Home Directories」フォルダーの内容を一覧表示できるようにする必要がある場合は、次の権限を検討してください。

  • SYSTEM-フルコントロール-このフォルダー、サブフォルダー、およびファイルに適用
  • BUILTIN \ Administrators-フルコントロール-このフォルダー、サブフォルダー、およびファイルに適用
  • BUILTIN \ Authenticated Users-読み取りと実行-このフォルダーのみに適用

最後のアクセス許可はサブフォルダーに継承されません。各サブフォルダーで、継承は有効なままで、「変更」または「フルコントロール」権限を持つユーザーを指定するだけです(ユーザーがホームディレクトリ内でアクセス許可を設定できるかどうかに応じて)。(通常、最後のアクセス許可を設定するには、「詳細」以外のセキュリティプロパティシートに「認証済みユーザー」を追加し、「読み取り」および「読み取りと実行」チェックボックスをオフにします。次に、「詳細」ダイアログに進み、そのACEの[適用先]設定を[このフォルダのみ]に設定します。これは、クリック数の観点から設定する最も簡単な方法です)

次に、スクリプトは次のようになります。

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

上記で説明した「Authenticated Users」権限と「This folder only」に設定された継承を追加すると、機能で探しているものが得られ、将来的には柔軟性が得られると思います将来的にすべてのユーザーのホームディレクトリに継承する必要があるかもしれない許可を設定する必要があること。

これは、ユーザーのホームディレクトリ、リダイレクトされた「マイドキュメント」、「デスクトップ」などのフォルダー、および移動ユーザープロファイルディレクトリのSOPです。それは素晴らしい作品です。

編集

re:BUILTIN \ Administratorsアクセスに関するコメント

私は、長年にわたってBUILTIN \ Administratorsアクセスを許可することについて、人々とさまざまな議論をしてきました。

  • ファイルにアクセスできれば、特定のクラスのユーザーの問題を簡単に解決できます。「所有権を取得する」のは苦痛であり、多数のファイルが存在する場合は非常に遅くなる可能性があります。

  • ICACLSで見たように、BUILTIN \ Administratorsは所有権を「割り当てる」ことができます(「取得する」以外に)。そもそもBUILTIN \ Administratorsがファイルにアクセスできないことによって「セキュリティ」が追加されることはありません。

  • 監査を使用している場合(および潜在的に膨大な数の誤検出エントリをふるいにかけている場合を除く)、BUILTIN \ Administratorsユーザーがアクセスしてはならないファイルの所有権を取得し、コピーした後、監査証跡はありませんファイルを「適切な」所有者と許可に戻します。

  • Microsoftの世界では、暗号化ファイルシステム(EFS)は、不正なBUILTIN \ Administratorsアクセスが発生しないようにする問題を解決することを目的としています。NTFS ACLはその問題を解決しません。(明らかに、EFSは町で唯一のショーではありません。暗号化は、どのようにスライスしても「ネットワーク管理者のアクセスを制限する」問題を解決する本当の答えです。)

私の考えでは、BUILTIN \ Administratorsにユーザーのホームディレクトリ(および実際には任意のフォルダー)へのアクセス権を指定しないことは、実際のセキュリティを提供する一方で、問題を解決するのに必要な複雑さと時間を増加させることを意味します「何もないところに誤った安心感を与えるからです」。

私は論理的に人々との議論に勝とうとすることをあきらめました。一部の人々にとっては感情的な問題のようです。Exchange組織のルートに配置され、特定の特権グループがユーザーのメールボックスを開かないようにする愚かな「拒否/受信」ACEのようなものです。実際のセキュリティ(監査なしで必要に応じてACEを削除/再適用できるため)、誤ったセキュリティの感覚を提供し、実際の問題を解決するときに邪魔になります。

BUILTIN \ Administratorsにアクセスできるという私の議論が気に入らなくても、必要に応じて "This folder only"継承を使用することにより、継承階層をそのまま維持したいです。許可階層での継承のブロックは、設計に関する何かが「壊れている」(反転など)ことを示す確かな兆候です。


1
BUILTIN \ Administratorsにディレクトリ構造全体へのフルアクセスを許可することをお勧めしますか?私たち(管理者)は、所有権を取得せずに、すべてのユーザーのディレクトリ/プロファイルに完全にアクセスするべきではないと考えています。
pk。

+1、誤った安心感についてのポイントが大好き
...-DCookie

1

まず、スクリプトの抜粋をありがとう。私は同じものに取り組んできましたが、別の場所で立ち往生しました。私のSBS 2008ボックスでは、以下のコードが動作します(もちろん、それが昇格されていると仮定しています)。OSによって作成された真新しい(既定の)ユーザーフォルダーのicacls%userdir%/ tを実行し、このスクリプトを実行した後、フォルダーのicacls%userdir%/ tと比較しました。私は」が正しいです。うまくいけばそれもあなたのために働くでしょう。

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

宜しくお願いします、

 -d

スクリプトの最終行を必ず確認してください。ICACLSが継承されたアクセス許可を正常に削除しないことは私の経験でした。「MYDOMAIN \%username%」フォルダーのエントリを削除しますが、サブフォルダーのアクセス許可は変更されません。したがって、「MYDOMAIN \%username%」は直接アクセスした場合でもサブフォルダーにアクセスできますが、サブフォルダーを参照することはできません。XCACLS.vbsはこれを解決しました。cscript.exe xcacls.vbs "e:\ Test" / E / R "MYDOMAIN \%username%"
pk。

それはどこです。私の編集の一部でした。親フォルダーで/ inheritance:rを実行すると、同じ問題が発生しました。しかし、それを行う親フォルダでトリックを行うように見えた。上記を実行した後、%userdir%には%username%、システム、および管理者がいますが、その下にあるものはすべて%username%とsystemであり、サーバーがそれらを最初に設定する方法です。

-1

技術的に可能な場合は、要件に応じてこのコマンドを変更してください。

ここに構造があります

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix ....など

各User $フォルダーの下に、「unix」という名前のフォルダーがあります。

「親」フォルダーの下にリストされているすべてのUser $フォルダー(上記の構造の名前)に対する完全なアクセス許可を持つユーザーまたはグループを追加しますが、「unix」フォルダーのみのアクセス許可を除外します。

このコマンドは、必要なアクセス許可の適用性の観点からはうまく機能しますが、これに除外機能を追加することはできません。

icacls "\\ Server \ Parent \ UserA" / grant Domain \ Group:(OI)(CI)F / T

このシナリオでガイドできますか?


1
こんにちは、Server Faultへようこそ!answerで質問しないでください。[ 質問する ]ボタンを使用して、リクエストを投稿します。
氏シュンツ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.