直腸扁桃摘出術：ADコマンドレットなしでPowershellでADを操作する

Windows Server 2008は、ActiveDirectoryを操作するための注目すべきPowerShellコマンドレットを初めて導入しました。 これらの美しく、論理的で、直観的で非常に強力なツールは、「いらいらする」とは言わないまでも、私を悲しくさせました。 私がサービスを提供した11のネットワークはすべて、Windows 2003 R2上に構築されました。



極東に点在するさまざまな都市の11の非接続ネットワークにある11の無関係なドメイン。 また、「セブン」、「ホイスト」さえ存在しないという事実はありません。これにより、 ADコマンドレットを2000および3と組み合わせて使用しようとする試みが終了します。





タスクは次のように定式化されました-「Windows XP / 2003で実行されるPowerShellスクリプトから基本的なAD管理操作を実行できるコードを作成します。」 それがどのように解決されたかを読んで、habrakat（ 注意深く、松葉杖;多くのテキストとコード ）の下で読んでください。

コンテキスト

最近、一般的に、enikeyschikの退屈な作業は、システム管理者や他のITチーフの異常な活動の期間によって幾分複雑になりました。彼らは、サーバーサービス、ユーザーワークステーション、および他のITエンタープライズの設定に多くの変更を加えることを決定しました。 当然、enikeyshchikovの手によって、tk。 AltirisやMS SCCMなどの通常のツールはありませんでした。



ある時点で、私に委ねられたネットワークで彼らの独創的なアイデアを実現する時間がないことを物理的に認識し、自動化について考えました。 労働時間の分析は、まず、ADの変更の複製プロセスを加速する必要があることを示しました。 そのためには、Active Directory Comandletsが必要であるように思えました（その作業のために、Windows 7のライセンスを少なくとも1つ購入する必要がありました）。



ビジネスリーダーとシステム管理者は容赦ありませんでした。「古いシステムが正常に機能するのに、なぜ新しいシステムが必要なのですか。 ああ、うまくいかないの？ しかし、すべてを素晴らしいものにするためのあなたがいます！ そうでなければ、なぜあなたはそんなに支払われますか？ はい、ところで、本当に新しいシステムが必要な場合は、自分のお金で自分で購入して使用してください！ そして、一般的に、提案されたツールの枠組み内でビジネス上の問題を解決できない場合、彼は会社を去りました！」



「わかりました」私は答えた：「外に出ない」。 最終的に、管理の「ウィッシュリスト」の実装は、enikeyschikと実際のシステム管理者の主な違いの1つです。 もう一度「工夫をして」「出て行く」必要があることが明らかになりました。 PowerShellは、「ersatz-management AD 」システムを構築するためのプラットフォームとして選択されました（主に.NETおよびCOMとの作業を容易にするため）。

コード

一意のユニット名を取得する

ActiveDirectoryを使用したことがある場合、または別のLDAP実装に精通している場合は、一意の（識別可能な）名前がDN（ 識別名 ）であるさまざまなケースでどれだけ広く使用されているかを知っています。



一意のLDAP名は、いくつかの相対的な一意の名前-RDN（ 相対識別名 ）で構成されます。これは「属性=値」のペアです。 組織単位の相対的な一意の名前の例：

ou=Managers
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じユニットの一意の名前の例：

 ou=Managers,DC=example,dc=com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このエントリは、「example.com」という名前のADドメインの最初のレベルに「マネージャー」ユニットがあることを示しています。



