Hi
Case # 08183204
I tried to enable SAML authentication and had some issues.
My VeeamOne runs on port 443.
When adding an identity provider, the "SP entity ID URL" and "Assertion consumer URL" is like this:
https://my-veeamone-fqdn:/api/Saml2/MyClientID
(there is a ":" after the fqdn which I cannot remove during the setup of the IDP inside VeeamOne)
I tested it with EntraID and when importing the xml, I cannot save the config since it does not allow a ":" in the Identifier.
And if I remove the ":" of the identifier in the EntraID, the login does not work since the identifier does not match with VeeamOne.
Is it possible to adjust those URLs while setting up the IDP?
The VONE web client seems to generate those two URLs based on how I access the WebUI, if I access VONE locally on the VONE server with https://localhost, then the URL is https://localhost:/api/Saml2/MyClientID and if I access it with the FQDN, it generates the URL based on the FQDN. Maybe it should be possible to set a fixed FQDN (with port?) and then the URL gets generated based on this value?
Thanks for having a look at it.
Timo
-
tm67
- Veeam Legend
- Posts: 241
- Liked: 91 times
- Joined: Feb 21, 2023 4:44 pm
- Full Name: Timo Marfurt
- Location: Switzerland
- Contact:
-
RomanK
- Veeam Software
- Posts: 882
- Liked: 237 times
- Joined: Nov 01, 2016 11:26 am
- Contact:
Re: SAML cannot adjust SP entity ID / ACS URL
Hello Timo,
Thank you for the case #.
As far as I know the problem is specifically the port segment. The Veeam ONE web UI runs on 443, which is the standard HTTPS port. When the port is the default for HTTPS, the web client resolves it to an empty value, but it still inserts the : separator. The workaround should be using any other free port or default.
The support engineer should check everything else, so please continue troubleshooting within the support case.
Thanks
Thank you for the case #.
As far as I know the problem is specifically the port segment. The Veeam ONE web UI runs on 443, which is the standard HTTPS port. When the port is the default for HTTPS, the web client resolves it to an empty value, but it still inserts the : separator. The workaround should be using any other free port or default.
The support engineer should check everything else, so please continue troubleshooting within the support case.
Thanks
Who is online
Users browsing this forum: No registered users and 4 guests