Remediation not working for AzureWindowsBaseline and blocks access to VM via RDP
I applied AzureWindowsBaseline Guest Assignment using ApplyAndMonitor mode, but the following items return non-compliant state.
| Name | Compliance State | Reason |
|---|---|---|
| Access this computer from the network | Non-compliant | [Critical] [] is missing one or more of the required values: ["*S-1-5-32-544","*S-1-5-11"] |
| Bypass traverse checking | Non-compliant | [Critical] "*S-1-5-32-545" is not one of the expected values: ["*S-1-5-32-544","*S-1-5-11","*S-1-5-32-551","*S-1-5-19","*S-1-5-20"] |
| Increase a process working set | Non-compliant | [Warning] "*S-1-5-32-545" is not one of the expected values: ["*S-1-5-32-544","*S-1-5-19"] |
Additionally I noticed that I can connect to VM before applying assignment, but I cannot after, which means that AzureWindowsBaseline is messing up the machine configuration.
The system administrator has restricted the types of log-on (network or interactive) that you may use. For assistance, contact your system administrator or technical support.
I verified manually that before applying is less restrictive and contains more that "*S-1-5-32-544","*S-1-5-11"
I know it was working fine a few months ago. Is there any changelog and the possibility to point my configuration to older version of this guest policy?
BTW is there any way to check what AzureWindowsBaseline does behind the scene? I cannot find any definition of checks in the documentation and troubleshooting procedure. From my perspective is a black box because MS docs contains most information how to create and assign guest policies.
https://learn.microsoft.com/en-us/answers/questions/2285141/azurewindowsbaseline-guest-assignment-started-to-b
@robga @shanhix1 Do you know who could help?
We're working with MS on trying to roll back this change to the Windows Baseline config aswell. In the meantime this is the command I've been using via "Run Command" in the azure portal to regain access via rdp.
# Export the current security policy
secedit /export /cfg C:\secpol.cfg
Get-Content C:\secpol.cfg
# Read the file, remove any SeNetworkLogonRight and SeDenyNetworkLogonRight lines, and insert the new SeNetworkLogonRight after [Privilege Rights]
$lines = Get-Content C:\secpol.cfg
$insertIndex = $lines.IndexOf('[Privilege Rights]') + 1
$seNetworkLine = 'SeNetworkLogonRight = *S-1-5-32-544,*S-1-5-32-545,*S-1-5-11'
# Remove existing SeNetworkLogonRight and SeDenyNetworkLogonRight lines
$lines = $lines | Where-Object { $_ -notmatch '^SeNetworkLogonRight'}
# Insert the new SeNetworkLogonRight line
$lines = $lines[0..($insertIndex-1)] + $seNetworkLine + $lines[$insertIndex..($lines.Count-1)]
$lines | Set-Content C:\secpol.cfg
# Import the updated security policy
secedit /import /cfg C:\secpol.cfg /quiet /overwrite
secedit /configure /db secedit.sdb /cfg C:\secpol.cfg /quiet /overwrite
# Display the contents of the imported secpol.cfg
secedit /export /cfg C:\secpol.cfg
Get-Content C:\secpol.cfg
# Clean up
Remove-Item C:\secpol.cfg
Thanks @mrmacky343, I'm using something similar. If you find out anything from MS, please let me know
+1 that this has suddenly started affecting new VMs we create in the last few weeks, and wasted a huge amount of time trying to figure out what the problem was (after which we applied a similar workaround to @mrmacky343 via the serial console).
Thanks @mrmacky343, I'm using something similar. If you find out anything from MS, please let me know
For what it's worth, this is now fixed for us on new VMs, without us having changed anything, so maybe it's been resolved upstream!
We still expect an explanation from the responsible team and information on how to avoid such situations in the future, because such problems can have a serious impact on our environment. I expect stable solutions and clear communication. On the Microsoft Q&A forum, MS support did not provide an answer as to whether this is a known issue, whether the responsible team is working on it, what the status is, or any other relevant information.