XWiki and Active Directory LDAP authentication

Connecting XWiki to Active Directory authentication without a second password store

The XWiki Active Directory Application authenticates users against Active Directory over LDAP on port 389 or LDAPS on port 636, creates XWiki profiles for AD users on first login, and syncs AD group membership to XWiki groups at login. For an organization that already manages staff accounts in AD, this means wiki users sign in with the credentials they already use, and access changes made in AD take effect at the next login. This section explains what the reader needs to decide and confirm before any configuration starts, so that the rest of the page can be followed against a known starting point.

The starting point is a version check. The Active Directory Application needs XWiki 15.10 or later, so the reader should confirm which XWiki line they run, whether stable, the LTS line or the intermediate LTS line, and whether it meets that minimum before planning further. The application works with Active Directory Domain Services, Azure AD Domain Services and other LDAP-compatible directories, but it is not compatible with standard Azure Active Directory or SAML. Teams that intend to use cloud identity sign-in should treat that as a separate decision, covered on the Microsoft Entra ID page in this group, rather than assume this application can bridge it.

The main decision is the transport. LDAP on port 389 sends bind credentials and directory queries without encryption, so it should be limited to test environments or networks where the traffic path is already protected to the organization's standard. LDAPS on port 636 is the expected choice for production, and it requires that the XWiki host trust the certificate chain of the domain controllers. The reader should confirm which domain controllers or load balancer name XWiki will target, that the certificate name matches that name, and that firewall rules allow the XWiki host to reach that endpoint. Certificate trust failures are a common reason a login test fails with an unclear error, so this check is worth doing first.

Plan the service account and the attribute scope before entering settings. The bind account should be a dedicated, low-privilege directory account with read access to the user and group objects that XWiki needs, not a personal administrator account. Decide which AD groups will become XWiki groups and who approves that list, because group mapping determines what users can read and edit. Confirm the attributes that will populate the profile, such as display name and mail, and check that the organization's naming conventions produce usable XWiki login names. Nested group membership, disabled accounts and users in more than one domain should be tested with real sample accounts, since each can change what a user receives at login.

Verification and failure points should be planned together. Test with at least one account from each group that carries a different permission, and one disabled account, before any wider rollout. Record which logins created profiles and which groups were synced, so that later changes can be compared against that baseline. The most frequent failures are an unreachable LDAPS endpoint, a certificate the XWiki host does not trust, a bind account whose password expired, and group names that differ between directory and wiki expectations. The reader should also confirm with the XWiki Store listing for the Active Directory Application how the extension handles these cases in the version they will install, because behavior around existing local accounts is the detail most likely to affect cutover.

What you need in place before the XWiki LDAP configuration starts

The LDAP configuration is quick to change and slow to debug when a prerequisite is missing. Confirm these six items with your directory and infrastructure owners first, so that the XWiki side is the only thing left to troubleshoot.

XWiki version floor

The XWiki Active Directory Application requires XWiki 15.10 or later, so confirm the version of the running instance before you plan anything else. Check the version shown in the administration pages, and do not assume it from your deployment file. If the instance is older, plan the upgrade as a separate project with its own backup and extension compatibility checks, and schedule it before the LDAP work starts.

Supported directory types

The extension works with Active Directory Domain Services, Azure AD Domain Services and LDAP-compatible directories. It does not support standard Azure Active Directory or SAML, so a cloud-only tenant needs a different authentication design. Confirm which directory holds the accounts, since a hybrid setup may keep users in on-premises AD DS while sign-in is handled elsewhere.

Bind account and password policy

XWiki needs a bind account that can read the user and group objects under the search base. Give it read rights only, and keep it under a directory service account policy that sets its password lifecycle, since a silent expiry will stop every login at once. Ask the directory team which attributes the account can read, and confirm that group membership attributes are included, because the group mapping depends on them.

Network paths to domain controllers

The XWiki host must reach at least one domain controller on TCP 389 for LDAP or TCP 636 for LDAPS. Firewall rules must allow that outbound path and the return traffic. Run the test from the XWiki host itself, because application servers often sit in a different network segment. Connect by the domain controller's DNS name, since LDAPS validation fails when the hostname in the connection differs from the name on the certificate.

Certificate trust for LDAPS

If you use LDAPS on port 636, the Java truststore used by the Tomcat process that runs XWiki must trust the certificate chain issued by your directory's certificate authority. Import the root and any intermediate certificates, then confirm the chain with a test connection from that host. Ask the PKI team which certificate template the domain controllers use and when it expires, because a renewal that is not added to the truststore will break logins after the change.

Test OU with test users and groups

Create a dedicated organizational unit with a few test users and groups that mirror the mappings you plan to use. Use it to confirm first-login profile creation, group sync at login and access to restricted spaces before any production users are involved. Keep the test accounts disabled outside test windows and remove them at the end, so that no one can sign in with a standing test identity.

How the Active Directory Application creates profiles and syncs groups at login

The Active Directory Application follows a fixed sequence each time a user signs in. First, the user submits a username and password through the XWiki login form. XWiki checks those credentials against the directory over LDAP on port 389 or over LDAPS on port 636, so your transport choice determines whether credentials cross the network encrypted. Second, if the directory accepts the credentials, XWiki creates a profile for that user on the first successful login. Third, on that login and every later one, XWiki reads the user's Active Directory group membership and maps those groups to XWiki groups, which are synced at login. Before go-live, confirm with the extension documentation for your XWiki version which directory attributes feed the profile and the group mapping.

The main operational consequence is timing. A group change made in Active Directory does not reach XWiki immediately. It takes effect at the user's next login, when the group sync runs again. A user added to a group that grants edit rights will not have those rights until that user signs in again, and a user removed from a group should be expected to keep the old XWiki group membership until the next login. Build your change process around this, especially for restricted spaces, and tell the directory team that changes made in Active Directory are not applied in XWiki until the affected user logs in. Confirm in your version's documentation how long existing sessions remain valid, because a session that stays open may delay the sync.

Removal is the second behavior to plan for. Disabling or deleting a user in Active Directory does not, by itself, delete the matching XWiki account, and the sync described above runs only for users who log in. Accounts of departed staff can remain in XWiki with their content, page history and group memberships in place until someone acts on them. Ask the extension documentation for your version exactly what happens to group memberships of users who no longer appear in the directory, whether any accounts are deactivated or removed automatically, and how a disabled Active Directory account is prevented from signing in. Do not assume that a disabled account ends access to an existing session until you have tested that case.

Turn these behaviors into a short test plan before go-live. Use a test organizational unit with accounts that are inside and outside the groups that matter, then run four checks: the first successful login creates exactly one profile, a new group membership appears after the next login, a group removal is reflected after the next login, and a disabled test account is refused at login. Record what happens to an account that was removed from Active Directory but still exists in XWiki, and decide who reviews those accounts and how often. Keep the test results with your access review evidence so that changes made in the directory can be traced into the wiki.

Active Directory Application or the open source LDAP authenticator: how to choose

The Active Directory Application is the option with verified behavior for this topic. It is built for Active Directory Domain Services, Azure AD Domain Services and other LDAP-compatible directories, and it requires XWiki 15.10 or later. It is not compatible with standard Azure Active Directory or SAML, so it fits an on-premises or domain services directory.

Directory fit: Works with Active Directory Domain Services, Azure AD Domain Services and LDAP-compatible directories.
Ports: Supports LDAP on port 389 and LDAPS on port 636. Confirm which port your domain controllers accept and how the certificate chain is trusted before the first test.
First login: Creates an XWiki profile for each AD user on first login, so plan how account names and profile fields will appear.
Group sync: Maps AD groups to XWiki groups and syncs them at login, so your AD group design becomes your XWiki access model.
Version floor: Requires XWiki 15.10 or later. Confirm that your target line, whether stable, LTS or intermediate LTS, meets this minimum before you select the extension.

Check the version floor, the port and certificate path, and whether standard Azure AD or SAML is also needed, because this extension does not cover those.

Configuring the Active Directory Application in order, with a check after each step

This sequence connects XWiki to your on-premises Active Directory so that users sign in with directory credentials, receive a profile on first login and inherit XWiki groups from their AD groups. Each step ends with a check, so any problem shows up before the next setting is added.

