10 replies to this topic

[JCIT15]

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).

 

 

 

 

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

 

Any ideas? 

 

Thanks.

[jeffb]

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

[JCIT15]

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,

[AndreyK]

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

[JCIT15]

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?

[AndreyK]

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.

[JCIT15]

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?

[JCIT15]

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? 

[AndreyK]

Is you managed object in ALE configured to all domain controllers or to PDC only?

 

Try changing that setting and check if RPC error disappears.

[JCIT15]

Is you managed object in ALE configured to all domain controllers or to PDC only?

 

Try changing that setting and check if RPC error disappears.

 

I've tried both Domain/All DCs as well as Domain/PDC Only

[JCIT15]

SOLUTION FOUND!

 

There was still a firewall between the machine running ALE and my DCs. I had a rule to allow MSRPC and MS-WMI to/from my machine and DCs. ALE is now working 100%.