3.3 Post-installation steps

After you successfully install LiveCycle, it is important to periodically maintain the environment from a security perspective.

The following section describes in detail the different tasks that are recommended to secure the deployed LiveCycle server.

3.3.1 LiveCycle security

The following recommended settings apply to the LiveCycle server outside of the administrative web application. To reduce the security risks to the server, apply these settings immediately after installing LiveCycle.

Security patches

There is an increased risk that an unauthorized user might gain access to the application server if vendor security patches and upgrades are not applied in a timely fashion. Test security patches before you apply them to production servers to ensure compatibility and availability of LiveCycle applications. Also, create policies and procedures to check for and install patches on a regular basis. LiveCycle updates are on the Enterprise products download site.

Service accounts (JBoss turnkey on Windows only)

LiveCycle installs a service, by default, by using the LocalSystem account. The built-in LocalSystem user account has a high level of accessibility; it is part of the Administrators group. If a worker-process identity runs as the LocalSystem user account, that worker process has full access to the entire system.

To run the application server on which LiveCycle is deployed, using a specific non-administrative account, follow these instructions:

  1. In the Microsoft Management Console (MMC), create a local user for the LiveCycle server service to log in as:

    • Select User cannot change password.

    • On the Member Of tab, ensure that the Users group is listed.

    Note: You cannot change this setting for PDF Generator.
  2. Select Start > Settings > Administrative Tools > Services.

  3. Double-click the JBoss for Adobe LiveCycle 10 and stop the service.

  4. On the Log On tab, select This Account, browse for the user account you created, and enter the password for the account.

  5. In the MMC, open Local Security Settings and select Local Policies > User Rights Assignment.

  6. Assign the following rights to the user account that the LiveCycle server is running under:

    • Deny log on through Terminal Services

    • Deny log on locally

    • Log on as Service (should be already set)

  7. Give the new user account the Read & Execute, List Folder Contents, and Read permissions for the LiveCycle web content directories item.

  8. Start the application server.

Disabling the Configuration Manager bootstrap servlet

Configuration Manager made use of a servlet deployed on your application server to perform bootstrapping of the LiveCycle database. Because Configuration Manager accesses this servlet before configuration is complete, access to it has not been secured for authorized users, and it should be disabled after you have successfully used Configuration Manager to configure LiveCycle.

  1. Unzip the adobe-livecycle-[appserver].ear file.

  2. Open the META-INF/application.xml file.

  3. Search for the adobe-bootstrapper.war section:

    <!-- bootstrapper start --> 
    <module id="WebApp_adobe_bootstrapper"> 
        <web> 
            <web-uri>adobe-bootstrapper.war</web-uri> 
            <context-root>/adobe-bootstrapper</context-root> 
        </web> 
    </module> 
    <module id="WebApp_adobe_lcm_bootstrapper_redirector"> 
        <web> 
            <web-uri>adobe-lcm-bootstrapper-redirector.war</web-uri> 
            <context-root>/adobe-lcm-bootstrapper</context-root> 
        </web> 
    </module> 
    <!-- bootstrapper end-->
  4. Comment out the adobe-bootstrapper.war and the adobe-lcm-bootstrapper-redirectory. war modules as follows:

    <!-- bootstrapper start --> 
    <!-- 
    <module id="WebApp_adobe_bootstrapper"> 
        <web> 
            <web-uri>adobe-bootstrapper.war</web-uri> 
            <context-root>/adobe-bootstrapper</context-root> 
        </web> 
    </module> 
    <module id="WebApp_adobe_lcm_bootstrapper_redirector"> 
        <web> 
            <web-uri>adobe-lcm-bootstrapper-redirector.war</web-uri> 
            <context-root>/adobe-lcm-bootstrapper</context-root> 
        </web> 
    </module> 
    --> 
    <!-- bootstrapper end-->
  5. Save and close the META-INF/application.xml file.

  6. Zip the EAR file and redeploy it to the application server.

  7. Type the URL into a browser to test the change and ensure that it no longer works.

Lockdown remote access to the Trust Store

Configuration Manager lets you upload a Reader Extensions 10 credential to the LiveCycle trust store. This means that access to the Trust Store Credential Service over remote protocols (SOAP and EJB) has been enabled by default. This access is no longer necessary after you have uploaded the Rights credential using Configuration Manager or if you decide to use the Administration Console later to manage credentials.

You can disable remote access to all of the Trust Store services by following the steps in the section 4.1 Disabling non-essential remote access to services.

Disable all non-essential anonymous access

Some LiveCycle server services have operations that may be invoked by an anonymous caller. If anonymous access to these services is not required, disable it by following the steps in 4.2 Disabling non-essential anonymous access to services.

3.3.1.1 Change the default administrator password

When LiveCycle is installed, a single default user account is configured for user Super Administrator/ login-id Administrator with a default password of password. You should immediately change this password using the Configuration Manager.

  1. Type the following URL in a web browser:

    http://[host name]:[port]/adminui

    The default port number is one of these:

    JBoss: 8080

    WebLogic Server: 7001

    WebSphere: 9080.

  2. In the User Name field, type administrator and, in the Password field, type password.

  3. Click Settings > User Management > Users and Groups.

  4. Type administrator in the Find field, and click Find.

  5. Click Super Administrator from the list of users.

  6. Click Change Password on the Edit User page.

  7. Specify the new password and click Save.

In addition, it is recommended to change the default password for CRX Administrator by performing the following steps:

  1. Log into http://[host name]:[port]/lc/libs/granite/security/content/admin.html using the default username/password.

  2. Type Administrator in the search field and click Go.

  3. Select Administrator from the search result and click the Edit icon at the bottom-right of the user interface.

  4. Specify the new password in the New Password field and the old password in the Your Password field.

  5. Click the Save icon at the bottom-right of the user interface.

3.3.1.2 Disable WSDL generation

Web Service Definition Language (WSDL) generation should be enabled only for development environments, where WSDL generation is used by developers to build their client applications. You may choose to disable WSDL generation in a production environment to avoid exposing a service’s internal details.

  1. Type the following URL in a web browser:

    http://[host name]:[port]/adminui
  2. Click Settings > Core System Settings > Configurations.

  3. Uncheck Enable WSDL and click OK.

3.3.1.3 Restricting LiveCycle Content Services (deprecated) user data check-in quotas

Note: Adobe is migrating Adobe® LiveCycle® Content Services ES customers to the Content Repository built on the modern, modular CRX architecture, acquired during the Adobe acquisition of Day Software. The Content Repository is provided with LiveCycle Foundation and is available as of the LiveCycle ES4 release.

By default, Content Services does not restrict on the amount of data a user can check in to the server at any one time. Large amounts of data are potentially threatening to the system as they leave the system without the resources to perform other operations. This situation can cause a denial of service to other incoming processes. Use JVM arguments to enable quota management in Content Services.

Important: These JVM arguments must be passed prior to synchronizing the users. This user quota cannot be modified once the users have been synchronized.

3.3.1.3.1 Enable quota management on Content Services:

On JBoss

  1. Navigate to the [jboss root]/bin directory and open the startup script in a text editor:

    • (Windows) run.bat

    • (Linux and UNIX) run.sh

  2. Add the following properties below the Set JAVA_OPTS argument:

    -Dsystem.usages.enableQuotaSize=true -Dsystem.usages.quota=[size in KB]

  3. Save and close the file.

  4. Restart the JBoss server before synchronizing the users.

On WebLogic

  1. Access the WebLogic Server Administration Console, type http://[host name]:[port]/console in the URL line of a web browser, where [port] is the non-secure listening port. By default, this port value is 7001.

  2. On the login screen, type your WebLogic user name and password and click Log In.

  3. Under Change Center, click Lock & Edit.

  4. Under Domain Structure, click Environment > Servers and, in the right pane, click the managed server name.

  5. In the Settings for Server pane, click the Configurationtab > Server Start tab.

  6. In the Arguments box, add the following arguments separated by a space delimiter:

    -Dsystem.usages.enableQuotaSize=true 
    -Dsystem.usages.quota=[size in KB]
  7. Click Save and then click Activate Changes.

  8. Restart the WebLogic server before synchronizing the users.

On WebSphere

  1. In the WebSphere Administrative Console navigation tree, do the following task for your application server:

    (WebSphere 6.x) Click Servers > Application servers

    (WebSphere 7.x) Click Servers > ServerTypes > WebSphere application servers

  2. Click the server name in the right pane.

  3. Under Server Infrastructure, click Java and Process Management > Process Definition.

  4. Under Additional Properties, click Java Virtual Machine.

  5. In the Generic JVM arguments box, add -Dsystem.usages.enableQuotaSize=true and -Dsystem.usages.quota=<size in KB>, separated by commas, to the existing properties.

  6. Click OK or Apply, and then click Save directly to the master configuration.

  7. Restart the WebSphere server before synchronizing the users.