私自身の経験から、一意のLDAP名は直感的ではなく、初心者のenikeyschikovにいくつかの困難を引き起こしていると言えます。 したがって、「example.com/Managers/Accounting/」という形式の直感的な表現をDN表記に変換する簡単な関数を記述する必要があることがわかりました。

 <# .SYNOPSIS    OU   "example.com/123/456",   Distinguished Name. .Description       ,       . :      DNS-,   NEIBIOS  (.. example.com,   EXAMPLE) .PARAMETER Path ,     DN .OUTPUTS System.String.  Distinguished Name,   . #> Function Convert-ADPath2DN([STRING]$Path) { $Res = "" $ResOU = $null #   OU  OU DN $P = Join-Path $Path "/" $P = $P.Replace("\","/") #,     -    if ($P -match "^(?<DNS_DOMAIN_NAME>(\w+\.\w+)+)\/.+$") { $i = 0 $DNS_DOMAIN_NAME = $Matches.DNS_DOMAIN_NAME #   OU While (-not ($P -eq $DNS_DOMAIN_NAME)) { $i++ $OU = Split-Path -Leaf $P $P = Split-Path -Parent $P If ($i -ne 1) { $ResOU = $ResOU + "," } $ResOU = $ResOU+ "OU=$OU" } } else { $DNS_DOMAIN_NAME = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name } #   ,           $DNS_DOMAIN_NAME = $DNS_DOMAIN_NAME.Replace(".","\") $DC_NAMES = @() While ($DNS_DOMAIN_NAME -ne "") { $DC = Split-Path -Leaf $DNS_DOMAIN_NAME $DNS_DOMAIN_NAME = Split-Path -parent $DNS_DOMAIN_NAME $DC_NAMES = $DC_NAMES + $DC } $Count = $DC_NAMES.Count for ($i=$Count;$i -gt 0;$i--) { $DC = $DC_NAMES[$i - 1] If ($i -ne $Count) { $ResDC = $ResDC + "," } $ResDC = $ResDC+ "DC=$DC" if ($ResOU -ne $null) { $Res = $ResOU + "," + $ResDC } else { $Res = $ResDC } } Return $Res }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用例：

 $Var = Convert-ADPath2DN -Path "example.com/Test/" $Var OU=Test,DC=example,DC=com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数はActiveDirectoryの管理に直接関係していませんが、非常に便利であり、他の関数で使用されています。

組織単位の組織

各enikeyschikは、特別に割り当てられたテストドメインでActiveDirectoryのスクリプトをテストする必要があることを知っている必要があります。できれば、企業のメインネットワークから物理的に切断してください。



同様に重要なのは、ITコストを削減するための会社のポリシーへの準拠です（多くの非中核組織がそのような指示を持っていると思います）。テスト環境を展開できるenikeyschikには原則としてありません。



したがって、私たちのヒーローは、上級の同志の厳しい命令に反して、「戦闘」ADで彼の成果を直接テストします。 私たちはこれを彼のせいにしませんが、代わりに助けようとします。



彼が最初にすべきことは、別の組織単位を作成することです。その中で、スクリプト作成スキルのさらなる開発が行われます。 さて、トピックのトピックはPowershellプログラミングに関連しているため、それに対応する関数を実装します。



これを行うには、 System.DirectoryServices.DirectoryEntryクラスのCreate コンストラクターを使用する必要があります。 最終バージョンは、たとえば次のようになります。

 <# .SYNOPSIS     AD      . .Description       ,    .   - .       New-ADOrganizationUnit .PARAMETER Path    AD,     OU (.. ). .PARAMETER Name    (Organization Unit). .OUTPUTS $null.    . #> Function New-ADOrganizationUnit_simple([STRING]$Path,[STRING]$Name) { #   , ..     . #  -   OU,   . $ErrorActionPreference = "SilentlyContinue" #    DN (.   ) $OUDN = Convert-ADPath2DN -Path $Path #    ADsPath $OUDN = "LDAP://$OUDN" # ,    $objDomain = [ADSI]$OUDN #  $objOU = $objDomain.Create("organizationalUnit", "ou=$Name") $objOU.SetInfo() #  Trap { #   ,     ,    . if ($_.Exception.ErrorCode -eq $SYSTEM_ERROR_CODE_OU_ALREADY_EXISTS) { Write-Host "OU $Name  $Path  " } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この実装の明らかな欠点は、この関数が完全なブランチブランチを作成できないことです。ブランチ " example.com/Users "を持たないドメインにOU " example.com/Users/HR/Women "を作成する必要がある場合、使用できません。彼女はこの問題を解決します。



