Jump to content


Photo

Logon Auditing Is Disabled - Remote Procedure Call Failed and Did Not Execute


  • Please log in to reply
7 replies to this topic

#1 JCIT15

JCIT15

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 03 January 2018 - 08:51 PM

I have followed the quick guide and enabled everything that it requires. I also tried setting my Advanced Audit Configuration to 'Not Configured', so that the regular audit settings would for sure take primary and that didn't work. Right now I have both all of the logon / logoff / account lockout audit settings enabled for failures, as well as some for failures+successful. Still am getting the following errors.

 

I am getting this in both my test and production environments. 

 

I also tried/ensured all of the following on this page (in my test environment) and still got the same errors (Allow remote admin exception enabled, file and printer share exception enabled, TCP/IP NetBIOS Helper running, RPC Service running): https://www.netwrix.com/kb/1291

 

Audit Status: Logon auditing is disabled, soem functionality will be unavailable for this DC. Please turn on auditing of invalid logins in audit policy settings for this DC.

Connection: The remote procedure call failed and did not execute (Exception from HRESULT: 0x800706BF).

 

 

LNQUevE.png

 

 

I can reach the DC security logs (event viewer) fine via my workstations in both my test and prod environments.

 

Any ideas? 

 

Thanks.



#2 jeffb

jeffb

    Advanced Member

  • Administrators
  • PipPipPip
  • 372 posts
  • Gender:Male

Posted 04 January 2018 - 02:00 PM

Hello,

 

If you lock an account out as a test does it come through?

 

When those lockouts come through, do they show the workstation where the lockout originated from?

 

Can you post the output of the following command run from an elevated command prompt on one of the domain controllers mentioned in the errors?

auditpol /get /category:"Logon/Logoff"

 

What OS are the domain controllers?

 

You mentioned connecting to the Event Logs from workstations but the better test would be from the server where ALE is installed to the domain controllers.

 

Thanks,

-Jeff



#3 JCIT15

JCIT15

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 05 January 2018 - 07:54 PM

Hello,

 

If you lock an account out as a test does it come through?

 

When those lockouts come through, do they show the workstation where the lockout originated from?

 

Can you post the output of the following command run from an elevated command prompt on one of the domain controllers mentioned in the errors?

auditpol /get /category:"Logon/Logoff"

 

What OS are the domain controllers?

 

You mentioned connecting to the Event Logs from workstations but the better test would be from the server where ALE is installed to the domain controllers.

 

Thanks,

-Jeff

 

1.) If you lockout an account, it does not come through/show up on ALE. Does not show anything for the Workstation or Domain Controller. The Status of the account eventually did change to 'Locked out'. I have since unlocked the account, about 5 minutes ago, and it still hasn't changed back to 'Not locked' even after refreshing ALE multiple times. 

 

2.) When lockouts occur, they do not show up where they came from in ALE at all. On the DC security event logs, they do show where the lockout came from though.

 

3.) Microsoft Windows [Version 6.1.7601]

auditpol /get /category:"Logon/Logoff"
System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure
  Logoff                                  Success and Failure
  Account Lockout                         Success and Failure
  IPsec Main Mode                         No Auditing
  IPsec Quick Mode                        No Auditing
  IPsec Extended Mode                     No Auditing
  Special Logon                           Success and Failure
  Other Logon/Logoff Events               Success and Failure
  Network Policy Server                   No Auditing
 
4.) This DC (test enviroment) is Windows Server 2008 R2 - Service Pack 1. Production environment is the same.
 
5.) I do not have ALE installed on a server. ALE is currently installed on my workstation/PC. That workstation/PC can successfully connect to the DC using Computer Management and read the security logs just fine. 
 
Thanks,


#4 AndreyK

AndreyK

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 10 January 2018 - 02:06 PM

Hi JCIT15,

 

What is the Windows version on the workstation/PC where ALE is installed?

Could you please double-check the Firewall rules? https://www.netwrix.com/kb/1394

 

AK



#5 JCIT15

JCIT15

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 11 January 2018 - 04:23 PM

Hi JCIT15,

 

What is the Windows version on the workstation/PC where ALE is installed?

Could you please double-check the Firewall rules? https://www.netwrix.com/kb/1394

 

AK

 

I attempted on my Windows 10 machine, as well as a Windows 7 machine in the test environment.

 

After checking with networking, they are currently denying MS-WMI and MSRPC from workstations -> servers. I could install ALE on a server, and bypass those denials (going to test that today), but I still feel like ALE should be a tool to use from our workstations, similar to using lockoutstatus.exe. If that's the case, then I am going to have to go through and get exceptions approved for networking to put in place. Do you guys run ALE from your workstations, or on a server itself?



#6 AndreyK

AndreyK

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 12 January 2018 - 12:21 PM

In my test environment ALE runs on a Windows 2012R2 server.

ALE is considered a server tool since you don't need to have more than one in your domain.

Please let us know how the server installation goes.



#7 JCIT15

JCIT15

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 16 January 2018 - 07:32 PM

In my test environment ALE runs on a Windows 2012R2 server.

ALE is considered a server tool since you don't need to have more than one in your domain.

Please let us know how the server installation goes.

 

To test this theory (and bypass any blocks from firewall), I temporarily installed ALE on one of the DCs in my test environment. ALE was then able to communicate successfully (no RPC errors). It however still complained about logon auditing not being enabled even though I have all of it fully enabled for Successes and Failures.

 

Also, whenever I locked out a test account, it was able to detect that it was 5 bad password attempts, and it was locked out. However, it did not list the workstation or domain controller it was coming from. Whenever bad password or lockout logs come into Event Viewer Security logs, they were listing the machine name in the logs. Not sure why ALE still couldn't retrieve that info though.

 

Also, with all of my the workstations in my environment being Windows 10... will ALE still be functional/worth using?



#8 JCIT15

JCIT15

    Newbie

  • Members
  • Pip
  • 6 posts

Posted Yesterday, 05:41 PM

So now that I have ALE installed on a VM, on "the same side of the fence" as my servers (including my DCs), ALE is now able to tell Bad Pwd Count, and the Status (locked out or not locked). BUT, it still doesn't show the Workstation or Domain Controller or Lockout Time? Also the Connection still states that the remote procedure call failed and did not execute. 

 

I just tested out a free / trial version of another AD Auditing tool, and it was able to pull in the Domain Controller and Caller Computer Name and timestamps just fine while using its lockout analyzer.

 

Any ideas why ALE wouldn't be able to? 






0 user(s) are reading this topic

0 members, guests, anonymous users