🦀 ⌚️ 👩🏻‍⚕️ PowerShellおよびADSI APIを使用したドメインアクセス許可の管理 🌩️ 🕺🏼 🌄

こんにちは ADSIおよびPowerShellインターフェイスを使用して、リソースへのユーザー権利の割り当てを自動化する方法を検討してください。最初は、古いWindows 2003ドメインコントローラーを使用し、インターネットアクセスを制限したときに問題が発生しました。このトピックは、以前にHabréで取り上げられました。私が説明したケースでは、Windows 2008 OSへの移行は部分的にしか行われませんでしたが、プロセスの複雑さと長さの点では、おそらく火星へのミッションに匹敵します。

問題文：

大規模な組織で新しいユーザーを作成すると、このアカウントのメンバーであるADグループを含む、このアカウントのすべての特権を説明するドキュメントが作成されます。

多数の共有リソースを持つユーザーのファイルストレージとして使用されるストレージシステムがあります。ストレージシステム上の各共有リソース（またはボール）には、少なくとも2つのADアクセスグループを含むアクセス制御リスト（ACL）が含まれています-ユーザー（読み取りおよび実行権限）と管理（編集および削除）。 ADの両方のグループの名前には、検索を容易にするためにリソース自体の名前が含まれています。したがって、リソースへのフルアクセスには、両方のグループのメンバーシップが必要です。

ストレージシステムには、パブリックドメインのリソースへのリンクへのショートカットを含むディレクトリもあります。ドメインの新しいエントリがログインすると、Startup.scriptを含むグループポリシーが処理されます。スクリプトは、必要なすべてのショートカットをユーザーのデスクトップにコピーします。ユーザーは何も検索せず、すぐに必要なすべてのドキュメントにアクセスできます。

私たちのタスクは次のとおりです。

ユーザーを作成します。
ユーザーがアクセスする必要があるディレクトリのリストを定義します。
ディレクトリ名を含む名前でグループを作成します。
グループをACLディレクトリに追加します。各グループに適切なNTFS権限を割り当てます。
作成されたグループにユーザーを含めます。
タイトルにディレクトリ名を使用してショートカットを作成します。
Startup.scriptを更新します。ユーザーがグループのいずれかにいる場合は、対応するショートカットをデスクトップにコピーします。
利用可能な技術的手段を使用します。

Windowsシステムで上記のアクションを実行するには、少なくとも4つの方法があります。言うまでもなく、1人の新しいユーザーでも標準のスナップインを使用してこれらのアクションを実行すると、マウスの100回のクリックに対応できなくなります。 50人のユーザーとアクセス権限がある場合、1日でそれを行うことはできません。各アイテムを個別に自動化しようとします。ユーザーの作成については詳しく説明しません。これは簡単にアクセスできる情報です。

ポイント7も記事の範囲を超えています。実際、GPOポリシーの管理用テンプレートです。スクリプトの内容は次のとおりです。ユーザーがグループに属している場合、特定のディレクトリからデスクトップに対応するショートカットをコピーする必要があります。他のすべてもPowerShellでかなり自動化されています。

エラーやその他のニュアンスをチェックせずにテストスクリプトを記述します。

テストの変数を手動で決定します。ユーザーの氏名と利用可能なリソースのリストは、アカウント作成ドキュメントから取得されます。

$server_name = read-host -prompt "Enter fileserver" $share_name = read-host -prompt "Enter share_name" $UNC="\\$server_name"+"\$share_name"+"$"

