Posts made by dant123

@julien-f confirmed fixed, thank you! Copy/pasted the Azure AD enterprise app's base64 cert in again and saved to get it working. After updating XO of course.

For what it's worth, most Web UIs I see that take in certs use a text box/area rather than a text field which (directly or indirectly, not sure) preserves the line breaks in the cert. Everywhere I'm seeing, a text field doesn't seem to preserve the needed line breaks when its value is stored in a string.

Not sure which file(s) I'd need to edit to test a fix for this as I'm not the strongest with web development, but would be willing to try and report back.

@olivierlambert sorry for the delay there! Relevant portion of the logs (extracted via journalctl -u xo-server.service)

Aug 08 14:33:24 xo-ce xo-server[517]: Error: error:0909006C:PEM routines:get_name:no start line
Aug 08 14:33:24 xo-ce xo-server[517]:     at Verify.verify (node:internal/crypto/sig:230:24)
Aug 08 14:33:24 xo-ce xo-server[517]:     at RSASHA256.verifySignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:140:24)
Aug 08 14:33:24 xo-ce xo-server[517]:     at SignedXml.validateSignatureValue (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:460:20)
Aug 08 14:33:24 xo-ce xo-server[517]:     at SignedXml.checkSignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:397:15)
Aug 08 14:33:24 xo-ce xo-server[517]:     at validateXmlSignatureForCert (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/xml.ts:103:14)
Aug 08 14:33:24 xo-ce xo-server[517]:     at /opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:730:41
Aug 08 14:33:24 xo-ce xo-server[517]:     at Array.some (<anonymous>)
Aug 08 14:33:24 xo-ce xo-server[517]:     at SAML.validateSignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:729:18)
Aug 08 14:33:24 xo-ce xo-server[517]:     at SAML.validatePostResponseAsync (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:785:17)
Aug 08 14:33:24 xo-ce xo-server[517]:     at runMicrotasks (<anonymous>)
Aug 08 14:33:24 xo-ce xo-server[517]:     at processTicksAndRejections (node:internal/process/task_queues:96:5)

I looked up "Error: error:0909006C:PEM routines:get_name:no start line" in relation to passport-saml and read through a ton of discussions but couldn't find a conclusive solution. I am copying the contents of the Base64 .cer file in their entirety and triple checked they are correct. Tried converting from UTF-8 to ANSI and ASCII as well as replacing "CERTIFICATE" with "PRIVATE KEY".

One thing to note: When copying the cert text back from the XO field, the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- are not in their own lines. I saw this mentioned in a couple discussions such as here. I did try manually replacing the spaces between the hyphens and the string with /n but it wasn't parsed correctly when entered via the web UI.

@fanuelsen thanks! Updated and confirmed I can now customize it.

Trying to SAML auth now gives me a blank page with "Internal Server Error" on it instead, with the displayed URL being the (correct) callback one. Refreshing the page shows a quick Microsoft auth URL then the error.

Not sure how to proceed here, would help if we could confirm what "Entry point" "Issuer" should be mapped to regarding Azure AD so I could at least rule out the config on XO being the issue. I tried checking Audit and Logs but there wasn't much info on why the auth failed.

@olivierlambert thanks for the heads up, added a comment on there and linked back

Don't see it officially documented anywhere so I'll put down what worked for me and where I'm stuck. Using fully updated community edition (Xen Orchestra commit a4118, xo-server 5.100.0, xo-web 5.101.0).

XO instance is behind reverse proxy (Nginx Proxy Manager) pointed to Web UI's IP, port 443, HTTPS with websocket support and forced HTTPS redirection. Cert is valid. Public URL confirmed working.

1. Azure Active Directory > Enterprise applications > New application > Create your own application > Name: Xen Orchestra, Type: Non-gallery > Create

2. Azure Active Directory > Enterprise applications >Xen Orchestra > Users and groups > Added myself

3. Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > Basic SAML Configuration >
   Identifier (Entity ID): https://<Public URL>
   Reply URL (Assertion Consumer Service URL): https://<Public URL>/signin/saml/callback

4. XO > Settings > Plugins > auth-saml (v0.9.0) >
   Certificate: Copied contents of Certificate (Base64) (from Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > SAML Signing Certificate)
   Entry point: Copied from Login URL (from Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > Set up Xen Orchestra)
   Issuer: Copied from Application ID (from Azure Active Directory > Enterprise applications > Xen Orchestra > Properties)
   Username field: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
   Don't request an authentication context: Enabled (tried disabled too)

With any other Issuer I try, Microsoft gives an error that the application was not found.
With the application ID, it's found but I get the following error:
"Sorry, but we’re having trouble signing you in.
AADSTS50011: The reply URL 'http://<Public URL>/signin/saml/callback' specified in the request does not match the reply URLs configured for the application '<Application ID>'. Make sure the reply URL sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/urlMismatchError to learn more about how to fix this. "

Issue is, everywhere I can see, from the reverse proxy to my enterprise app, I'm using HTTPS. For some reason XO is sending the SAML request as http.

I've tried replacing the HTTPS reply URL under Azure Active Directory > App registrations > Xen Orchestra > Manifest with HTTP but it won't save. Was able to add the HTTP one on top of the HTTPS one, but same error.

I see a single mention of it here: https://github.com/vatesfr/xen-orchestra/issues/3822 as the last comment on the issue with no followup.

tbe created this issue in vatesfr/xen-orchestra

closed SAML Auth: Wrong callback URL #3822

@ronivay very good point thank you! I guess hourly is excessive when snapshots are available. Will just schedule hourly snapshots instead as the main point is to be able to revert in the event of a breaking change.

Back when I used StorageCraft ShadowProtect for backups, we had it set up to consolidate backup images which simplified the search and restore process a lot. Pretty sure XO backup doesn't offer that but any suggestions for keeping backups "manageable"?

For now I have the schedules seen below, but it feels really inefficient and of course I get failures if a job doesn't complete within the hour. I basically would like to be able to restore from any of the last 24 hours, 7 days, 5 weeks, or 12 months.