You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
The text was updated successfully, but these errors were encountered: