In this procedure, you configure a remote system, the Audit Remote Server (ARS), to receive and store audit records from one or more audited systems. Then, you activate the audit daemon on the remote server.
The configuration is twofold. First, you configure the underlying security mechanisms to securely transport the audit data, that is, you configure the KDC. Second, you configure the audit service on both the audited system and the ARS. This procedure illustrates a scenario with one audited client and one ARS, where the ARS and the KDC are on the same server. More complex scenarios can be configured similarly. The first four steps describe the configuration of the KDC, while the final step describes the configuration of the audit service.
Before You Begin
Ensure that you have completed the following You must assume the root role.
You have assumed the root role.
You have installed the Kerberos packages, as described in How to Prepare to Stream Audit Records to Remote Storage.
You are working with an administrator who has configured the audited system, as described in How to Send Audit Files to a Remote Repository.
You need a KDC on a system that both the audited system and the ARS can use, a host principal for each system, and an audit service principal. The following example illustrates a KDC configuration strategy:
arstore # kdcmgr -a audr/admin -r EXAMPLE.COM create master
This command uses the administrative principal audr/admin to create a master KDC in the EXAMPLE.COM realm, enables the master KDC, and starts the Kerberos service.
For more information, see the kdcmgr(1M) man page.
# kdcmgr status KDC Status Information -------------------------------------------- svc:/network/security/krb5kdc:default (Kerberos key distribution center) State: online since Wed Feb 29 01:59:27 2012 See: man -M /usr/share/man -s 1M krb5kdc See: /var/svc/log/network-security-krb5kdc:default.log Impact: None. KDC Master Status Information -------------------------------------------- svc:/network/security/kadmin:default (Kerberos administration daemon) State: online since Wed Feb 29 01:59:28 2012 See: man -M /usr/share/man -s 1M kadmind See: /var/svc/log/network-security-kadmin:default.log Impact: None. Transaction Log Information -------------------------------------------- Kerberos update log (/var/krb5/principal.ulog) Update log dump : Log version # : 1 Log state : Stable Entry block size : 2048 Number of entries : 13 First serial # : 1 Last serial # : 13 First time stamp : Wed Feb 29 01:59:27 2012 Last time stamp : Mon Mar 5 19:29:28 2012 Kerberos Related File Information -------------------------------------------- (Displays any missing files)
You can add the principal by typing the kadmin.local command on the KDC system. Or, you can remotely add the principal by using the kadmin command and providing a password. In this example, the arstore system is running the KDC.
# kadmin -p audr/admin kadmin: addprinc -randkey audit/arstore.example.com@EXAMPLE.COM kadmin: ktadd audit/arstore.example.com@EXAMPLE.COM
The receiver and the sender must have keys.
enigma # kclient .. Enter the Kerberos realm: EXAMPLE.COM .. KDC hostname for the above realm: arstore.example.com .. Will this client need service keys ? [y/n]: y
# auditconfig -setremote group create Bank_A
Bank_A is a connection group. Because the hosts attribute is not defined, this group accepts all connections, which means that it is a wildcard group. Any audited system in this Kerberos realm whose audit_remote plugin is correctly configured can reach this ARS.
# auditconfig -setremote group Bank_A "hosts=enigma.example.com"
Connection group Bank_A now accepts only connections from the enigma system. A connection from any other host is refused.
# auditconfig -setremote group Bank_A "binfile_fsize=4GB" # auditconfig -getremote Audit Remote Server Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0; Connection group: Bank_A (inactive) Attributes: binfile_dir=/var/audit;binfile_fsize=4GB;binfile_minfree=1; hosts=enigma.example.com;
To specify the ARS, use the p_hosts attribute.
enigma # auditconfig -setplugin audit_remote \
active p_hosts=arstore.example.com
enigma # auditconfig -getplugin audit_remote
Plugin: audit_remote
Attributes: p_retries=3;p_timeout=5;p_hosts=arstore.example.com;
The audit service reads the audit plugin change upon refresh.
# audit -s
The KDC now manages the connection between the audited system enigma and the ARS.
This example extends the example in the procedure. The administrator separates audit records by host on the ARS by creating two connection groups.
Audit files from audsys1 stream to the Bank_A connection group on this ARS.
arstore # auditconfig -setremote group create Bank_A arstore # auditconfig -setremote group active Bank_A "hosts=audsys1" \ "hosts=audsys1;binfile_dir=/var/audit/audsys1;binfile_fsize=4M;"
Audit files from audsys2 stream to the Bank_B connection group.
arstore # auditconfig -setremote group create Bank_B arstore # auditconfig -setremote group active Bank_B \ "hosts=audsys2;binfile_dir=/var/audit/audsys2;binfile_fsize=4M;"
For easier maintenance, the administrator sets other attribute values identically.
arstore # auditconfig -getremote Audit Remote Server Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0; Connection group: Bank_A Attributes: binfile_dir=/var/audit/audsys1;binfile_fsize=4M;binfile_minfree=1; hosts=audsys1 Connection group: Bank_B Attributes: binfile_dir=/var/audit/audsys2;binfile_fsize=4M;binfile_minfree=1; hosts=audsys2Example 4-10 Placing the ARS on a Different System From the KDC
In this example, the administrator places the ARS on a different system from the KDC. First, the administrator creates and configures the master KDC.
kserv # kdcmgr -a audr/admin -r EXAMPLE.COM create master
kserv # kadmin.local -p audr/admin
kadmin: addprinc -randkey \
audit/arstore.example.com@EXAMPLE.COM
kadmin: ktadd -t /tmp/krb5.keytab.audit \
audit/arstore.example.com@EXAMPLE.COM
After securely transmitting the /tmp/krb5.keytab.audit file to the ARS, arstore, the administrator moves the file to the correct location.
arstore # chown root:root krb5.keytab.audit arstore # chmod 600 krb5.keytab.audit arstore # mv krb5.keytab.audit /etc/krb5/krb5.keytab
Rather than rewrite the file, the administrator also has the option to use the ktutil command on the ARS to merge the KDC krb5.keytab.audit file with existing keys in the arstore 's /etc/krb5/krb5.keytab file.
Finally, the administrator generates keys on the audited system.
enigma # kclient .. Enter the Kerberos realm: EXAMPLE.COM .. KDC hostname for the above realm: kserv.example.com .. Will this client need service keys ? [y/n]: y