Confirm the XWiki version and install the extension
An administrator on a non-production XWiki instance confirms that the running version is 15.10 or later, which is the minimum the Active Directory Application requires. They then install the extension from the XWiki Store and restart the instance as the extension page directs. Run this entire sequence in non-production first and leave production untouched until every step passes. Check: the extension appears in the installed extensions list after restart, and the instance starts without extension errors in its logs.
Create or confirm the bind account
The directory team creates or confirms a dedicated service account that XWiki uses to bind to the directory and search for users and groups. Ask for read access to the user and group objects under the search base, and agree with the directory team who owns the password policy and rotation schedule. Do not reuse a personal administrator account. Check: enter the account in the test configuration and confirm that a successful bind appears in the XWiki log, which proves the credentials and network path work before any user signs in.
Set the server address and port
Enter the domain controller or load-balanced LDAP address in the extension settings, then choose LDAP on port 389 or LDAPS on port 636. Use LDAPS wherever your directory team can provide it, because it encrypts the bind and search traffic. Confirm that the certificate presented by the directory is trusted by the Java runtime under XWiki's Tomcat, since a missing trust chain is a common cause of LDAPS failures. Check: the log shows a successful connection to the chosen host and port. If it shows a certificate error instead, fix trust before moving on.
Configure the base DN and user search filter
Set the base DN to the container that holds the users who should be able to sign in. Write a user search filter that matches only the account types you intend to admit, such as enabled user accounts in the right organizational units. Confirm with the directory team whether the directory is Active Directory Domain Services, Azure AD Domain Services or another LDAP-compatible directory, because the search configuration depends on it. Check: a lookup of a known test user returns one matching entry, and a test account outside the search base returns nothing.
Enable profile creation on first login
Turn on profile creation so that a directory user who signs in for the first time gets an XWiki user profile automatically. Settle the admission rules before enabling it, because the search filter from the previous step decides which accounts can create profiles at all. Keep a list of accounts that must never receive a profile, such as service or disabled accounts, and confirm the filter excludes them. Check: sign in with a test account that has never used this instance, then confirm the new profile appears in the XWiki user directory with the expected name and email address from AD.
Map AD groups to XWiki groups
List the AD groups that should grant access or rights, then map each one to an existing XWiki group. Confirm the target XWiki groups exist and have the permissions you expect before you map anything to them. Groups sync at login, so a membership change in AD takes effect the next time that user signs in. Keep the mapping short and record it, since the directory team will need it for future changes. Check: after a test user signs in, their profile shows membership in the mapped XWiki group, and a user outside the AD group does not show it.
Test with one account per group
Choose one test account from each mapped AD group and one account that should be refused, then sign in to the non-production instance with each. Confirm that each allowed account gets or updates its profile and the expected groups, and that the refused account cannot sign in. Record the XWiki and extension versions, the LDAP settings used and the results, so the production change can be compared against them. Check: every test account behaves as the plan states, and the log shows no unexpected bind or search errors before you repeat the sequence on production.

Which directory fields map to XWiki profiles and groups

This table lists each directory field and group decision the Active Directory Application affects, from login name to group sync. Read each row as a design decision to settle before the pilot, and confirm every attribute name in the extension documentation because the examples given are only starting points. The main takeaway is that login identifiers and group nesting are the decisions hardest to reverse later.

Mapping	How it maps	Design decision for the team	What to confirm in the extension documentation
User identifier to XWiki login	A directory attribute that uniquely identifies each user becomes the XWiki login name.	Pick an identifier that does not change. A renamed login can create a second profile for the same person.	Which attribute is read for login, and whether matching is case sensitive. Example names to verify: sAMAccountName, userPrincipalName.
Display name to profile name	Directory name attributes populate the first name, last name or display name fields, if the extension maps them.	Decide whether AD or XWiki owns names. Later directory edits may overwrite values users changed in the wiki.	Which attributes fill each name field, and whether values refresh after the first login or only at creation.
Mail to profile email	A directory mail attribute populates the XWiki profile email field.	Decide whether email serves notifications only or also helps match existing accounts.	Which attribute is read for email (example to verify: mail) and whether it updates on later logins.
Group membership to XWiki groups	Each mapped AD group that a user belongs to adds that user to a matching XWiki group at login.	Choose which AD groups are mapped and whether local XWiki groups stay outside the sync.	How group names are matched, the search base used, and whether target XWiki groups are created automatically.
Nested group membership	Indirect membership through nested AD groups may or may not be included in the XWiki group set.	Decide whether to flatten nesting in AD or rely on the extension to resolve it. Test with deep nesting.	Whether nested groups are resolved, and any recursion limit. Verify with a test user two or more levels deep.
Sync direction	Changes flow from the directory to XWiki only. Edits made in the wiki are not written back to AD.	Confirm that wiki administrators accept AD as the source for these fields and group memberships.	Whether any write-back to the directory is supported. Assume none unless the documentation states otherwise.
Timing of sync	The profile is created on first login, and group membership is synced when the user logs in.	Accept that group removals apply at the next login, or plan a separate refresh process if faster changes are needed.	Whether a background sync exists, and how existing sessions behave after group changes.
Disabled or removed AD accounts	Login-time sync may not remove wiki access when an AD account is disabled or deleted.	Define who revokes wiki access, how quickly, and whether accounts must be deactivated by hand.	Whether disabled AD accounts are refused at login, and whether existing wiki accounts are deactivated or kept.

