4200 Error - Can't audit some computers
Page 1 of 1

Author:  dkleen [ Wed Apr 04, 2007 7:28 am ]
Post subject:  4200 Error - Can't audit some computers

I just recently installed the Open-Audit system, worked out a few bugs thanks to some other posts here, and now i've got a few bugs of my own.

When auditing some computers on our network with the domain script, the wbem/logs logfile 'wmiprov.log' returns numerous:
WDM call returned error: 4200
Impersonation failed - Access denied

This is bullshit though 'cause our script works and outputs information from over 100 of our computers but for a small handful it fails. When specifically choosing one of these computers to audit, the audit.bat returns this error:
No username and password provided - therefore assuming local domain PC.
C:\audit\local script\audit.vbs(158, 7) (null): 0x80041003

then it terminates.

I searched all over for this error code and found it and ones like it in numerous areas:
I found this one regarding granting DCOM remote launch and activation permissions.
Also this one regarding the 4200 error:
That one states that the GUID being passed is not recognized as valid by a WMI data provider. This ones a bit beyond me 'cause i don't know which GUID it's talking about, there are dozens.
Then i started reading this one and opted to just run the diag tool listed at the very top for WMI thinking I had a serious problem with a corrupted WMI installation. ... mspx#E2EAC
That returned only one error "# of machines w/ WMI enumeration errors (E) 1 100.00%" BUT, and here's a tricky part... this tool pops up dialog boxes telling me that WMI is working perfectly when the script has completed running.

I've tried most of the tricks like starting and stopping winmgmts and granting additional dcom security rights, turning off/on the windows firewall, to no avail. I did read an interesting area on impersonation where i think the problem actually lies because of the 'access denied' types of error message i'm getting.
I don't know enough VB to figure out how to fix it, but I believe the server i run the script from is not doing this impersonation properly on the remote PC. (But again it works on 95% of my organization, just not this random handful)

Other bits of info:
All windows XP systems.
We are but one small OU of a much larger domain.
I log into the server as my domain admin account and run the domain script so that it extracts the LDAP data properly. The script then audits all computers and ignores some with these WMI errors.
All computers have the same local administrator username and password. The administrator username and password is inserted into audit.config as:
strUser = "strComputer\AdministratorUsernameHere"
strPass = "MyLocalAdminPasswordHere"

Changing this to:
strUser = "MyDomain\DomainAdminUsernameHere"
strPass = "MyDomainAdminPWHere"

doesn't work either. In fact that one doesn't work at all on any computers even thogh 'Domain Admins' are part of the administrators group, and i am a part of that group.

Then it gets a bit crazy:
I can log on to the same server as the same local administrator username and password as all the other computers in the organization and run the local script again (forcing it to run on a computer of my choosing only by entering the computer name), and it will audit it perfectly.

My theory: Impersonation is failing on some computers. I need to be logged in as a domain admin to force the domain script to work so I can get current LDAP information. I can't run the domain script as a local admin obviously so I can't get LDAP information, but i need to manually force the script on a handful of machines this way. When i'm logged in as a domain admin, and impersonation fails, why?

Help. Why is the WMI failing on some but not others? There is no rhyme or reason as to which ones fail and which do not. No consistency; i've got laptops, desktops that are old, and desktops that are new. Various OS installation methods from RIS server to CD's.

Thanks in advance.

Author:  mikeyrb [ Wed Apr 04, 2007 8:35 am ]
Post subject: 

What I recommend doing is logging into the computer, and audit with no username/password (e.g., set them to ""). Though I feel like you've tried this. There are various domain security settings regarding impersonation, perhaps this is where you should look. I don't see any reason to need to login as a local administrator, domain admin should be fine. I think you should double check that the domain admin is capable of impersonation.

Author:  A_Hull [ Wed Apr 04, 2007 10:40 am ]
Post subject:  Just a thought....

From the auditing Server, can you use manage the remote boxes and connect to WMI?

Log in on the Server as your domain Admin.Next, right Click on My Computer> Manage, then from there choose Action> Connect to another computer, Select the failing machine using browse, then try to open the WMI Control under services and applications... Right Click, select Properties, what is the result? My guess is you get an error, or partial enumeration of the WMI...


Author:  dkleen [ Thu Apr 05, 2007 9:18 am ]
Post subject: 

Ok, went to the computer, logged in as domain admin, went to my computer > manage > action > connect to another computer. No matter which computer I choose WMI returns access denied. Though it does let me 'connect' and i can pull logs from event viewer, but not much else.

I have this strange feeling that WMI does not understand windows security groups. Though my user account is a domain admin, and part of the group 'domain admins', and the 'domain admins' group is listed as part of the 'administrators' group under all systems... WMI doesn't believe that I am indeed an admin. I ran another test and added my domain user account to a computer's 'administrators' group, and Bam... the WMI will connect by performing the steps above.

{Confirmed} I just completed testing of this, (writing it down helped me figure out what was going on) and in fact, WMI cannot accept a connection from a user account unless that specific user account is specifically selected as having admin rights on the computer. Even though i'm an admin, and the admin 'group' is listed, WMI gives me the finger and says I don't think so, give me a username, not a group name.

Nevertheless, it's strangely odd that my domain script works great on most systems and fails on others. This leads me to believe that there may be differences in WMI driver versions across my organization where some permit impersonation, and others do not. Here is my domain script:
audit_location = "l"
verbose = "y"
online = "yesxml"
strComputer = ""
strUser = "strComputer\AdminUsernameHere"
strPass = "passwordhere"
ie_visible = "n"
ie_auto_submit = "y"
ie_submit_verbose = "y"
ie_form_page = ""
non_ie_page = ""
input_file = ""
email_to = ""
email_from = ""
email_server = ""
audit_local_domain = "y"
local_domain = "hiding the ldap info"
hfnet = "n"
Count = 0
number_of_audits = 10
script_name = "audit.vbs"
monitor_detect = "y"
printer_detect = "y"
software_audit = "y"
uuid_type = "mac"
'local_domain = "hiding the ldap info"

With this script, the vb stuff is supposed to inject my local admin username and password into WMI and extract the data. It works for most of them, but not all. Am I doing this properly?

Author:  dkleen [ Thu Apr 05, 2007 9:29 am ]
Post subject: ... x?mfr=true

I found this... it sounds like it is related and is not defined at the moment. Perhaps someone with more knowledge of impersonation can give me a hint as to whether this needs to be on or not.

Author:  A_Hull [ Fri Apr 06, 2007 2:34 am ]
Post subject: 

dkleen wrote:

I found this... it sounds like it is related and is not defined at the moment. Perhaps someone with more knowledge of impersonation can give me a hint as to whether this needs to be on or not.

I think you may be on the right track here, I suspect that this may be related to domain policies, which have been applied to certain OUs and not others. Difficult to tell without being on site.

If you have access to the domain policies, you could check to see what is applied to each OU (assuming the working computers are in a different OU from the non working ones.)

I have seen a similar issue, when we had set the Windows Firewall policy on some of the OUs in our organisation to be more draconian then others. Under these conditions, I found I could no longer audit the computers in the say, the admin department but could audit the ones in accounts.

Page 1 of 1 All times are UTC + 10 hours
Powered by phpBB® Forum Software © phpBB Group