Could you further explain why you think PowerShell is the reason for this? Any other salient details you can provide?
It seems youâre really running cmd under the hood. and simply invoking it with Invoke-Expression. Furthermore, you mentioned it works when you run it interactively but not via gpo. This would imply that the command ran in the first block works interactively, which means something else would be at play (like the GPO).
Also I want to make sure I, as well as others, fully understand the problem. When you try via GPO to set this, the actual SDDL string that is set on the SC manager is:
Iâm hung up on the term âscrambleâ. It seems like only a part of the SDDL string is not expected, specifically:
# The unexpected section of SDDL string
(**A;;CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-9941730060-274077788-3990600260**)
# Should actually be:
(A;;CCLCRPRC;;;S-1-5-21-5126416528-1234567890-3447268803-1234)
Is that correct? Iâm assuming the SID being different is expected potentially. the bigger issue being the other part of the SDDL string missing stuff and adding asterick characters. because I remove that bit from the corresponding âexpected outputâ, the output is exactly the same, so its not really âscrambledâ.
Have you confirmed the GPOâs code is indeed matching what you do interactively? Is this just running a PS1 file? Have you tried just not doing Invoke-Expression and just doing a batch script to rule out PS? Based on the information provided I canât really conclude that PS is the issue.
the ** - I noticed there was ending **⌠was this added perhaps by mistake when you were entering the data and trying to bold something?
If 1 is true, then maybe it has something to do with timing and it not being able to properly resolve. You might investigate other ways to set that via GPO, or through a different means. Perhaps itâs trying to validate parts of that string and isnât able too, thus not properly completing it. maybe a login script instead of a startup script?
The ** ** are added by the Code formatter here.
The origional code is
ââA;;CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-9941730060-274077788-3990600260ââ
Thx for the response.
I doubt this is caused by GPO as it merely calling the PS1 file with the code.
The result is that the SID is scrambled, and some permissions are not set.
the expected permissions would be CCLCRPRC, while only CC is being set.
The SID is way longer then the SID applied in the PS1 file.
Just to make sure you did uncomment all your code when you are calling it in your ps1 via gpo? If you forgot to uncomment any part of your code in the actual PS1 file that gets called, that could explain it. What if youâre calling it and its null, and that other SID was just something thta happened to be on that service object already? Code works interactively for me when I uncomment⌠but when I ran the code as is, not uncommenting (but updated the SID of course), i got a success message, but the SDDL string that retunrs using sc.exe sdshow scmanager didnât change at all.
EDIT: To clarify, if you left it as is, in the first code, the script would just basically do nothing. Just for giggles I ran something like this:
I really havenât used the sc.exe command much but the result of that is basically empty $SCmanParams var. I ran that and it just did nothing. I was expecting it to null out the SDDL string tbh.