Getting an unable to parse input: yaml error

[insanedasi]

🐛 Summary

When I run the script using all products, I get a message saying "unable to parse input: yaml: line 184: found unknown escape character" followed by a much of objects not found in the Orchestrator.psml. If I run the products individually in the RunScuba script the issue does not occur.

Basically, if I run this, I get the error: $ProductNames = @("aad", "defender", "exo", "onedrive", "sharepoint", "teams") # The specific products that you want the tool to assess.

If I run the script with this (tested with all products) it runs find $ProductNames =@("teams")

Any help would be greatly appreciated.

[ethanb-cisa]

Thanks for opening the issue. We're looking into it and will assign someone to the issue soon.

Can you step through each baseline and maybe identify which baseline is generating the error? It seems like Teams runs fine, but one of the others might be the problem.

[insanedasi]

When you run the base lines individually the issue is not duplicated. However as soon as you run it all of them together (the default in the script) then I get this. I have tested this against multiple tenants and the results are all the same.

[buidav]

When you run the base lines individually the issue is not duplicated. However as soon as you run it all of them together (the default in the script) then I get this. I have tested this against multiple tenants and the results are all the same.

• In a text editor that can highlight invalid JSON like VS Code, could you screenshot the line (line 184) that is causing the error in the JSON. The JSON file should be in your output path in a folder called "M365BaselineConformance_*" with the name "ProviderSettingsExport.json"
• Could you run the tool with multiple combinations of products to see if it's a specific combination is causing the issue? For example @("aad", "teams"), @("exo", "sharepoint", "onedrive") or @("defender").
• What licenses do the tenants you're running the tool against have? E3/E5, Azure AD Premium Plan 1/2, and/or Microsoft Defender for Office 365 Plan 1/2 etc.

[LatetoGitHub]

I have the same issue, except it's occurring on a different line. Tried two separate tenants, one with Business Premium licenses, and the other with a mix of many different license types.

[LatetoGitHub]

Here's the line from ProviderSettingsExport.json file

[buidav]

Here's the line from ProviderSettingsExport.json file

Thank you for the screenshot. Looks like the error is being caused by the JSON conversion of the Get-CsTenant cmdlet from the MicrosoftTeams PowerShell module. Short version: If anyone else is facing this issue the quickest solution until the next release is to remove "teams" from $ProductNames in RunScuba.ps1

What's causing this issue

OPA Rego will output the unable to parse input : yaml: ... error when encountering \ "backslash" characters. Even though this is valid JSON, we've seen Rego throw the same error for backslash characters in other instances and do some minor sanitization to remove such characters from the ProviderSettingExport.json. The sanitization was NOT being done on this specific function in the code Get-TeamsTenantDetail where an invocation of Get-CsTenant is located.

However, we're unable to reproduce the error ourselves, even with an E5 tenant that has similar output in the JSON. See image below. This line is not being used for the configuration assessment so we're unsure why the error is being thrown in this instance. Regardless, for the next release we'll add in the fix for this by adding full JSON sanitization to this function.

Temporary solutions

1. As mentioned above omit teams from $ProductNames in RunScuba.ps1.
2. Another solution is to edit the Get-TeamsTenantDetail function in ExportTeamsProvider.psm1 yourself and add this line $TenantInfo.SyncInLyncAdInfo = @() somewhere before the ConvertTo-Json call in the function.

[LatetoGitHub]

Thanks, I was able to use the omit Teams workaround to get the reports generated. I was running the scripts from Windows Terminal on Win 11, just in case it helps

` Name Value

---

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

[buidav]

Thanks, I was able to use the omit Teams workaround to get the reports generated. I was running the scripts from Windows Terminal on Win 11, just in case it helps

` Name Value

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

Thanks for the additional information. I spun up a Windows 11 VM and reran my tests. No errors thrown from OPA with the JSON on my side. So, Windows 11 doesn't seem to be part of the root issue.

[insanedasi]

I apologize for the delay in responding. Here is line 184:

                             "StopSyncTimestamp":  "\/Date(1657087007367)\/"

I am currently testing out the various combinations and will post any finding once I have completed. For licensing the following is true: 1 tenant has o365 E3 2 tenants have M365 E5 All 3 tenants have Azure AD P2

The error is observable in all 3 tenants.

[buidav]

I apologize for the delay in responding. Here is line 184:

                             "StopSyncTimestamp":  "\/Date(1657087007367)\/"

I am currently testing out the various combinations and will post any finding once I have completed. For licensing the following is true: 1 tenant has o365 E3 2 tenants have M365 E5 All 3 tenants have Azure AD P2

The error is observable in all 3 tenants.

Thank you for the reply and additional information. The issue is definitely related to the backslashes in the StopSyncTimeStamp then and from the evidenced gathered has nothing to do with different Tenant licensing levels. Doesn't seem operating system related as we are able to successfully run on both Windows 10 and 11. The issue seems to be related to the OPA exe and how that's being run with the Rego on a client system. Sanitizing the JSON will resolve the issue but still a mystery of what is making OPA behave differently between systems.

[ethanb-cisa]

Closed in #24