3.3.2 Application server security

The following table describes some techniques for securing your application server after the LiveCycle application is installed.

Issue

Description

Application server administrative console

After you install, configure, and deploy LiveCycle on your application server, you should disable access to the application server administrative consoles. See your application server documentation for details.

Application server cookie settings

Application cookies are controlled by the application server. When deploying the application, the application server administrator can specify cookie preferences on a server-wide or application-specific basis. By default, the server settings take preference.

All session cookies generated by your application server should include the HttpOnly attribute. For example, when using the JBoss Application Server, you can modify the SessionCookie element to httpOnly="true" in the deploy/jbossweb.sar/context.xml file.

You can restrict cookies to be sent using HTTPS-only. As a result, they are not sent unencrypted over HTTP. Application server administrators should enable secure cookies for the server on a global basis. For example, when using the JBoss Application Server, you can modify the connector element to secure=true in the server.xml file.

See your application server documentation for more details on cookie settings.

Directory browsing

When someone requests a page that does not exist or requests the name of a director (the request string ends with a forward slash (/)), the application server should not return the contents of that directory. To prevent this, you can disable directory browsing on your application server. You should do this for the Administration Console application and for other applications running on your server.

For JBoss, set the value of the listings initialization parameter of the DefaultServlet property to false in the web.xml file, as shown by this example:

<servlet>

<servlet-name>default</servlet-name>

<servlet-class>

org.apache.catalina.servlets.DefaultServlet

</servlet-class>

<init-param>

<param-name>listings</param-name>

<param-value>false</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

For WebSphere, set the directoryBrowsingEnabled property in the ibm-web-ext.xmi file to false.

For WebLogic, set the index-directories properties in the weblogic.xml file to false, as shown by this example:

<container-descriptor>

<index-directory-enabled>false

</index-directory-enabled>

</container-descriptor>

3.3.3 Using JMX Console on JBoss

When the Java Management Extensions (JMX) console is installed with JBoss, URLs can be constructed for use as cross-site scripting (XSS) exploits that can reveal sensitive information about your system.

If you installed LiveCycle by using the turnkey method and are using the version of JBoss that was included with the turnkey installation, the JBoss JMX Console is removed by default to ensure that security risks are minimized. However, if you need to use the JBoss JMX Console, reinstall it by following this procedures.

  1. Download a copy of JBoss 4.2.0 (or later) from JBoss.org.

  2. Stop the JBoss Application Server.

  3. From the zipped archive file you downloaded, extract the files from [JBoss root]/deploy/jmx-console.war/.

  4. Place the jmx-console.war/... files in the deploy directory of the JBoss installation directory.

  5. Restart JBoss.

  6. Go to the following URL to ensure that the JBoss JMX Console is available:

    http://localhost:8080/jmx-console

3.3.4 Database security

When securing your database, you should implement the measures described by your database vendor. You should allocate a database user with the minimum required database permissions granted for use by LiveCycle. For example, do not use an account with database administrator privileges.

On Oracle, the database account that you use needs only the CONNECT, RESOURCE, and CREATE VIEW privileges. For similar requirements on other databases, see Preparing to Install LiveCycle (Single Server).

3.3.4.1 Configuring integrated security for SQL Server on Windows for JBoss

  1. Modify [JBOSS_HOME]\server\all\deploy\adobe-ds.xml to add integratedSecurity=true to the connection URL, as shown in this example:

    jdbc:sqlserver://<serverhost>:<port>;databaseName=<dbname>;integratedSecurity=true
  2. Add the sqljdbc_auth.dll file to the Windows systems path on the computer that is running the application server. The sqljdbc_auth.dll file is located with the Microsoft SQL JDBC 1.2 driver installation (the default is [InstallDir]/sqljdbc_1.2/enu/auth/x86).

  3. Modify JBoss Windows service (JBoss for LiveCycle) property for Log On As from Local System to a login account that has LiveCycle database and a minimum set of privileges. If you are running JBoss from the command line instead of as a Windows service, you do not need to perform this step.

  4. Set Security for SQL Server from Mixed mode to Windows Authentication only.

