WMF 5.1 の Desired State Configuration (DSC) の機能強化Improvements in Desired State Configuration (DSC) in WMF 5.1

DSC クラス リソースの機能強化DSC class resource improvements

WMF 5.1 で、次の既知の問題を修正しました。In WMF 5.1, we have fixed the following known issues:

  • クラスベースの DSC リソースの Get() 関数によって複合/ハッシュ テーブル型が返される場合、Get-DscConfiguration は空の値 (null) やエラーを返すことがあります。Get-DscConfiguration may return empty values (null) or errors if a complex/hash table type is returned by Get() function of a class-based DSC resource.
  • Get-DscConfiguration は、RunAs 資格情報が DSC 構成で使用される場合、エラーを返します。Get-DscConfiguration returns error if RunAs credential is used in DSC configuration.
  • コンポジット構成では、クラス ベースのリソースは使用できません。Class-based resource cannot be used in a composite configuration.
  • Start-DscConfiguration は、クラス ベースのリソースに独自の型のプロパティがあると、応答を停止します。Start-DscConfiguration hangs if class-based resource has a property of its own type.
  • クラス ベースのリソースは排他リソースとして使用できません。Class-based resource cannot be used as an exclusive resource.

DSC リソースのデバッグの機能強化DSC resource debugging improvements

WMF 5.0 では、PowerShell デバッガーは、クラス ベースのリソース メソッド (Get/Set/Test) で直接停止しませんでした。In WMF 5.0, the PowerShell debugger did not stop at the class-based resource method (Get/Set/Test) directly. WMF 5.1 では、このデバッガーは、MOF ベースのリソース メソッドと同様に、クラス ベースのリソース メソッドで停止します。In WMF 5.1, the debugger stops at the class-based resource method in the same way as for MOF-based resources methods.

DSC プル クライアントは TLS 1.1 と TLS 1.2 をサポートDSC pull client supports TLS 1.1 and TLS 1.2

以前、DSC プル クライアントは HTTPS 接続で SSL3.0 と TLS1.0 にのみ対応していました。Previously, the DSC pull client only supported SSL3.0 and TLS1.0 over HTTPS connections. より安全なプロトコルを使用するように強制されると、このプル クライアントは動作を停止しました。When forced to use more secure protocols, the pull client would stop functioning. WMF 5.1 では、DSC プル クライアントは SSL 3.0 をサポートせず、より安全な TLS 1.1 プロトコルと TLS 1.2 プロトコルをサポートします。In WMF 5.1, the DSC pull client no longer supports SSL 3.0 and adds support for the more secure TLS 1.1 and TLS 1.2 protocols.

プル サーバー登録の機能強化Improved pull server registration

以前のバージョンの WMF では、ESENT データベースを使用しながら同時に DSC プル サーバーに登録/レポートを要求すると、LCM は登録またはレポートに失敗していました。In the earlier versions of WMF, simultaneous registrations/reporting requests to a DSC pull server while using the ESENT database would lead to LCM failing to register and/or report. そのような場合、プル サーバーのイベント ログに "既に使用されているインスタンス名" というエラーが記録されました。In such cases, the event logs on the pull server has the error "Instance Name already in use." これは、マルチスレッド シナリオで ESENT データベースにアクセスするとき、間違ったパターンが使用されることに起因していました。This was due to an incorrect pattern being used to access the ESENT database in a multi-threaded scenario. WMF 5.1 では、この問題は修正されました。In WMF 5.1, this issue has been fixed. 同時登録または同時レポート (ESENT データベースを含む) が WMF 5.1 では正常に機能します。Concurrent registrations or reporting (involving ESENT database) works fine in WMF 5.1. この問題は ESENT データベースにのみ関連し、OLEDB データベースには関連しません。This issue is applicable only to the ESENT database and does not apply to the OLEDB database.

ESENT データベース インスタンスでの循環ログの有効化Enable Circular log on ESENT database instance