Securing the LDAP bind, certificates and group rights

The Active Directory connection gives XWiki a privileged view of your directory and decides who becomes an administrator, so its security settings deserve the same review as the rest of your identity stack. The cards below cover the transport, the trust chain, the bind account, group-to-role decisions, and who may change the configuration and read the logs.

Prefer LDAPS on port 636

The Active Directory Application supports both LDAP on port 389 and LDAPS on port 636. Choose LDAPS so user credentials and the bind password are encrypted between XWiki and your domain controllers. If plain LDAP on 389 is still used for a specific reason, such as a legacy constraint, record that justification, its owner and a review date in your change documentation.

Install the directory certificate chain

For LDAPS to validate, XWiki's Java runtime must trust the certificate chain that your domain controllers present. Export the issuing CA chain from your Active Directory certificate services or the enterprise PKI, import it into the Java trust store used by the Tomcat instance, and restart XWiki. Confirm the chain includes intermediates and that the hostname in the configuration matches a name on the certificate. Plan a renewal check, because an expired or rotated certificate will break logins.

Use a least-privilege bind account

XWiki needs a directory account to search for users and groups. Create a dedicated service account with read access only to the users, groups and attributes the integration needs, and deny interactive logon. Define a password rotation plan that names the owner, the rotation interval set by your policy and the steps to update the password in XWiki. Confirm with your directory team how the account is protected against lockout.

Restrict AD groups that grant admin rights

Group mapping decides which people receive XWiki group membership, so a broad AD group can silently grant administrative rights. Map only purpose-built groups to XWiki administrators, keep those groups small and owned by the identity team, and review membership on a schedule. Test with a sample of accounts before enabling the mapping in production, and document which AD group maps to which XWiki group.

Limit who changes directory settings

The directory configuration controls authentication for every user, so editing it is a privileged change. Restrict edit rights on the configuration pages and the related administration screens to a small named group of XWiki administrators, and keep a record of who changed what. Confirm how your XWiki version exposes these settings and whether changes can be made only through your change process.

Keep bind passwords out of logs

Authentication and debug logging can capture connection details and, if verbosity is raised during troubleshooting, the bind credentials. Review the logging levels for the LDAP components, confirm that bind passwords never appear in application, Tomcat or reverse proxy logs, and check what your log shipper forwards. Set a rule that debug logging is turned on only for a defined window and turned off afterward, and test that the rule works before go-live.

How to test first login, group changes and failed binds before go-live

Before XWiki goes live against Active Directory, run a fixed set of login tests that cover the paths users will actually take: first login, login through an allowed group, login by someone outside the mapped groups, a group change followed by a new login, a disabled account, a wrong password and an LDAPS connection with an untrusted certificate. Write each case down with its expected result before you run it, so the outcome is compared against an agreed expectation rather than against whatever XWiki happens to do. Use test accounts in a non-production AD organizational unit that mirror the real group structure, and record the AD account name, the groups it holds, the time of each attempt and the XWiki result.

The first-login case checks that a new AD user who has never signed in gets an XWiki profile created on first login and lands on a page without manual administrator action. Confirm the profile fields that come from AD, such as name and email, and check that the user receives the group memberships mapped from AD at that login. The allowed-group case uses an account in a group you have mapped to an XWiki group and confirms access to the spaces that group grants. The outside-group case uses an account that is valid in AD but holds none of the mapped groups. Confirm with your XWiki administrator exactly what that user can see, because the answer depends on the Active Directory Application configuration and on the default rights you have set for authenticated users.

