Skip navigation
1 2 Previous Next 22023 Views 21 Replies Latest reply: Sep 30, 2013 3:55 PM by Chris Smith RSS Go to original post
  • Simon Jakesch Rank: Green Belt 84 posts since
    Aug 2, 2007

    Jay,

     

    given that you are using a local admin user for your authentication. I am wondering what //hostname resolves to? There is a possibility of the RPC handshake going wrong and therefore the communication never taking place successfully (see http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/99c278fe-df63-408b-b5b1-b95554b6b630/)

     

    Simon

  • Jay Kay Newbie 6 posts since
    Dec 2, 2011

    Hey Simon,

     

    That would make sense, but in this case I dont think it applies.  The machines (both zenoss server and the ToBeMonitored win2k3 mahcine) are in the same network segment.  if I do a dns resolution of that hostname, it comes back with the correct IP.  Same thing goes for the reverse-lookup. 

     

    Thanks for the help.  If you have any other clues, please let me know.

     

    Regards,

  • Robert Booth Rank: White Belt 25 posts since
    Dec 12, 2011

    Jay,

     

    Try running the same WMI command with the IP address instead of hostname.

     

    If you get the same successful result, check out the event logs for any failures to connect.

     

    If you see nothing in the event logs try getting a network capture on the Windows server side with Wireshark if you can or Windows NetMon. That should provide a little more information to what exactly is happening and where.

     

    -Rob

  • Jay Kay Newbie 6 posts since
    Dec 2, 2011

    Thanks Robert,

     

    That is a great idea, I will try it with this server, although this may be a firewall realted issue as we are using old local sygate installation for firewall filtering.

     

    Thanks much!

  • Doug Syer Rank: White Belt 27 posts since
    Feb 20, 2012

    I'm seeing the same issue, its mostly 2008 issues.  It looks like UAC issues.  What has worked so far is to add the zenoss user into the distributed dcom group (if it isnt a domain controller) or go into the dcom program and give the user access (if it is a domain controller).

     

    then, restart the WMI service. I also suspect a windows bug on some of the servers I've seen, especially pre-SP1 2008 R2 servers.

  • Chris Smith Rank: White Belt 23 posts since
    Jun 4, 2013

    I had really hoped Doug's suggestion above would work but adding my ZenAdmin to the DCOM group did not resolve the problem. The account is also a member of Administrators.

     

    I recently built 4 Windows 2008 servers and added them to Zenoss. Only one of them is having this issue where Zenoss is getting NT_STATUS_ACCESS_DENIED everytime it tries to connect via WMI.

     

    I can connect to this server with the same credentials that are in zWinUser and zWinPassword over RDP and through the WMI test tool (wbemtest.exe). Oddly enough the error that is logged in the Security event log on the server states "Unknown user name or bad password". I've tried creating multiple accounts and even having Zenoss use the Administrator account without success. It's almost like Zenoss is passing weird credentials to this device only...

     

    Any ideas? I've been banging my head against this wall for several hours.


    Event log entry:

     

     

     

    "An account failed to log on.

     

     

    Subject:

              Security ID:                    NULL SID

              Account Name:                    -

              Account Domain:                    -

              Logon ID:                    0x0

     

     

    Logon Type:                              3

     

     

    Account For Which Logon Failed:

              Security ID:                    NULL SID

              Account Name:                    zenadmin

              Account Domain:                    WORKGROUP

     

     

    Failure Information:

              Failure Reason:                    Unknown user name or bad password.

              Status:                              0xc000006d

              Sub Status:                    0xc000006a

     

     

    Process Information:

              Caller Process ID:          0x0

              Caller Process Name:          -

     

     

    Network Information:

              Workstation Name:          NA-DEN-ZEN-01

              Source Network Address:          68.177.51.51

              Source Port:                    56545

     

     

    Detailed Authentication Information:

              Logon Process:                    NtLmSsp

              Authentication Package:          NTLM

              Transited Services:          -

              Package Name (NTLM only):          -

              Key Length:                    0

     

     

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

     

     

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

     

     

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

     

     

    The Process Information fields indicate which account and process on the system requested the logon.

     

     

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

     

     

    The authentication information fields provide detailed information about this specific logon request.

              - Transited services indicate which intermediate services have participated in this logon request.

              - Package name indicates which sub-protocol was used among the NTLM protocols.

              - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."

  • Chris Smith Rank: White Belt 23 posts since
    Jun 4, 2013

    Fixed my WMI issue...this turned out to be a weird setting that was applied when doing security lockdown. I think it was applied incorrectly. I found this by comparing local security policy between a server that was working and this server that wasn't.

     

    I found under Local Security Policy > Local Policies > Security Options > Network security:

     

     

    LAN Manager authentication level was set to Send NTLMv2 response only. Refuse LM & NTLM. Once I matched my other server and changed it to Send NTLMv2 response only Zenoss could login correctly.

     

     

    No idea why this did it but I'm glad it's working finally.

1 2 Previous Next

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points