Hi, we’re in the process of migrating our current BigFix infra to new Cloud Servers. We will migrate to new OS (Windows Server OS: 2022 and for Linux to RedHat 8.8)
The version of BigFix will remain the same (10.0.10.46) for time being until we fully migrated to new hardware and then plan upgrading to version 11.x
I’m running into issue on our BigFix Console server (Dedicated Windows Server 2022) and loggin into the BigFix console using SAML authentication. It does work just fine using local operator but not with SAML.
The SAML version is the same as we currently use, the MFA is also the same (PingID).
Error message I’m getting after providing credentials to SAML Login page
I’ve also opened case with HCL support but wanted to see if somebody has come accross similar issue and what possible solution could be.
Our SAML login does just work fine on our current production/QA servers it’s not that we’re trying to implement SAML or anything like that.
THx for help/suggestions
I haven’t worked with your specific SAML provider but do have experience with ADFS & Okta - what I would look into for such infrastructure migration, especially if you all have it working on the old boxes, are:
-
Configuration on the WebUI server both within the WebUI and as client settings (_WebUI_AppServer_Hostname / _WebUIAppEnv_LOGIN_SESSION_TIMEOUT_SECONDS / _WebUIAppEnv_PLATFORM_HOST / _WebUIAppEnv_SAML_AUTHNCONTEXT), specifically the *authcontext as it can cause all sorts of strange errors.
-
SAML provider configuration - check specifically entrypoints within it and make sure the hostnames that you are using to authenticate with are all listed as accepted for all BigFix interfaces (console, WR, WebUI). Make sure if they are configured to be encrypted the shared certificate of encryption are sync’ed up.
-
Look into the trusted sites from wherever you are getting the errors - different SAML providers require different level of trusted sites (“intranet”, etc) for all of their sites (in some cases they have multiple components underneath so have multiple sites that need to be trusted - this is info you ought to be given by whoever manages the Identity Provider in your organization) because under the hood it does use web pages for the authentication, so if for example you are launching this console on a machine that doesn’t trust the identity/saml provider’s web pages it may result in this untrusted session even though both BigFix & SAML provider are perfectly configured.
Hope this give you a direction of the things you need to look into. Sorry couldn’t be of more help but every identity/SAML provider is different and can’t really be more specific without knowing yours. Support may help you decipher the actual errors in logs. Also, what is useful is the SAML tracer extension you can put in browsers (Chrome, Firefox, etc) as it allows you to trace the SAML request sent to SAML provider from BigFix and its response, and potentially spot mis-configuration/conflicting info but just FYI, it gets very complicated in a hurry and my suggestion (unless you are expert yourself in SAML assertions, tokens and so on) to engage your Identity Provider admin and look those together.
2 Likes
THx for the update, and indeed the issue was related to trusted sites. It’s now resolved. (I forgot to post the update earlier)
2 Likes