The group-change case is where most surprises appear. Move a test account out of one mapped group and into another in AD, then log in again and check the XWiki group membership on the user's profile. Note whether the old group membership is removed at that login, since the groups are synced at login and any gap between an AD change and the next login should be documented as expected behavior for your change record. The disabled-account case signs in with an AD account set to disabled and expects a refused login with no new session. The wrong-password case expects a refused login and a failed-bind entry, and you should check how many attempts your lockout policy allows in AD, since XWiki does not replace that control.

The LDAPS case points XWiki at the domain controller over port 636 using a certificate signed by a CA that the XWiki Tomcat truststore does not trust. Expect a connection failure and a clear error in the XWiki log rather than a silent fallback to plain LDAP on port 389. Then import the correct CA chain and repeat the test. For evidence, keep the XWiki log excerpts for each case, the profile and group screenshots or exports, the domain controller security events for failed binds, and a signed test record with the tester, date, XWiki version and configuration file version. Auditors preparing compliance evidence will ask for this record, and it becomes evidence of the test, not an audit opinion, which only an independent auditor can give.

Why the LDAP login fails and how to fix it

This table lists the failures teams most often meet when XWiki authenticates against Active Directory, with a likely cause and a check for each. Treat every fix as a verification step your team performs in its own environment, not as a guaranteed resolution. Most issues trace back to certificates, bind accounts, search scope or group names that differ between test and production.

Symptom	Likely cause	Check to perform
Bind fails on port 636 with a certificate error	The domain controller certificate chain is not trusted by the Java truststore used by XWiki's Tomcat, or the host name does not match the certificate.	Confirm the full chain, including any internal CA, is imported into the truststore XWiki uses, and that the configured host name matches the certificate subject.
Bind fails on port 389 or 636 with invalid credentials	The bind account DN or user principal name format is wrong, or the password has expired or the account is locked.	Repeat the bind from the XWiki host with the same account and DN format using an LDAP client, and confirm the account is enabled and not locked.
Users authenticate but receive no groups	The group search base or filter does not reach the group objects, or the membership attribute is not read as expected.	Run the group search with the configured base and filter, then confirm the member values on a known group match what the mapping expects.
First login does not create an XWiki profile	The Active Directory Application is not installed on a supported XWiki version (15.10 or later), or required user attributes such as name or mail are missing.	Confirm the XWiki version, review the logs for the first login attempt, and test with one newly created account before rolling out.
Some users can log in and others cannot	The search base or filter scope excludes the organizational unit or child domain where the failing accounts sit.	Compare the distinguished names of a working and a failing account, then confirm the search base is a subtree that covers both locations.
Group mapping works in test but not in production	Group names differ between environments, nested groups from another domain are not resolved, or group scope differs between the two directories.	Compare group distinguished names rather than display names across environments, and confirm nested membership and group scope match the mapping design.
Sign-in fails when the directory is Azure AD	The Active Directory Application is not compatible with standard Azure Active Directory or SAML, so it cannot reach the directory this way.	Confirm the target is Active Directory Domain Services or Azure AD Domain Services with LDAP access enabled, or plan a different authentication method.

Questions buyers ask before connecting XWiki to Active Directory

What drives the cost and effort of an XWiki Active Directory integration?

Directory complexity, the number of groups to map, LDAPS and certificate work, the testing scope and your team's XWiki administration skills are the main drivers. A single forest with a small set of groups and a plain bind account is a short exercise. Multiple domains, nested groups, or a certificate chain your team has not deployed to the XWiki server before add analysis and test cycles. Testing scope matters because you need test accounts across every group that gates access, and login failures are easier to diagnose before users see them. DeployOpen does not publish prices; a quote follows from the written scope. For reference, XWiki SAS lists consulting at 1200 EUR per day on its pricing page, and that rate requires a Business or Enterprise support plan. Ask any provider for the assumptions behind a quote, including who pays for the test environment and what recurs after go-live.

Can our own team connect XWiki to Active Directory without a partner?

