Skip to content
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

When using the Export-M365DSCConfiguration command with the Security & Compliance components I get odd errors that it is missing parameters #5446

Open
rick-engle opened this issue Nov 21, 2024 · 7 comments

Comments

@rick-engle
Copy link

Description of the issue

I've been using Export-M365DSCConfiguration for exporting a lot of components from my source tenant. But if I use that for any of the Security & Compliance components, I get this error:
Export-M365DSCConfiguration -Components @("SCAuditConfigurationPolicy" ) -ApplicationId $clientId -TenantId $tenantIdDomainName -ApplicationSecret $clientSecretValue -Path $SavePath -FileName $SaveFileName

Exporting Microsoft 365 configuration for Components: SCAuditConfigurationPolicy

Authentication methods specified:

  • Service Principal with Application Secret

Connecting to {SecurityComplianceCenter}...✅
[1/1] Extracting [SCAuditConfigurationPolicy] using {}...Partial Export file was saved at: C:\Users\RICKE~1.RED\AppData\Local\Temp\15bd646a-ba9f-456e-94f5-969215a1c05c.partial.ps1
You must specify either the Credential or ApplicationId, TenantId and CertificateThumbprint parameters.
At C:\Program Files\WindowsPowerShell\Modules\Microsoft365DSC\1.24.1120.1\Modules\M365DSCUtil.psm1:1971 char:9

  •     throw $errorText
    
  •     ~~~~~~~~~~~~~~~~
    
    • CategoryInfo : OperationStopped: (You must specif...int parameters.:String) [], RuntimeException
    • FullyQualifiedErrorId : You must specify either the Credential or ApplicationId, TenantId and CertificateThumbprint parameters.

That exact command used with the very same parameter values works for AAD, Intune and Office 365 components with no errors. For example this command works fine for an AAD component:
Export-M365DSCConfiguration -Components @("AADConditionalAccessPolicy" ) -ApplicationId $clientId -TenantId $tenantIdDomainName -ApplicationSecret $clientSecretValue -Path $SavePath -FileName $SaveFileName
while this very similar command for component "SCAuditConfigurationPolicy" fails:
Export-M365DSCConfiguration -Components @("SCAuditConfigurationPolicy" ) -ApplicationId $clientId -TenantId $tenantIdDomainName -ApplicationSecret $clientSecretValue -Path $SavePath -FileName $SaveFileName

Microsoft 365 DSC Version

1.24.1120.1

Which workloads are affected

Security & Compliance Center

The DSC configuration

Verbose logs showing the problem

Export-M365DSCConfiguration -Components @("SCAuditConfigurationPolicy" ) -ApplicationId $clientId -TenantId $tenantIdDomainName -ApplicationSecret $clientSecretValue -Path $SavePath -FileName $SaveFileName

Exporting Microsoft 365 configuration for Components: SCAuditConfigurationPolicy
 
Authentication methods specified:
- Service Principal with Application Secret
 
Connecting to {SecurityComplianceCenter}...✅
[1/1] Extracting [SCAuditConfigurationPolicy] using {}...Partial Export file was saved at: C:\Users\RICKE~1.RED\AppData\Local\Temp\15bd646a-ba9f-456e-94f5-969215a1c05c.partial.ps1
You must specify either the Credential or ApplicationId, TenantId and CertificateThumbprint parameters.
At C:\Program Files\WindowsPowerShell\Modules\Microsoft365DSC\1.24.1120.1\Modules\M365DSCUtil.psm1:1971 char:9
+         throw $errorText
+         ~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (You must specif...int parameters.:String) [], RuntimeException
    + FullyQualifiedErrorId : You must specify either the Credential or ApplicationId, TenantId and CertificateThumbprint parameters.

Environment Information + PowerShell Version

OsName               : Microsoft Windows 11 Enterprise
OsOperatingSystemSKU : EnterpriseEdition
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 26100.1.amd64fre.ge_release.240331-1435
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Key   : PSVersion
Value : 5.1.26100.2161
Name  : PSVersion

Key   : PSEdition
Value : Desktop
Name  : PSEdition

Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0...}
Name  : PSCompatibleVersions

Key   : BuildVersion
Value : 10.0.26100.2161
Name  : BuildVersion

