Identify syslog type for User-ID parse

Showing results for 
Search instead for 
Did you mean: 

Identify syslog type for User-ID parse

L2 Linker

I'm in the process of implementing User-ID and want to parse syslog logs. the predefined parse profile don't appear to be a match, as I'm looking to pull syslog from my domain controller. However, my Active Directory team can't provide me with a sample of the syslog event or tell me the type of syslog (regex or field) being generated. So I'm looking from some additional information about to identify the type of syslog file to help push this process along. Anything would be helpful. Thank you.


If you have events that your can access in qradar that contain both a valid username and that IP address then you will be able to forward those events to a firewall for parsing of those messages.


It doesn't make sense that there would be a built in parser for this, the firewall won't know what your message format is. If there was going to be a default, it would be for the same messages that the User-ID agent would see, which do not exist in your environment as you are not auditing auth success messages. 

This is why you can write a regular expression to parse them. 


If you get a pcap of what the log messages look like on the wire, or a sample log from qradar, you can use something like to help you appropriately craft the regular expressions required to capture the username and IP out of the message. 


If you can massage the info before you forward it out of qradar, you may also be able to use field matching if you can simplify the message format. 






Thanks for the response. I've been able successful log event in Qradar and grab sample of the log to use for a custom parse. A few things I ran into.

1) When going through Palo documentation I read that that "syslog senders were the network services that authenticate users. I took this as, the syslog sender had to be the Domain Controller and I'd have to pull the logs directly from it. Thus, I haven't tried to go down the path of having the Qradar forward syslog events to the User ID Agent. Did I interpret that incorrectly?  

2) Another sticking point: When attempting to create a custom parse file, Palo requires the identification of a regex vs field type. I don't know enough about these formats to understand which is which by just looking at the Qradar log. Do you know how to identify the type? 

3) Does the syslog server log into the domain controller to pull logs, or does the Domain Controller forward its logs to the syslog server? I found an article that send syslog listeners will log in and pull information, so I've setup the agent with a service account that has access to the domain controller but I haven't gotten anything, so I'm wondering if the DC needs to be told to forward log traffic to my User ID agent. I haven't gotten much feedback from my team on how the setup actually works so still trying to figure it out.


Thanks for your feedback.

Typically, the device that supports syslog messages sends the messages to the syslog server.

So think about any network piece of hardware (switch/router, wireless access controller, etc)

These devices would typically fwd to the IP of a syslog server.


In this case, your syslog server should be sending them to another syslog server (in this case, the IP of the FW mgmt)


What does a log message look like in QRadar, when the DC successfully fwds the messages to the syslog server?

Help the community: Like helpful comments and mark solutions


Got it.


As for the log message in Qradar:

<13>Nov 27 10:37:56 x.x.10.37 AgentDevice=WindowsLog AgentLogFile=Security PluginVersion= Source=Microsoft-Windows-Security-Auditing Computer={Domain.Controller.Name} OriginatingComputer=x.x.10.37 User= Domain= EventID=4624 EventIDCode=4624 EventType=8 EventCategory=12544 

RecordNumber=959957311 TimeGenerated=1574869076 TimeWritten=1574869076 Level=Log Always Keywords=Audit Success Task=SE_ADT_LOGON_LOGON Opcode=Info Message=An account

was successfully logged on.  Subject:  Security ID:  NULL SID  Account Name:  -  Account Domain:  -  Logon ID:  0x0  Logon Information:  Logon Type:  3  Restricted Admin Mode: -  Virtual

Account:  No  Elevated Token:  Yes  Impersonation Level:  Impersonation  New Logon:  Security ID:  {Domain\User-ID}  Account Name:  {User-ID here}  Account Domain:  {Domain.Name.Here}  Logon ID:  0xA1D8416  Linked Logon ID:  0x0  Network Account Name: -  Network Account Domain: -  Logon GUID:  {40724BD3-9F5D-A463-A21A-367F5AA824FF}  Process Information:  Process

ID:  0x0  Process Name:  -  Network Information:  Workstation Name: -  Source Network Address: x.x.196.115 Source Port:  49203  Detailed Authentication Information: 

Logon Process:  Kerberos  Authentication Package: Kerberos  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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!