Autoconfiguring dockerised Openfire

Chris102 · May 7, 2026, 11:31am

I’m trying to automatically configure Openfire as much as possible so less clicks = better in my case.
A thing I’m still struggling with is LDAP admin group configuration. This works fine when I use the web wizard on first boot. But I’m trying to not use that part.
So I created a custom openfire.xml with my settings for the sql database and ldaps in it and all is working well except I can only seem to put specific users from Active Directory as Admin users not whole groups.

Maybe using Groups for admins needs a different approach?

I also would like to configure the monitoring plugin without clicks. Installing is not a problem but after the install it still needs enabling in the web interface.

Is there a way to automate this?

The image I’m using is: Package openfire · GitHub Openfire 5.0.4

guus · May 9, 2026, 9:27am

Hi Chris! It sounds like you’re already well on your way!

To configure groups as admins, rather than individual users, you should not use admin.authorizedJIDs which is probably what you’re using now. It only supports individual users.

Instead, you want something like (I’m doing this from memory without testing) to configure Openfire to use group-based administrators:

provider.admin.className=org.jivesoftware.openfire.admin.GroupBasedAdminProvider

You should then be able to configure a group name like this:

provider.group.groupBasedAdminProvider.groupName=MyGroupOfSuperUsers

There are alternative approaches (which do not exactly cover what you’re asking) which may be of interest to you, too. These are documented here: Openfire: Separating Administrative Users Guide

For the monitoring plugin, exactly which ‘enabling’ are you referring to? Most configuration options can be set in openfire.xml (although I’m not quite sure if that works for every option for every plugin). In the end, those are stored as database values, so an alternative/hacky approach could be to preprovision your database.

Chris102 · May 11, 2026, 8:00am

Edit: I figured out that after creating the container using the openfire.xml below it did not work. However if I reboot the container after first creation the Active Directory group containing the admins are all able to log in. So issue solved.

As for the monitoring plugin I have to manually enable the archiving features after first boot(4 checked checkboxes on the print screen). I was indeed already looking into an Database initialize script/file to do this but maybe there is or was an easier way to automate this.

Thanks for your reply! I have been struggling to implement the advice you gave. Below I added my
current setup with the single admin user which is working fine. I also added the whole openfire.xml I used to try and implement the ldap group based admins.

When I use a non existing ldap group I get the following error in the openfire.log.
2026.05.11 08:13:32.411 ERROR [main]: org.jivesoftware.openfire.admin.GroupBasedAdminProvider - Unable to retrieve members of group ‘Admins’ - assuming no administrators

Then when using an existing group no errors are present in the openfire.log indicating to me that all is good, but I am not able to log into the admin console with a user from the used ldap group.

Single User Admin.

<provider>
    <user>
      <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
    </user>
    <auth>
      <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
    </auth>
    <group>
      <className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
    </group>
</provider>
    <admin>
    <authorizedUsernames>MY_ADMIN_LDAP_USERNAME</authorizedUsernames>
  </admin>

Group based admin.

<jive>
<autosetup>
        <run>true</run>
        <locale>en</locale>
        <connectionProvider>
            <className>org.jivesoftware.database.EmbeddedConnectionProvider</className>
        </connectionProvider>
        <xmpp>
            <domain>openfire.my.domain</domain>
            <fqdn>openfire.my.domain</fqdn>
           <socket>
                <ssl>
                    <active>true</active>
                </ssl>
            </socket>
        </xmpp>
         <encryption>
           <algorithm>AES</algorithm>
            <key>TheEncryptionKey123</key>
        </encryption>
             <database>
            <mode>standard</mode>
            <defaultProvider>
                <driver>org.postgresql.Driver</driver>
                <serverURL>jdbc:postgresql://postgres:5432/openfire</serverURL>
                <username>openfire</username>
                <password>openfire</password>
                <minConnections>5</minConnections>
                <maxConnections>25</maxConnections>
                <connectionTimeout>1.0</connectionTimeout>
            </defaultProvider>
        </database>
        <authprovider>
            <mode>ldap</mode>
        </authprovider>
</autosetup>
<adminConsole>
 <port>9090</port>
 <secureport>9091</secureport>
 <interface>0.0.0.0</interface>
</adminConsole>
       <ldap>
            <host>my.domain.controller</host>
            <port>636</port>
            <sslEnabled>true</sslEnabled>
            <startTlsEnabled>false</startTlsEnabled>
            <usernameField>sAMAccountName</usernameField>
            <nameField>displayName</nameField>
            <emailField>mail</emailField>
            <baseDN>BASE_DN_FOR_USERS</baseDN>
            <adminDN>CN_OF_MY_LDAP_USER</adminDN>
            <adminPassword>LDAP_USER_PASSWORD</adminPassword>
             <searchFilter>(objectClass=organizationalPerson)</searchFilter>
              <groupMemberField>member</groupMemberField>
            <groupDescriptionField>description</groupDescriptionField>
            <posixMode>false</posixMode>
            <groupSearchFilter>(objectClass=group)</groupSearchFilter>
      </ldap>
