This section describes items you should consider when using CA Access Control on UNIX endpoints.
This section contains the following topics:
The default installation location has changed in r12.0 and is as follows:
You can upgrade to CA Access Control r12.5 SP2 for UNIX from r12.5 SP1, r12.5, r12.0 SP1, r12.0, and r8 SP1.
If you install CA Access Control on a SLES 11 Linux s390x computer, install the J2SE Version 5.0 31-bit System z JRE on the computer before you install CA Access Control. The RPM package name for the JRE is ibm-java2-s390-jre-5.0-10.0.s390.rpm.
Valid values for the proc_bypass configuration setting in the SEOS_syscall section have changed in r12.5 SP2. The proc_bypass configuration setting specifies if CA Access Control bypasses file access checks when a file belongs to a process file system (/proc).
In earlier releases, the default value was 0 (do not bypass file access checks) and valid values were any sum of access types. In r12.5 SP2 and later, the default value is 1 (bypass file access checks) and valid values are 0 and 1 only. When you upgrade to r12.5 SP2 or later, the upgrade script replaces any nonzero value for this configuration setting with 1.
To use Message Queue functionality on Linux s390 and s390x endpoints, verify that J2SE version 5.0 or later is installed on the endpoint. Message Queue functionality lets you send report data to the Report Portal and audit data to CA Enterprise Log Manager.
Note: You may need to configure the java_home configuration setting in the accommon.ini file. For more information, see the Implementation Guide.
Valid on AIX
When CA Access Control is installed or uninstalled from an endpoint that UNAB is running on, the UNAB agent, uxauthd, is stopped and started.
Valid on AIX
If you set auth_login=pam in the seos section of the seos.ini file, CA Access Control uses PAM to authenticate users. CA Access Control uses the PAM API library during authentication, but AIX does not provide the PAM library in a shared library format that CA Access Control can easily link to. When CA Access Control attempts to use the PAM API it fails with an error "cannot find /usr/lib/libpam.o". To avoid this error, you must configure the CA Access Control PAM module.
To configure the CA Access Control PAM module on AIX
This archive contains the AIX PAM shared library (shr.o).
ar -xv libpam.a
mv shr.o libpam.o
This configuration setting instructs sepass to use the PAM interface to change passwords.
On Linux, if you recompile your kernel, you must copy the system.map file to the /boot directory to load the CA Access Control daemons.
By default, the TCP, CONNECT, and HOST classes are not active and the CA Access Control kernel module is not loaded into streams. Before you activate any of these classes, be sure that the streams module is enabled for network interception.
Note: Streams module is only available for systems that support streams.
To read the documentation for CA Access Control in print format (PDF files), you must install Adobe Reader 7.0.7 or later. You can download Adobe Reader from the Adobe website if it is not already installed on your computer.
Note: Adobe Reader is not available on HP-UX Itanium (IA64) and Red Hat Linux Itanium IA64.
You must load the CA Access Control kernel module for some utilities to use the CA Access Control kernel interface. These utilities include selogrd and selogrcd on most platforms.
On Red Hat Linux computers with a 2.4 kernel, to deny the RENAME authority you must also deny the READ authority.
If you want to use the SNMP extension of selogrd, and CA Access Control is not installed in the default location (/opt/CA/AccessControl), you must set an environment variable before running selogrd. The environment variables are as follows:
ACInstallDir is the directory where you installed CA Access Control.
To obtain failed login events from SSH, the SSH version you are using must be compiled and configured to support PAM.
If your version of SSH does not use PAM, CA Access Control cannot detect whether a user has violated the failed login rules.
CA Access Control PAM features that rely on identifying user login attempts (for example, segrace, serevu, and log audit records) do not work if the line "auth requisite" appears before the CA Access Control line "auth optional pam_module" in the operating systems's PAM configuration file.
If you want PAM to write user login attempts, the PAM configuration file should contain the line "auth required pam_module" instead of "auth requisite pam_module". If you specify the control-flag required and the module fails, it continues to next module. If you use the control-flag requisite and the module fails, it exits immediately and does not reach the CA Access Control line and so pam_module does not run.
Note: pam_module is the name of the PAM module file on your platform. For example, on Linux, this is pam_unix2.so.
To add information from the LDAP Directory Information Tree (DIT) to the user lookaside database that sebuildla creates (-n option), the computer must have LDAP v3 run-time support.
You cannot use telnet or rsh to log in to a computer if your PAM configuration file:
login account optional /usr/lib/security/libpam_unix.1
login account optional /usr/lib/security/pam_seos.sl
To fix this, comment out the CA Access Control line if you want PAM to use the "OTHER account..." line instead, or uncomment the operating system's line.
When you set selogrd to route audit records to SNMP listeners, you can use an SNMP community name that is different from the default name ("public"). To do this, use the following format in the selogrd.cfg configuration file:
Defines the SNMP gateway host name.
Defines the SNMP community name that matches the target SNMP environment.
The following syslog messages have been reduced to informational priority (INFO rather than ERROR):
syslog messages have been affected by the CA Access Control name change in r12.0.
Where messages contained the "eTrust AC" string before, they now contain the "CA Access Control" string.
If you use enterprise users (osuser_enabled is set to 1), CA Access Control does not consider any user as undefined.
Rules for the _undefined user are not relevant in this case.
If you do not use enterprise users (osuser_enabled is set to 0), users that are not defined in the CA Access Control database are included in rules that apply to all users (using the mask *).
If you want to exclude undefined users from rules that apply to all users, create a more specific rule for the _undefined user that defines the required access to users that are not defined in the database.
If you want to work with serevu, and root does not have the ADMIN attribute or terminal access to the local database, you should define the following:
eu _serevu admin logical authorize terminal localTerminalName uid(_serevu) access(a) er specialpgm $ACDIR/bin/serevu seosuid(_serevu ) unixuid(root)
If you want serevu to send commands to the PMD (which, you can configure in serevu.cfg) and root is not defined on the PMD with the ADMIN attribute or with terminal access, you should define the following on the PMD and all of its subscribers:
eu _serevu logical authorize admin USER uid(_serevu) access(a) # The following line can be executed on the master PMD only authorize terminal localTerminalName uid(_serevu) access(a)
You should use gmake (GNU make) and not make to compile the API samples.
By default x86_64 Linux operating systems are not installed with the 32bit compatibility libraries. CA Access Control endpoint requires that the library libstdc++.so.6 exists under the usr/lib directory.
Verify that this library exists on the endpoint before you install CA Access Control.
This release of CA Access Control uses CAPKI 4.1 instead of ETPKI 3.2. The upgrade is automatic and keeps the ETPKI 3.2 libraries on your computer if they are used by other components. To determine whether other components are using ETPKI 3.2, CAPKI uses an internal reference count. When this count equals 0, ETPKI 3.2 uninstalls on upgrade.
CAPKI 4.1 provides a static library (libcapki_stub.lib for Windows, libcapki_stub.a for UNIX) that acts as a stub for the CAPKI interface and removes the need to dynamically load the library.
CA Access Control takes into account resource group ownership when checking user authorization to a resource. This behavior was introduced in r12.0. In earlier releases, the authorization process considered only the resource's owner.
For example, you define a FILE resource with a default access of none and no owner that is a member to a GFILE resource with a named owner. In CA Access Control r12.0 and later, the named group owner has full access to the file. In earlier releases, nobody has access to the file.
Unicenter integration is not supported on HP-UX Itanium (IA64) and Red Hat Linux Itanium IA64.
CA Access Control generates at startup the login session ID that it adds to audit log records. This means that a logged on user gets a different session ID within the same terminal session every time CA Access Control restarts. The session ID remains the same only within the same CA Access Control session.
Policy Manager is not included in r12.0 and later releases. The web-based CA Access Control Endpoint Management replaces this interface. The r8 SP1 Policy Manager is upward compatible with new CA Access Control endpoints. However, it supports pre-r12.0 features only.
When you setup a new Solaris zone, there are several post installation steps you must complete before you can propagate CA Access Control and UNAB to the new zone.
Note: For more information on setting up a new zone correctly, see Sun's System Administration Guide: Solaris Containers--Resource Management and Solaris Zones, which is available at the Sun Microsystems Documentation website.
The Security Administrator Motif interface is not included in r12.0 and later releases. The web-based CA Access Control Endpoint Management replaces this interface. The r8 SP1 Security Administrator is upward compatible with new CA Access Control endpoints. However, it supports pre-r12.0 features only.
Note: As the Security Administrator is not provided, the CAeACGUI native package is not supplied. Also, the -admin option of the install_base script is no longer available.
By default, CA Access Control protects audit log backup files if you configure settings to keep timestamped backups. This is the same default protection that the size-triggered audit backup file receives. To remove these files, you need to set permissive rules in the database.
The Report Agent daemon and the PUPM Agent are not supported on Linux Itanium (IA64). CA Access Control does not install the Report Agent and the PUPM Agent on these operating systems regardless of the selections you make during installation.
The symmetric encryption key is embedded in the libcryptscr.so.125.0 library. If you patch this library, the patch may restore the default CA Access Control encryption key. To avoid communication problems, you must always change the encryption key immediately after you apply a patch to libcryptscr.so.125.0.
To change the key, navigate to /opt/CA/AccessControl/lib/libcryptscr.so.125.0 and run sechkey as follows, where previous_key is the encryption key that you used before the patch:
sechkey d previous_key
sechkey replaces the default encryption key with the previous key.
The SYSTEM_AAUDIT_MODE property in the SEOS class specifies the default audit mode for users and enterprise users (systemwide audit mode). When you upgrade to CA Access Control r12.5 SP1 or later, CA Access Control sets the value of the SYSTEM_AAUDIT_MODE property to the value of the DefaultAudit configuration setting in the [newusr] section of the lang.ini file.
Note: The default value of both the SYSTEM_AAUDIT_MODE property and the DefaultAudit configuration setting is Failure LoginSuccess LoginFailure.
Before r12.0 SP1 CR1, the default audit mode was None for the following accessors:
Note: If you use enterprise users, CA Access Control does not consider any users as undefined. Properties of the _undefined user are not relevant in this case.
From r12.0 SP1 CR1, the default audit mode for these accessors is Failure, LoginSuccess, and LoginFailure. To retain earlier behavior, set the value of the AUDIT property to None for these users.
If you have a GROUP record that has two functions:
From r12.0 SP1 CR1 onwards, the GROUP record also defines the audit policy for the second set of users. To avoid problems that this behavior change may cause, create a separate GROUP for the second set of users.
CA Access Control supports a SAN (storage area network) environment when you install CA Access Control on a local file system and use it to protect files on a SAN, when the SAN is accessible from the single host where CA Access Control is installed.
Note: If the SAN is accessible from multiple hosts, install CA Access Control on each host that can access the SAN and use each installation to protect files on the SAN.
If the SAN is accessible from multiple hosts and CA Access Control is installed on the SAN, and you want to install CA Access Control from a different host to the same location on the SAN, consider the following before you begin:
Note: CA Access Control behavior is unspecified when you install it on a SAN and it is executed from multiple connected hosts.
CA Access Control runs in an IPv4-only environment, an IPv6-only environment, or a mixed environment of both IPv4 and IPv6.
Note: selogrd and selogrcd will not work in IPv6-only environments.
CA Access Control does not currently support network access controls on IPv6 networks. This affects the HOST, CONNECT and TCP classes.
You can specify IP addresses to CA Access Control in IPv6 format, except that the mask and match feature of HOSTNET class records requires IPv4 format addresses.
You cannot upgrade to CA Access Control r12.5 SP2 from CA Access Control for UNIX r5.3 and CA Access Control for Windows r5.2. To upgrade to CA Access Control r12.5 SP2, we recommend that you first install CA Access Control r8.0 SP1 CR1 and then install CA Access Control r12.5 SP2.
|Copyright © 2010 CA. All rights reserved.||Email CA about this topic|