より正確には、できますが、それは非常に不便です。 最初にOU「ユーザー」を作成し、次に「HR」を作成し、その後で「女性」を作成する必要があります。



このようなシナリオは、ルーチン自動化の原則と明らかに矛盾するため、受け入れられません。 代わりに、次のように、ブランチ全体を自動的に作成する関数を使用することをお勧めします。

 <# .SYNOPSIS     AD   . .Description      ,      (  ). .PARAMETER Path    . .OUTPUTS $null.    . #> Function New-ADOrganizationUnit ([STRING]$Path) { #,        (example.com/Unit1/Unit2...) If ($Path -match "^(?<DNS_DOMAIN_NAME>(\w+\.\w+)+)\/.+$") { $i = 0 #  ,    "*-Path" $Pth = Join-Path $Path "/" $Pth = $Pth.Replace("\","/") $OUs = @() # OU   While ($Pth -ne "") { $i++ $Pos = $Pth.IndexOf("/") If ($i -eq 1) { $DNS_DOMAIN_NAME = $Pth.Substring(0,$Pos) } else { $OU = $Pth.Substring(0,$Pos) $OUs = $OUs + $OU } $Pth = $Pth.Substring($Pos+1,($Pth.Length - $Pos -1)) } #   OU $Pth = $DNS_DOMAIN_NAME For ($i=0;$i -lt $OUs.Count;$i++) { $OU = $OUs[$i] #      OU. #  " ",    #     - . New-ADOrganizationUnit_simple -Name $OU -Path $Pth $Pth = $Pth + "/" + $OU } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数の使用は簡単です：

 #  "Test"  "MyFirstOU"   example.com New-ADOrganizationUnit -Path "example.com/Test/MyFirstOU/" | Out-Null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セキュリティグループの追加

本物の本を読んだ経験豊富なシステム管理者は、AD管理シナリオで、特にその構造を計画するときに（もちろん、パダワンが一般にこの問題の解決への参加を許可している場合）、 セキュリティグループを単一ユーザーアカウントよりもパダワンが推奨することをお勧めします。



引数は通常、結果の構造の複製可能性です。たとえば、ディレクターが個人的に（または彼のアカウント）任意のソフトウェアを実行できるようにするグループポリシーの読み取りを許可する場合、そのような機会を他の誰かに提供する必要が生じた場合、すべての手順を実行する必要があります別の重要な叔父のアクセス権の設定を繰り返します。



「 gAllowRunAnything 」などのグループを作成し、このグループのメンバーに任意の実行可能ファイルを実行する許可を与えると、プロセスは大幅に簡素化されます。このグループに2人目の従業員のアカウントを含めるだけで十分です。 明らかに、このオプションはenikeyschik（これらの操作を実行する必要があります）の方がはるかに単純であり、システム管理者（後でenikeyshikerが何をしたかを把握する必要があります）に対して透過的です。



グループの重要性について上級の同僚と議論することはせず、単にそれらをPowerShell関数として作成する可能性を認識します。

 <# .SYNOPSIS   AD   OU. .Description         (Organization Unit). .PARAMETER Path    ,     . .PARAMETER Name    .PARAMETER Force   .   ,    OU   . .OUTPUTS $null.     . #> Function New-ADGroup([STRING]$Path, [STRING]$Name, [System.Management.Automation.SwitchParameter]$Force) { # ,     $ErrorActionPreference = "SilentlyContinue" If ($Force -eq $true) { New-ADOrganizationUnit -Path $Path } #      DN $OUDN = Convert-ADPath2DN -Path $Path #  -   $OUDN = "LDAP://$OUDN" $OU = [ADSI]"$OUDN" #       $Group = $OU.Create("group", "cn=$Name") $Group.Put("sAMAccountName", "$Name") $Group.SetInfo() #  Trap { #   ,   : # "   " if ($_.Exception.ErrorCode -eq $SYSTEM_ERROR_CODE_OU_ALREADY_EXISTS) { Write-Host " $Name  $Path  " } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、 System.DirectoryServices.DirectoryEntryクラスのCreateコンストラクターのバージョンの 1 つもここで使用されています。



