Planning and Configuring HP-UX DCE 1.9

Chapter 2
About HP-UX DCE Version 1.9
Notes, Cautions and Warnings Regarding This Release
14
Support for POSIX 1003.1c Threads
CMA applications have to be migrated from Draft 4 of the POSIX threads standard to the final, ratified
1003.1c standard for kernel threads. This migration will result in source incompatibility, and it is
recommended that application developers plan for this transition. HP plans to preserve binary compatibility.
However, developers can prepare for this change as follows:
1. Isolate new threads API usage to macros or wrapper APIs.
2. Minimize the use of signals, and use only POSIX semantics when programming with signals.
For example, we recommend that threaded applications use only the functions sigaction(), sigprocmask(),
and sigwait().
HP-UX Integrated Login Utilities
Most systems will require the transfer of account information from /etc/passwd to the DCE Security
Registry before the system will be useful.
The script /usr/sbin/auth.adm is supplied to activate the integrated login utilities once your system has
been set up with the needed accounts. See Chapter 6 for more information about using the
/usr/sbin/auth.adm script.
Do not use the auth.adm script to activate the HP-UX Integrated login utilities until after you have set up the
accounts necessary for your site in the DCE security service registry.
The DCE Audit Service
The DCE Audit Service was first released with HP-UX DCE 1.4.x; the DCE Audit Service provides auditing
capabilities for DCE Security and Time services.
By default, all audit events are disabled (not logged). As part of the default DCE configuration start-up, the
DCEAUDITFILTERON environment variable is set. When set, the DCEAUDITFILTERON environment
variable specifies that audit event filtering must be utilized to enable logging the desired set of audit events.
To enable auditing, the auditd server process must be started on any system where auditing is desired. As
part of the standard DCE configuration start-up for auditd, a set of audit filters is specified for the Security,
DTS and auditd server processes. (You can modify these filters as necessary for your site.).
You will need to do some planning to determine the degree of audit proper for your site, and to allow for disk
space overhead for your audit logs. If you want to do some auditing, such as logging and tracking
modifications to the security registry database, audit filtering is highly recommended. By using audit
filtering, it is possible to change the types of events being audited dynamically, without needing to restart the
servers for the changes to take effect.
Administrators should periodically monitor the size of the Security audit logs on the Security server
machines. Each audit trail log consists of two files — the actual trail log file and the associated index file.
These logs are in:
• /var/opt/dce/security/sec_audit_trail
• /var/opt/dce/security/sec_audit_trail.md_index
Other older audit logs may also be present. These can be found under the same directory, but have a date and
time stamp format inserted into the name. As an example:
sec_audit_trail.1995-08-31-15-19-52sec_audit_trail.1995-08-31-15-19-52.md_index
For detailed information on the DCE Audit Service, see the OSF DCE Administration Guide and Reference.
For Audit Service configuration information see Chapter 5 of this manual.