3.3.4.2 Configuring integrated security for SQL Server on Windows for WebLogic

  1. Start the WebLogic Server Administration Console by typing the following URL in the URL line of a web browser:

    http://[host name]:7001/console
  2. Under Change Center, click Lock & Edit.

  3. Under Domain Structure, click [base_domain]> Services > JDBC > Data Sources and, in the right pane, click IDP_DS.

  4. On the next screen, on the Configuration tab, click the ConnectionPool tab and, in the Properties box, type integratedSecurity=true.

  5. Under Domain Structure, click [base_domain] > Services > JDBC > Data Sources and, in the right pane, click RM_DS.

  6. On the next screen, on the Configuration tab, click the Connection Pool tab and, in the Properties box, type integratedSecurity=true.

  7. Add the sqljdbc_auth.dll file to the Windows systems path on the computer that is running the application server. The sqljdbc_auth.dll file is located with the Microsoft SQL JDBC 1.2 driver installation (the default is [InstallDir]/sqljdbc_1.2/enu/auth/x86).

  8. Set Security for SQL Server from Mixed mode to Windows Authentication only.

3.3.4.3 Configuring integrated security for SQL Server on Windows for WebSphere

On WebSphere, you can configure integrated security only when you use an external SQL Server JDBC driver, not the SQL Server JDBC driver that is embedded with WebSphere.

  1. Log in to the WebSphere Administrative Console.

  2. In the navigation tree, click Resources > JDBC > Data Sources and, in the right pane, click IDP_DS.

  3. In the right pane, under Additional Properties, click Custom Properties, and then click New.

  4. In the Name box, type integratedSecurity and, in the Value box, type true.

  5. In the navigation tree, click Resources > JDBC > Data Sources and, in the right pane, click RM_DS.

  6. In the right pane, under Additional Properties, click Custom Properties, and then click New.

  7. In the Name box, type integratedSecurity and, in the Value box, type true.

  8. On the computer where WebSphere is installed, add the sqljdbc_auth.dll file to the Windows systems path (C:\Windows). The sqljdbc_auth.dll file is in the same location as the Microsoft SQL JDBC 1.2 driver installation (default is [InstallDir]/sqljdbc_1.2/enu/auth/x86).

  9. Select Start > Control Panel > Services, right-click the Windows service for WebSphere (IBM WebSphere Application Server <version> - <node>) and select Properties.

  10. In the Properties dialog box, click the Log On tab.

  11. Select This Account and provide the information required to set the login account you want to use.

  12. Set Security on SQL Server from Mixed mode to Windows Authentication only.

3.3.5 Protecting access to sensitive content in the database

The LiveCycle database schema contains sensitive information about system configuration and business processes and should be hidden behind the firewall. The database should be considered within the same trust boundary as the LiveCycle server. To guard against information disclosure and theft of business data, the database must be configured by the database administrator (DBA) to allow access only by authorized administrators.

As an added precaution, you should consider using database vendor-specific tools to encrypt columns in tables that contain the following data:

  • Rights Management Document Keys

  • Trust Store HSM PIN encryption key

  • Local User Password Hashes

For information about vendor-specific tools, see 2.1.3 Database security information .

3.3.6 LDAP security

A Lightweight Directory Access Protocol (LDAP) directory is typically used by LiveCycle as a source for enterprise user and group information, and a means to perform password authentication. You should ensure that your LDAP directory is configured to use Secure Socket Layer (SSL) and that LiveCycle is configured to access your LDAP directory using its SSL port.

3.3.6.1 LDAP denial of service

A common attack using LDAP involves an attacker deliberately failing to authenticate multiple times. This forces the LDAP Directory Server to lock out a user from all LDAP-reliant services.

You can set the number of failure attempts and subsequent lock-out time that LiveCycle implements when a user repeatedly fails to authenticate to LiveCycle. In Administration Console, choose low values. When selecting the number of failure attempts, it is important to understand that after all attempts are made, LiveCycle locks out the user before the LDAP Directory Server does.

3.3.6.2 Set automatic account locking

  1. Log in to Administration Console.

  2. Click Settings > User Management > Domain Management.

  3. Under Automatic Account Locking Settings, set Maximum Consecutive Authentication Failures to a low number, such as 3.

  4. Click Save.

3.3.7 Auditing and logging