繰り返しますが、関数の使用は基本です（AD / LDAPの組織化と管理の分野で特別な知識を持たない同じ同僚である同僚がすぐに理解できるように、構文を単純化することを特に試みました）。

 #  "gSales"   "Unit1".   -       . New-ADGroup -Path "example.com/Test/MySuperScriptingResults/Fatal/Unit1" -Name "gSales" -Force
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

グループポリシーオブジェクトの作成とリンク

ActiveDirectoryとは何ですか？ ウィキペディアによると、これはMSのLDAP準拠のディレクトリサービス実装です。 システム管理者はおそらくフォレスト、ドメイン、および信頼を記憶し、セキュリティガードは認証メカニズムを記憶し、eneykeyschikはグループポリシーについて話します。



なぜ彼らについて？ 彼らはenikeyschikの全職業生活を持っています：ワークステーションにソフトウェアをインストールし、 IE設定をロックし、ユーザーがさまざまな「* -Bars」、 SRPをインストールできないようにし、勤務時間中のゲームの問題を解決し、さらに左に移動するのが大好きなタスクバーをロックします 、enikeyschikがすぐに「元の状態に戻ることを要求します。さもなければ、仕事をすることは不可能です。」 しかし、私は思い出に深く入り込みました。 WindowsネットワークでのGPOの重要性についての論文には、誰も議論しないと思います 。



また、GPOは必要で重要なので、作成するライブラリにGPOを操作するためのメカニズムを含める必要があります。 最初にGPOで何をする必要がありますか？ もちろん、それを作成します（明らかに、作成の前に操作はできません）：

 <# .SYNOPSIS        . .Description        .    COM- GPMC (, GPMC   ). .PARAMETER DomainDNSName FQDN- ,       . .PARAMETER GPOName     . .OUTPUTS GPMGPO.     . #> Function New-GPO([STRING]$DomainDNSName,[STRING]$GPOName) { $GPM = New-Object -ComObject GPMgmt.GPM #   $GPMConstants = $GPM.GetConstants() #  $GPMDomain = $GPM.GetDomain($DNS_DOMAIN_NAME, $DNS_DOMAIN_NAME, $Constants.UseAnyDC) # GPO $GPMGPO = $GPMDomain.CreateGPO() $GPMGPO.DisplayName = $GPOName Return $GPMGPO }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数は、オブジェクトリポジトリにGPOを作成しますが、それ以上は作成しません。 これは便利ですが、実際の使用には十分ではありません。作成されたオブジェクトをユニットにリンク （ リンク ）する必要があります。 これがなければ、「非アクティブ」のように残ります（厳密に言えば、アクティブであり、影響範囲は単に定義されていません）。 また、OUにポリシーを添付するには、そのオブジェクト表現を取得する必要があります。 たとえば、次のように、GPOの名前を知って、取得しようとするのは論理的です。

 <# .SYNOPSIS  COM-  GPO   . .Description       GPO,   . .PARAMETER DomainDNSName FQDN- ,     GPO. .PARAMETER GPOName  GPO,   . .OUTPUTS GPMGPO.    COM-  GPO (  $null,  GPO   ). #> Function Get-GPO([STRING]$DomainDNSName,[STRING]$GPOName) { $GPMGPO = $null #     $ErrorActionPreference = "SilentlyContinue" # ,  GPMC $GPM = New-Object -ComObject GPMgmt.GPM #   $GPMConstants = $GPM.GetConstants() #  GPMDomain,    $GPMDomain = $GPM.GetDomain($DomainDNSNAme, $DomainDNSNAme, $GPMConstants.UseAnyDC) #        $GPMGPO = $GPMDomain.SearchGPOs($GPM.CreateSearchCriteria()) | Where-Object{$_.DisplayName -eq $GPOName} #  GPO.     -  $null. Return $GPMGPO }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前でGPOを検索するためのメカニズムを武器庫に用意して、次のようにバインドすることができます。

 <# .SYNOPSIS   (Link)        (OU). .Description    GPO        . -   . .PARAMETER DomainDNSName FQDN- ,     . .PARAMETER GPOName    GPO.           . .PARAMETER OUPath    ,       GPO. .OUTPUTS $Null.     . #> Function Mount-GPOToOU ([STRING]$GPOName,[STRING]$OUPath,[STRING]$DomainDNSName) { #   GPO    $GPMGPO = Get-GPO -DomainDNSName $DomainDNSName -GPOName $GPOName #  ,    If ($GPMGPO -ne $Null) { #    DN $OUDN = Convert-ADPath2DN -Path $OUPath #     COM- GPMC $GPM = New-Object -ComObject GPMgmt.GPM $GPMConstants = $GPM.GetConstants() $GPMDomain = $GPM.GetDomain($DomainDNSName, $DomainDNSName, $Constants.UseAnyDC) #    $GPMSOM = $GPMDomain.GetSOM($OUDN) #  (Link)  GPO   $GPMSOM.CreateGPOLink(-1, $GPMGPO) | Out-Null trap { #   COM-.       . # ,    ,     .   continue } } #  GPO     ,      else { Write-Host "Cannot find a GPO object named $GPOName" Throw "Cannot_find_GPO" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の機能では、新しく作成されただけでなく、リポジトリ内のGPOもバインドできます。 この機能のアプリケーションの1つは、以前に作成されたグループポリシーオブジェクトをすばやく「運用環境に導入」することでした。最初に特別な別のユニット（OU）でテストされ、その後、システム管理者からテストおよび承認を得た後、 突然 「戦闘」ユニットに連絡しました。 快適でした。