<provider>
    <user>
        <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
    </user>
    <auth>
        <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
    </auth>
    <group>
        <className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
        <groupBasedAdminProvider>
            <groupName>ADMIN_GROUP</groupName>
        </groupBasedAdminProvider>
    </group>
    <admin>
        <className>org.jivesoftware.openfire.admin.GroupBasedAdminProvider</className>
    </admin>
</provider>
</jive>

My openfire.xml is an edited version of the one posted by spricer here: https://discourse.igniterealtime.org/t/autosetup-with-ldap-integration-active-directory/93651/4

guus · May 12, 2026, 1:14pm

Hi @Chris102 - good to hear you made progress! As the discussion is fanning out to multiple topics, I’ll try to keep things nice and separated by responding in a couple distinct comments.

guus · May 12, 2026, 1:24pm

Indeed, there is an easier way.

For starters, with the next release of the monitoring plugin (2.8.0), these features will be enabled by default (as tracked in this ticket: Enable Message Archiving by Default · Issue #441 · igniterealtime/openfire-monitoring-plugin · GitHub ).

These settings are stored in the following system properties:

conversation.metadataArchiving
conversation.messageArchiving
conversation.roomArchiving
conversation.roomArchivingStanzas

All Openfire system properties (except for the ones that we haven’t migrated yet - but that’s unrelated) can be set through openfire.xml by providing them outside of the autosetup element. Their name is converted by treating every name betwee dots (.) as element names that are nested. For the four properties that you’re after, you can do something like this:

<jive>
    <autosetup>
        <!-- unrelated things -->
    </autosetup>

    <!-- more unrelated things -->

    <conversation>
        <metadataArchiving>true</metadataArchiving>
        <messageArchiving>true</messageArchiving>
        <roomArchiving>true</roomArchiving>
        <roomArchivingStanzas>true</roomArchivingStanzas>
    </conversation>
</jive>

You can also set most other properties like this. To find out what property names are used, you can use the admin console’s “System Properties” page. If you filter for the name of the plugin, you get a listing of all its properties. You’ll probably be able to identify the ones you’re after from their name, description, and current or default values.

guus · May 12, 2026, 1:33pm

You’re saying that you needed a reboot to get Openfire to recognize that admin users? That is unexpected.

I have tested this locally, but I could immediately log in with an LDAP-provided user, where the permission was granted through group membership of an LDAP-provided group.

For my test, I used a development build of Openfire (which is soon-to-be-released as 5.1.0). I used a local, empty MySQL server (which I happened to have installed), and Rafael Römhild’s docker-based OpenLDAP test server.

I’ve then stored this in openfire.xml

<jive>
    <autosetup>
        <run>true</run>
        <locale>en</locale>
        <connectionProvider>
            <className>org.jivesoftware.database.EmbeddedConnectionProvider</className>
        </connectionProvider>
        <xmpp>
            <domain>example.org</domain>
            <fqdn>example.org</fqdn>
            <socket>
                <ssl>
                    <active>true</active>
                </ssl>
            </socket>
        </xmpp>
        <encryption>
            <algorithm>AES</algorithm>
            <key>TheEncryptionKey123</key>
        </encryption>
        <database>
            <mode>standard</mode>
            <defaultProvider>
                <driver>com.mysql.cj.jdbc.Driver</driver>
                <serverURL>jdbc:mysql://example.org:3306/openfire?rewriteBatchedStatements=true&amp;characterEncoding=UTF-8&amp;characterSetResults=UTF-8&amp;serverTimezone=UTC</serverURL>
                <username>openfire</username>
                <password>openfire</password>
                <testSQL>select 1</testSQL>
                <testBeforeUse>false</testBeforeUse>
                <testAfterUse>false</testAfterUse>
                <testTimeout>PT0.5S</testTimeout>
                <timeBetweenEvictionRuns>PT30S</timeBetweenEvictionRuns>
                <minIdleTime>PT15M</minIdleTime>
                <maxWaitTime>PT0.5S</maxWaitTime>
                <minConnections>5</minConnections>
                <maxConnections>25</maxConnections>
                <connectionTimeout>1.0</connectionTimeout>
            </defaultProvider>
        </database>
        <authprovider>
            <mode>ldap</mode>
        </authprovider>
    </autosetup>
    <adminConsole>
        <port>9090</port>
        <secureport>9091</secureport>
        <interface>0.0.0.0</interface>
    </adminConsole>
    <ldap>
        <host>127.0.0.1</host>
        <port>10389</port>
        <baseDN>dc=planetexpress,dc=com</baseDN>
        <adminDN>cn=admin,dc=planetexpress,dc=com</adminDN>
        <adminPassword>GoodNewsEveryone</adminPassword>
        <sslEnabled>false</sslEnabled>
    </ldap>
    <provider>
        <user>
            <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
        </user>
        <auth>
            <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
        </auth>
        <group>
            <className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
            <groupBasedAdminProvider>
                <groupName>admin_staff</groupName>
            </groupBasedAdminProvider>
        </group>
        <admin>
            <className>org.jivesoftware.openfire.admin.GroupBasedAdminProvider</className>
        </admin>
    </provider>
</jive>

Directly after startup, I could log in with one of the accounts that are in the admin_staff group (I used hermes/hermes).

The only thing that I think could be a relevant difference between our setups is that I did not use a container. Can you find out maybe if the containerization is relevant in reproducing this problem? Anything else? I’d love to get this ‘needs a reboot’ to be fixed!

guus · May 12, 2026, 1:36pm

As an aside: with the current implementation of Openfire’s ‘autosetup’ combined with using a non-default user/auth provider, I did notice a small bug. Openfire tries unconditionally to set the password and email address of a user named admin - even if you don’t have such a user. This can cause a stack trace like this to be logged in the console:

org.jivesoftware.openfire.user.UserNotFoundException
	at org.jivesoftware.openfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java:176)
	at org.jivesoftware.openfire.user.UserManager.getUser(UserManager.java:282)
	at org.jivesoftware.openfire.XMPPServer.runAutoSetup(XMPPServer.java:521)
	at org.jivesoftware.openfire.XMPPServer.initialize(XMPPServer.java:404)
	at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:675)
	at org.jivesoftware.openfire.XMPPServer.<init>(XMPPServer.java:223)
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:79)
	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:189)
	at java.base/java.lang.Class.newInstance(Class.java:715)
	at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:92)
	at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:56)

