We have extended our Early Bird Tickets for Inspire 2023! Discounted pricing goes until February 24th. Save your spot!

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.

Failed Interactive logons being reported in Windows Security event log on Alteryx Server.

jkohut
5 - Atom

Hello,

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.

4. 

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:

https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-....

By our company CIS policy only Administrators are allowed the “Allow log on locally” User Rights Assignment.

To make applications more secure, we setup the Least Privilege Access for the Alteryx application.  We followed Alteryx recommendations at the following link: https://help.alteryx.com/20221/server/configure-required-run-user-permissions. The Allow log on locally permission was not specified in Alteryx documentation at the time so it was not granted.

 

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 )

and

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

 

An account failed to log on.

Subject:
Security ID: SYSTEM
Account Name: EVALTERYXP01$
Account Domain: CORP
Logon ID: 0x3E7

Logon Type: 2

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: salteryxp01
Account Domain: CORP

Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xC000015B
Sub Status: 0x0

Process Information:
Caller Process ID: 0x1c04
Caller Process Name: D:\Program Files\Alteryx\bin\AlteryxService.exe

Network Information:
Workstation Name: EVALTERYXP01
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

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 :

 

An account was successfully logged on.

Subject:
Security ID: SYSTEM
Account Name: EVALTERYXP01$
Account Domain: CORP
Logon ID: 0x3E7

Logon Information:
Logon Type: 4
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: No

Impersonation Level: Impersonation

New Logon:
Security ID: CORP\SALTERYXP01
Account Name: salteryxp01
Account Domain: CORP
Logon ID: 0x1C579174
Linked Logon ID: 0x0
Network Account Name: -
Network Account Domain: -
Logon GUID: {c5f8d6a9-58b9-16f3-5a28-f899eaf2f255}

Process Information:
Process ID: 0x1c04
Process Name: D:\Program Files\Alteryx\bin\AlteryxService.exe

Network Information:
Workstation Name: EVALTERYXP01
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

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.

 

Thanks,

Jeff Kohut

OneMain Financial

 

5 REPLIES 5
abelebczuk
5 - Atom

Did you ever hear back on this? Our security team is also noticing interactive logons for our run as accounts, and is asking if we can turn this off somehow.

 

Thanks

Adam Belebczuk

Dealer Tire, LLC

jkohut
5 - Atom

Adam,

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 

abelebczuk
5 - Atom

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.

jkohut
5 - Atom

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.

Thanks,
Jeff 

abelebczuk
5 - Atom

Excellent. Thanks for your help, Jeff.