細心の注意を払った読者は、 GPMC COMオブジェクトの用途を尋ねる場合があります。 すべてが非常に単純です。.NETは高レベルの抽象化を提供し、一部の操作の実行を許可しません。 たとえば、GPOを組織単位にバインドする方法が見つかりませんでした。System.DirectoryServices.DirectoryEntryを使用してGPO（以下を参照）をインポートおよびエクスポートできませんでした。 GPMCを使用すると、これらの手順を実行できるだけでなく、比較的簡単に実行できます。

GPO設定のインポートとエクスポート

そのため、グループポリシーオブジェクトとユニットへのバインディングを作成する機会があります。 目標を思い出しましょう-なぜこれらすべての機能を開発するのでしょうか？ 彼の努力でエニキースキクを助けるために。 enikeyschikにはどのような支援が必要ですか？ 彼が実行すべき日常業務の自動化。 GPOに関連するのはどれですか？ 原則として、システム管理者が開発した多くのネットワーク（または同じドメインの異なるOU）のGPOパラメーターに変更を加えることについて話します。



通常、これは起こります。たとえば、セキュリティガードは、リムーバブルメディア上の情報の「削除」を禁止するために、これらの使用を禁止することを決定します。 システム管理者は、対応するGPO設定の説明 （手順）を準備し、これらの変更をネットワークで複製するようにenikeyshchikovに指示します。



多くの変更があり、さらに悪いことに、ネットワークもあります。 その結果、enikeyschikは1日中複製に忙しく、詰まった用紙をプリンターから引き出したり、トイレのオーディオシステムに必要なレパートリーを提供したり、会計士の娘学生のエッセイをWebで見つけたり、最悪の場合、ユーザーに同じ「任意のキー」があります。



そして、ここで全能のMSは、GPMCのフレームワーク内に実装された独自のGPO設定インポート/エクスポートメカニズムを備えたキーボードとドライバーの戦闘機の助けになります。 このメカニズムにより、これら2つのGPO（ドナーと受信者）が異なるドメインにある場合でも、1つのGPOで指定された設定を別のGPOにインポートできます。 Powershellを使用すると、プロセスを完全自動化できます。



参照ポリシーをシステム管理者にエクスポートする手順はそのままにして、 インポートを自分で行います。 まず、GPOバックアップとは何かを考えます（MS自体は、エクスポートではなくバックアップであると主張しています）。





