User identity is like a container that holds information about a user and forms their network access credentials. Each user’s identity is defined by data and includes: a username, e-mail address, password, account description, associated administrative group, user group, and role.

User groups are a collection of individual users who share a common set of privileges that allow them to access a specific set of Cisco ISE services and functions.

A user’s group identity is composed of elements that identify and describe a specific group of users that belong to the same group. A group name is a description of the functional role that the members of this group have. A group is a listing of the users that belong to this group.

A user role is a set of permissions that determine what tasks a user can perform and what services they can access on the Cisco ISE network. A user role is associated with a user group. For example, a network access user.

Cisco ISE allows you to restrict network access based on user attributes for both network access users and administrators. Cisco ISE comes with a set of predefined user attributes and also allows you to create custom attributes. Both types of attributes can be used in conditions that define the authentication policy. You can also define a password policy for user accounts so that passwords meet specified criteria.

Not all external identity stores allow network access users to change their passwords. See the section for each identity source for more information.

Network use password rules are configured on Administration > Identity Management > Settings > User Authentication Settings.

The following section has additional information about some of the fields on the Password Policy tab.

• Required Characters: If you configure a user-password policy that requires upper or lowercase characters, and the user’s language does not support these characters, the user cannot set a password. To support UTF-8 characters, uncheck the following check boxes:

  • Lowercase alphabetic characters.

  • Uppercase alphabetic characters

• Password Change Delta: Specifies the minimum number of characters that must change when changing the current password to a new password. Cisco ISE does not consider changing the position of a character as a change.

  For Example, if the password delta is 3, and the current password is "?Aa1234?", then "?Aa1567?" ("5","6" and "7" are the three new characters) is a valid new password. "?Aa1562?" fails, because "?","2", and "?" characters are in the current password. "Aa1234??" fails, because even though the character positions changed, the same characters are in the current password.

  Password change delta also considers the previous X passwords, where X is the value of Password must be different from the previous versions. If your password delta is 3, and your password history is 2, then you must change 4 characters that are not part of the past 2 passwords.

• Dictionary words: Check this check box to restrict the use of any dictionary word, its characters in reverse order, or its letters replaced with other characters.

  Substitution of "$" for "s", "@" for "a", "0" for "o", "1" for "l", "!" for "i", "3" for "e", is not permitted. For example, "Pa$$w0rd".

  • Default Dictionary: Choose this option to use the default Linux dictionary in Cisco ISE. The default dictionary contains approximately 480,000 English words.

  • Custom Dictionary: Choose this option to use your customized dictionary. Click Choose File to select a custom dictionary file. The text file must be of newline-delimited words, .dic extension, and size less than 20 MB.

• You can use the Password Lifetime section to update the password reset interval and reminder. To set the lifetime of the password, check the Disable user account after __ days if password was not changed check box and enter the number of days in the input field. To send a reminder email for password reset, check the Display Reminder __ Days Prior to Password Expiration check box and enter the number of days before which a reminder email should be sent to the email address configured for the network access user. While creating a network access user, you can add the email address in the Administration > Identity Management > Identities > Users > Add Network Access User window to send an email notification for password reset.

  Note

  The reminder email is sent from the following email address: iseadminportal@<ISE-Primary-FQDN>. You must explicitly permit access for this sender. You cannot customize the email content. The reminder email has the following content: Your network access password will expire on <password expiry date and time>. Please contact your system administrator for assistance.

• Lock/Suspend Account with Incorrect Login Attempts: You can use this option to suspend or lock an account if the login attempt failed for the specified number of times. The valid range is from 3 to 20.

• The Account Disable Policy tab is where you configure rules about when to disable an existing user account. See Disable User Accounts Globally for more information.

Cisco ISE allows you to authenticate internal users against external identity store passwords. Cisco ISE provides an option to select the password identity store for internal users from the Administration > Identity Management > Identities > Users window. Administrators can select the identity store from the list of Cisco ISE External Identity Sources while adding or editing users in the Users window. The default password identity store for an internal user is the internal identity store. Cisco Secure ACS users will retain the same password identity store during and after migration from Cisco Secure ACS to Cisco ISE.

Cisco ISE supports the following external identity stores for password types:

• Active Directory

• LDAP

• ODBC

• RADIUS Token server

• RSA SecurID server

Note

As per the current design, if authentication is done against an external ID store, then the internal user identity group name cannot be configured in authorization policy. In order to use internal user identity group for authorization, authentication policy must be configured to authenticate against Internal Users ID store and password type, which can be either internal or external, must be selected in user configuration.

Active Directory supports features such as user and machine authentications, changing Active Directory user passwords with some protocols. The following table lists the authentication protocols and the respective features that are supported by Active Directory.

Cisco ISE retrieves user or machine attributes and groups from Active Directory for use in authorization policy rules. These attributes can be used in Cisco ISE policies and determine the authorization level for a user or machine. Cisco ISE retrieves user and machine Active Directory attributes after successful authentication and can also retrieve attributes for an authorization that is independent of authentication.

Cisco ISE may use groups in external identity stores to assign permissions to users or computers; for example, to map users to sponsor groups. You should note the following restrictions on group memberships in Active Directory:

• Policy rule conditions may reference any of the following: a user’s or computer’s primary group, the groups of which a user or computer is a direct member, or indirect (nested) groups.

• Domain local groups outside a user’s or computer’s account domain are not supported.

Note

You can use the value of the Active Directory attribute, msRadiusFramedIPAddress, as an IP address. This IP address can be sent to a network access server (NAS) in an authorization profile. The msRADIUSFramedIPAddress attribute supports only IPv4 addresses. Upon user authentication, the msRadiusFramedIPAddress attribute value fetched for the user will be converted to IP address format.

Attributes and groups are retrieved and managed per join point. They are used in authorization policy (by selecting first the join point and then the attribute). You cannot define attributes or groups per scope for authorization, but you can use scopes for authentication policy. When you use a scope in authentication policy, it is possible that a user is authenticated via one join point, but attributes and/or groups are retrieved via another join point that has a trust path to the user's account domain. You can use authentication domains to ensure that no two join points in one scope have any overlap in authentication domains.

Note

During the authorization process in a multi join point configuration, Cisco ISE will search for join points in the order in which they listed in the authorization policy, only until a particular user has been found. Once a user has been found the attributes and groups assigned to the user in the join point, will be used to evaluate the authorization policy.

Note	See Microsoft-imposed limits on the maximum number of usable Active Directory groups: http://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(v=WS.10).aspx

An authorization policy fails if the rule contains an Active Directory group name with special characters such as /, !, @, \, #, $, %, ^, &, *, (, ), _, +, or ~.

Admin user login through Active Directory might fail if the admin username contains $ character.

Cisco ISE supports certificate retrieval for user and machine authentication that uses the EAP-TLS protocol. The user or machine record on Active Directory includes a certificate attribute of the binary data type. This certificate attribute can contain one or more certificates. Cisco ISE identifies this attribute as userCertificate and does not allow you to configure any other name for this attribute. Cisco ISE retrieves this certificate and uses it to perform binary comparison.

The certificate authentication profile determines the field where the username is taken from in order to lookup the user in Active Directory to be used for retrieving certificates, for example, Subject Alternative Name (SAN) or Common Name. After Cisco ISE retrieves the certificate, it performs a binary comparison of this certificate with the client certificate. When multiple certificates are received, Cisco ISE compares the certificates to check for one that matches. When a match is found, the user or machine authentication is passed.

When authenticating or querying a user, Cisco ISE checks the following:

• MS-CHAP and PAP authentications check if the user is disabled, locked out, expired or out of logon hours and the authentication fails if any of these conditions are true.

• EAP-TLS authentications checks if the user is disabled or locked out and the authentication fails if any of these conditions are met.

Cisco ISE supports Active Directory with multidomain forests. Within each forest, Cisco ISE connects to a single domain, but can access resources from the other domains in the Active Directory forest if trust relationships are established between the domain to which Cisco ISE is connected and the other domains.

Refer to Release Notes for Cisco Identity Services Engine for a list of Windows Server Operating Systems that support Active Directory services.

Note	Cisco ISE does not support Microsoft Active Directory servers that reside behind a network address translator and have a Network Address Translation (NAT) address.

Cisco ISE supports multiple joins to Active Directory domains. Cisco ISE supports up to 50 Active Directory joins. Cisco ISE can connect with multiple Active Directory domains that do not have a two-way trust or have zero trust between them. Active Directory multi-domain join comprises a set of distinct Active Directory domains with their own groups, attributes, and authorization policies for each join.

You can join the same forest more than once, that is, you can join more than one domain in the same forest, if necessary.

Cisco ISE now allows to join domains with one-way trust. This option helps bypass the permission issues caused by a one-way trust. You can join either of the trusted domains and hence be able to see both domains.

• Join Point: In Cisco ISE, each independent join to an Active Directory domain is called a join point. The Active Directory join point is an Cisco ISE identity store and can be used in authentication policy. It has an associated dictionary for attributes and groups, which can be used in authorization conditions.

• Scope: A subset of Active Directory join points grouped together is called a scope. You can use scopes in authentication policy in place of a single join point and as authentication results. Scopes are used to authenticate users against multiple join points. Instead of having multiple rules for each join point, if you use a scope, you can create the same policy with a single rule and save the time that Cisco ISE takes to process a request and help improve performance. A join point can be present in multiple scopes. A scope can be included in an identity source sequence. You cannot use scopes in an authorization policy condition because scopes do not have any associated dictionaries.

  When you perform a fresh Cisco ISE install, by default no scopes exist. This is called the no scope mode. When you add a scope, Cisco ISE enters multi-scope mode. If you want, you can return to no scope mode. All the join points will be moved to the Active Directory folder.

  • Initial_Scope is an implicit scope that is used to store the Active Directory join points that were added in no scope mode. When multi-scope mode is enabled, all the Active Directory join points move into the automatically created Initial_Scope. You can rename the Initial_Scope.

  • All_AD_Instances is a built-in pseudo scope that is not shown in the Active Directory configuration. It is only visible as an authentication result in policy and identity sequences. You can select this scope if you want to select all Active Directory join points configured in Cisco ISE.

Identity rewrite is an advanced feature that directs Cisco ISE to manipulate the identity before it is passed to the external Active Directory system. You can create rules to change the identity to a desired format that includes or excludes a domain prefix and/or suffix or other additional markup of your choice.

Identity rewrite rules are applied on the username or hostname received from the client, before being passed to Active Directory, for operations such as subject searches, authentication, and authorization queries. Cisco ISE will match the condition tokens and when the first one matches, Cisco ISE stops processing the policy and rewrites the identity string according to the result.

During the rewrite, everything enclosed in square bracket [ ] (such as [IDENTITY]) is a variable that is not evaluated on the evaluation side but instead added with the string that matches that location in the string. Everything without the brackets is evaluated as a fixed string on both the evaluation side and the rewrite side of the rule.

The following are some examples of identity rewrite, considering that the identity entered by the user is ACME\jdoe:

• If identity matches ACME\[IDENTITY], rewrite as [IDENTITY].

  The result would be jdoe. This rule instructs Cisco ISE to strip all usernames with the ACME prefix.

• If the identity matches ACME\[IDENTITY], rewrite as [IDENTITY]@ACME.com.

  The result would be jdoe@ACME.com. This rule instructs Cisco ISE to change the format from prefix for suffix notation or from NetBIOS format to UPN formats.

• If the identity matches ACME\[IDENTITY], rewrite as ACME2\[IDENTITY].

  The result would be ACME2\jdoe. This rule instructs Cisco ISE to change all usernames with a certain prefix to an alternate prefix.

• If the identity matches [ACME]\jdoe.USA, rewrite as [IDENTITY]@[ACME].com.

  The result would be jdoe\ACME.com. This rule instructs Cisco ISE to strip the realm after the dot, in this case the country and replace it with the correct domain.

• If the identity matches E=[IDENTITY], rewrite as [IDENTITY].

  The result would be jdoe. This is an example rule that can be created when an identity is from a certificate, the field is an email address, and Active Directory is configured to search by Subject. This rule instructs Cisco ISE to remove ‘E=’.

• If the identity matches E=[EMAIL],[DN], rewrite as [DN].

  This rule will convert certificate subject from E=jdoe@acme.com, CN=jdoe, DC=acme, DC=com to pure DN, CN=jdoe, DC=acme, DC=com. This is an example rule that can be created when identity is taken from a certificate subject and Active Directory is configured to search user by DN . This rule instructs Cisco ISE to strip email prefix and generate DN.

The following are some common mistakes while writing the identity rewrite rules:

• If the identity matches [DOMAIN]\[IDENTITY], rewrite as [IDENTITY]@DOMAIN.com.

  The result would be jdoe@DOMAIN.com. This rule does not have [DOMAIN] in square brackets [ ] on the rewrite side of the rule.

• If the identity matches DOMAIN\[IDENTITY], rewrite as [IDENTITY]@[DOMAIN].com.

  Here again, the result would be jdoe@DOMAIN.com. This rule does not have [DOMAIN] in square brackets [ ] on the evaluation side of the rule.

Identity rewrite rules are always applied within the context of an Active Directory join point. Even if a scope is selected as the result of an authentication policy, the rewrite rules are applied for each Active Directory join point. These rewrite rules also applies for identities taken from certificates if EAP-TLS is being used.

Some type of identities include a domain markup, such as a prefix or a suffix. For example, in a NetBIOS identity such as ACME\jdoe, “ACME” is the domain markup prefix, similarly in a UPN identity such as jdoe@acme.com, “acme.com” is the domain markup suffix. Domain prefix should match to the NetBIOS (NTLM) name of the Active Directory domain in your organization and domain suffix should match to the DNS name of Active Directory domain or to the alternative UPN suffix in your organization. For example jdoe@gmail.com is treated as without domain markup because gmail.com is not a DNS name of Active Directory domain.

The identity resolution settings allows you to configure important settings to tune the security and performance balance to match your Active Directory deployment. You can use these settings to tune authentications for usernames and hostnames without domain markup. In cases when Cisco ISE is not aware of the user's domain, it can be configured to search the user in all the authentication domains. Even if the user is found in one domain, Cisco ISE will wait for all responses in order to ensure that there is no identity ambiguity. This might be a lengthy process, subject to the number of domains, latency in the network, load, and so on.

Cisco ISE identifies users using the attributes SAM, CN, or both. Cisco ISE, Release 2.2 Patch 5 and above, and 2.3 Patch 2 and above, use sAMAccountName attribute as the default attribute. In earlier releases, both SAM and CN attributes were searched by default. This behavior has changed in Release 2.2 Patch 5 and above, and 2.3 Patch 2 and above, as part of CSCvf21978 bug fix. In these releases, only the sAMAccountName attribute is used as the default attribute.

You can configure Cisco ISE to use SAM, CN, or both, if your environment requires it. When SAM and CN are used, and the value of the SAMAccountName attribute is not unique, Cisco ISE also compares the CN attribute value.

For Windows Server 2012 R2, give the Microsoft AD user full control permissions on the following registry keys:

• HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}

• HKLM\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}

Use the following commands in Windows PowerShell to check if full permission is given to the registry keys:

• get-acl -path "Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}" | format-list

• get-acl -path "hklm:\Software\Classes\Wow6432Node\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}" | format-list

The following permissions are required when a Microsoft AD user is not in the Domain Admin group, but is in the Domain Users group:

• Add registry keys to allow Cisco ISE to connect to the domain controller.

• Permissions to Use DCOM on the Domain Controller

• Set Permissions for Access to WMI Root and CIMv2 Namespace

These permissions are only required for the following Microsoft AD versions:

• Windows 2003

• Windows 2003R2

• Windows 2008

• Windows 2008 R2

• Windows 2012

• Windows 2012 R2

• Windows 2016

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"AppID"="{76A64158-CB41-11D1-8B02-00600806D9B6}"

