This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
We are having an issue with a large number of failed logons ( event type 4265) being reporting in the Windows Security log on our Windows 2016 Alteryx Server. We have had the issue in previous versions and we just completed upgrade to latest GA V2022.1.1.25127 and the problem continues.
As far as we can tell all Alteryx server functionality is working even though we are receiving these errors, the errors are just causing our Security department concern (and creating additional noise in our Security logs).
1. We are running Alteryx server jobs using the "Run as different user" option in the Alteryx Server configuration.
2. We have an Active Directory Service Account "salteryxp01" that is used as the Run As user.
3. We have Alteryx Server configured to perform "Integrated Windows Authentication with Kerberos" that supports the Active Directory user above.
More details about why we think we are seeing the failed logins. FAILED shows Logon type 2 is the Interactive logon type (also know as Log On locally, see this link for more details:
My question is: Is the Alteryx application somehow incorrectly programmed to attempt to request Interactive Logons for the Run as different user" account (and thereby generating the excessive 4625 error messages) when it should really be requesting the appropriate type (batch or other NON Interactive Logon) ?
Below are 2 examples:
An Example of Failed (Logon Type =2 = Interactive )
An Example of Success (Logon Type = 4 = Batch) Security log events.
Below here is an Example FAILED 4625 Type Windows Security Log event for Logon Type =2 (Interactive) coming from Alteryx Server ( see Workstation Name: EVALTERYXP01 which is the name of the Alteryx Server computer).
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.
Below Here is an Example of SUCCESSFUL Logon by same salteryxp01 :
This event is generated when a logon session is created. It is generated on the computer that was accessed.
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 occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The impersonation level field indicates the extent to which a process in the logon session can impersonate.
The authentication information fields provide detailed information about this specific logon request. - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event. - 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.
I opened a ticket with Alteryx support. We went back and forth for quite some time checking to make sure we had implemented everything according to their instructions (which we had). We debugged many things and I believe it boiled down to their software not 100% working the way they though it did.
In general, Alteryx is functioning correctly, but it is accessing the system in such a way that it still triggers those Event log messages, even thought tasks are running.
I gave them quite a bit of information, so not sure if their Developers are working to incorporate a fix or not.
For now, we explained to security that software is working "as is" and that Security log entries are just a byproduct.
Our Security's primary concern was that validate functionality was happening, as we did not see these entries at times when jobs were not running, so they said OK.
Thanks, Jeff. Just so I make sure I understand, you've only granted log on as a batch job (and not interactive logon) to the run as account, and that works fine for jobs to run, etc., except that the security log shows failed interactive logon attempts, correct? I think this may be workable for us, if that's the case.
I believe that is correct. We did not want to grant "Interactive login" unless absolutely necessary. So, we left "logon as batch" and jobs are working, with the exception of generating the extra msessages in the Security logs.
If you validate all is working, then I suspect you would be in the same position.