この例のフォルダー名は、エクスポートされたGPOの一意の識別子です。 インポートするときに必要になるので、このGUIDを取得する方法を学ぶのがいいでしょう。 私はネットワークの民間伝承の有名なキャラクターを手に入れようと思いますが、この識別子を取得する最も簡単な方法は、たとえば次のようにフォルダー名を調べることです。

 <# .SYNOPSIS   GUID   GPO   () . .Description         GPO,    ,   - GUID,       GUID'  .    ,     GPO        GUID'.     -   GUID'  . .PARAMETER Path Path -   ,      GPO. .OUTPUTS System.String. GUID   GPO,    . #> Function Get-ExportedBackupGUID([STRING]$Path) { #,    ,   -   If (-not (Test-Path $Path)) { Write-Host " $Path  " Throw "Backup dir path not found" } #   $Children = Get-ChildItem -Force -LiteralPath $Path #    ,   GUID' Foreach ($Child in $Children) { If ($Child.FullName -match "^*\{\w{8}\-(\w{4}\-){3}\w{12}\}$") { Return $Matches[0] } } # ,    GPO   . Write-Host "  $Path     " Throw "GPO Backup(s) not found" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エクスポートされたGPOのGUIDがわかったら、その設定をADリポジトリの任意のGPOにロードできます。

 <# .SYNOPSIS   GPO   . .Description        ,       GPO.     ,      ,       GPO.    GPO  ,   . .PARAMETER BackupPath       GPO .PARAMETER DNS_DOMAIN_NAME FQDN- ,      (). .PARAMETER MigrationTablePath  .    . .PARAMETER NewGPOName    ,        .     ,       (..     GPO    ,     GPO-). .OUTPUTS $null.    . #> Function Import-GPO ([STRING]$BackupPath, [STRING]$DNS_DOMAIN_NAME, [STRING]$MigrationTablePath, [STRING]$NewGPOName = "") { #      GPO.   ,   If (-not (Test-Path $BackupPath)) { Write-Host "     GPO: $BackupPath" Throw "GPO Backup path not found" } # COM- GPMC -   $GPM = New-Object -ComObject GPMgmt.GPM $GPMConstants = $GPM.GetConstants() $GPMDomain = $GPM.GetDomain($DNS_DOMAIN_NAME, $DNS_DOMAIN_NAME, $Constants.UseAnyDC) #  GPMBackupDir,      $GPMBackupDir = $GPM.GetBackupDir($BackupPath) # GUID  GPO $BackupGUID = Get-ExportedBackupGUID -Path $BackupPath #  -   GPO $GPMBackup = $GPMBackupDir.GetBackup($BackupGUID) # GPO,     :   ,     #  ,     If ($NewGPOName -eq "") { $TargetGPOName = $GPMBackup.GPODisplayName } else { $TargetGPOName = $NewGPOName } #    GPO,      $GPMGPO = Get-GPO -DomainDNSNAme $DNS_DOMAIN_NAME -GPOName $TargetGPOName # GPO     ,   If ($GPMGPO -eq $Null) { $GPMGPO = New-GPO -DomainDNSNAme $DNS_DOMAIN_NAME -GPOName $TargetGPOName } #  GPO $GPMGPO.Import(0, $GPMBackup) | Out-Null }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のコードは、GPOを操作するために説明した関数を使用する一般的な例として使用できます。

 ##:   "c:\good_gpo\"      ,    ,   . #:      (  ),    "example.com/TestUnits/OU1" ##: #     GPO   "Imported_good_GPO" (    ). Import-GPO -BackupPath "c:\good_gpo\" -Dns_Domain_Name "example.com" -NewGPOName "Imported_good_GPO" #     OU Mount-GPOToOU -GPOName "Imported_good_GPO" -OUPath "example.com/TestUnits/OU1" -DomainDNSName "example.com"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GPOアクセス

, Windows AD, , , GPO, .



, OU «Users», .. () - .. () : " pAllow_Run_Any_Executable ", , , , , " pDisallow_Run_Anything_Except_HelpDesk ", , .



