Forum Discussion
MDI - AD FS Sensor Errors
Seeing the following error every few minutes on AD FS sensors (newer install) and then found it on all existing DC sensors. Followed the "Configure object auditing" documentation as carefully as poss...
- Which DACL did you use on with the first issue?
This is the one you need to add:
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
As for the second issue, you should contact support and they can guide you with a script to add proper permissions to WID.
EliOfek
Microsoft
MicrosoftWhich DACL did you use on with the first issue?
This is the one you need to add:
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
As for the second issue, you should contact support and they can guide you with a script to add proper permissions to WID.
This is the one you need to add:
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
As for the second issue, you should contact support and they can guide you with a script to add proper permissions to WID.
Thanks for the reply. I added that DACL to the GPO (I had previously used the DACL for our ATP directory service account instead). Applying this new DACL doesn't seem to have fixed the issue though as we are still seeing frequent security log access errors (on the AD FS servers only):
2021-10-06 04:56:20.2335 Error WindowsEventLogReader RunPeriodic actionAsync failed
Microsoft.Tri.Infrastructure.ExtendedException: [unauthorizedAccessLogNames=Security] ---> System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
at void System.Diagnostics.Eventing.Reader.EventLogException.Throw(int errorCode)
at EventLogHandle System.Diagnostics.Eventing.Reader.NativeWrapper.EvtSubscribe(EventLogHandle session, SafeWaitHandle signalEvent, string path, string query, EventLogHandle bookmark, IntPtr context, IntPtr callback, int flags)
at void System.Diagnostics.Eventing.Reader.EventLogWatcher.StartSubscribing()
at void Microsoft.Tri.Sensor.WindowsEventLogReader.EnableEventLogWatchers()+(KeyValuePair<string, EventLogWatcher> logNameToEventLogWatcher) => { }
--- End of inner exception stack trace ---
at void Microsoft.Tri.Sensor.WindowsEventLogReader.EnableEventLogWatchers()
at Func<Task> Microsoft.Tri.Infrastructure.ActionExtension.ToAsyncFunction(Action action)+() => { }
at async Task Microsoft.Tri.Infrastructure.Module.RunTaskAsync(Func<Task> actionAsync, string name, SimpleTimeMetric timeMetric)
at async void Microsoft.Tri.Infrastructure.Module.RegisterPeriodicTask(IMetricManager metricManager, Action action, PeriodicTaskConfiguration configuration)+(?) => { }
at async Task Microsoft.Tri.Infrastructure.TaskExtension.RunPeriodic(Action action, PeriodicTaskConfiguration configuration, CancellationToken cancellationToken)+(?) => { }
We're on Server 2019 if that might make a difference.
Is there somewhere else this permission should be set? I'm not seeing any new ACLs if I view the Security.evtx file.
This file is stored in a non-standard location on our AD FS servers [D:\logs\Security.evtx] so maybe that isn't allowing necessary permissions to apply?
Re: the second issue, I received and applied the script from support; still seeing the same SQL errors on the AD FS sensors.
- EliOfekDid you make sure the added dacl was still persisted some time after you added it ?
I had cases before where there was a gpo that overwritten it once a while.
I never tested a scenario where there log store is in a non standard path, I guess it could have impact if the path does not have the same permissions as the standard one, so I would try to make sure it does first.
If it still fails, ask MDI support to collaborate with platform support to check why the permissions are still broken..
As for ADFS WID, that sounds weird, maybe the script failed? or maybe the WID was hardened to a point where the script is not doing enough ?( the script assumes default WID permissions).
