Почему для ресурса файла конфигурации желаемого состояния работают учетные данные, а PsDscRunAsCredential — нет?

Кажется, моя догадка могла быть верной; превращая мой комментарий в ответ:

У меня только что возникла мысль: ресурс File... несколько особенный. Это один из немногих ресурсов, реализованных в двоичном виде. У него есть некоторые странности, такие как отсутствие возврата ModuleName при запуске Get-DscResource. Возможно, это реализовано таким образом, что LCM не может изменить свой контекст. Было бы интересно включить отладку для DSC, а потом ворваться в отладчик и проверьте свой контекст, попробуйте получить доступ к общему ресурсу и локальной файловой системе и т. д.

При выполнении теста оказывается, что (по какой-то причине) ресурс File просто не поддерживает должным образом PsDscRunAsCredential.

Вот демонстрация с использованием Invoke-DscResource, сравнивающая File с Script и показывающая, что владелец результирующего файла другой.

С File владельцем всегда будет SYSTEM.

С Script владельцем является SYSTEM при запуске без учетных данных (ожидается), но при запуске с учетными данными владелец другой (в моем случае владельцем стала локальная группа Administrators, потому что учетные данные, которые я предоставил, являются локальным администратором) .

$cred = Get-Credential

$module = 'PsDesiredStateConfiguration'

$fprop = @{
    DestinationPath = "$env:USERPROFILE\delme.txt"
    Contents = "Hello"
}

$sprop = @{
    GetScript = { @{} }
    TestScript = { $false }
    SetScript = [ScriptBlock]::Create("'Hello'|sc '$env:USERPROFILE\delme.txt'")
}

$cprop = @{ PsDscRunAsCredential = $cred }

function Assert-FileTest { Get-Item -LiteralPath $fprop.DestinationPath | % { $_.GetAccessControl().Owner | Write-Verbose -Verbose ; $_ } | Remove-Item -Force }

Invoke-DscResource -Name File -ModuleName $module -Method Set -Property $fprop -Verbose
Assert-FileTest

Invoke-DscResource -Name File -ModuleName $module -Method Set -Property ($fprop + $cprop) -Verbose
Assert-FileTest


Invoke-DscResource -Name Script -ModuleName $module -Method Set -Property $sprop -Verbose
Assert-FileTest

Invoke-DscResource -Name Script -ModuleName $module -Method Set -Property ($sprop + $cprop) -Verbose
Assert-FileTest

@briantist правильно указывает, что файл - это ресурс особого типа... он реализован на C ++ как ресурс WMI. Остальные встроенные ресурсы реализованы в PowerShell (за исключением журнала, который реализован внутри самого механизма DSC).

Ресурсы WMI не приобрели популярности, и File — единственный ресурс, реализованный таким образом.

PsDscRunAsCredential был реализован для ресурсов PowerShell, но не для ресурсов WMI. Вот почему он не работает для File.

Кроме того, свойство Credential объекта File более ограничено, чем PsDscRunAsCredential: оно используется только для доступа к файлам в сетевой папке.

Я постараюсь добавить эту информацию в нашу документацию. Спасибо, что указали на это.

См. статью Учетные данные ConfigData, в частности

Ресурсы конфигурации DSC по умолчанию работают как локальная система. Однако для некоторых ресурсов требуются учетные данные, например, когда ресурсу Package требуется установить программное обеспечение под определенной учетной записью пользователя.

В более ранних ресурсах для этого использовалось жестко заданное имя свойства Credential. В WMF 5.0 добавлено автоматическое свойство PsDscRunAsCredential для всех ресурсов. Сведения об использовании PsDscRunAsCredential см. в разделе Запуск DSC с учетными данными пользователя. Новые ресурсы и пользовательские ресурсы могут использовать это автоматическое свойство вместо создания собственного свойства для учетных данных.