明らかに、最初のGPOはユーザーLoginov-Parolevに影響を与えることなくMr. Glavnovskyのアカウントに影響を与え、2番目のGPOは2番目のGPOに影響を与えます。これらのGPOが本質的に互いに矛盾していることも同様に明らかです。



つまり , GPO. , , (OU) GPO, . , AD , .



( — ) , GPO . , , .



" gAllow_Run_Any_Executable ", GPO " pAllow_Run_Any_Executable " . — .



, , , GPO. , .



MSDN , GPO (, , AD) System.DirectoryServices.ExtendedRightAccessRule。このようなオブジェクトには、アクセスルールのエントリに関する情報が含まれています。誰に、何が正確に禁止または許可されているか。

 # PowerShell  ,    ACE,     $NewRule = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $objTrustee, $objRihgt, $objACT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ArgumentListを介して渡される引数を処理してみましょう。明白なことから始めましょう：$ objTrusteeは、このルールが適用されるセキュリティサブジェクトです。たとえば、ユーザーまたはセキュリティグループ。簡単に言えば、これは「このルールが適用される対象」です。「マーシャは、Vaska が太ももに触れてsales.example.comドメインを変更できるようにした」という設計では、Vaskaがセキュリティの対象になります。



通常のenikeyschikの観点から（これらの従業員は、著者が考えているように、この記事で説明した松葉杖のセットの主なユーザーです）、セキュリティの主題を彼の名前で示すのが最も簡単です。ただし、ここで考慮すべき微妙な違いがあります。Windowsの言語バージョンごとに名前が異なる標準的なセキュリティプリンシパルが非常に多くあります。たとえば、英語版のWindowsの「管理者」の名前は「管理者」です。



この問題を解決するために、MSはすべてのOSローカリゼーションで変更されていない特別な識別子の使用を考え出しました。次に、それらの使用方法を学習するだけで済みます。列挙型を使用する最も簡単な方法はSystem.Security.Principal.WellKnownSidTypeです。

 # SID    $SID = [System.Security.Principal.WellKnownSidType]::AccountDomainAdminsSid
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

法律の主題がよく知られていない場合（つまり、標準のセキュリティ主題のリストに含まれていない場合）、System.Security.Principal.NTAccountクラスのオブジェクトとしての表現は、名前で取得できます。

 [STRING]$FQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name $objTrustee = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList "$FQDN", "$Trustee"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、私たちは法の主題の表現を作成することを学びました（私たちはそれを許可/禁止します）。今、あなたが作成する必要があり、法律自体の表現を、$ objRihgt（それが許可または拒否すること）。上記の例は、「変更を加える」権利を示しています[ドメインsales.example.comに対して]。



ご存知のように、アクセス許可の種類（「読み取り」、「書き込み」、「削除」など）の数は制限されており、それらはすべて列挙型System.DirectoryServices.ActiveDirectoryRightsの有効な値のリストに含まれているため、次を使用してビューを作成するのが最も簡単です対応するコンストラクター、関数でラップされた使いやすさのため：

 <# .SYNOPSIS    System.DirectoryServices.ActiveDirectoryRights   . .Description     System.DirectoryServices.ActiveDirectoryRights.     . .PARAMETER StrRight     System.DirectoryServices.ActiveDirectoryRights. .OUTPUTS System.DirectoryServices.ActiveDirectoryRights  $null.    System.DirectoryServices.ActiveDirectoryRights,   ,  $null (      ) #> Function Convert-ToAccessRight([STRING]$StrRight) { $Res = $null $ErrorActionPreference = "SilentlyContinue" $Res = [System.DirectoryServices.ActiveDirectoryRights]::$StrRight $ErrorActionPreference = "Stop" Return $Res }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

( " "), $objACT — (, «» (Allow), «» (Deny)). , MSDN , System.Security.AccessControl.AccessControlType , ( ) :

 #  $objACT = [System.Security.AccessControl.AccessControlType]::Allow #  $objACT = [System.Security.AccessControl.AccessControlType]::Deny
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

