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 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 system that is sending audit records, 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(8) 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 8 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 8 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 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/[email protected] kadmin: ktadd audit/[email protected]
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
For example:
$ 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 and separates audit records by host on the ARS by creating two connection groups.
Audit files from the 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 the 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, set 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 27 Placing the ARS on a Different System From the KDC
In this example, the ARS is places on a different system from the KDC. First, create and configure the master KDC.
kserv# kdcmgr -a audr/admin -r EXAMPLE.COM create master kserv# kadmin.local -p audr/admin kadmin: addprinc -randkey \ audit/[email protected] kadmin: ktadd -k /var/user/root/krb5.keytab.audit \ audit/[email protected]
After securely transmitting the /tmp/krb5.keytab.audit file to the ARS, arstore, move 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, you also have 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, generate 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