I do not think that there’s a functional impact, but it’s confusing, and should be avoided. I’ve raised a ticket (OF-3276) for this, which will likely be resolved in Openfire 5.1.0.

Chris102 · May 12, 2026, 2:31pm

I will recreate my whole setup without docker next week to look if it still needs a reboot when not run in docker. For now I’m also thinking it might have to do with how I’m seeding the openfire.xml into the docker image. As I am quite new to using docker and openfire I resulted into using a dockerfile to create a custom image with the custom openfire.xml in it using the official openfire docker image as base.

Dockerfile:

# Use the official Openfire image as the base
FROM ghcr.io/igniterealtime/openfire:latest

# Set the environment variable for Openfire's home directory
ENV OPENFIRE_HOME=/usr/local/openfire

# Rename/move directories 
RUN mv /usr/local/openfire/conf_org /usr/local/openfire/conf \
   && mv /usr/local/openfire/resources/security_org /usr/local/openfire/resources/security \
   && mv /usr/local/openfire/plugins_org /usr/local/openfire/plugins \
   && chown -R openfire:openfire /usr/local/openfire/conf /usr/local/openfire/plugins /usr/local/openfire/resources/security

# Copy custom openfire.xml and plugins into the container's directories
COPY ./openfire.xml /usr/local/openfire/conf/openfire.xml
COPY ./jsxc.jar /usr/local/openfire/plugins/jsxc.jar
COPY ./monitoring.jar /usr/local/openfire/plugins/monitoring.jar

# Expose the required ports
EXPOSE 9090 9091 5222 5223 8080 8443 7777 80 443 3478 3479 5229 5269 5270

# Start Openfire using the openfire.sh script
ENTRYPOINT ["/usr/local/openfire/bin/openfire.sh"]

Chris102 · May 18, 2026, 11:20am

Ok, so I spend all morning on this, and somehow I was not able to reproduce this . I then also went back to my original setup with the issues and they were also not present. So I guess no issues after all.

The situations I tested:
Both of these used my original openfire.xml.

Clean installed Debian 13 VM with PostgresSQL16 running in a docker container and openfire_5.0.5_all.deb to install openfire.

Clean installed Debian 13 VM with PostgresSQL16 running in a docker container and openfire 5.0.4 running in a docker container(copy of the original setup).

Chris102 · May 18, 2026, 11:22am

This is exactly what I was hoping and looking for! I don’t know if I missed something in the docs. But this is of great help to get a cleaner setup with less scripts.

Thanks for all your help!

guus · May 18, 2026, 11:24am

Ah, that’s excellent news! I think that covers all issues that we’ve discussed so far, right?

Chris102 · May 18, 2026, 11:28am

That does indeed cover all the issues that were addressed. Thanks for all the help!

I’ll be sure to reach out again if I ever get stuck .