If you have an issue authenticating with Fortiauthenticator and OIDC, follow this steps.
First of all : you need a real certificate signed by a legitimate authority on the fortiauthenticator. Self signed will not work ! No ifs or but (beside fumbling in the code to allow self signed I suppose)
You might have to import the certificate as a bundle with it's direct signee (not the full chain)

After that just log into your FAC and go to : Authentication/Oauth Service/Portals
Create a new portal with your specific configuration if needed (default should be fine for a test)

go to : Authentication/Oauth Service/Policies

Create a new policy and select the Portal you created in the previous step

go to : Authenticator/Oauth Service/ Relying Party

Create a new Relying party
Select Confidential and Authorization
Select the policy you created before

Select Relying Scope and add "openid"
Select Add Claims and add a openid claim named "preferred_username" and user attribute "username" (if you select another user attribute like email, you will need to adjust the configuration in XOA)
Take note of the Client ID and Client Secret

Now in XOA, go to Settings/plugins/Auth-oidc plugin

Input the autodiscovery of your FAC
https://your-fac-FQDN/api/v1/oauth/.well-known/openid-configuration/

Input the client ID and client secret from your Relying Party in the FAC

Enable the plugin and you should be set

I'm starting to think that something is wrong.
Everywhere I check, I can see that the SAML request from the SP should have a signature of some sort.
It doesn't seem that there is anything of the sort in our case.
We are using the opensource for preproduction and are waiting for a pro license (paperwork on it's way) so maybe there is something wrong in the implementation ?

@probain Thanks, tried to have new line at the end with no luck. I already had found your guide I think and tried also to add the -----BEGIN CERTIFICATE----- & -----END CERTIFICATE----- and also newline withor without the certificate line without luck.
When inspecting the saml request and checking on other google research, I can see that the request doesn't have a signature like this <ds:SignatureMethod Algorithm="XMLSecurity::Document::RSA_SHA1" />
I'm not sure if this is normal or not

I was able to configure Keycloak with OIDC without any issue.
We also have a working configuration SAML for our vcloud so we know our setup should be working.
However with XOA we fail whatever the setting we use.
If we use Client Signature and copy the public key in the approriate field in XOA we get Invalid Requester in Keycloak and Invalid_Signature error
If we disable Client Signature, we reach the authentication page and can login, however when we are redirected to the /signin/saml/callback we get an Internal Server Error and in XO logs we have the following
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: Error: Invalid signature
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: at SAML.validatePostResponseAsync (/opt/xo/xo-builds/xen-orchestra-202501241022/node_modules/passport-saml/src/node-saml/saml.ts:792:17)
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: at processTicksAndRejections (node:internal/process/task_queues:95:5)

I found a old topic of 2022 with someone being able to have it work with Keycloak but the user has not been active since then and did not indicated how he made it work.

When I check the SAML request and Response, they all look fine and I can see my user shown in the field NameID.
Only issue seems to be the expected signature in Xen-Orchestra.

Couldn't find any guide for XOA & Keycloak online sadly.

@nathanael-h In the contexte of SSO this makes sense to not logout the session of the IDP as it might be used for other SP but usually when one disconnect from an application (like logging out from Google), you get an option to log out from all other application.
This would send the logout to the IDP ?

@olivierlambert We are in the process of purchasing entreprises licenses for a 4 hosts cluster. It's not a big deal so I'll wait untill we have support to open a ticket

We were able to connect with OIDC via Keycloak with this guide (https://xen-orchestra.com/blog/xen-orchestra-5-80/ Olivier Lambert being on top of everything as usual )
Unfortunately when we disconnect, the user is not disconnected from Keycloak and the session stays active.
We are using the .well-known/openid-configuration url so the logout url should be taken into account but we don't see any log showing further communication between XOA and Keycloak when we logout from XOA.
Any idea is appreciated

@olivierlambert Can't wait. V6 Gui is really nice
Most of my colleagues are saying it's sexier than vcenter

@DustinB Thanks. Didn't realized the /v6 was available on XOA. Thought it was specific on the host.
Unfortunately nothing works for users who are not admin (users can't even view their VM)
There is still a lot of work for permission like Olivier mentionned.

@olivierlambert Thanks Olivier. Unfortunately in our configuration XO Lite cannot be used.
So it will be XO 6... 2025 ?

We intend to give open access to ressource pools for customers and this can only be done with orchestra.
This altgr issue is present since at least 2020 but hasn't been fixed yet

I have tried for days to make a Debian template (this probably applies to other Linux OS)
The main issue I was facing was that when creating multiple machine they would get the same IP from our DHCP server.
The reason is that Debian sends the machine-id (under /etc/machine-id) as dhcp identifier.
Adding to /etc/dhcp/dhclient.conf file dhcp-client-identifier = hardware;
did not help and deleting /etc/machine-id resulted in the absence of generation of a new id by cloud init for some reason and the VM not requesting an IP at all.

This is what I did:

Downloaded from https://cdimage.debian.org/images/cloud/ the latest bookworm raw file and imported it as a disk in XO

Booted a VM with a random template and some network (internet access will be usefull in a few steps)

Deleted the existing disk and attached the raw disk I uploaded

Converted the VM to template

Created a VM from this template with my ssh key

Once booted, you will need to install dmidecode (https://packages.debian.org/search?keywords=dmidecode ) due diligence on your part to get the latest .deb, install with dpgk -i

Also install xcp-ng guest tools

Then run :

sudo cloud-init clean
sudo cloud-init clean --logs
rm /home/debian/.ssh/authorized_keys
sudo mkdir -p /var/lib/cloud/scripts/per-once/ (folders get deleted on cloud-init clean)
cd /var/lib/cloud/scripts/per-once/
sudo nano generate-machine-id.sh
(coming from user modem7 on github)

#!/bin/bash

# KVM UUID Recreator
# Use this for new VM's or templates that require a unique machine ID.

if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root" 
   exit 1
fi

UUID=$(dmidecode -s system-uuid | tr -d '-')
if grep -q "$UUID" /etc/machine-id; then
    echo "UUID matches"
else
    echo "UUID does not match. Recreating."
    echo -n > /etc/machine-id && echo -n > /var/lib/dbus/machine-id && systemd-machine-id-setup && reboot
fi

chmod +x generate-machine-id.sh

sudo cat /dev/null > ~/.bash_history && history -c && shutdown now

You can now rename the VM and it's disk, delete the network card to prevent the template to have some tags added automatically with the IPV4 and IPV6 and convert the VM to a template.

You should now have a working Debian 12 template accessible with your ssh key if you add it on deploy and DHCP working and not overlapping. Hopefully, I did not forget anything.

On first start, the VM will loop once after the first prompt. The reboot is required for the change of the machine-id to be effective.

This is a lot of work and I have no doubt there is a simpler solution but I couldn't find it.

@dsmteam Still trying to browse the web and various xo forum but it looks like those parameters are in the .c and other precompile file so the build in xcp-ng are probably using those default parameters.

@olivierlambert Unfortunately, the parameters are reverted back to their default value when I turn on HA. Might be hard coded somewhere.

@olivierlambert I think I found what I need in the following documentation
https://xapi-project.github.io/features/HA/HA.html
Various parameters which must be the same of every hosts in /etc/xensource/xhad.conf

<parameters>
      <HeartbeatInterval>4</HeartbeatInterval>
      <HeartbeatTimeout>30</HeartbeatTimeout>
      <StateFileInterval>4</StateFileInterval>
      <StateFileTimeout>30</StateFileTimeout>
      <HeartbeatWatchdogTimeout>30</HeartbeatWatchdogTimeout>
      <StateFileWatchdogTimeout>45</StateFileWatchdogTimeout>
      <BootJoinTimeout>90</BootJoinTimeout>
      <EnableJoinTimeout>90</EnableJoinTimeout>
      <XapiHealthCheckInterval>60</XapiHealthCheckInterval>
      <XapiHealthCheckTimeout>10</XapiHealthCheckTimeout>
      <XapiRestartAttempts>1</XapiRestartAttempts>
      <XapiRestartTimeout>30</XapiRestartTimeout>
      <XapiLicenseCheckTimeout>30</XapiLicenseCheckTimeout>
    </parameters>

@Danp Oh..................
Indeed, much faster now. Down from 2:00 minutes to 1:20 minutes
Less than 10 seconds might be too aggressive.
This is closer to what we expect.
I can see in the GUI that when I bring a host down, the pool still takes a minute to consider the host down. Any way to decrease this timer further or there are too many dependencies ?

@olivierlambert Just tried but there is no change in reaction time.
After googling this parameter I found this page you wrote (small world) on xcp-ng.org website https://xcp-ng.org/blog/2024/08/22/xcp-ng-high-availability-a-guide/ which indicates that this timeout purpose is for self fencing in case of loss of network/storage (I actually had this page opened already in my browser but missed this line)
Doesn't seem to influence restart timer in case of full host failure.

@olivierlambert Thanks a lot.
We have not SPOF and full fiber 100Gb network spine/leaf infrastructure so I will give it a go (currently we are only on a test plateform so I do as much as I need )

@Danp Hello Danp,
no just the standard DRS and High availabilty configuration, no overkill FT
In case of host failure, VM would restart with 10 seconds (at worse)

Hello everyone,
we are testing XCP-NG and are quite satisfied with the ease of use and functionnality (still using ESX with around 100 hosts)
However one caveat we saw (same issue with Proxmox) is that the failover reaction time is quite long compared to ESX.
Under ESX, VM that are hosted on a failed host are restarted on a different host within seconds.
With XCP-NG it takes about 2 minutes for the VM to be restarted on a different host (HA cluster of 3 hosts which had ESX installed before so the physical environnement is identical)
Are those delays normal ? I suppose they are according to various video we saw online showing this kind of reaction time.
If they are, is there some way to reduce them ?
Couldn't find any information nor settings in Orchestra or in the hosts themselves