Running AEM in Production Ready Mode

With AEM 6.1, Adobe introduces the new "nosamplecontent" runmode aimed at automating the steps required to prepare an AEM instance for deployment in a production environment.
The new runmode will not only automatically configure the instance to adhere to the security best practices described in the security checklist, but will also remove all the sample geometrixx applications and configurations in the process.
Note:
Since, due to practical reasons, the AEM Production Ready Mode will only cover a majority of tasks needed to secure an instance, it is highly recommended you consult the Security Checklist before going live with your production environment.
Also, note that running AEM in Production Ready Mode will effectively disable access to CRXDE Lite. If you need it for debugging purposes, see Enabling CRXDE Lite in AEM.
chlimage_1
In order to run AEM in production ready mode all you need to do is add the nosamplecontent via the -r runmode switch to your existing startup arguments:
1
java -jar aem-quickstart.jar -r nosamplecontent
For example, you can use the production ready to launch an author instance with MongoDB persistence like this:
1
java -jar aem-quickstart.jar -r author,crx3,crx3mongo,nosamplecontent -Doak.mongo.uri=mongodb://remoteserver:27017 -Doak.mongo.db=aem-author

Changes part of the Production Ready Mode

More specifically, the following configuration changes will be performed when AEM is ran in production ready mode:
  1. The CRXDE Support bundle (com.adobe.granite.crxde-support) is disabled by default in production ready mode. It can be installed at any time from the Adobe public Maven repository. Version 3.0.0 is required for AEM 6.1.
  2. The Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav) bundle will only be available on author instances.
  3. Newly created users will be required to change the password on the first login. This does not apply to the admin user.
  4. Generate debug info is disabled for the Apache Java Script Handler.
  5. Mapped content and Generate debug info are disabled for the Apache Sling JSP Script Handler.
  6. The Day CQ WCM Filter is set to edit on author and disabled on publish instances.
  7. The Adobe Granite HTML Library Manager is configured with the following settings:
    1. Minify: enabled
    2. Debug: disabled
    3. Gzip: enabled
    4. Timing: disabled
  8. The Apache Sling GET Servlet is set to support secure configurations by default, as follows:
ConfigurationAuthorPublish
TXT renditiondisableddisabled
HTML renditiondisableddisabled
JSON renditionenabledenabled
XML renditiondisableddisabled
json.maximumresults1000100
Auto Indexdisableddisabled

How to Audit User Management Operations in AEM

Solution

AEM has introduced the ability to log permission changes so they can be audited at a later time.
The enhancement allows for the auditing CRUD (Create, Read, Update, Delete) actions on permissions and group assignments of users. More specifically, it will log:
  • A new user getting created
  • A user being added to a group
  • Permission changes of an existing user or group
By default, the entries will be written to the error.log file. To make monitoring easier, it is recommended that they be redirected to a separate log file. More info on how to do this in the paragraph below.

Redirecting the output to a separate log file

In order to redirect the logging output to a separate log file, you'll need to create a new Apache Sling Logging Loggerconfiguration. We'll use useraudit.log as the name of the separate file in the example below.
  1. 1. Go to the Web Console by browsing to http://serveraddress:serverport/system/console/configMgr
  2. 2. Search for Apache Sling Logging Logger. Then, press the "+" in the right hand side of the entry to create a new factory configuration.
  3. 3. Create the following configuration:
    • Log Level: Information
    • Log File: logs/useraudit.log
    • Message Pattern: leavel default
    • Logger: com.adobe.granite.security.user.internal.audit, com.adobe.granite.security.user.internal.servlets.AuthorizableServlet
    4. In order to enter both loggers into the Logger field, you need to enter the name of the first, then create another field by pressing the "+" button and entering the name of the second logger.

  4. Sample out of useraudit.log file:
  5. 1. 19.05.2017 15:21:34.419 *INFO* [0:0:0:0:0:0:0:1 [1495196494417]
  6. POST /home/groups/d/dGf7f7vGrZRLs6HS3AK-.rw.html HTTP/1.1]
  7. com.adobe.granite.security.user.internal.audit.AuditAuthorizableAction Group 'group1' was removed
  8. 2. 19.05.2017 15:21:34.419 *INFO* [0:0:0:0:0:0:0:1 [1495196494417]
  9. POST /home/groups/d/dGf7f7vGrZRLs6HS3AK-.rw.html HTTP/1.1]
  10. com.adobe.granite.security.user.internal.servlets.AuthorizableServlet Delete Group 'group1' operation initiated by User 'admin' (administrator)

Configure/Setup the Admin Password on Installation in AEM 6.3

Overview

Since version 6.3, AEM allows the admin password to be set using the command line when installing a new instance.
With earlier versions of AEM, the password for the admin account, along with the password for various other consoles had to be changed after installation.
This feature adds the facility of setting a new administrator password for the repository and the Servlet Engine during the installation of an AEM instance, thus eliminating the need to do it manually afterwards.
Caution:
Please note that feature does not cover the Felix Console, for which the password needs to be changed manually. For more information, see the relevant Security Checklist section.

How Do I Use It?

This feature will trigger automatically if you choose to install AEM via the command line, as opposed to double clicking the JAR from a filesystem explorer.
The general synthax for running an AEM instance from the command line is:
1
java -jar aem6.3.jar
Upon running the instance from the command line, you will be presented with the option to change the admin password during the installation process:
chlimage_1
Note:
The prompt to change the admin password will only appear during the installation of a new AEM instance.

Using the -nointeractive Flag

You can also choose to specify the password from a properties file. This is done by using the -nointeractive flag combined with the the -Dadmin.password.file system property.
Below is an example:
1
java -Dadmin.password.file =/path/to/passwordfile.properties -jar aem6.3.jar -nointeractive
The password inside the passwordfile.properties file needs to have the below format:
1
admin.password = 12345678
Note:
If you simply use the -nointeractive parameter without the -Dadmin.password.file system property, AEM will use the default admin password without asking you to change it, essentially replicating behaviour from earlier versions. This non interactive mode can be used for automated installations using the command line in an installation script.