以前のバージョンの DSC-PullServer では、データベース インスタンスが循環ログなしで作成されていたため、ESENT データベース ログ ファイルがプルサーバーのディスク領域を占有していました。In eariler version of DSC-PullServer, the ESENT database log files were filling up the disk space of the pullserver becouse the database instance was being created without circular logging. このリリースには、プルサーバーの web.config を使用してインスタンスの循環ログ動作を制御するオプションがあります。In this release, you have the option to control the circular logging behavior of the instance using the web.config of the pullserver. 既定では、CircularLogging が TRUE に設定されます。By default CircularLogging is set to TRUE.

<appSettings>
    <add key="dbprovider" value="ESENT" />
    <add key="dbconnectionstr" value="C:\Program Files\WindowsPowerShell\DscService\Devices.edb" />
    <add key="CheckpointDepthMaxKB" value="512" />
    <add key="UseCircularESENTLogs" value="TRUE" />
  </appSettings>

部分構成命名規則のプルPull partial configuration naming convention

以前のリリースでは、部分構成の命名規則は、プル サーバー/サービスの MOF ファイル名はローカル構成マネージャー設定に指定されている部分構成名に一致する必要があり、ローカル構成マネージャー設定は MOF ファイルに組み込まれている構成名に一致する必要があるというものでした。In the previous release, the naming convention for a partial configuration was that the MOF file name in the pull server/service should match the partial configuration name specified in the local configuration manager settings that in turn must match the configuration name embedded in the MOF file.

下のスナップショットを参照してください。See the snapshots below:

  • ローカル構成設定により、あるノードに受信を許可する部分構成が定義されます。Local configuration settings which defines a partial configuration that a node is allowed to receive.

サンプルのメタ構成

  • サンプルの部分構成定義Sample partial configuration definition
Configuration PartialOne
{
    Node('localhost')
    {
        File test
        {
            DestinationPath = "$env:TEMP\partialconfigexample.txt"
            Contents = 'Partial Config Example'
        }
    }
}
PartialOne
  • 生成された MOF ファイルに組み込まれている 'ConfigurationName'。'ConfigurationName' embedded in the generated MOF file.

生成された mof ファイルのサンプル

  • プル構成リポジトリの FileNameFileName in the pull configuration repository

構成リポジトリの FileName

Azure Automation サービス名により、MOF ファイルが <ConfigurationName>.<NodeName>.mof として生成されました。Azure Automation service name generated MOF files as <ConfigurationName>.<NodeName>.mof. そのため、下の構成は PartialOne.localhost.mof にコンパイルされます。So the configuration below compiles to PartialOne.localhost.mof.

これで、Azure Automation サービスから部分構成をプルできなくなりました。This made it impossible to pull one of your partial configuration from Azure Automation service.

Configuration PartialOne
{
    Node('localhost')
    {
        File test
        {
            DestinationPath = "$env:TEMP\partialconfigexample.txt"
            Contents = 'Partial Config Example'
        }
    }
}
PartialOne

WMF 5.1 では、プル サーバー/サービスの部分構成の名前を <ConfigurationName>.<NodeName>.mof にできます。In WMF 5.1, a partial configuration in the pull server/service can be named as <ConfigurationName>.<NodeName>.mof. さらに、コンピューターがプル サーバー/サービスから 1 つの構成をプルする場合、プル サーバー構成リポジトリの構成ファイルに任意のファイル名を与えることができます。Moreover, if a machine is pulling a single configuration from a pull server/service then the configuration file on the pull server configuration repository can have any file name. このように命名規則が柔軟なことから、ノードを部分的に Azure Automation サービスで管理し (ノードの一部の構成が Azure Automation DSC から誘導されます)、部分構成をローカル管理できます。This naming flexibility allows you to manage your nodes partially by Azure Automation service, where some configuration for your node is coming from Azure Automation DSC and with a partial configuration that you manage locally.

以下のメタ構成では、ローカルと Azure Automation サービスの両方で管理されるようにノードが設定されます。The metaconfiguration below sets up a node to be managed both locally as well as by Azure Automation service.