:

 <# :     "gForbidden_Users"   GPO "pForbidden_GPO"   "Example.com" #> #: #   ,    [STRING]$FQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name #   "gForbidden_Users",      $objTrustee = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList "$FQDN", "gForbidden_Users" #    $objActDeny = [System.Security.AccessControl.AccessControlType]::Deny #    $objRihgt = [System.DirectoryServices.ActiveDirectoryRights]::GenericRead #   "  'gForbidden_Users' ".       GPO 'gForbidden_Users' $NewRule = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $objTrustee, $objRihgt, $objACT #   GPO   . $GPMGPO = Get-GPO -DomainDNSName "Example.com" -GPOName "pForbidden_GPO" #  COM-    .NET-  System.DirectoryServices.DirectoryEntry [STRING]$GPOPath = $GPMGPO.Path $objGPO = New-Object System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$GPOPath" #         GPO #      ,      $objGPO.ObjectSecurity.AddAccessRule($NewRule) | Out-Null # . $objGPO.CommitChanges() | Out-Null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、これでGPO ADオブジェクトへのアクセス権の変更が完了します。ただし、ここには微妙な違いがあります。事実、各グループポリシーオブジェクトには、ドメインDFS（\\ domanname.example.com \ SYSVOL \）にフォルダーがあります。また、このフォルダへのアクセス権は、通常、GPO自体に設定されたアクセス権に対応しています。さらに、これらの権利が異なる場合、GPMCは対応するエラーを生成します。





このような非同期化について考えると、論理的です。上記のコードでは、ファイルシステムに触れることなくGPOオブジェクトへのアクセス権を変更します。もちろん、類推によってSYSVOLのフォルダーのアクセス許可を変更するコードを追加できますが、もっと簡単な方法があります。これは、GPO自体のアクセス許可を変更すると、GPMCがフォルダーのアクセス許可を自動的に付加するという事実に基づいています。したがって、GPMCコンソールを使用して偽の変更を加えるだけで十分であり、それ（コンソール）が通信自体を処理します。

 #FQDN-  $DomainDNSName = "Example.com" #  GPO,       $GPOName = "pForbidden_GPO" #   GPO    $GPMGPO = Get-GPO -DomainDNSName $DomainDNSName -GPOName $GPOName #  $GPOSecurityInfo = $GPMGPO.GetSecurityInfo() #   ,    . # GPMC         SYSVOL. $GPMGPO.SetSecurityInfo($GPOSecurityInfo) | Out-Null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

一定の「慣らし」期間の後、個々のAD管理タスクのスクリプトの作成（または以前に作成された編集）が、同じタスクを手動で解決するよりもはるかに優れていることに気付きました。特に、実行する必要があるすべての操作に便利な一連の機能を自由に使用できる場合。



しかし、enikeyshchiki-人々は怠け者であり、しばらくしてスクリプトを書いてADを管理するためのタスクを率直に退屈させました。システム管理者サーバーからXMLファイル形式のタスクをダウンロードし、参加せずにこれらのタスクを実行できる「ユニバーサル管理シナリオ」の作成で具体化されるメカニズムのさらなる発展についての考えがありました認証ウィンドウにログインを入力する、キーボードをワイプするなど）。



結果のメカニズムの完全な説明は、明らかにこの記事の範囲外です。スクリプトがモジュール構造を受け取り、モジュールの1つがCM_ActiveDirectoryであり、説明とともに利用可能であるという事実のみに注意しますpasteBinで。正常に動作させるには、このシステムの他のすべてのモジュールと同様に、CM_Systemモジュールをロードする必要があります。CM_Systemモジュールは（対応する記述ファイルとともに）そこからダウンロードできます。



読者が提示された情報を必要としないことを願っています。2012年、多くのドメインを集中管理する必要のある人々、企業が適切なツールを提供し、説明されたオフィスが唯一の不快な例外であると信じたい。しかし、同様の状況に陥った場合でも、絶望しないでください！ご覧のように、「古い」を使用しても、目的の結果を得ることができます。



同僚に最適なツール！