In pre-8.0 releases, only one user can have auditing privileges. Initially, the primary administrator has Auditor privileges. Once this admin creates another user who has access to the auditing realm, the admin loses access to the realm. The admin cannot delete the audit user or remove the auditing realm from that user. (Starting in Release 7.0, during setup and configuration, the admin user retains access to the auditing realm until the CommitChanges command is sent. In earlier releases, it is recommended to postpone defining the auditor user until after sending CommitChanges.)
Starting in Release 8.0, all administrators have implicit auditing privileges by default without being in Auditor Realm and can manipulate the audit log. Assigning an explicit Auditor role removes the Auditor privileges from the admin users. The admin cannot delete the audit user or remove the auditing realm from that user.
See the following use cases for creating users: Add a Digest User, Add a Kerberos User, Create a Digest User Using Role-Based Authorization, and Create a Kerberos User Using Role Based Authorization.
If the Auditor (the user with access to the Auditing realm) relinquishes access to the Auditing realm:
• In pre-8.0 releases the access reverts back to the primary administrator.
• From Release 8.0, access reverts back to all administrators.
Using the role-based authorization methods, an Auditor can also delete his own ACL entry.
An Intel AMT “user” can be defined by an Active Directory SID (also known as a Kerberos user). The SID may define an Active Directory group. If this ACL entry was granted Auditor privileges, then all users in that group can access audit log functions. The individual with auditing responsibilities should control who is in this group to assure audit log integrity. A member of this group can remove audit privileges from the group.
An Auditor automatically has access to the following realms and an administrator cannot remove permissions to them:
Auditor Realm Privilege
The Auditor can perform the following actions from the AUDIT_LOG_REALM:
• Establish an audit log policy by defining which events should be logged
• Define a storage policy that states the conditions under which an event is allowed to overwrite entries in the log when the log is full
• Set the certificate chain and key used to generate an audit log signature when the Auditor requests an export of a signature
• Enable/disable the audit log
• Clear the audit log
• Lock/unlock the audit log
• Request an audit log signature
User Access Control Realm Privilege
Once an Auditor has been defined by giving a user access of the audit realm, the user can also manage his ACL entry with the commands in the User Access Control Realm. An Auditor can change his digest password, and drop the Auditor privilege. In an environment where Digest authentication is used, an Auditor should change his password using the command in this realm as soon as he has Auditor permission. See Update a User ACL Entry to change a Digest user’s password or to drop Auditor privilege. Alternatively, see Update User (Digest/Kerberos) Privileges using role-based methods (see Additional Information there).
General Info Realm Privilege
The Auditor, and any other user with General Info permission, can read the audit log policy, the audit log status, and the audit log itself.
Copyright © 2006-2022, Intel Corporation. All rights reserved.