[DscLocalConfigurationManager()]
Configuration RegistrationMetaConfig
{
    Settings
    {
        RefreshFrequencyMins = 30
        RefreshMode = "PULL"
    }

    ConfigurationRepositoryWeb web
    {
        ServerURL =  $endPoint
        RegistrationKey = $registrationKey
        ConfigurationNames = $configurationName
    }

    # Partial configuration managed by Azure Automation service.
    PartialConfiguration PartialConfigurationManagedByAzureAutomation
    {
        ConfigurationSource = "[ConfigurationRepositoryWeb]Web"
    }

    # This partial configuration is managed locally.
    PartialConfiguration OnPremisesConfig
    {
        RefreshMode = "PUSH"
        ExclusiveResources = @("Script")
    }

}

RegistrationMetaConfig
Set-DscLocalConfigurationManager -Path .\RegistrationMetaConfig -Verbose

PsDscRunAsCredential と DSC 複合リソースを使用するUsing PsDscRunAsCredential with DSC composite resources

PsDscRunAsCredential と DSC 複合リソースが使用できるようになりました。We have added support for using PsDscRunAsCredential with DSC Composite resources.

構成内で複合リソースを使用するとき、PsDscRunAsCredential の値を指定できるようになりました。You can now specify a value for PsDscRunAsCredential when using composite resources inside configurations. 指定されると、すべてのリソースが複合リソース内で RunAs ユーザーとして実行されます。When specified, all resources run inside a composite resource as a RunAs user. 複合リソースが別の複合リソースを呼び出す場合、そのリソースのすべても RunAs ユーザーとして実行されます。If a composite resource calls another composite resource, all of its resources are also executed as RunAs user. RunAs 資格情報が複合リソース階層のあらゆるレベルに配信されます。RunAs credentials are propagated to any level of the composite resource hierarchy. 複合リソース内の何らかのリソースにより PsDscRunAsCredential の独自の値が指定される場合、構成コンパイル中に結合エラーが発生します。If any resource inside a composite resource specifies its own value for PsDscRunAsCredential, a merge error results during configuration compilation.

この例は、PSDesiredStateConfiguration モジュールに含まれている WindowsFeatureSet 複合リソースの利用を示しています。This example shows usage with WindowsFeatureSet composite resource included in PSDesiredStateConfiguration module.

Configuration InstallWindowsFeature
{
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Node $AllNodes.NodeName
    {
        WindowsFeatureSet features
        {
            Name = @("Telnet-Client","SNMP-Service")
            Ensure = "Present"
            IncludeAllSubFeature = $true
            PsDscRunAsCredential = Get-Credential
        }
    }
}

$configData = @{
    AllNodes = @(
        @{
            NodeName             = 'localhost'
            PSDscAllowDomainUser = $true
            CertificateFile      = 'C:\publicKeys\targetNode.cer'
            Thumbprint           = '7ee7f09d-4be0-41aa-a47f-96b9e3bdec25'
        }
    )
}

InstallWindowsFeature -ConfigurationData $configData

DSC のモジュールと構成の署名検証DSC module and configuration signing validations

DSC では、プル サーバーから管理対象コンピューターに構成とモジュールが配信されます。In DSC, configurations and modules are distributed to managed computers from the pull server. プル サーバーが侵害された場合、攻撃者はプル サーバーで構成とモジュールを改ざんし、すべての管理対象ノードに配信し、侵害する可能性があります。If the pull server is compromised, an attacker can potentially modify the configurations and modules on the pull server and have it distributed to all managed nodes, compromising all of them.

WMF 5.1 では、DSC はカタログ ファイルと構成 (.MOF) ファイルのデジタル署名の検証に対応しています。In WMF 5.1, DSC supports validating the digital signatures on catalog and configuration (.MOF) files. この機能では、信頼できる署名者が署名していない、あるいは信頼できる署名者が署名した後に改ざんされた構成ファイルまたはモジュール ファイルの実行が防止されます。This feature prevents nodes from executing configurations or module files which are not signed by a trusted signer or which have been tampered with after they have been signed by trusted signer.

