MDI - AD FS Sensor Errors

[dcoffrin]

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 possible. We're using a standard AD user account as service account. There is group policy set for security log access and this service account is added with "0x1" read access (AccessAllowed (List Directory)). We've also added this account to the Builtin/Event Log Readers group and restarted the DC and AD FS servers, but we're still seeing this error. Also tried uninstalling and reinstalling the sensor. Are we missing another location where security log permissions are set?

2021-09-27 21:05:59.1767 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 also seeing the login fail for the service account on the WID on the AD FS sensors. Can someone explain how to set the proper permissions on the WID? The service account has a login, public role assigned, mapped to AdfsConfiguration and AdfsConfigurationV4, default schema of dbo, Grant permission to connect to db engine, login enabled, explicit permissions granted are Select and Connect (both with dbo grantor).

2021-09-28 05:14:12.1864 Error SqlInternalConnectionTds QueryAdfsServerDnsNamesAsync failed to get ADFS servers dns names [adfsConfigurationDatabaseConnectionString=Data Source=np:\\.\pipe\microsoft##wid\tsql\query;Initial Catalog=AdfsConfigurationV4;Integrated Security=True]
System.Data.SqlClient.SqlException (0x80131904): Login failed for user 'DOMAIN\serviceaccount'.
at new System.Data.SqlClient.SqlInternalConnectionTds(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, object providerInfo, string newPassword, SecureString newSecurePassword, bool redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, string accessToken, bool applyTransientFaultHandling, SqlAuthenticationProviderManager sqlAuthProviderManager)
at DbConnectionInternal System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
at DbConnectionInternal System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)
at DbConnectionInternal System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
at DbConnectionInternal System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
at bool System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, uint waitForMultipleObjectsTimeout, bool allowCreate, bool onlyOneCheckConnection, DbConnectionOptions userOptions, out DbConnectionInternal connection)
at void System.Data.ProviderBase.DbConnectionPool.WaitForPendingOpen()
at async Task<IEnumerable<TResult>> Microsoft.Tri.Infrastructure.SqlClient.QueryAsync<TResult>(string query, CancellationToken cancellationToken)
at async Task<HashSet<DnsName>> Microsoft.Tri.Sensor.DirectoryServicesResolver+<>c__DisplayClass126_0.<SynchronizeAdfsServerDnsNamesAsync>g__QueryAdfsServerDnsNamesAsync|1(?)+QueryAdfsServerDnsNamesAsync(?)
ClientConnectionId:0577f6a3-837d-419f-8508-2c7fd6dce706
Error Number:18456,State:1,Class:14

Thanks for any assistance!

Derek

[#2 · Accepted solution]

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.

[#3]

@EliOfek 

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.

[#4]

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