On the second example observe that i have "Force = $True". That works perfectly if there is only one identity involved. The module will set that without issue.
On EXAMPLE1 if i add force, the script will fail. If i leave it as it is and change an identity DSC will report compliance even though Local Sec Pol will not reflect any change
So lets for example take this setting : This is the default out of the box
This is now my script 👍
I have added the "Force" into it and i compiled it to .mof
then i run it:
Is this how it is supposed to work or i am missing something here?
Another example
I removed all the groups from there
then run my script that contains:
Did check for compliance using : Test-DscConfiguration -Detailed | ft ResourcesNotInDesiredState
and all seems ok, however if i switch back to the gui and hit "reload" there is nothing there
So to double check i did a SecEdit.exe /export /areas USER_RIGHTS /cfg C:\t\u.txt and looked into the file to see if SeRemoteShutdownPrivilege is there and it is actually not.
I am a bit lost to be honest. Everything else seems to be working ok, however User Rights Assignment are a bit quirky and hit and miss.
Verbose logs showing the problem
Suggested solution to the issue
i have none!
The DSC configuration that is used to reproduce the issue (as detailed as possible)
# insert configuration here
The operating system the target node is running
OsName : Microsoft Windows Server 2022 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture : 64-bit
WindowsVersion : 2009
WindowsBuildLabEx : 20348.1.amd64fre.fe_release.210507-1500
OsLanguage : en-US
OsMuiLanguages : {en-US}
Version and build of PowerShell the target node is running
Details of the scenario you tried and the problem that is occurring
So i am applying Microsoft Security Baseline and i have got User rights assignments like :
(EXAMPLE 1)
(EXAMPLE 2) }
On the second example observe that i have "Force = $True". That works perfectly if there is only one identity involved. The module will set that without issue.
On EXAMPLE1 if i add force, the script will fail. If i leave it as it is and change an identity DSC will report compliance even though Local Sec Pol will not reflect any change
So lets for example take this setting : This is the default out of the box![image](https://user-images.githubusercontent.com/95470450/232872341-0d50bef2-078c-4bc8-8173-aef40984aca3.png)
This is now my script 👍![image](https://user-images.githubusercontent.com/95470450/232872566-0ddb771f-f62a-496a-8f1c-6619f236534c.png)
I have added the "Force" into it and i compiled it to .mof
then i run it:
Is this how it is supposed to work or i am missing something here?
Another example
I removed all the groups from there
then run my script that contains:
Did check for compliance using : Test-DscConfiguration -Detailed | ft ResourcesNotInDesiredState![image](https://user-images.githubusercontent.com/95470450/232881477-3c2ce0b9-a307-431a-baf0-59b15a0d4857.png)
and all seems ok, however if i switch back to the gui and hit "reload" there is nothing there![image](https://user-images.githubusercontent.com/95470450/232881890-4ea439e8-27ff-40f0-a34b-f629cd28a449.png)
So to double check i did a SecEdit.exe /export /areas USER_RIGHTS /cfg C:\t\u.txt and looked into the file to see if SeRemoteShutdownPrivilege is there and it is actually not.
I am a bit lost to be honest. Everything else seems to be working ok, however User Rights Assignment are a bit quirky and hit and miss.
Verbose logs showing the problem
Suggested solution to the issue
i have none!
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
OsName : Microsoft Windows Server 2022 Standard OsOperatingSystemSKU : StandardServerEdition OsArchitecture : 64-bit WindowsVersion : 2009 WindowsBuildLabEx : 20348.1.amd64fre.fe_release.210507-1500 OsLanguage : en-US OsMuiLanguages : {en-US}
Version and build of PowerShell the target node is running
Name Value
PSVersion 5.1.20348.1 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.20348.1 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1
Version of the DSC module that was used