Yes, if your team has directory administration skills, working knowledge of XWiki administration, and a test environment that mirrors production. The work is mostly careful configuration against the extension documentation, plus directory queries to confirm the user and group distinguished names you will map. The steps that most often stall in-house teams are LDAPS certificates, which the XWiki runtime must trust, and group mapping across nested or multi-domain groups. Plan a rollback path, test with accounts from each group that gates access, and keep a local administrator account so you can recover if the directory is unreachable. A partner adds the most value when the directory is complex or nobody on the team has done this before. DeployOpen plans, implements and documents these integrations inside your infrastructure under a written scope.

How long does an XWiki Active Directory LDAP integration take?

The duration depends on the scope, so it is set in the written scope, which is agreed before work starts. The main inputs are how many directories and domains are involved, how many AD groups map to XWiki groups, whether LDAPS certificates must be issued or chained, how many environments you test in, and whether a change window must be booked. Ask any provider to break the timeline into discovery, configuration in a test environment, validation with test accounts, and the production change window. Ask which steps depend on your directory team or certificate authority responding. Certificate issuance is often the longest single dependency because it runs through another team's queue, so start that request early.

What do we need to provide for an XWiki Active Directory integration?

Your side provides the inputs and approvals, and the implementation team does the configuration. Typical inputs are read access to the directory containers that hold the relevant users and groups, a dedicated bind account with only the permissions needed to search users and groups, and a set of test accounts covering each group that gates access. If you use LDAPS on port 636, you also need the server certificate chain and the correct server name. You will need a change window agreed with operations, an XWiki instance on version 15.10 or later, and a staging copy to test against. Confirm with your directory team which object type holds group membership and whether any groups are nested. Ask the provider to list every input in the written scope with its owner and the date it is needed.

Can XWiki use Azure AD or SAML with the Active Directory extension?

No. The Active Directory Application does not work with standard Azure Active Directory or with SAML. It authenticates against Active Directory Domain Services, Azure AD Domain Services and other LDAP-compatible directories, using LDAP on port 389 or LDAPS on port 636. Azure AD Domain Services is a separate service from standard Azure Active Directory, so check which one your tenant exposes to LDAP clients before you design the integration. If your identity provider is cloud-only Microsoft Entra ID, plan a different approach, such as the OpenID Connect route covered on the Microsoft Entra ID single sign-on page for XWiki, and confirm the design against the extension documentation before you choose.

Does XWiki create user profiles and sync groups at each login?

Yes for profiles: the Active Directory Application creates an XWiki profile for each AD user on first login. Group membership maps from AD groups to XWiki groups and syncs at login, so a change in AD takes effect the next time the user signs in. A user removed from a group keeps any open session until it expires, then loses access at the next login. Decide the group mapping before go-live, and test a disabled account and a user moved between groups in staging. Confirm with the extension documentation how profiles behave for leavers, because your offboarding process depends on it.

What should we verify before moving XWiki Active Directory login to production?

Verify login, group mapping, failure behavior and recovery in a staging environment that matches production as closely as you can. Test each class of user: a member of every gating group, a user in no mapped group, a disabled account and a user whose password has expired. Confirm that LDAPS validates the certificate chain from the XWiki host and that the bind account can read only what it needs. Check what users see when the directory is unreachable, and confirm that a local administrator can still sign in. Record the results in a sign-off document, and agree who approves the production change window before you start.

How DeployOpen scopes and delivers the XWiki Active Directory integration

DeployOpen plans the XWiki Active Directory Application around your directory, your XWiki version and your group model before any configuration changes. The work covers LDAP or LDAPS binding, first-login profile creation and AD group to XWiki group mapping, delivered in infrastructure you control.

How we scope

Confirm your XWiki version is 15.10 or later, since the Active Directory Application requires it.
Confirm whether your directory is Active Directory Domain Services, Azure AD Domain Services or another LDAP-compatible directory.
Record which AD groups map to which XWiki groups and who approves that mapping in writing.

How we build

Configure LDAP on port 389 or LDAPS on port 636, with certificate trust validated on every XWiki node.
Test first-login profile creation with representative AD accounts before any production users sign in.
Verify group sync at login, including users who change groups or leave the directory.

How we hand over

Deliver the written configuration, group mapping table and a record of each test case and its result.
Document how to add a new AD group, rotate the bind account credential and roll back the change.
Walk your identity and wiki administrators through login troubleshooting and where logs are written.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, XWiki upgrades and re-testing after directory changes are available as a retainer.
Confirm with DeployOpen how upgrades to new XWiki releases will be retested against your directory settings.