[HKEY_CLASSES_ROOT\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"="  "

[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{76A64158-CB41-11D1-8B02-00600806D9B6}]
"DllSurrogate"="  "

To get started using Cisco PassiveID work center quickly, follow this flow:

1. Ensure you have properly configured the DNS server, including configuring reverse lookup for the client machine from Cisco ISE. For more information, see DNS Server.

2. Enable the Passive Identity and pxGrid services on the dedicated Policy server (PSN) you intend to use for any of the Passive Identity services. Choose Administration > System > Deployment, open the relevant node, and under General Settings, enable Enable Passive Identity Service and pxGrid.

3. Synchronize clock settings for the NTP servers.

4. Configure an initial provider with the ISE Passive Identity Setup. For more information, see Getting Started with the PassiveID Setup

5. Configure a single or multiple subscribers. For more information, see Subscribers

After setting up an initial provider and subscriber, you can easily create additional providers (see Additional Passive Identity Service Providers) and manage your passive identification from the different providers in the PassiveID work center.

The Cisco PassiveID Work Center dashboard displays consolidated and correlated summary and statistical data that is essential for effective monitoring and troubleshooting, and is updated in real time. Dashlets show activity over the last 24 hours, unless otherwise noted. To access the dashboard, choose Work Centers > PassiveID and then from the left panel choose Dashboard. You can only view the Cisco PassiveID Work Center Dashboard in the Primary Administration Node (PAN).

• The Main view has a linear Metrics dashboard, chart dashlets, and list dashlets. In the PassiveID Work Center, the dashlets are not configurable. Available dashlets include:

  • Passive Identity Metrics: Displays the total number of unique live sessions currently being tracked, the total number of identity providers configured in the system, the total number of agents actively delivering identity data, and the total number of subscribers currently configured.

  • Providers: Providers provide user identity information to PassiveID Work Center. You configure the ISE probe (mechanisms that collect data from a given source) through which to receive information from the provider sources. For example, an Active Directory (AD) probe and an Agents probe both help ISE-PIC collect data from AD (each with different technology) while a Syslog probe collects data from a parser that reads syslog messages.

  • Subscribers: Subscribers connect to ISE to retrieve user identity information.

  • OS Types: The only OS type that can be displayed is Windows. Windows types display by Windows versions. Providers do not report the OS type, but ISE can query Active Directory to get that information. Up to 1000 entries are displayed in the dashlet.

  • Alarms: User identity-related alarms.

Active Directory (AD) is a highly secure and precise source from which to receive user identity information, including user name, IP address, and domain name.

The AD probe, a Passive Identity service, collects user identity information from AD through WMI technology, while other probes use AD as a user identity provider through other technologies and methods. For more information about other probes and provider types offered by ISE, see Additional Passive Identity Service Providers.

By configuring the Active Directory probe you can also then quickly configure and enable these other probes (which also use Active Directory as their source):

• Active Directory Agents

  Note	The Active Directory agents are only supported on Windows Server 2008 and higher.

• SPAN

• Endpoint Probe

In addition, configure the Active Directory probe in order to use AD user groups when collecting user information. You can use AD user groups for the AD, Agents, SPAN, and Syslog probes. For more information about AD groups, see Configure Active Directory User Groups.

From the Passive Identity service work center install the native 32-bit application, Domain Controller (DC) agents, anywhere on the Active Directory (AD) domain controller (DC) or on a member server (based on your configurations) to retrieve user identity information from AD and then send those identities to the subscribers you have configured. The Agent probe is a quick and efficient solution when using Active Directory for user identity information. Agents can be installed on a separate domain, or on the AD domain, and once installed, they provide status updates to ISE once every minute.

The agents can be either automatically installed and configured by ISE, or you can manually install them. Upon installation, the following occurs:

• The agent and its associated files are installed at the following path: Program Files/Cisco/Cisco ISE PassiveID Agent

• A config file called PICAgent.exe.config is installed indicating the logging level for the agent. You can manually change the logging level from within the config file.

• The CiscoISEPICAgent.log file is stored with all logging messages.

• The nodes.txt file contains the list of all nodes in the deployment with which the agent can communicate. The agent contacts the first node in the list. If that node cannot be contacted, the agent continues to attempt communication according to the order of the nodes in the list. For manual installations, you must open the file and enter the node IP addresses. Once installed (manually or automatically), you can only change this file by manually updating it. Open the file and add, change or delete node IP addresses as necessary.

• The Cisco ISE PassiveID Agent service runs on the machine, which you can manage from the Windows Services dialog box.

• ISE supports up to 100 domain controllers, while each agent can monitor up to 10 domain controllers. In order to monitor 100 domain controllers, you must configure 10 agents.

• The Active Directory agents are only supported on Windows Server 2008 and higher. If you cannot install agents, then use the Active Directory probe for passive identity services. For more information, see Active Directory as a Probe and a Provider.

Note	Even if you are running the AD agent on a member server, it still queries the Active Directory for the login requests.

The API Providers feature in Cisco ISE enables you to push user identity information from your customized program or from the terminal server (TS)-Agent to the built-in ISE passive identity services REST API service. In this way, you can customize a programmable client from your network to send user identities that were collected from any network access control (NAC) system to the service. Furthermore, the Cisco ISE API provider enables you to interface with network applications such as the TS-Agent on a Citrix server, where all users have the same IP address but are assigned unique ports.

For example, an agent running on a Citrix server that provides identity mappings for users authenticated against an Active Directory (AD) server can send REST requests to ISE to add or delete a user session whenever a new user logs in or off. ISE then takes the user identity information, including the IP address and assigned ports, delivered from the client and sends it to pre-configured subscribers, such as the Cisco Firepower Management Center (FMC).

The ISE REST API framework implements the REST service over the HTTPS protocol (no client certificate validation necessary) and the user identity information is delivered in JSON (JavaScript Object Notation) format. For more information about JSON, see http://www.json.org/ .

The ISE REST API service parses user identities and in addition, maps that information to port ranges, in order to distinguish between the different users logged in simultaneously to one system. Everytime a port is allocated to a user, the API sends a message to ISE.

SPAN is a Passive Identity service that allows you to quickly and easily enable Cisco ISE to listen to the network and retrieve user information without having to configure Active Directory to work directly with Cisco ISE. SPAN sniffs network traffic, specifically examining Kerberos messages, extracts user identity information also stored by Active Directory and sends that information to ISE. ISE then parses the information, ultimately delivering user name, IP address and domain name to the subscribers that you have also already configured from ISE.

In order for SPAN to listen to the network and extract Active Directory user information, ISE and Active Directory must both be connected to the same switch on the network. In this way, SPAN can copy and mirror all user identity data from Active Directory.

With SPAN, user information is retrieved in the following way:

1. The user endpoint logs in to the network.

2. Log in and user data are stored in Kerberos messages.

3. When the user logs in and the user data passes through the switch, SPAN mirrors the network data.

4. Cisco ISE listens to the network for user information and retrieves the mirrored data from the switch.

5. Cisco ISE parses the user information and updates passive ID mappings.

6. Cisco ISE delivers the parsed user information to the subscribers.

Passive Identity service parses syslog messages from any client (identity data provider) that delivers syslog messages, including regular syslog messages (from providers such as InfoBlox, Blue Coat, BlueCat, and Lucent) as well as DHCP syslog messages, and sends back user identity information, including MAC addresses. This mapped user identity data is then delivered to subscribers.

You can specify the syslog clients from which to receive the user identity data (see Configure Syslog Clients). While configuring the provider, you must specify the connection method (TCP or UDP) and the syslog template to be used for parsing.

Note

When TCP is the configured connection type, if there is a problem with the message header and the host name cannot be parsed, ISE attempts to match the IP address received in the packet to the IP address of any of the providers in the list of providers that have already been configured for Syslog messages in ISE. To view this list, choose Work Centers > PassiveID > Providers > Syslog Providers. We recommend that you check the message headers and customize if necessary to guarantee parsing succeeds. For more information about customizing headers, see Customize Syslog Headers.

The syslog probe sends syslog messages that are received to the ISE parser, which maps the user identity information, and publishes that information to ISE. ISE then delivers the parsed and mapped user identity information to the Passive Identity service subscribers.

To parse syslog messages for user identity from ISE-PIC ISE:

• Configure syslog clients from which to receive user identity data. See Configure Syslog Clients.

• Customize a single message header. See Customize Syslog Headers.

• Customize message bodies by creating templates. See Customize the Syslog Message Body.

• Use the message templates pre-defined in ISE when configuring your syslog client as the message template used for parsing, or base your customized header or body templates on these pre-defined templates. See Work with Syslog Predefined Message Templates.