Admin setting and group policy for configuration processor path argument#6119
Admin setting and group policy for configuration processor path argument#6119JohnMcPMS merged 5 commits intomicrosoft:masterfrom
Conversation
| <string id="EnableWindowsPackageManagerConfigurationProcessorPathExplanation"> | ||
| This policy controls whether users can specify a custom DSC processor path via the --processor-path argument in Windows Package Manager configuration commands. This option is intended for testing purposes. |
There was a problem hiding this comment.
If it is for testing, do we need to expose it as a GP?
There was a problem hiding this comment.
I removed that bit of the text. I think if it exists it is worth having the GP for.
|
|
||
| If you enable or do not configure this setting, users will be able to specify a custom DSC processor path in configuration commands. | ||
|
|
||
| If you disable this setting, users will not be able to specify a custom DSC processor path in configuration commands.</string> |
There was a problem hiding this comment.
I assume that not being able to set the custom processor path is the more secure option? Shouldn't that be the default if not configured?
There was a problem hiding this comment.
Yes, but maybe it should read "then the admin setting is considered, which is default disabled". This is similar to local manifest, as is the text here.
Not Configured -> Admin setting is considered, defaults to disabled.
Enabled/Disabled -> Overrides admin setting.
Trenly
left a comment
Trenly
left a comment
There was a problem hiding this comment.
Are there future plans for a DefaultConfigurationProcessor setting so that admins can force a custom processor, or users can set their own default (if allowed by policy) ?
| If you enable or do not configure this setting, users will be able to use the Windows Package Manager's MCP server. | ||
|
|
||
| If you disable this setting, users will not be able to to use the Windows Package Manager's MCP server.</string> | ||
| <string id="EnableWindowsPackageManagerConfigurationProcessorPath">Enable Windows Package Manager Configuration processor path</string> |
There was a problem hiding this comment.
Nit: Seems most other GPO names are Title Cased
Not currently. If that is strongly desired, I would suggest building a custom wrapper in the interim. |
| If you enable or do not configure this setting, users will be able to use the Windows Package Manager's MCP server. | ||
|
|
||
| If you disable this setting, users will not be able to to use the Windows Package Manager's MCP server.</string> | ||
| <string id="EnableWindowsPackageManagerConfigurationProcessorPath">Enable Windows Package Manager Configuration Processor Path</string> |
There was a problem hiding this comment.
I'm not a fan of this string. Maybe "Enable custom Configuration Processor Path for Windows Package Manager"?
There was a problem hiding this comment.
Two questions:
- Do you think we should have this policy? We could just leave it as an admin setting only, but thus far I every admin setting has a policy.
- Have a naming opinion?
There was a problem hiding this comment.
Enable Windows Package Manager Configuration Processor Path
Enable Windows Package Manager Configuration Processor Override
Enable Windows Package Manager Custom Configuration Processor Path
Enable Custom Configuration Processor Path for Windows Package Manager
Enable Configuration Processor Override for Windows Package Manager
There was a problem hiding this comment.
We have a bunch of policies under Desktop App Installer
The ones with "App Installer" in the name were from a time when the naming seemed to best align that way.
The newer ones have "Windows Package Manager" in their name.
I believe I would go with:
Enable Windows Package Manager Configuration Processor Override
When it is not configured, the elevated user can enable the setting.
When it is enabled, the user can use the setting (it's enabled).
When it is disabled, the user cannot use the setting (it's disabled, and the elevated user cannot enable the setting).
We know the elevated user can modify the GPO setting, so it's a best effort if the setting is disabled and the user can elevate.
This comment was marked as outdated.
This comment was marked as outdated.
4 participants
Change
Adds an admin setting (
ConfigurationProcessorPath) and group policy (EnableWindowsPackageManagerConfigurationProcessorPath) to gate access to the--processor-pathargument for configuration commands.Yes, it sadly does take touching 23 files to implement that.
Validation
New unit test for gp/setting interaction and e2e test for enforcement. Manual confirmation of admin setting functionality as well.
Microsoft Reviewers: Open in CodeFlow