WebLogic boot.properties: Start Servers Without the Password Prompt

WebLogic boot.properties cover: server and key

In a production-mode WebLogic domain, starting a server with startWebLogic.sh prompts for the administrator user name and password every time. I ran an OID domain on WebLogic 12.2.1.4 and started both the Administration Server and the Managed Servers with the start scripts (startWebLogic.sh and startManagedWebLogic.sh) rather than Node Manager, so that prompt got in the way every time a server had to run in the background or come back after a reboot. The file that answers the prompt for you is boot.properties, which Oracle’s documentation calls a boot identity file.

This post combines two notes I wrote in Notion in October 2024. In October 2026 I checked every point against the 12.2.1.4 and 14.1.2 editions of Oracle’s “Starting and Stopping Servers” guide; the behavior described here is the same in both. The original Python script hard-coded the password in plain text, so I replaced it with a shell script that asks for the password at run time.

Location and format

By default, a server reads boot.properties from the security directory under its own root directory. Each server in the domain can have a different file.

<DOMAIN_HOME>/servers/<SERVER_NAME>/security/boot.properties

# Example: the AdminServer and the OID Managed Server of an OID domain
/u01/oracle/config/domains/oid_domain/servers/AdminServer/security/boot.properties
/u01/oracle/config/domains/oid_domain/servers/wls_ods1/security/boot.properties

The file has two lines.

username=weblogic
password=<admin_password>
  • The user must exist in the Authentication provider of the default security realm and belong to a role that is allowed to start and stop servers.
  • Enter the values exactly as the account has them. My original note said the user name and password had to be lowercase; Oracle’s documentation says nothing of the kind, so I removed it.
  • The first time a server starts with this file, it reads the file and then overwrites it with an encrypted version of the user name and password.

Before you create it

  • Start the Administration Server at least once by hand. The first startup generates the security files a server needs before it can use a boot identity file, so enter the credentials at the prompt once.
  • Development-mode domains already have an encrypted file for the Administration Server, created by the Configuration Wizard. In production mode you create it yourself.
  • From 14.1.2, choosing production mode for a domain automatically turns on the stricter defaults of secured production mode. According to Oracle’s Securing a Production Environment (14.1.2), boot.properties behaves the same in secured production mode as in production mode: it isn’t created automatically, and you can create one yourself if your environment needs it.
  • Managed Servers started by Node Manager don’t need one. See “If you use Node Manager” below.

Create it by hand

DOMAIN_HOME=/u01/oracle/config/domains/oid_domain
SERVER_NAME=AdminServer
mkdir -p "$DOMAIN_HOME/servers/$SERVER_NAME/security"
vi "$DOMAIN_HOME/servers/$SERVER_NAME/security/boot.properties"
chmod 600 "$DOMAIN_HOME/servers/$SERVER_NAME/security/boot.properties"

Work as the OS account that runs WebLogic. The server overwrites the file with the encrypted version at startup, so that account must be able to write to it.

Create it with a script

If several servers are started from scripts, this script repeats the same steps for each one. It asks for the password instead of storing it, and it never overwrites an existing file.

#!/bin/bash
# Usage: ./create_boot_properties.sh <DOMAIN_HOME> <SERVER_NAME> [USERNAME]
set -euo pipefail
DOMAIN_HOME=${1:?DOMAIN_HOME required}
SERVER_NAME=${2:?SERVER_NAME required}
USERNAME=${3:-weblogic}
BOOT_DIR="$DOMAIN_HOME/servers/$SERVER_NAME/security"
BOOT_FILE="$BOOT_DIR/boot.properties"

[ -f "$DOMAIN_HOME/config/config.xml" ] || { echo "Not a domain directory: $DOMAIN_HOME"; exit 1; }
[ -e "$BOOT_FILE" ] && { echo "Already exists: $BOOT_FILE"; exit 0; }

read -rsp "Password for $USERNAME: " PASSWORD; echo
umask 077
mkdir -p "$BOOT_DIR"
printf 'username=%s\npassword=%s\n' "$USERNAME" "$PASSWORD" > "$BOOT_FILE"
unset PASSWORD
echo "Created: $BOOT_FILE (it is encrypted the next time the server starts)"

umask 077 makes the file readable and writable only by its owner (600) from the moment it is created. The original version had Python write a shell script and then run it; that extra layer isn’t needed, so I dropped it.

Check that it was encrypted

Start the server once, then open the file. If the plain-text values you typed have been replaced by encrypted strings, it worked. If the plain text is still there, the server either didn’t read the file (check the path and file name) or the server account couldn’t write to it. A server that can’t use its boot identity file shows the user name and password prompt and writes a message to its log.

Don’t copy it between servers

Oracle doesn’t support copying a boot identity file from one server’s root directory to another’s. With several servers, create a plain-text file for each one and let each server encrypt its own on startup. The one exception: a Managed Server that uses the same root directory as the Administration Server can use the Administration Server’s file.

If you use Node Manager

Managed Servers started by Node Manager don’t need a file you create. Node Manager encrypts the credentials it used to start the server, saves them in <DOMAIN_HOME>/servers/<SERVER_NAME>/data/nodemanager/boot.properties, and uses them for automatic restarts. security/boot.properties is for servers started from a script or with java weblogic.Server.

Use a file in another location

To use a file outside the default location, give its fully qualified path in the startup command.

-Dweblogic.system.BootIdentityFile=/secure/path/boot.AdminServer

Oracle’s example adds this option to JAVA_OPTIONS. Generated scripts such as setDomainEnv are overwritten during domain upgrades, though, so instead of editing them, put the option in <DOMAIN_HOME>/bin/setUserOverrides.sh (or setUserOverridesLate.sh, which runs after product defaults are set). Node Manager does not read setUserOverrides; for servers it starts, set the option in the server’s Server Start arguments in the Administration Console.

# <DOMAIN_HOME>/bin/setUserOverrides.sh
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.system.BootIdentityFile=/secure/path/boot.AdminServer"
export JAVA_OPTIONS

When a server won’t start after a password change

Changing the weblogic password does not update boot.properties. If the server log shows BEA-090402 “Authentication denied: Boot identity not valid” after a password change, the file still holds the old password.

  1. Rewrite the server’s security/boot.properties in plain text with the new password; it is encrypted again on the next start. The script above stops if the file exists, so move the old file aside first if you want to use it.
  2. Servers started by Node Manager can show the same error. In that case, check whether data/nodemanager/boot.properties still holds the old credentials.
  3. Start the server and confirm the file was encrypted again.

Security checklist

  • Keep the file at mode 600, owned by the WebLogic account. Even though it is encrypted, protect access to the whole domain directory and its backups.
  • Don’t pass the password with -Dweblogic.management.password in a startup script. Oracle advises against it because it leaves the password in the script in plain text.
  • If you don’t want the file to stay on disk, -Dweblogic.system.RemoveBootIdentity=true makes the server delete the file it started with. The next start will prompt again.

Summary

Start the Administration Server once by hand. Then, for each server you start from a script, create security/boot.properties in plain text and confirm it was encrypted on the next start. Node Manager handles the servers it starts. After a password change, update the file yourself.

For WebLogic and JVM settings in an OID domain, see Oracle Internet Directory Scaling Part 3: WebLogic & JVM Optimization. For a case where only the weblogic account signs in slowly, see OAS Sign-In Delays: When AD Users Are Fast but weblogic Is Slow.

Scroll to Top