構成とモジュールに署名する方法How to sign configuration and module


  • 構成ファイル (.MOF): 既存の PowerShell コマンドレット Set-AuthenticodeSignature が拡張され、MOF ファイルの署名に対応しています。Configuration Files (.MOFs): The existing PowerShell cmdlet Set-AuthenticodeSignature is extended to support signing of MOF files.
  • モジュール: モジュールの署名は、次の手順を利用し、対応するモジュール カタログに署名することで完了します:Modules: Signing of modules is done by signing the corresponding module catalog using the following steps:
    1. カタログ ファイルの作成: カタログ ファイルには、暗号法のハッシュまたは拇印の集まりが含まれています。Create a catalog file: A catalog file contains a collection of cryptographic hashes or thumbprints. 拇印はそれぞれ、モジュールに含まれるファイルに対応します。Each thumbprint corresponds to a file that is included in the module. 新しいコマンドレット New-FileCatalog が追加され、ユーザーは自分のモジュールのカタログ ファイルを作成できます。The new cmdlet New-FileCatalog, has been added to enable users to create a catalog file for their module.
    2. カタログ ファイルの署名: Set-AuthenticodeSignature を利用し、カタログ ファイルに署名します。Sign the catalog file: Use Set-AuthenticodeSignature to sign the catalog file.
    3. モジュール フォルダー内にカタログ ファイルを配置します。Place the catalog file inside the module folder. 慣例では、モジュール カタログ ファイルは、モジュールと同じ名前のモジュール フォルダーの下に配置する必要があります。By convention, module catalog file should be placed under the module folder with the same name as the module.

LocalConfigurationManager 設定で署名検証を有効にするLocalConfigurationManager settings to enable signing validations

プルPull

ノードの LocalConfigurationManager は、その現在の設定に基づき、モジュールと構成の署名を検証します。The LocalConfigurationManager of a node performs signing validation of modules and configurations based on its current settings. 既定では、署名検証は無効です。By default, signature validation is disabled. 署名検証は、‘SignatureValidation’ ブロックを下の図のようにノードのメタ構成定義に追加することで有効にできます:Signature validation can enabled by adding the ‘SignatureValidation’ block to the meta-configuration definition of the node as shown below:

[DSCLocalConfigurationManager()]
Configuration EnableSignatureValidation
{
    Settings
    {
        RefreshMode = 'PULL'
    }

    ConfigurationRepositoryWeb pullserver{
      ConfigurationNames = 'sql'
      ServerURL = 'http://localhost:8080/PSDSCPullServer/PSDSCPullServer.svc'
      AllowUnsecureConnection = $true
      RegistrationKey = 'd6750ff1-d8dd-49f7-8caf-7471ea9793fc' # Replace this with correct registration key.
    }
    SignatureValidation validations{
        # If the TrustedStorePath property is provided then LCM will use the custom path. Otherwise, the LCM will use default trusted store path (Cert:\LocalMachine\DSCStore) to find the signing certificate.
        TrustedStorePath = 'Cert:\LocalMachine\DSCStore'
        SignedItemType = 'Configuration','Module'         # This is a list of DSC artifacts, for which LCM need to verify their digital signature before executing them on the node.
    }

}
EnableSignatureValidation
Set-DscLocalConfigurationManager -Path .\EnableSignatureValidation -Verbose