すべてを正しく入力したら、最初にディレクトリとそれを参照するショートカットを作成します。

 if ($server_name -eq "S182froc152"){ $path = "\\$server_name" +"\vol1$\projetspec2\" #Check if the directory exists. Skip if true. if(!(Test-Path($UNC))) { #Create directories Write-Host "Creating $share_name" New-Item -path $path -name $share_name -Type directory

COMオブジェクトを介してショートカットを作成します。

 Write-Host "Creating shortcut" New-Item -path $path\E182_P_GroupWare\Projets_Specifiques\$share_name -Type directory $wsh = New-Object -com 'WScript.Shell' $dir = "$path\E182_P_GroupWare\Projets_Specifiques\$share_name" $sct = $wsh.CreateShortcut("$dir" +"\$share_name.lnk") $sct.TargetPath =$UNC $sct.Save()

セキュリティグループを作成します。

まず、ちょっとした理論：

ADにはセキュリティグループと配布グループがあります。配布グループは、主にMS Exchangeのメーリングリストに使用されます。

グループは、ローカル、グローバル、ユニバーサルに分けられます。

ローカルグループ-ドメインの権限を管理します。他のドメインのオブジェクトを含めることができます。
グローバル-任意のドメインのオブジェクトへのアクセスを許可しますが、1つのドメインのユーザーのみを含めます。
ユニバーサル-多くのドメインのフォレストで使用され、すべてを大きく混乱させます。それらを使用する必要はありませんでした。

属性を調べてみると、ローカルグループの識別子がgroupType -2147483644であり、グローバルが-2147483646であることがわかります。

グループ自体の目的は、数の一部によって決定されるようです。見にくい場合は、TechNetで識別子を確認できます。

ドメインにローカルグループを指定して作成します。コメントに追加情報を指定します：グループリソースへのパス、およびグループ自体が与える権利。

ユーザーを追加：

 #Create security_group $ADS_GROUP_TYPE_LOCAL_GROUP = -2147483644 $objOU = [ADSI]"LDAP: //OU=Groups,OU=MPC,OU=E182,DC=emea,DC=corpdir,DC=net" $GroupName = "$share_name" $objGroup = $objOU.Create("group", "CN=" + $GroupName) $objGroup.Put("groupType", $ADS_GROUP_TYPE_LOCAL_GROUP ) $objGroup.Put("description", $UNC ) $objGroup.Put("sAMAccountName", $GroupName ) $objGroup.SetInfo() }}

リソースの権利は、SMBアクセス許可とNTFSに分けられます。これは、それぞれ、フォルダーレベルでのアクセスとファイルシステムレベルでのアクセスです。実際、それらは独立しています。 FATを使用する場合、SMB権限のみを処理する必要があります。リソースへのアクセスは、最終的にSMB + NTFSアクセス許可の合計で構成されます。

リソースに対する権利との混同を避けるため、NTFSの権利のみで運営しています。 SMBの権利では、すべてのユーザーに一般的なアクセスを設定します。理論を思い出してください：

システム内の各ユーザーは、特定のログインセッションのセキュリティ情報を含むアクセストークンを持っています。システム自体は、ログイン時にアクセストークンを作成します。ユーザーに代わって実行される各プロセスには、このアクセストークンのコピーがあります。トークンは、ユーザー、ユーザーグループ、および特権を識別します。トークンには、現在のログインセッションを識別するログインSID（セキュリティ識別子）も含まれています。ユーザーが保護されたオブジェクトにアクセスしようとすると、システムで認証が行われ、その結果、ユーザーはアクセス許可またはアクセス拒否を受け取ります。この場合、承認はACL（アクセス制御リスト）の検索に基づいています。

オブジェクトACLの各エントリ（またはACE-Access Control Entry）は、アクセス権を定義します。エントリには3つの要素が含まれます。

SID-エントリが適用されるユーザーまたはグループの識別子。
アクセスの種類-読み取り、書き込みなど
レコードタイプ-許可または拒否。

オブジェクトの所有者がオブジェクトACLにエントリを作成していない場合、システムはすぐにアクセスを提供します。したがって、アクセストークンのすべてのSIDエントリが比較されます。エントリの順序も重要です。

要求されたアクセスが明示的に許可または拒否されると、システムはACEエントリのチェックを停止します。たとえば、明示的なアクセス拒否は、親ディレクトリから継承されたアクセス許可よりも優先されます。 2番目は、親ディレクトリから許可を継承し、ディレクトリツリーのすべての許可です。また、オブジェクトの所有者がオブジェクトに対する独自の権限を決定できることを意味します。これにより、ユーザーのグループへのアクセスが許可され、グループのサブグループへのアクセスが拒否されます。オブジェクトの継承パラメーターは次の値を取ることができます。

価値	説明
「なし」、「なし」	権利はこのフォルダにのみ適用されます。
ContainerInherit、なし	このフォルダーとそのサブフォルダーに権利が適用されます
ObjectInherit、なし	このフォルダーとそのファイルには権利が適用されます。
「ContainerInherit、ObjectInherit」、「なし」	このフォルダーのサブフォルダーとファイルの権利が適用されます。
ContainerInherit、InheritOnly	権利はサブフォルダーにのみ適用されます。
ObjectInherit、InheritOnly	権限はファイルにのみ適用されます。
「ContainerInherit、ObjectInherit」、「InheritOnly」	権限はサブフォルダーとファイルにのみ適用されます。

テストでは、次のステップが実行される前に、グループがドメイン内に常に作成されるとは限らないことが明らかになりました。まだ確認していないので、5秒の十分な休止時間を設定してください。次に、ディレクトリACLを取得します。 ACLアクセスリストに新しいエントリを作成して保存します。

 start-sleep 5 $dirpath=$path+$share_name $acl = get-acl $dirpath $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$share_name","ReadAndExecute", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.SetAccessRuleProtection($True, $True) $acl.AddAccessRule($rule) Set-Acl $dirpath $acl

2番目のグループ、管理者、異なるアクセス権で同じことを繰り返します。

 start-sleep 5 #$objOU = [ADSI]"LDAP://OU=Groups,OU=MPC,OU=E182,DC=emea,DC=corpdir,DC=net" $GroupName = "$share_name"+"_ADM" $objGroup = $objOU.Create("group", "CN=" + $GroupName) $objGroup.Put("groupType", $ADS_GROUP_TYPE_LOCAL_GROUP ) $objGroup.Put("description", $UNC ) $objGroup.Put("sAMAccountName", $GroupName ) $objGroup.SetInfo() start-sleep 20 $dirpath=$path+$share_name $acl = get-acl $dirpath $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$GroupName","Modify", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.SetAccessRuleProtection($True, $True) $acl.AddAccessRule($rule) Set-Acl $dirpath $acl Write-Host " $share_name created"

単にディレクトリを「共有」するだけです。

 $dirpath=$path+"\$sharename" $Shares=[WMICLASS]”WIN32_Share” If (!(GET-WMIOBJECT Win32_Share -filter “name='$share_name'”) { $Shares.Create(“$dirpath”,”$share_name”,0) }

おわりに

PowerShellには、追加の便利なActive DirectoryモジュールとファイルシステムセキュリティPowerShellモジュールがあります。通常の管理者は、PowerShellで権限を割り当てる際にオブジェクトクラスのジャングルをいじることさえ考えないかもしれません。そうしないと、管理者ではなくプログラマーになります。 ADモジュールを使用するローカルグループのリストは、たとえば次のようにして取得できます。

 get-qadgroup -GroupScope DomainLocal | Get-QADGroupMember -Type group | Where{$_.GroupScope -eq "Local"}

一方、ADSIの使用は、より普遍的なアプローチです。ちなみに、Windows XPから拒否することを納得させられない保守的な顧客が多数います。

この場合、あるユーザーのすべての権限を別のユーザーに複製するには、コマンドラインから標準ユーティリティを使用します。

 dsquery user -samid Person |dsget user -memberof |dsmod group -addmbr "CN=Some Other Person(222),OU=Users,OU=_GlobalResources,OU=222,OU=E777,DC=emea,DC=corpdir,DC=net" –c

良い自動化！

PowerShellおよびADSI APIを使用したドメインアクセス許可の管理

More articles: