AdcsCertificationAuthority: Uses login type 8 - plain text password

[ghost]

Details of the scenario you tried and the problem that is occurring

We are using DSC resource AdcsCertificationAuthority with an Azure Automation account to run on an Azure Windows Server. Azure Log analytics of the server is showing that each time the DSC script runs there is a plain text password being used by the server (Login type 8).

When I remove the AdcsCertificationAuthority resource no Login Type 8 is logged. This is a security problem for our environment.

Verbose logs showing the problem

An account was successfully logged on.

Subject:
	Security ID:		SYSTEM
	Account Name:		{sensitive}
	Account Domain:		{sensitive}
	Logon ID:		0x3E7

Logon Information:
	Logon Type:		8
	Restricted Admin Mode:	-
	Virtual Account:		No
	Elevated Token:		Yes

Impersonation Level:		Impersonation

New Logon:
	Security ID:		{sensitive}
	Account Name:		admin
	Account Domain:		{sensitive}
	Logon ID:		0x31476D
	Linked Logon ID:		0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{sensitive}

Process Information:
	Process ID:		0x1320
	Process Name:		C:\Windows\System32\wbem\WmiPrvSE.exe

Network Information:
	Workstation Name:	v1prodvampca
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Advapi  
	Authentication Package:	Negotiate
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Suggested solution to the issue

Unknown

The DSC configuration that is used to reproduce the issue (as detailed as possible)

    AdcsCertificationAuthority CertificateAuthority {
      IsSingleInstance          = 'Yes'
      Ensure                    = 'Present'
      CAType                    = 'EnterpriseRootCA'
      Credential                = $Admin1Creds
      CryptoProviderName        = 'RSA#Microsoft Software Key Storage Provider'
      HashAlgorithmName         = 'SHA256'
      KeyLength                 = '2048' 
      CACommonName              = $RootCertName
      CADistinguishedNameSuffix = $domainPath
      ValidityPeriod            = 'Years'
      ValidityPeriodUnits       = 10
      DependsOn                 = '[WindowsFeature]ADCA'
    }

The operating system the target node is running

OsName : Microsoft Windows Server 2019 Datacenter OsOperatingSystemSKU : DatacenterServerEdition OsArchitecture : 64-bit WindowsVersion : 1809 WindowsBuildLabEx : 17763.1.amd64fre.rs5_release.180914-1434 OsLanguage : en-US OsMuiLanguages : {en-US}

Version and build of PowerShell the target node is running

PSVersion 5.1.17763.2931 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.17763.2931 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

Module version 5.0.0

[johlju]

Closing this as it is a duplicate with https://github.com/dsccommunity/ActiveDirectoryCSDsc/issues/134, and this issue is for a resource that is not in this repo.

[johlju]

My bad. It was absolutely the correct repo, I thought it was in the module ActiveDirectoryDsc. Sorry about that. Reopened.

[johlju]

My guess is; You are passing credential (encrypted I assume) in the compiled configuration (the variable $Admin1Creds). The the node runs the configuration, the credentials are decrypted by LCM and then used to run this command:

https://github.com/dsccommunity/ActiveDirectoryCSDsc/blob/fc7d5d1870ddeda0dbe0e564977b49671263c601/source/DSCResources/DSC_AdcsCertificationAuthority/DSC_AdcsCertificationAuthority.psm1#L691

Do you mean that it is okay that it uses the credentials when calling Set-function, but not okay to use the credential for each run when the configuration is monitored/enforced, when it calls Test-function?

Not sure how to avoid using the credentials that are provided in the configuration? 🤔

[ghost]

I recommend we use the -credential param instead of a json param for the credentials. This would use a PSCredential instead of plain text username and password initialization of the CA.

https://learn.microsoft.com/en-us/powershell/module/adcsdeployment/install-adcscertificationauthority?view=windowsserver2022-ps#-credential