none
Get-WMIObject Win32_DCOMApplicationSetting permission issue after latest windows update RRS feed

  • General discussion

  • Hi,

    We have PS script similar like below to access DCOM security descriptor:

    ...

    $dcom=Get-WMIObject Win32_DCOMApplicationSetting -Filter "AppId='{61738644-F196-11D0-9953-00C04FD919C1}'" -EnableAllPrivileges;

    $sd = $dcom.GetLaunchSecurityDescriptor().Descriptor;

    ...

    It was working fine for a long time until recently we start to see the problem the above $sd returns as $null with return code 2147943714 (guess it means "A required privilege is not held by the client") 

    Name       : Descriptor
    Value      : 
    Type       : Object
    IsLocal    : False
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE, ID}

    Name       : ReturnValue
    Value      : 2147943714
    Type       : UInt32
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE}

    The same script return correct info, before windows update, as below:

    Name       : Descriptor
    Value      : System.Management.ManagementBaseObject
    Type       : Object
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE, ID}

    Name       : ReturnValue
    Value      : 0
    Type       : UInt32
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE}

    Anybody is aware such (breaking) change from recent windows update?

    Thanks

    Hao


    Tuesday, May 16, 2017 7:28 PM

All replies

  • Hi,

    We have PS script similar like below to access DCOM security descriptor:

    ...

    $dcom=Get-WMIObject Win32_DCOMApplicationSetting -Filter "AppId='{61738644-F196-11D0-9953-00C04FD919C1}'" -EnableAllPrivileges;

    $sd = $dcom.GetLaunchSecurityDescriptor().Descriptor;

    ...

    It was working fine for a long time until recently we start to see the problem the above $sd returns as $null with return code 2147943714 (guess it means "A required privilege is not held by the client") 

    Name       : Descriptor
    Value      : 
    Type       : Object
    IsLocal    : False
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE, ID}

    Name       : ReturnValue
    Value      : 2147943714
    Type       : UInt32
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE}

    The same script return correct info, before windows update, as below:

    Name       : Descriptor
    Value      : System.Management.ManagementBaseObject
    Type       : Object
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE, ID}

    Name       : ReturnValue
    Value      : 0
    Type       : UInt32
    IsLocal    : True
    IsArray    : False
    Origin     : __PARAMETERS
    Qualifiers : {CIMTYPE}

    Anybody is aware such (breaking) change from recent windows update?

    Thanks

    Hao

    • Merged by jrv Tuesday, May 16, 2017 8:51 PM DUPLICATE
    Tuesday, May 16, 2017 7:30 PM
  • First step:

    if($dcom = Get-WMIObject Win32_DCOMApplicationSetting -Filter "AppId='{61738644-F196-11D0-9953-00C04FD919C1}'" -EnableAllPrivileges){
    	$sd = $dcom.GetLaunchSecurityDescriptor().Descriptor
    }else{
    	Write-Host 'AppID not found'
    }

    You must be running as admin and running elevated.  If the Installer owns the key then you probably cannot read it.


    \_(ツ)_/


    • Edited by jrv Tuesday, May 16, 2017 8:42 PM
    Tuesday, May 16, 2017 8:41 PM
  • In your case the " IIS WAMREG admin Service" is owned and maintained by the Trusted Installer.  Use a custom installer so you cannot read the SD.

    It is not an error but is by design.


    \_(ツ)_/

    Tuesday, May 16, 2017 8:48 PM
  • Thanks for the suggestions. We have the problem on both the "IIS WAMREG admin Service" and some of our own DCOM components which are installed/registered by our own product installer. 

    I am not expert on the (Trusted) installer concept. Are you suggesting these SD permissions are set during the DCOM install/registration so not able to add later on?

    Two things still appear strange though:

    1. The above PS scripts work fine until we apply the latest WU
    2. If we do it manually (the goal here is the assign launch and activate DCOM permission for new created user) from the component service, it works. So seems something to do with the Powershell privilege. 

    Again, thanks for the response and looking forward for more :-)  ...


    update to my post on MSDN

    Wednesday, May 17, 2017 5:41 PM
  • When running DCOMCNFG you are at a higher privilege level.  You need to find the missing privilege in PowerShell and add it to your session.

    I suspect the latest security patches are protecting these keys for a reason.

    I recommend calling MS Support to get a better view of what has been changed and how to best work with it.

    You can also try to add the user as a group which would make things easier once you figure out the best way to update the security.

    DCOM security is set on the object and not on the registry key.  Changing it on the key can be dangerous.


    \_(ツ)_/

    Wednesday, May 17, 2017 5:58 PM
  • Here is how to use the command line to set dcom permissions:

    http://stackoverflow.com/questions/11363342/change-dcom-config-security-settings-using-powershell

    You will need to be an elevated admin for any of this to work.


    \_(ツ)_/

    Wednesday, May 17, 2017 6:02 PM
  • Thanks for the reply.

    The link you sent on the usage of PS is pretty much like the way how we are doing except it uses query:

    $app = get-wmiobject -query ('SELECT * FROM Win32_DCOMApplicationSetting WHERE Description = "' + $appdesc + '"') -enableallprivileges

    While we are using filter. 

    I guess like you mentioned, it has something difference between command line and Powershell. Unfortunately, we are somehow locked with PS as other features also provided in PS.

    Yes, probably we have to check with MSFT support to get more details on the changes with WU. To add more complication, I did not mention earlier, is that the very latest windows10 update (4016871) actually revert back to the original behavior so our code works. But the same problem still exist for other OS (win8, win2012 etc.) with latest WU applied.


    update to my post on MSDN

    Wednesday, May 17, 2017 6:18 PM
  • Then I would guess that a patch has been released to adjust the behavior.  If you ask MS they may release an early version for your other systems.

    It is best to fix the underlying issue in a compliant way to prevent further issues.


    \_(ツ)_/

    Wednesday, May 17, 2017 6:31 PM
  • "It is best to fix the underlying issue in a compliant way to prevent further issues.", yeah that's how I originally thought. But after done some research, it appears the way how we use Get-WMIObject Win32_DCOMApplicationSetting to get GetLaunchSecurityDescriptor is a quite command approach in Powershell. Lots of code sample online do in the same/similar way. That's part of the reason I'm asking in this forum to see if others encounter the same issue.

    Or could be the case the permissions/privilege in PS is tied to the way how these DCOM components were registered in the first place (and whether they are OOB provided by OS or user created ones). If so, we have to trace back to our installer code.


    update to my post on MSDN

    Wednesday, May 17, 2017 6:52 PM
  • Also the correct method is:

    $sd = $dcom.GetLaunchSecurityDescriptor().Descriptor.DACL

    You should also check

    $wam = Get-WMIObject Win32_DCOMApplicationSetting -Filter "AppId='{61738644-F196-11D0-9953-00C04FD919C1}'" -EnableAll
    $wam.GetConfigurationSecurityDescriptor().Descriptor.Dacl|?{$_.trustee.Name -match 'Administrators'}|select accessmask

    If it is a protected object then the config descriptor cannot be retrieved.


    \_(ツ)_/



    • Edited by jrv Wednesday, May 17, 2017 7:48 PM
    Wednesday, May 17, 2017 7:08 PM
  • you above lines all return $null - not sure if you are seeing the same result.

    Yes, actually in our PS script, we are also getting dacl from descriptor property from $dcom.GetLaunchSecurityDescriptor(). I did not list all as we can identify the descriptor property is already $null so it causes below error:

    System.Management.Automation.RuntimeException: The property 'Dacl' cannot be found on this object. Verify that the property exists and can be set.
       at CallSite.Target(Closure , CallSite , Object , Object )
       at System.Management.Automation.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame)
       at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)


    update to my post on MSDN

    Wednesday, May 17, 2017 7:35 PM
  • This got truncated:

    $wam = Get-WMIObject Win32_DCOMApplicationSetting -Filter "AppId='{61738644-F196-11D0-9953-00C04FD919C1}'" -EnableAll

    run elevated.


    \_(ツ)_/

    Wednesday, May 17, 2017 7:45 PM
  • Same $null result :-(.

    It's very similar as the code I list at the beginning except we use "-EnableAllPrivileges". Are you seeing different result, especially when trying to access $wam.GetConfigurationSecurityDescriptor().Descriptor.Dacl ?


    update to my post on MSDN

    Wednesday, May 17, 2017 8:00 PM
  • Which is what we expected.  You need to contact MSSupport and note the behavior of the WU that causes this.  If it is the WU issue then the call should be free,


    \_(ツ)_/

    Wednesday, May 17, 2017 8:01 PM
  • Thanks for your help/suggestion on this. Yes we will probably contact MS support at least let them know this in case it's indeed a regression bug. In the meantime, we will suggest some workarounds on our side likely with manual steps.

    update to my post on MSDN

    Tuesday, May 23, 2017 3:03 PM
  • Hi,

    any update on how to fix the issue.

    Thanks

    Sanil

    Thursday, June 1, 2017 7:03 AM
  • This issue got resolved once i applied the latest updates. Hope it helps
    Thursday, June 1, 2017 9:27 AM
  • Hi,

    I have the same problem on WS2012R2 servers. I can't tell if the problem is new since servers are new, but I don't have this issue on WS2008R2 servers.

    If this issue was solved by "latest updates", can you tell wich one ?

    Thanks,

    Boris

    Tuesday, June 6, 2017 8:31 AM
  • For win10, it is solved by KB4016871. But seems for other OS like win2012, problem still remains. 

    update to my post on MSDN

    Tuesday, June 6, 2017 4:07 PM
  • Hello,

    I notice this problem on WS2008R2 after upgrade from Microsoft .NET Framework 4.5.1 to 4.5.2.

    The downgrade resolve the issue.

    Best Regards.

    JP

    Friday, June 30, 2017 10:02 AM
  • Does anyone know the patch that is causing this problem on Windows 2012 Servers? I am definitely having this problem as well.  @liuhao777888 , my DCOM Script is pretty similar to yours.
    Thursday, July 27, 2017 7:14 PM
  • So that just looks like instructions for changing the perms using the MMC which frankly I know how to do.  The whole point is I need my scripted process to work.  I have to many servers to configure.  This process was working until recently.  I'd like to know which patch is effecting it.  Obviously I'm not the only one. 
    Thursday, July 27, 2017 7:30 PM
  • So that's it.  Nothing else to offer on this issue?? 
    Wednesday, August 2, 2017 9:16 PM
  • Unfortunately this forum is not an official support channel. (We're volunteers who answer scripting questions; we are not Microsoft employees.) If you need an official answer, you will need to open an official Microsoft support incident.

    -- Bill Stewart [Bill_Stewart]

    Wednesday, August 2, 2017 9:29 PM
    Moderator
  • Correct me if Im wrong, but JRV is a consultant with Microsoft? I realize this is not an official support channel.  But obviously there's some smoke here. A little help would be nice. I work at a large enterprise. We don't just pick up the phone and open incidents with Microsoft over small issues like this. It doesn't work like that. But thanks anyway.
    Wednesday, August 2, 2017 10:01 PM
  • Correct me if Im wrong, but JRV is a consultant with Microsoft?

    I suspect that if jrv had access to internal Microsoft resources that could escalate this problem internally, he would have done so already.

    I realize this is not an official support channel. But obviously there's some smoke here. A little help would be nice. I work at a large enterprise. We don't just pick up the phone and open incidents with Microsoft over small issues like this. It doesn't work like that. But thanks anyway.

    I also work at a fairly large enterprise, and we also have restrictions on Microsoft incidents. So this depends on how critical the issue is. If it's critical enough, you can spare the resources.

    All we can say in this forum is, "yes, we can reproduce the problem," which is nice psychologically but not really of much help technically. You need to get with Microsoft for a fix. The more customers the problem affects, the more likely they are to deliver a fix.


    -- Bill Stewart [Bill_Stewart]

    Wednesday, August 2, 2017 10:11 PM
    Moderator
  • This has been an issue for may years,  Usually a third party product breaks an install or update. If it affects more than one system and it is caused by a Microsoft update the MS incident will be free.

    I usually fix these by troubleshooting the issue to discover how it is getting broken.  There is no one-size-fits-all fix.

    I do not work for Microsoft.


    \_(ツ)_/

    Wednesday, August 2, 2017 10:17 PM
  • Sorry for the misunderstanding.  I was a bit punchy yesterday.  End of a long day.  I have busted out the rusty old CIM Studio and think I found something to help track the issue better regarding this null on the descriptor for GetLaunchSecurityDescriptor in Win32_DCOMApplicationSettings.  I'll report back here if I find anything.  Thanks

    Thursday, August 3, 2017 11:30 AM