Skip to content

PowerShell Core configuration #111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
185 changes: 185 additions & 0 deletions 1-Draft/RFCnnnn-PowerShell-Configuration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,185 @@
---
RFC: RFCnnnn
Author: Ilya Sazonov
Status: Draft
SupercededBy: N/A
Version: 0.1
Area: Engine
Comments Due: 2/25/2018
---

# `PowerShell Core` configuration

## Motivation

Consumers, developers, and enterprise system administrators should be able to flexibly and conveniently configure PowerShell Core and applications based on it.

A public PowerShell Core configuration API would allow a unified way to manage PowerShell-based applications in a consistent manner.

## Specification

`PowerShell Core` is configured using the following schemes:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use bold for key terms, rather than backticks.


- On Windows - Group Policy Objects (GPO), Group Policy Preferences (GPP) and settings files.
- On Unix - settings files.

The settings files have `JSON` format.

**Warning** The settings files differ from `PowerShell Core` _profile_ files, which are PowerShell scripts run at startup.

Configuration schemes allow to customize `PowerShell Core` in the most flexible way:

- Enterprise system administrators can use GPO, GPP and computer-wide settings files to apply approved configuration settings and mandatory security settings in a centralized manner. The same settings can be applied at user, application or startup levels.
- Developers and consumers can use user, application and startup level settings files.

### Settings locations

`PowerShell Core` settings are grouped into `Policy settings` and `Regular settings`. Regular settings are normal configuration settings. Regular settings can be treated as default values. Policy settings is high priority and overlap regular settings. Policy settings are used by administrators to centrally manage applications.

Location | Policy settings | Regular settings
- | - | -
File section | "PowerShell": { "PolicySettings": {...} } | "PowerShell": { "RegularSettings": {...} }
File section | "OtherPowerShellApplication": { "PolicySettings": {...} } | "OtherPowerShellApplication": { "RegularSettings": {...} }
Registry key | Software\Policies\PowerShellCore | Software\PowerShellCore
Registry key | Software\Policies\PowerShellCore\OtherPowerShellApplication | Software\PowerShellCore\OtherPowerShellApplication

### Priority of applying settings

Because a configuration setting can be in several schemes, the setting wins according to the priority of its scheme.

#### Priorities for Policy settings in descending order

Scheme | Windows | Unix
-| - | -
GPO -> Computer Policy | HKLM\Software\Policies\PowerShellCore | /etc/powershell.config.json
GPO -> User Policy | HKCU\Software\Policies\PowerShellCore | See `Comment A` below
File -> Computer-Wide | %ProgramFiles%/PowerShell/powershell.config.json | /opt/Microsoft/powershell/powershell.config.json
File -> Application-Startup | pwsh -settingsfile `somepath/powershell.config.json` | pwsh -settingsfile `somepath/powershell.config.json`
File -> User-Wide | %APPDATA%/powershell.config.json | %XDG_CONFIG_HOME%/powershell.config.json
File -> Application-Wide | $apphome/powershell.config.json | $apphome/powershell.config.json

Defaults:

`%APPDATA%` - `C:\Users\useraccount\AppData\Roaming`

`%XDG_CONFIG_HOME%` - `HOME/.config`

#### Parameter `-settingsfile`

With `-settingsfile` parameter users can assign custom settings from the config file and overwrite user-wide and application-wide settings. Only users with elevated rights can overwrite computer-wide and user policy settings.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we are in lockdown mode, even elevated users should not be able to overwrite computer-wide settings

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only users with elevated rights can overwrite computer-wide and user policy settings.

I do not know how to formulate it right at the same time for Windows (GPO) and for Unix (only files).
In fact, the administrator always has the ability to change any setting.
Maybe remove the sentence at all?


#### Priorities for Regular settings in descending order

Scheme | Windows | Unix
-| - | -
File -> Application-Startup | pwsh -settingsfile `somepath/powershell.config.json` | pwsh -settingsfile `somepath/powershell.config.json`
File -> Application-Wide | $apphome\powershell.config.json | $apphome/powershell.config.json
File -> User-Wide | %APPDATA%\powershell.config.json | ~/powershell.config.json
File -> Computer-Wide | %ProgramFiles%\PowerShell\powershell.config.json | /opt/Microsoft/powershell/powershell.config.json
GPO -> User Config | HKCU\Software\PowerShellCore | See `Comment A` below
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regular setting should be deployed via GPP not GPO

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPP is for setting the user can change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're talking about values in the registry. In this case, the user can change any value if it has permissions (mainly in HKCU). (Of course then this value will be overwritten by GPO or GPP)

I don't see the point of distinguishing between regular settings and policies by name. What is the criterion? We are able to set the value in the registry using GPP in the Policy branch (even in HKLM) and thereby assign the policy.

The only question is who, how and for what set/changes the settings. System administrators or security administrators will most often use GPOs to set mandatory standard values that are less likely to GPP to set recommended values.

This document tries to describe all the ways that can be to provide maximum flexibility and also how to get an effective value based on priority.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPP has the ability to not overwrite if the user changes the registry.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, GPO implies that the setting is policy, which this setting is not. It is a preference.

GPO -> Computer Config | HKLM\Software\PowerShellCore | /etc/powershell.config.json

### Configuration settings

A set of configuration settings in GPO scheme and file scheme for policy settings and regular settings is the same. This allows to discover and configure settings in the simplest and fastest way.

#### Registry keys and settings

| Key | SubKey | Option | Type
| -| - | - | -
Software\Policies\PowerShellCore | - | -
Software\PowerShellCore | - | -
| | | ExecutionPolicy | String
| | | PipelineMaxStackSizeMB | DWORD
| | ConsoleSessionConfiguration | EnableConsoleSessionConfiguration | DWORD
| | ConsoleSessionConfiguration | ConsoleSessionConfigurationName | String
| | ModuleLogging | EnableModuleLogging | DWORD
| | ModuleLogging | ModuleNames | String
| | ProtectedEventLogging | EncryptionCertificate | DWORD
| | ScriptBlockLogging | EnableScriptBlockInvocationLogging | DWORD
| | ScriptBlockLogging | EnableScriptBlockLogging | DWORD
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can ScriptBlockLogging\* and ProtectedEventLogging\* also be configured via policy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If logging settings refers to security then this make sense.
(Here I meant that all the settings listed can be either policy or regular)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These setting plus execution policy are Security related.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ModuleLogging also..

Transcription would not be set system wide, it would need to be per user or it's better to use scriptblock logging. IMHO.

cc @PaulHigin

| | Transcription | EnableTranscripting | DWORD
| | Transcription | EnableInvocationHeader | DWORD
| | Transcription | OutputDirectory | String
| | UpdatableHelp | DefaultSourcePath | String
|Software\Policies\Microsoft\Windows\EventLog | ProtectedEventLogging | EnableProtectedEventLogging | DWORD

#### JSON file settings format

```json
{
"PowerShell": {
"RegularSettings": {
"ConsoleSessionConfiguration": {
"EnableConsoleSessionConfiguration": true,
"ConsoleSessionConfigurationName": "name"
},
"ProtectedEventLogging": {
"EnableProtectedEventLogging": false,
"EncryptionCertificate": [
"Joe"
]
},
"ScriptBlockLogging": {
"EnableScriptBlockInvocationLogging": true,
"EnableScriptBlockLogging": false
},
"ScriptExecution": {
"ExecutionPolicy": "RemoteSigned",
"PipelineMaxStackSizeMB": 10
},
"Transcription": {
"EnableTranscripting": true,
"EnableInvocationHeader": true,
"OutputDirectory": "c:\\tmp"
},
"UpdatableHelp": {
"DefaultSourcePath": "f:\\temp"
}
},

"PoliciesSettings": {
...
}
},

"OtherPowerShellApplication": {
"RegularSettings": {
...
},
"PolicySettings": {
...
}
}
```

## Alternate Proposals and Considerations

We could redesign `-settingsfile` startup parameter. If we'd support configuration sections for applications we'd can introduce `-settings` parameter to specify a particular configuration as `-settings OtherPowerShellApplication`. Ex.: `pwsh -settings Debug`.

### Comment A

Mainly for Unix we'd add `Users` section to computer wide JSON file (`/etc/powershell.config.json`) to allow administrators set policies and regular settings on user level base

```json
{
"PowerShell": {
"RegularSettings": {
...
},
"PolicySettings": {
...
},
"Users": {
"Smith": {
"PowerShell": {
"RegularSettings": {
...
},
"PolicySettings": {
...
}
}
}
}
```