The proper and secure use of application auditing and logging can help ensure that security and other anomalous events are tracked and detected as quickly as possible. Effective use of auditing and logging within an application includes such items as tracking successful and failed logins, as well as key application events such as the creation or deletion of key records.

You can use auditing to detect many types of attacks, including these:

  • Brute force password attacks

  • Denial of service attacks

  • Injection of hostile input and related classes of scripting attacks

This table describes auditing and logging techniques you can use to reduce your server’s vulnerabilities.

Issue

Description

Log file ACLs

Set appropriate LiveCycle log file access control lists (ACLs).

Setting the appropriate credentials helps prevent attackers from deleting the files.

The security permissions on the log file directory should be Full Control for Administrators and SYSTEM groups. The LiveCycle user account should have Read and Write permissions only.

Log file redundancy

If resources permit, send logs to another server in real time that is not accessible by the attacker (write only) by using Syslog, Tivoli, Microsoft Operations Manager (MOM) Server, or another mechanism.

Protecting logs this way helps prevent tampering. Also, storing logs in a central repository aids in correlation and monitoring (for example, if multiple LiveCycle servers are in use and a password-guessing attack is taking place across multiple computers where each computer is queried for a password).

3.3.8 LiveCycle Unix system library dependencies

The following information is intended to help you plan for a LiveCycle deployment on a UNIX environment.

3.3.8.1 Convert PDF service

The Convert PDF service that is part of LiveCycle requires the following minimum system libraries:

Linux

/lib/ 
    libdl.so.2 (0x00964000) 
    ld-linux.so.2 (0x007f6000) 
/lib/tls/ 
    libc.so.6 (0x00813000)     
    libm.so.6 (0x0093f000) 
    libpthread.so.0 (0x00a5d000) 
/usr/lib/libz.so.1 (0x0096a000) 
/gcc410/lib/ 
    libgcc_s.so.1 (0x00fc0000) 
    libstdc++.so.6 (0x00111000)

Solaris

/usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 
/usr/lib/ 
    libc.so.1 
    libdl.so.1 
    libintl.so.1 
    libm.so.1 
    libmp.so.2 
    libnsl.so.1 
    libpthread.so.1 
    libsocket.so.1 
    libstdc++.so.6  
    libthread.so.1

AIX

/usr/lib/ 
    libpthread.a(shr_comm.o) 
    libpthread.a(shr_xpg5.o) 
    libc.a(shr.o) 
    librtl.a(shr.o) 
    libpthreads.a(shr_comm.o) 
    libcrypt.a(shr.o) 
/aix5.2/lib/gcc/powerpc-ibm-aix5.2.0.0/4.1.0/libstdc++.a(libstdc++.so.6) 
/aix5.2/lib/gcc/powerpc-ibm-aix5.2.0.0/4.1.0/libgcc_s.a(shr.o)

3.3.8.2 XMLForms

XMLForms requires the following minimum system libraries:

Linux

/lib/ 
    libdl.so.2 
    libpthread.so.0 
    libm.so.6 
    libgcc_s.so.1 
    libc.so.6 
    librt.so.1 
    ld-linux.so.2 
/usr/X11R6/lib/ 
    libX11.so.6

Solaris

/usr/lib/ 
    libdl.so.1 
    libpthread.so.1 
    libintl.so.1 
    libsocket.so.1 
    libnsl.so.1 
    libm.so.1 
    libc.so.1 
    librt.so.1 
    libX11.so.4 
    libmp.so.2 
    libmd5.so.1 
    libscf.so.1 
    libaio.so.1 
    libXext.so.0 
    libdoor.so.1 
    libuutil.so.1 
    libm.so.2 
usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 
usr/platform/SUNW,Sun-Fire-V210/lib/libmd5_psr.so.1

AIX 6.1

/usr/lib/ 
    libpthread.a(shr_comm.o) 
    libpthread.a(shr_xpg5.o) 
    libc.a(shr.o) 
    librtl.a(shr.o) 
    libdl.a(shr.o) 
    libX11.a(shr4.o) 
    libiconv.a(shr4.o) 
    libpthreads.a(shr_comm.o) 
/unix 
    /usr/lib/libcrypt.a(shr.o) 
    /usr/lib/libIM.a(shr.o) 
    /usr/lib/libpthreads.a(shr_xpg5.o)

// Ethnio survey code removed