S
StefT
Situation :
Monitoring Server 2012r in the domain , system A
non domain FTP Server 2012r2 , system B
Problem : Unable to remote monitor the server via WMI due to Access Denied 0x80041003
Facility : WMI
Decription : access denied
The problem is confirmed using WBEMTEST
Used the same Impersonation level (Identify ) & Authentication Level (Connection) as on the monitored system B
Measures taken :
The monitoring account is made member of the local admin group. The remote monitoring server uses the credentials of the local monitored server for the querying.
The monitoring account is added to the local Distributed DCOM users of system B (I'd guess this not a requirement for a local admin as administrators have explicit DCOM permissions)
Configured the networkinterface mode > Private
Disabled UAC
Reboot Server
Still stuck with WBEMTEST ( > Access denied on the root & underlying queried root\cimv2 namespace)
In theory I didn't have to add additional/explicit rights on the dcom computer object & WMI child object dcomcnfg) , nor in the security settings of the wmi control , as the account with which I monitor/evaluate was still an local admin account, not an ordinary user where additional underneath referenced steps would be an requirement.
Securing a Remote WMI Connection
When logging in to the console with the monitoring account on the monitored system B the local permissions worked fine. This does not seem to be the case when querying in remote mode.
I accidentally used the built-in local administrator and guess what ? He was able , in remote, to query the WMI namespace.
How come the built-in local admin and the newly created for the purpose local admin, work out differently ?
How to configure the dcom/wmi control security as such I could at least monitor with another admin account and/or even beyond that with an ordinary user ?
So far I didn't came across a complete picture of all required steps. Many have explored the same surface , but nothing is final in what I found on the internet. What is special in this case is , that I try to monitor the typical FTPS server which is not in the domain from a monitoring server that is of course within your domain.
Continue reading...
Monitoring Server 2012r in the domain , system A
non domain FTP Server 2012r2 , system B
Problem : Unable to remote monitor the server via WMI due to Access Denied 0x80041003
Facility : WMI
Decription : access denied
The problem is confirmed using WBEMTEST
Used the same Impersonation level (Identify ) & Authentication Level (Connection) as on the monitored system B
Measures taken :
The monitoring account is made member of the local admin group. The remote monitoring server uses the credentials of the local monitored server for the querying.
The monitoring account is added to the local Distributed DCOM users of system B (I'd guess this not a requirement for a local admin as administrators have explicit DCOM permissions)
Configured the networkinterface mode > Private
Disabled UAC
Reboot Server
Still stuck with WBEMTEST ( > Access denied on the root & underlying queried root\cimv2 namespace)
In theory I didn't have to add additional/explicit rights on the dcom computer object & WMI child object dcomcnfg) , nor in the security settings of the wmi control , as the account with which I monitor/evaluate was still an local admin account, not an ordinary user where additional underneath referenced steps would be an requirement.
Securing a Remote WMI Connection
When logging in to the console with the monitoring account on the monitored system B the local permissions worked fine. This does not seem to be the case when querying in remote mode.
I accidentally used the built-in local administrator and guess what ? He was able , in remote, to query the WMI namespace.
How come the built-in local admin and the newly created for the purpose local admin, work out differently ?
How to configure the dcom/wmi control security as such I could at least monitor with another admin account and/or even beyond that with an ordinary user ?
So far I didn't came across a complete picture of all required steps. Many have explored the same surface , but nothing is final in what I found on the internet. What is special in this case is , that I try to monitor the typical FTPS server which is not in the domain from a monitoring server that is of course within your domain.
Continue reading...