ノードに上記のメタ構成を設定すると、ダウンロードした構成とモジュールで署名を検証できます。Setting the above metaconfiguration on a node enables signature validation on downloaded configurations and modules. ローカル構成マネージャーは次の手順でデジタル署名を検証します。The Local Configuration Manager performs the following steps to verify the digital signatures.

  1. 構成ファイル (.MOF) の署名が有効であることを検証します。Verify the signature on a configuration file (.MOF) is valid. これは PowerShell コマンドレット Get-AuthenticodeSignature を使用します。このコマンドレットは 5.1 で拡張され、MOF 署名検証に対応しています。It uses the PowerShell cmdlet Get-AuthenticodeSignature, which is extended in 5.1 to support MOF signature validation.
  2. 署名者が信頼できることを認定した証明機関を検証します。Verify the certificate authority that authorized the signer is trusted.
  3. 構成のモジュール/リソース依存性を一時的な場所にダウンロードします。Download module/resource dependencies of the configuration to a temp location.
  4. モジュール内に含まれるカタログの署名を検証します。Verify the signature of the catalog included inside the module.
    • <moduleName>.cat ファイルを見つけ、コマンドレット Get-AuthenticodeSignature でその署名を検証します。Find a <moduleName>.cat file and verify its signature using the cmdlet Get-AuthenticodeSignature.
    • 署名者が信頼できることを認定した証明機関を検証します。Verify the certification authority that authenticated the signer is trusted.
    • 新しいコマンドレット Test-FileCatalog を利用し、モジュールのコンテンツが改ざんされていないことを検証します。Verify the content of the modules has not been tampered using the new cmdlet Test-FileCatalog.
  5. $env:ProgramFiles\WindowsPowerShell\Modules\ にモジュールをインストールするInstall-Module to $env:ProgramFiles\WindowsPowerShell\Modules\
  6. プロセス構成Process configuration

注: モジュール カタログと構成の署名検証は、構成がシステムに最初に適用されるときか、モジュールがダウンロードされ、インストールされるときにのみ実行されます。Note: Signature validation on module-catalog and configuration is only performed when the configuration is applied to the system for the first time or when the module is downloaded and installed. 整合性実行では、Current.mof やそのモジュール依存性の署名は検証されません。Consistency runs do not validate the signature of Current.mof or its module dependencies. 何らかの段階で検証に失敗した場合、たとえば、プル サーバーからプルされた構成に署名がされていない場合、構成の処理が中止となり、下にエラーが表示されます。一時ファイルはすべて削除されます。If verification has failed at any stage, for instance, if the configuration pulled from the pull server is unsigned, then processing of the configuration terminates with the error shown below and all temporary files are deleted.

構成のエラー出力のサンプル

同様に、カタログに署名のないモジュールがプルされると次のエラーが発生します。Similarly, pulling a module whose catalog is not signed results in the following error:

モジュールのエラー出力のサンプル

プッシュPush

プッシュで配信された構成は、ノードに届く前にその出所で改ざんされていた可能性があります。A configuration delivered by using push might be tampered with at its source before it delivered to the node. ローカル構成マネージャーは、プッシュまたは公開された構成に対して同様の署名検証手順を実行します。The Local Configuration Manager performs similar signature validation steps for pushed or published configuration(s). 以下は、プッシュの署名検証の完全例です。Below is a complete example of signature validation for push.

  • ノードで署名検証を有効にします。Enable signature validation on the node.
[DSCLocalConfigurationManager()]
Configuration EnableSignatureValidation
{
    Settings
    {
        RefreshMode = 'PUSH'
    }
    SignatureValidation validations{
        TrustedStorePath = 'Cert:\LocalMachine\DSCStore'
        SignedItemType =  'Configuration','Module'
    }

}
EnableSignatureValidation
Set-DscLocalConfigurationManager -Path .\EnableSignatureValidation -Verbose
  • サンプル構成ファイルを作成します。Create a sample configuration file.
# Sample configuration
Configuration Test
{

    File foo
    {
        DestinationPath =  "$env:TEMP\signingTest.txt"
        Contents = "ABC"
    }
}
Test
  • 署名のない構成ファイルをノードにプッシュしてみます。Try pushing the unsigned configuration file in to the node.
Start-DscConfiguration -Path .\Test -Wait -Verbose -Force

ErrorUnsignedMofPushed

  • コード署名証明書を利用し、構成ファイルに署名します。Sign the configuration file using code-signing certificate.

SignMofFile

  • 署名された MOF ファイルをプッシュしてみます。Try pushing the signed MOF file.

SignMofFile