@julien-f Just looking at testing this now, will let you know once its setup.

So you can do

#Check you have a TPM 2.0 otherwise this isn't going to work

systemd-creds has-tpm2

#Create plaintext.txt that contains your strong password.

echo "i]BM|yWq=7+-Be}n{9k=%26$O95V7"E$$G,+n&:!" > plaintext.txt

#generate a credentials file that is encrypted will be called ciphertext.cred the name we are using will be XO-PassPhrase

systemd-creds --name=XO-PassPhrase encrypt plaintext.txt ciphertext.cred

#Add this to your service file in the [servce] section

LoadCredential=XO-PassPhrase:/path/where/you/stored/ciphertext.cred

#Start the service and the encrypted passphrase is stored in $CREDENTIALS_DIRECTORY/XO-PassPhrase you can unencrypt it in the process using

systemd-creds decrypt $CREDENTIALS_DIRECTORY/XO-PassPhrase

The downsides are this is complex to setup, Needs modern Linux so works con Centos 9 but not 8, if the process is running you can grab the passphrase as root running this. (I was using creds-test as a service name to test this)

systemd-creds decrypt /run/credentials/creds-test.service/XO-PassPhrase

@olivierlambert Just having a bit of an investigate and not sure if this is actually possible or if it is but there is a requirement for a TPM 2.0.

Assuming you only support Linux and there is a modern systemd you can provide keys on process start https://systemd.io/CREDENTIALS/ the SetCredentialEncrypted option looks like what could be used.

Honestly never tested any of this and I'm running XO on xcp-ng 8.2 that doesn't support vTPM's yet.

@olivierlambert More than happy to test it.

From what I understand this feature is actually optional in the saml standard so a fair few providers do not support it and just ignore it. Might confuse a few people when it does nothing for their IDP. Defiantly works for entra though.

I had a poke around on a fresh install of XO as I wondered how hypervisor passwords are being stored and can see they are just plaintext inside redis which isn't ideal.

Can see a thread about this already from a few years ago https://xcp-ng.org/forum/topic/2866/exported-xen-orchestra-config-contains-plaintext-host-passwords-is-this-intentional/5

Is there any plans to introduce some form of encryption for these. Even if its just a simple passphrase.

Just Setup xen Orchastra and configured auth-saml to authenticate against azure/Entra. If I have already authenticated against Azure in another browser tab then I'm auto logged into Xo. Some services allow for force reauthentication on each login.

It appears you are using https://github.com/node-saml/passport-saml this library for Saml 2.0 and it does support this feature and is called forceAuthn. Would it be possible to add another toggle like "Don't request an authentication context" that switches this feature on or off.

forceAuthn: if set to true, the initial SAML request from the service provider specifies that the IdP should force re-authentication of the user, even if they possess a valid session.

@stormi said in vTPM support requirements:

The TPM device is emulated in the controller domain, so it's all software. No need for hardware TPM.

thanks, That's great to hear. Makes getting windows 11 machines working much easier.

I can see that vTPM support is due to land in the xcp-ng 8.3 release and that it will support v2.0. Can I just confirm does this mean all the hypervisors in a pool will require a TPM 2.0 module, a 1.2 module or will any be required at all ?

Currently trying to get hold of tpm 2.0 modules for servers is pretty much impossible at the minute.

We recently installed a new hypervisor that has 2 times "Intel(R) Xeon(R) CPU E5-2670 v3" processors in.

When I look in xcp-center I can see the CPU's listed as this which looks accurate.

Vendor: GenuineIntel
Model: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
Speed: 2300 MHz

If I SSH onto the box and use top or look at /proc/cpuinfo I'm only seeing 16 cores. Any ideas about this discrepancy ?