Key   : CLRVersion
Value : 4.0.30319.42000
Name  : CLRVersion

Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion

Key   : PSRemotingProtocolVersion
Value : 2.3
Name  : PSRemotingProtocolVersion

Key   : SerializationVersion
Value : 1.1.0.1
Name  : SerializationVersion
@FabienTschanz
Copy link
Collaborator

@rick-engle That is because e.g. SCAuditConfigurationPolicy does not support the ApplicationSecret authentication method. It only supports Credential, CertificateThumbprint, CertificatePassword (with CertificatePath) and AccessTokens. Other methods are not supported.

@rick-engle
Copy link
Author

rick-engle commented Nov 22, 2024

Oh, that is a good detail @FabienTschanz. Would you have a complete PowerShell script snippet that shows the proper way to create credentials and call Export-M365DSCConfiguration -Components that consumes that credential? I was using ApplicationSecret because we are mandated to use MFA in our company and @NikCharlebois recommended that I instead use the ApplicationSecret method.

@FabienTschanz
Copy link
Collaborator

The resource page of SCAuditConfigurationPolicy contains an example on how to do it, but I am not familiar with the Credential object myself. From what I was able to gather, you can either specify the Credential object in the ConfigurationData.psd1 file (and then reference that in the configuration from a parameter) or you can also directly request it in the configuration like so: $cred = Get-Credential -UserName contoso\genericuser -Message "Password please"

More information about credentials can be found here: https://learn.microsoft.com/en-us/powershell/dsc/configurations/configdatacredentials?view=dsc-1.1
General informations about deploying the configurations (with some more links): https://microsoft365dsc.com/user-guide/get-started/deploying-configurations/

Hope that helps.

@FabienTschanz
Copy link
Collaborator

@rick-engle Any updates on the issue?

@rick-engle
Copy link
Author

Sorry @FabienTschanz I have not had a chance to try that out let me see if I can get your technique to work.

@rick-engle
Copy link
Author

Ok, @FabienTschanz I got back to this and got it working. I used:

$credential = Get-Credential -UserName $SourceTenantUserName -Message "Please enter your password for $SourceTenantUserName"

PS C:\WINDOWS\system32> Export-M365DSCConfiguration -Components @("SCAuditConfigurationPolicy", "SCAutoSensitivityLabelPolicy", "SCAutoSensitivityLabelRule", "SCCaseHoldPolicy", "SCCaseHoldRule", "SCComplianceCase", "SCComplianceSearch", "SCComplianceSearchAction", "SCComplianceTag", "SCDeviceConditionalAccessPolicy", "SCDeviceConfigurationPolicy", "SCDLPCompliancePolicy", "SCDLPComplianceRule", "SCFilePlanPropertyAuthority", "SCFilePlanPropertyCategory", "SCFilePlanPropertyCitation", "SCFilePlanPropertyDepartment", "SCFilePlanPropertyReferenceId", "SCFilePlanPropertySubCategory", "SCLabelPolicy", "SCProtectionAlert", "SCRetentionCompliancePolicy", "SCRetentionComplianceRule", "SCRetentionEventType", "SCRoleGroup", "SCRoleGroupMember", "SCSecurityFilter", "SCSensitivityLabel", "SCSupervisoryReviewPolicy", "SCSupervisoryReviewRule") -Credential $credential -Path $SavePath -FileName $SaveFileName

At first it had an issue saying that dependencies were wrong, and I had to take these steps:
Please run Update-M365DSCDependencies as Administrator. Please run Uninstall-M365DSCOutdatedDependencies.

After that it worked. But as I said when I opened this bug it is very odd that the Security & Compliance components are the only ones that don't support this auth method:
Authentication methods specified:
Service Principal with Application Secret

Is that considered a bug as you would think that all of the components could be accessed the same way?

@FabienTschanz
Copy link
Collaborator

@rick-engle From the outside perspective, yes, it would appear to be a bug. Just as you described, one would expect that all resources are accessible the same way. From the inside perspective, that changes: The SC resources rely on the ExchangePowerShell module and more specifically on the Connect-IPPSSession cmdlet. This cmdlet unfortunately doesn't support anything but Credential and certificate authentication according to the documentation. So for this you either use the Credential parameter or switch to a certificate authentication. I'm always using certificates, so I normally don't run into these problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants