23.2 Auditing with XDAS

The XDAS specification provides a standardized classification for audit events. It defines a set of generic events at a global distributed system level. XDAS provides a common portable audit record format to facilitate the merging and analysis of audit information from multiple components at the distributed system level. The XDAS events are encapsulated within a hierarchical notational system that helps to extend the standard or existing event identifier set. The XDAS taxonomy defines a set of fields, of these the primary fields are observer, initiator and target. XDAS events helps you easily understand the audit trails of heterogeneous applications.

Configuring eDirectory to use XDAS provides the following benefits:

  • Provides secured audit services for a distributed system.

  • Defines a set of generic events at a global distributed system level.

  • Defines a common portable audit record format to help merge and analyze the audit information from multiple components of a distributed system.

  • Defines a common format for audit events that analysis applications can use.

  • Records XDAS audit trail.

  • Configures event preselection criteria and event disposition actions.

  • Provides a common audit format regardless of the platform on which the XDAS service is running.

  • Supports heterogeneous environments without the necessity to re-engineer the current operating system or application-specific audit service implementations.

  • Supports adequate separation of duties for users.

  • Protects the audit log by making it accessible only to principals acting in specific administrative or security roles.

  • Optionally caches audit events locally on the agent in case of communication failure between the agent and the auditing server and re-sends events when communication is re-established.

23.2.1 Configuring XDAS

The eDirectory installation kit includes both a Linux and a Windows XDAS client as part of its download package. The installation program for eDirectory installs the XDAS packages on your operating system. The XDAS package contains the following files:

  • Linux

    • novell-edirectory-xdaslog

    • novell-edirectory-xdaslog-conf

    • novell-edirectory-xdasinstrument

  • Windows

    • xdasauditds.dlm

    • xdaslog.dll

NOTE:From the OES 11 SP2 release, the XDAS RPMs are bundled with the Open Enterprise Server.

System Requirements

Installing and using the NetIQ Audit iManager Plug-in requires iManager 3.0 at a minimum. See NetIQ iManager Product Page for requirements and download instructions.

Installing or Upgrading the iManager Plug-In for XDAS

The iManager plug-in for XDAS is bundled with eDirectory plug-ins. Alternatively, you can download the eDirectory plug-ins from the NetIQ Download Site.

To upgrade the plug-in to the latest version:

  1. Open iManager from a Web browser, using the following URL:

    https://ip_address_or_DNS/nps/iManager.html

    where ip_address_or_DNS is the IP address or DNS name of your iManager server.

    For example:

    http://111.111.1.1/nps/iManager.html
  2. Log in to the iManager using your username and password.

    If you want to access all the NetIQ iManager features, you must login as an administrator to the tree. Only administrative user has full access to all the features. A non-administrative user can only access those roles for which rights are assigned.

    For more information, see the NetIQ iManager Administration Guide.

  3. Select Roles and Tasks > Audit Configuration

    iManager displays an alert message about the new XDAS changes.

  4. Click OK.

    During upgrade, new iManager files are installed and they cause configuration changes. After the upgrade is complete, a message is displayed stating the success or failure status of the installation.

Configuring the XDAS Property File

The eDirectory media includes a sample properties file, xdasconfig.properties.template file in the configdir (n4u.server.configdir) directory.

Table 23-1 lists the default location of the xdasconfig.properties file on Linux and Windows operating systems.

Table 23-1 XDAS Configuration File

Operating System

Location of the Property File

Linux

/etc/opt/novell/eDirectory/conf/
xdasconfig.properties

For non-root installations, the XDAS property file is located in the conf directory.

Windows

<Install Path>/novell/nds/xdasconfig
 

The property file is usually in the eDirectory installation directory.

If you configure the property file and then upgrade your environment to eDirectory 9.0, the installer does not replace the property file. Instead, the upgrade process updates the file (xdasconfig.properties.template) to retain the customization.

You can configure XDAS after installing iManager. The XDAS configuration settings are stored in a simple text-based xdasconfig.properties configuration file. You can customize the file based on your requirements.

The XDAS property file contains the following information:

Linux

# Set the level of the root logger to DEBUG and attach appenders.
#log4j.rootLogger=debug, S, R
# Defines appender S to be a SyslogAppender. 
#log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server.
#log4j.appender.S.Host=localhost
#log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL)
#log4j.appender.S.Protocol=UDP
# Specify SSL certificate file for SSL connection.
# File path should be given with double backslash.
#log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
# Minimum log-level allowed in syslog.
#log4j.appender.S.Threshold=INFO
# Defines the type of facility.
#log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender.
# Inputs should be yes/no
#log4j.appender.S.CacheEnabled=no
# Cache location directory
# Directory should be available for creating cache files
#log4j.appender.S.CacheDir=/var/opt/novell/eDirectory
# Cache File Size
# Cache File Size should be in the range of 50MB to 4000MB
#log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S.
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
# Defines appender R to be a Rolling File Appender.
#log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R.
#log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
# Max size of log file for appender R.
#log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R.
# Max can be 13. If set to zero, then there will be no backup files.
#log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Windows

# Set the level of the root logger to DEBUG and attach appenders.
#log4j.rootLogger=debug, S, R
# Defines appender S to be a SyslogAppender. 
#log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server.
#log4j.appender.S.Host=localhost
#log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL)
#log4j.appender.S.Protocol=UDP
# Specify SSL certificate file for SSL connection.
# File path should be given with double backslash.
#log4j.appender.S.SSLCertFile=C:\\Novell\\mycert.pem
# Minimum log-level allowed in syslog.
#log4j.appender.S.Threshold=INFO
# Defines the type of facility.
#log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender.
# Inputs should be yes/no
#log4j.appender.S.CacheEnabled=no
# Cache location directory
# Directory should be available for creating cache files
#log4j.appender.S.CacheDir=C:\\Novell\\NDS
# Cache File Size
# Cache File Size should be in the range of 50MB to 4000MB
#log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S.
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
# Defines appender R to be a Rolling File Appender.
#log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R.
#log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
# Max size of log file for appender R.
#log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R.
# Max can be 13. If set to zero, then there will be no backup files.
#log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Before going through the content of the xdasconfig.properties file, NetIQ recommends reviewing the following considerations:

  • The letters S and R specify Syslog Appender and Rolling File Appender respectively.

  • The entries are not case sensitive.

  • The entries can appear in any order.

  • Empty lines in the file are valid.

  • Any line that starts with a hash (#) is commented out.

The following table provides information about the settings in the xdasconfig.properties file:

IMPORTANT:You must restart eDirectory After changing any configuration.

Setting

Description

log4j.rootLogger=debug, S, R

Sets the level of the root logger to debug and attaches an appender named R or S, where S specifies a Syslog appender and R specifies a Rolling File appender.

log4j.appender.S=org.apache.log4j.net.SyslogAppender

Specifies the appender S to be a Syslog appender.

log4j.appender.S.Host=localhost

Specifies the location of the Syslog server where XDAS events are logged.

IFor example,log4j.appender.S.Host=192.168.0.1

log4j.appender.S.Port=port

The port at which the XDAS connects to the Syslog server.

The port supports values from 1 to 65535. If you specify an invalid value, the port defaults to 514.

If the connection between XDAS and the Syslog server fails, Identity Manager cannot log events until the connection is restored.

log4j.appender.S.Protocol=UDP

Specifies the protocol to use. For example, UDP, TCP, or SSL.

log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem

Specifies the SSL certificate file for the SSL connection. Use double backslashes to specify the path of the file. This is an optional setting.

log4j.appender.S.Threshold=INFO

Specifies the minimum log level allowed in the Syslog appender. Currently, the INFO log level is supported.

log4j.appender.S.Facility=USER

Specifies the type of facility. The facility is used to try to classify the message.Currently, USER facility is supported. These values may be specified as upper or lower case characters.

log4j.appender.S.layout=org.apache.log4j.PatternLayout

Layout setting for Syslog appender.

log4j.appender.S.layout.ConversionPattern=%c : %p%m%n

Layout setting for Syslog appender. For information about the conversion patters and their descriptions, see logging.apache.org.

log4j.appender.R=org.apache.log4j.RollingFileAppender

Specifies appender R to be a Rolling File appender.

log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log

The location of the log file for a Rolling File appender.

log4j.appender.R.MaxFileSize=100MB

The maximum size, in MBs, of the log file for a Rolling File appender. Set this value to the maximum size that the client allows.

log4j.appender.R.MaxBackupIndex=10

Specify the maximum number of backup files for a Rolling File appender. The maximum number of the backup files can be 10. A 0 value means no backup files.

log4j.appender.R.layout=org.apache.log4j.PatternLayout

Layout setting for Rolling File appender.

log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n

Layout setting for Rolling File appender. For simple date format patterns, see Table 23-2.

For information about the conversion patters and their descriptions, see logging.apache.org.

Table 23-2 lists examples with the date and time patterns interpreted in the U.S. The given date and time are 2012-07-04 12:08:56 local time in the U.S. Pacific Time time zone.

Table 23-2 Date and Time Pattern Example

Date and Time Pattern

Result

"yyyy.MM.dd G 'at' HH:mm:ss z"

2012.07.04 AD at 12:08:56 PDT

"EEE, MMM d, ''yy"

Wed, Jul 4, '01

"h:mm a"

12:08 PM

"hh 'o''clock' a, zzzz"

12 o'clock PM, Pacific Daylight Time

"K:mm a, z"

0:08 PM, PDT

"yyyyy.MMMMM.dd GGG hh:mm aaa"

02012.July.24 AD 12:08 PM

"EEE, d MMM yyyy HH:mm:ss Z"

Wed, 24 Jul 2012 12:08:56 -0700

"yyMMddHHmmssZ"

120724120856-0700

"yyyy-MM-dd'T'HH:mm:ss.SSSZ"

2012-07-04T12:08:56.235-0700

Enabling the Syslog Appender

You can use the Syslog appender, if you want centralize the auditing messages at one place. Additionally, a Syslog server offers better backup support in the event of a disaster.

To enable the Syslog appender, make the following changes in the xdasxconfig.properties file:

  1. Change the following entry to S to attach a Syslog appender:

    log4j.rootLogger=debug, S

  2. Uncomment the following entries:

    log4j.appender.S=org.apache.log4j.net.SyslogAppender
    log4j.appender.S.Host=localhost
    log4j.appender.S.Port=port
    log4j.appender.S.Protocol=UDP
    log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
    #log4j.appender.S.Threshold=INFO
    #log4j.appender.S.Facility=USER
    #log4j.appender.S.layout=org.apache.log4j.PatternLayout
    #log4j.appender.S.layout.ConversionPattern=%c : %p%m%n
  3. Log into iManager and change the log events. For information about configuring XDAS Events, see Configuring the XDAS Events for Auditing.

NOTE:XDAS caching using UDP protocol for SyslogAppender does not work.

Generating Certificate for Syslog SSL Connection

To generate a certificate for syslog connection:

  1. Create the certificate by using the following OpenSSL command:

    openssl s_client -host LOG_SERVER  -port 1443 -showcerts
  2. Specify the location of the certificate file that you created in the /etc/opt/novell/eDirectory/conf/xdasconfig.properties file.

Enabling the Rolling File Appender

The File appender is preferred, if the auditing solution is limited to an individual server. Also, it is easy to bring up this solution because the number of components to be setup are few and thus, is more suited for demonstrations.

To enable the Rolling File appender, make the following changes in the xdasxconfig.properties file:

  1. Change the following entry to R to attach a Rolling File appender.

    log4j.rootLogger=debug, R

  2. Uncomment the following entries:

    log4j.appender.R=org.apache.log4j.RollingFileAppender
    log4j.appender.R.File=/var/opt/novell/eDirectory/log/xdas-events.log
    log4j.appender.R.MaxFileSize=100MB
    log4j.appender.R.MaxBackupIndex=10
    log4j.appender.R.layout=org.apache.log4j.PatternLayout
    log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n
  3. Select the desired event from iManager.

    For information about configuring XDAS Events, see Configuring the XDAS Events for Auditing.

Configuring XDAS for Auditing

Using the iManager Plug-In for Configuring XDAS

  1. Open iManager from a Web browser using the following URL:

    https://ip_address_or_DNS/nps/iManager.html

    where ip_address_or_DNS is the IP address or DNS name of your iManager server.

    For example:

    http://111.111.1.1/nps/iManager.html
  2. Log in using your username and password.

    If you want to access all the NetIQ iManager features, you must login as an administrator to the tree. Only administrative user has full access to all the features. A non-administrative user can only access those roles for which rights are assigned.

    For more information, see the NetIQ iManager Administration Guide.

  3. Select Roles and Tasks. > Audit Configuration.

  4. Specify the name of your eDirectory server in NCP Server, then click the Object Selector icon to browse for the eDirectory server.

  5. Click OK.

    The XDAS Audit page is displayed. Continue with Configuring XDAS.

Configuring the XDAS Events for Auditing

  1. Log in to iManager using your username and password.

  2. Select Roles and Tasks. > Audit Configuration.

  3. Select the XDAS tab.

  4. Configure the XDAS events.

    • Basic Events Configuration: Specify the values for the following options based on the events required for your environment:

      NOTE:Individual event categories under the basic events configuration section will be collapsed by default. You can expand each category to select individual events.

      Options

      Description

      Account Management Events

      Select the account management events for which you want to log events. You can log events to create, delete, enable, disable, and also to query and modify accounts.

      Trust Management Events

      Select the trust management events for which you want to log events. You can log events to create, delete, query and modify trust.

      Account Data Events

      Select the account data events for which you want to log events. You can log events to create and delete data items and to modify and query data item attributes.

      Security Events

      Select the account security events for which you want to log events. You can log events to grant or revoke access, login, password modification and query. This set of events also help to detect intruder attempts on the eDirectory system.

    • Advanced: Specify the values for the following options based on the events required for your environment:

      • Global: You can select or clear the global settings for duplicate entries.

        • Do Not Send Replicated Events: Select this option to stop receiving duplicate events due to replication from other servers.

      • Log Event’s Values: The events are logged into a text file. Event values with more than 768 bytes in size are considered “large values.” You can log events of any size.

        • Log Large Values: Select this option to log events that are more than 768 bytes in size.

        • Don’t Log Large Values: Select this option to log events that are less than 768 byte in size.

        NOTE:If the event size is more, the event value is truncated and saved to the log file.

    • Advanced Events Configuration: Specify the values for the following options based on the events required for your environment:

    Options

    Description

    Service or Application Management Events

    Select the service or application management events for which you want to log events. You can log events to enable, disable, invoke, and terminate services.

    Operational Events

    Select the operational management events for which you want to log events. You can log events to start and shutdown system, to backup and recover data store, to audit internal operations and modify process contexts.

    For information about eDirectory internal events mapped with the corresponding XDAS events, see Mapping eDirectory Events with XDAS Events.

    NOTE:After you select the event, it takes up to 3 minutes for the configuration changes to take effect on the NCP Server. If you want the configuration changes to be implemented immediately on the NCP server, you can unload and load the xdasauditds module.

Loading and Unloading the Modules

After you configure the XDAS events, run the following commands to load and unload the XDAS modules:

To automatically load the xdasauditds module whenever the ndsd server is started:

  • Linux

    Add xdasauditds to the /etc/opt/novell/eDirectory/conf/ndsmodules.conf file.

  • Windows

    Run ndscons.exe, select xdasauditds from the list of available modules, click Startup, and then select Automatic for Startup Type.

To manually load and unload the xdasauditds module:

  • Linux

    To load, run ndstrace -c "load xdasauditds".

    To unload, run ndstrace -c "unload xdasauditds".

  • Windows

    To load, run ndscons.exe, select xdasauditds from the list of available modules, then click Start.

    To unload, run ndscons.exe, select xdasauditds from the list of available modules, then click Stop.

If you installed NMAS and enabled NMAS auditing, the NMAS server automatically loads the XDAS library.

Enabling XDAS Event Caching

eDirectory 9.0 allows you to optionally store XDAS events locally on the agent in a Syslog Appender cache. With events cached, if the agent cannot communicate with the auditing server, the audit events generated are retained, ensuring that audit data is not lost. The agent then attempts to re-send the cached events when the agent computer can once again communicate with the auditing server.

XDAS event caching is disabled by default. To enable event caching, complete the steps below.

  1. On the agent computer, navigate to the location of the XDAS property file. The xdasconfig.properties file is located at /etc/opt/novell/eDirectory/conf/xdasconfig.properties by default. For non-root installations, the XDAS property file is located in the conf directory by default.

  2. Use a text editor to open the xdasconfig.properties file.

  3. Within the property file, navigate to the log4j.appender.S.CacheEnabled property and change the property value to yes.

  4. (Conditional) If you want to cache events in a specific directory, modify the value of the log4j.appender.S.CacheDir property to specify the directory path. The default path is /var/opt/novell/eDirectory. If you specify a directory, ensure that the directory path is a valid location on the server. If the specified path does not exist, the Syslog Appender logs events to the default location.

  5. (Conditional) If you want to specify a custom file size for the cache, modify the value of the log4j.appender.S.CacheMaxFileSize property. The default value is 500 MB. The minimum value should be 50 MB, with a maximum value of 4 GB.

  6. Save and close the xdasconfig.properties file.

Using Collectors for XDAS Events

For more information about using collectors for collecting XDAS events, visit the Sentinel Plug-ins page .

Understanding XDAS Auditing Event Filtering

Using filters and event notifications, XDAS is capable of reporting when a specific type of event occurs, or when it does not occur. You can also filter events for one or more specific object classes or attributes, depending on the event type. XDAS evaluates all the generated events against the configured filters on the eDirectory server and logs only the events matching to those filters.

You can configure filters and events notifications for XDAS Accounts, XDAS Trusts, and XDAS Data Items. In case of XDAS Accounts and Trusts, any selected object class will be mapped to their respective event categories. For example, if you select User class from Accounts filtering, this class gets automatically mapped to the Accounts Management Events category. By default, any object class which is not mapped to accounts or trusts, will be mapped to Data Items Management Events category.

This section provides the information you need to configure your system filters and notifications.

Filtering XDAS Account Management Events

You can configure filtering for Accounts to look for only a specific event or events. For example, if you want to be notified when someone creates a user account in eDirectory, you can create a filter selecting the User Object class to log events for creating a new user object.

To configure accounts filtering, click the Account Management Events link, select the class, and then click OK to exit the application.

To configure filters for Account Management events:

  1. In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.

  2. Select the NCP Server you want to monitor, and then click OK.

    By default, the XDAS Events tab is selected.

  3. Click Account Management Events.

    The XDAS Accounts Configuration Filtering window appears.

  4. In the Available Classes list, select any object class, then click the right arrow to move the object class to the Selected Classes list, and then click OK. By default Organizational Person, Person, and User object classes are selected.

  5. In the Available Attributes(s) list, select any number of attributes for the selected object classes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.

    The filter for the Account Management events is configured.

Using the configured filter, XDAS audit module checks all generated events for the selected object classes and attributes and logs those events.

Filtering XDAS Trusts Management Events

Click the Trust Management Events link to configure filtering for the Trust Management Events. For example, if you want to be notified when someone creates a new trust in eDirectory, you can create a filter selecting the Group Object class to log events for creating a new trust.

To configure filtering for Trust Management Events:

  1. In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.

  2. Select the NCP Server you want to monitor, and then click OK.

    By default, the XDAS Events tab is selected.

  3. Click Trust Management Events.

    The XDAS Trust Configuration Filtering window appears.

  4. In the Available Classes list, select object classes for which you want to collect events, then click the right arrow to move them to the Selected Classes list. By default dynamicGroup, dynamicGroupAux, Group, LDAP Group and Organizational Role object classes are selected

  5. In the Available Attributes(s) list, select any number of attributes for the selected object classes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.

    NOTE:If you select an object class, then all the Trust Events for all attributes on that object class are selected. In this case, you will get all the Trust Management Events for the all attributes on the selected object classes.

  6. Click OK.

With the filter configured, XDAS audit module checks the generated events for all the selected object classes and attributes and logs those events.

Filtering XDAS Data Item Management Events

Click the Data Item Management Events link to configure filtering for the XDAS data items. You can configure XDAS data items for the objects for which you want to collect XDAS events. You can select object classes and set attributes for them.

To configure filtering for Data Item Management Events:

  1. In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.

  2. Select the NCP Server you want to monitor, and then click OK.

    By default, the XDAS Events tab is selected.

  3. Click Data Item Management Events.

    The XDAS Data Configuration Filtering window appears.

  4. In the Available Classes list, select object classes for which you want to collect events, then click the right arrow to move them to the Selected Classes list. By default any object class which is not mapped to accounts or trusts, will be mapped to the Data Items Management Events category.

    NOTE:If no object classes are selected, events for all the available object classes will be generated.

  5. In the Available Attributes(s) list, select any number of attributes for the selected object classes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.

  6. Click OK.

Using the configured filter, XDAS audit module checks the generated events for all the selected object classes and attributes and logs those events.

Filtering eDirectory Events With Exclusion Filter

Click the Exclusion List link to configure filtering for those object classes and attributes for which you do not want an event to be generated. You can select object classes and set attributes for them.

To configure filtering for unwanted eDirectory Events:

  1. In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.

  2. Select the NCP Server you want to monitor, and then click OK.

    By default, the XDAS Events tab is selected.

  3. Click Exclusion List.

    The XDAS Exclusion Filtering window appears.

  4. In the Available Classes list, select object classes for which you do not want to collect events, then click the right arrow to move them to the Selected Classes list.

  5. In the Available Attributes(s) list, select any number of attributes for the selected object classes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.

  6. Click OK.

Using the configured filter, XDAS audit module stops generating events for all the selected object classes and attributes.

XDAS Schema

The XDAS schema is defined as follows:

XDAS JSON Schema

{
    "id":"XDAS",
    "title":"XDAS Version 2 JSON Schema",
    "description":"A JSON representation of an XDAS event record.",
    "type":"objectr",
    "properties":{
      "Source":{
        "description":"The original source of the event, if applicable.",
        "type":"string",
        "optional":true
      },
      "Observer":{
        "description":"The recorder (ie., the XDAS service) of the event.",
        "type":"object",
        "optional":false,
        "properties":{
          "Account":{"$ref":"account"},
          "Entity":{"$ref":"entity"}
        }
      },
      "Initiator":{
        "description":"The authenticated entity or access  that causes an event.",
        "type":"object",
        "optional":false,
        "properties":{
          "Account":{"$ref":"account","optional":true},
          "Entity":{"$ref":"entity"},
          "Assertions":{
            "description":"Attribute/value assertions about an identity.",
            "type":"object",
            "optional":true
          }
        }
      },
      "Target":{
        "description":"The target object, account, data item, etc of the event.",
        "type":"object",
        "optional":true,
        "properties":{
          "Account":{"$ref":"account"},
          "Entity":{"$ref":"entity"},
          "Data":{                           
            "description":"A set attribute/value pairs describing the target object.",        * 
            "type":"object",        
            "optional":true
          }  
        }
      },
      "Action":{
        "description":"The action describes the event in a uniform manner.",
        "type":"object",
        "optional":false,
        "properties":{
          "Event":{
            "description":"The event identifier in standard XDAS taxonomy.",
            "type":"object",
            "optional":false,
            "properties":{
              "Id":{
                "description":"The XDAS taxonomy event identifier.",
                "type":"string",
                "optional":false,
                "pattern":"/^[0-9]+(\.[0-9]+)*$/" 
              },
              "Name":{
                "description":"A short descriptive name for the specific event.", eg. a new replica is added 
                "type":"string",
                "optional":true
              },
      "CorrelationID":{
          "description":"Correlation ID, source#uniqueID#connID",
                 "type":"string",
                 "optional":true
      }
     },
     "SubEvent":{
      "type":object
      "description": "Describes the actual domain specific event that has occured.",
      "optional":true,
      "properties":{
        "Name"":{
                    "description":"A short descriptive name for this event.",
                    "type":"string",
                    "optional":true
                  },
      }
            }  
          }
          "Log":{
            "description":"Client-specified logging attributes.",
            "optional":true,
            "properties":{
              "Severity":{"type":"integer", "optional":true},
              "Priority":{"type":"integer", "optional":true},
              "Facility":{"type":"integer", "optional":true}
            }
          }
          "Outcome":{
            "description":"The XDAS taxonomy outcome identifier.",
            "type":"string",
            "optional":false,
            "pattern":"/^[0-9]+(\.[0-9]+)*$/"
          }
          "Time":{
            "description":"The time the event occurred.",
            "type":"object",
            "optional":false,
            "properties":{
              "Offset":{
                "description":"Seconds since Jan 1, 1970.",
                "type":"integer"
              },
              "Sequence":{
                "description":"Milliseconds since last integral second.",
                "type":"integer",
                "optional":true
              },
              "Tolerance":{
                "description":"A tolerance value in milliseconds.",
                "type":"integer",
                "optional":true
              },
              "Certainty":{
                "description":"Percentage certainty of tolerance.",
                "type":"integer",
                "optional":true,
                "minimum":0,
                "maximum":100,
                "default":100,
              },
              "Source":{
                "description":"The time source (eg., ntp://time.nist.gov).",
                "type":"string",
                "optional":true
              },
              "Zone":{
                "description":"A valid timezone symbol (eg., MST/MDT).",
                "type":"string",
                "optional":true
              }
            }
      "ExtendedOutcome":{
            "description":"The XDAS taxonomy outcome identifier.",
            "type":"string",
            "optional":false,
            "pattern":"/^[0-9]+(\.[0-9]+)*$/"
           }
        }
      }
    }
  },
  {
    "id":"account",
    "description":"A representation of an XDAS account.",
    "type":"object",
    "properties":{
      "Domain":{
        "description":"A (URL) reference to the authority managing this account.",    /* lets take it as the partition?
        "type":"string"
      },
      "Name":{
        "description":"A human-readable account name.",        - DN
        "type":"string",
        "optional":true
      },
      "Id":{
        "description":"A machine-readable unique account identifier value.",  - EntryID
        "type":"integer"
      }
    }
  },
  {
    "id":"entity",                    - Server details for Target, client address details for the initiator
    "description":"A representation of an addressable entity.",
    "type":"object",
    "properties":{
      "SysAddr":{"type":"string","optional":true},  
      "SysName":{"type":"string","optional":true},
      "SvcName":{"type":"string","optional":true},
      "SvcComp":{"type":"string","optional":true},
    }
  }

XDAS Field Definitions

These fields in the schema are the XDAS fields defined specifically for audit events. Some or all of these fields may also be relevant to other types of event, but information of this sort is required for auditing services. The XDAS JSON record format is open. By that, we mean that any additional fields may be added to the record at any place, as long as they don't conflict with the field values defined for audit by the XDAS standard.Thus, if there is a particular type of correlation data, such as a workflow identifier, or a session identifier that can be used as correlation data points between events within a particular workflow or client session, you may add these fields. Simply choose a non-conflicting name for your field.

Table 23-3 XDAS Field Definitions

XDAS Field

Description

Source (Optional)

The source of an event identifies the event service of another system from which this event was originally defined and converted to an XDAS event. Since many events are generated directly by XDAS clients, the source field is optional.

Initiator

The initiator of an event is the authenticated entity that initially provoked creation of the event. Note that an initiator need not be identified. If the entity can't be identified - perhaps an entity is attempting to login, thus provoking the generation of a login event by an observer - then as much information about the origin of the event as possible should be specified. NOTE: In the special case of a login event, the authenticated identity of the initiator is not yet known until after the login attempt has succeeded. Therefore a failed login event should not give the identity of the target account as the identity of the initiator.

An initiator is described in terms of an account and an entity (described below), as well as an optional set of assertions. These assertions describe, in terms of a set of name/value pairs, the attributes of the initiator identity. Some initiators are not known by a specific account, but are known only by a set of assertions (SAML2, for instance) that describe the rights of the actor. The schema is not defined for these assertions, as they will be different for each class and potentially for each individual object.

Action

The action identifies the event that is being recorded. This field provides the XDAS event identifier, as well as an outcome code (success, or failure class), and the time the event occurred, with as much accuracy as possible.

Event

The event field is the key to XDAS events. Event encapsulates a taxonomical identifier and a short descriptive name for human readability.

Id

The event Id code represents the event identifier, defined by the XDAS standard event taxonomy, and extensions defined by the Novell CSS product.

Name

The event name is a human readable representation of the event identifier. The event name is optional, but recommended for readability.

Data

The event data provides additional descriptive information about the event.

Log

The log field contains standard syslog-like log-level values, in terms of Severity and Facility numeric identifiers. The log field is optional, as well as every sub-field within the log field. These values should only be used when necessary, as they generally represent judgment calls on the part of the instrumentor. Such judgment calls are best left to analysis software or engineers once the event data is collected.

Outcome

For details on outcome codes, see Outcome Codes.

Time

The event time is the time recorded by the observer at the point the event was committed to the event service. Time values are gathered by the XDAS client helper library. Thus, there is no reason to be concerned about values stored in this field, as the helper library will attempt to be as accurate as possible when generating time information.

Offset

The offset field contains a value representing the number of seconds since midnight, January 1, 1970 - otherwise known as the Linux epoch.

Sequence

The sequence field contains a unique numeric value identifying this event from another event which may have been recorded within the same second. For the most part, this value should be taken as a monotonically increasing numeric value that begins at zero and continues until the next second boundary, at which point, it begins again at zero.

Tolerance

The tolerance value is a value between 0 and 100, indicating the tolerance of the clock used to record the time in offset. Values of zero indicate the clock is very accurate. Values of 100 indicate that the clock should not be trusted.

Certainty

The certainty value is a value between 0 and 100, indicating the percentage certainty of the tolerance value. Zero means there is no certainty of the tolerance, and thus, it shouldn't be trusted to any degree of accuracy. A value of 100 indicates that the tolerance value is very accurate.

Source

The time source is information indicating the source of time for the observer system. This may be a URL for a time server, or simply a local time source, such as a hardware clock.

Zone

The time zone is the new time zone string representing the time zone of this clock.

Target (Optional)

The target of an event is the account or protected resource upon which the initiator is attempting to act, thereby provoking the generation of an event. A target is described in terms of an account and an entity (described below), as well as an optional and unspecified Data object. The Data object is a set of name/value pairs describing class-specific attributes of the actor. The schema does not define the actual fields, as different classes will have a unique set of data attributes (if any).

Observer

The observer of an event is the authenticated identity of an entity (service) that is monitoring the system, and generating events based on initiator actions. An observer is described in terms of an account and an entity (described below).

Referenced Classes

The observer, initiator, and target fields contain references to the account and entity classes defined separately within the schema. These other classes identify key attributes of the three primary actors within an audit event.

Account Class

The account class represents the identity of the actor. This identity is relative to an authentication realm or Domain. Both an account name and an account Id are provides, although only the Id is really required. The Name is for human readability.

Account Domain

The account Domain defines the authentication authority of the actor. Account identifiers mean very little without an authentication authority.

Account Name

The account Name is optional, providing human readability.

Account Id

The account Id is a unique identifier of the account within the authentication Domain.

Entity Class

The entity class describes the location of the actor. This location is defined in terms of a system access end point (IP network) address and a system access end point (host/domain) name. Additional fields are also available to describe the service and component names within the software that manages the above end points.

Entity SysAddr

An IP address describing the access end point of the software actor. The IP address is displayed as IP Address:Port. For example:

  • IPv4: 194.99.188.103:34564

  • IPv6: [2015::15]:43333

Note that internal event IP address is displayed as 0.0.0.0:0.

Entity SysName

A host/domain name describing the access end point of the software actor.

Entity SvcName

A service name further describing the service that manages the above end point.

Entity SvcComp

A service component name describing the component within the above service.

Outcome Codes

The outcome code is a hierarchical numeric value much like the event code. Outcome codes indicate success or a failure class and reason. The success hierarchy is encapsulated by the 0.x sub-arc. Failure classes are represented by the 1.x hierarchy. Denial codes are represented by the 2.x hierarchy.

Example of an Event

An example event is given below:

Mar 16 21:46:40 eDirectory : INFO {"Source" : "eDirectory#DS","Observer" : {"Account" : {"Domain" : "TREEUPGRADE","Name" : "CN=SLE12-142,O=novell"},"Entity" : {"SysAddr" : "164.99.179.142","SysName" : "SLE12-142"}},"Initiator" : {"Account" : {"Domain" : "TREEUPGRADE","Name" : "CN=SLE12-142,O=novell"},"Entity" : {"SysAddr" : "164.99.179.142:43230"}},"Target" : {"Data" : {"ClassName" : "Tree Root","Name" : "TREEUPGRADE","Version" : "2"}},"Action" : {"Event" : {"Id" : "0.0.3.2","Name" : "QUERY_DATA_ITEM_ATTRIBUTE","CorrelationID" : "eDirectory#5#","SubEvent" : "DSE_LIST_PARTITIONS"},"Time" : {"Offset" : 1489681000},"Log" : {"Severity" : 7},"Outcome" : "0","ExtendedOutcome" : "0"}}

XDAS Events

For more information about XDAS events, see Section H.0, Mapping eDirectory Events with XDAS Events.

Troubleshooting XDAS

For more information about troubleshooting the installation and configuration issues, see Troubleshooting XDAS.