BigFix Console failed to login with "Windows NT Authentication"

I have installed the BigFix version 9.5.11 and the SQL Database is installed on the Different server not on same BigFix server . one local user was created during the installation . I was able to login to the BigFix console using that local user .
I have integrated the BigFix server with LDAP and used the “Windows Authentication” option to login to the user . I got the Error message as "Failed to connect to https://xxxxxx.com:52311. Windows Error 0x80090303: The specified target is unknown or unreachable " .

Is that I should do some configuration as below link for the Remote database ,
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli+Endpoint+Manager/page/Remote+Database+Guide.

The specified target is unknown or unreachable

Check that your BigFix server is registered in DNS and that the firewalls allow connections to TCP and UDP port 52311.

see here: IBM Documentation

Hello thamayanthi,

This also might related to a permission to write/register the SPN (Service Principal Name).
Please take a look at the following KB article:
http://www-01.ibm.com/support/docview.wss?uid=swg21970300

Regards,
Vitaliy

Hi Vitaliy ,

Thanks for responding to my query . Actually I found the permission to write/register the SPN (Service Principal Name) issue and Manually set the SPN using the shared KB Article .
Once it is done , I have restarted the BES Root Server service and tried again to login . I got different error as below

.

Just to check, have you created an Operator account tied to your Windows/LDAP credentials yet? BigFix doesn’t allow everyone with a Windows credential, you still need to create the matching operator account before you can log on.

Hi Jason ,
You mean we need to create an operator inside the Bigfix console .

My id is the domain id and added my group in one of the BigFix AD groups and Assigned this AD groups to one of the roles inside the BigFix console .

One more thing , I forgot to mention here is , If I provide my domain id and password directly without selecting “Windows authentication” . I was able to login to the console successfully but if I use the "Windows Authentication " I am getting the Error.

Oh, ok, that’s good information.

I’d suggest you may need to open a Support case.

Are you using the default Service configuration for the BESRootServer service, where it uses LocalSystem to start, or do you have that tied to a service account? The SPN should be attached to either the computer account (if using LocalSystem) or to the service account (if you’ve changed the service logon user).

You may need to restart the BESRootServer service after creating the SPN, but I’m not certain on that point.

Also are you connecting to the BESRootServer using the exact SPN name that you registered, or do you have any kind of DNS Alias involved?

Hi Jason,

Thanks for quick response .
The BESRootServer Service is running as a Service Account (svc_ibm-bigfix) . I have requested the Domain controller team to provide Write access to SPN for this service account . I am attaching the SPN information for the Root server after manuall register of SPN

I am not sure how to check the below ,
Also are you connecting to the BESRootServer using the exact SPN name that you registered, or do you have any kind of DNS Alias involved?

Ah, I see (and it was super helpful but please remove the picture as it contains your real server names and domains in it).

So the instructions would assume that the service is running under the LocalSystem account, which is why you would use HOSTNAME$ as the account to attach to the spn. In your case, running under a dedicated Service Account, you’d need to configure the SPNs a bit differently.

First you need to remove the iem/hostname and iem/hostname.domainname SPNs from the HOSTNAME$ user account, which you should be able to do with the ‘setspn’ command. The service principal names have to be unique within the Domain, and even with the right permission your server won’t be able to update the service account’s SPN if there is an existing duplicate in the domain.

Then, you could either wait for your AD team to update permissions on the service account, or create the mapping manually. It’s been a while since I’ve gone through this, but my recollection is you should create the SPNs manually via

setspn -U -S iem/HOSTNAME domain\service-account-name
setspn -U -S iem/hostname.domainname.com domain\service-account-name

For reference, this is updating the user object for the “service-account-name” user account to add the “iem” Service (on your host) to that account. Which means that when your client requests a Kerberos ticket for the “iem” service on HOSTNAME, you receive a ticket which is encrypted with a key that the “service-account-name” (running the BigFix Server) can decrypt to authenticate you.

(For a time, “IEM” was a brand name for BigFix, “IBM Endpoint Manager”)

Hi Jason,

Thanks a lot for the SPN command . I have asked the Domain Controller team to remove the iem/hostname and iem/hostname.domainname SPNs from the HOSTNAME$ .

Then , Created the SPNs Manually with the command you have shared which fixed the issue .
I was able to login to the BigFix console using "Windows NT Authentication " option successfully.

Thank you for the support once again .

1 Like

Greetings everyone,
I have the same exact problem with the exception that the Windows Authentication was working before but after applying some critical updates to windows server and SQL server 2019 and then restarting Bigfix server.

What to check to get the the windows authentication to work again.

thanks

As with troubleshooting any patch issues, the first thing is to determine which patches were installed. Likely only patches on the Root Server and Domain Controllers matter in this case; if non-Windows-Integrated auth is still working, the connection between BigFix and SQL is still good.
With those patches identified, check the release notes for each, especially anything dealing with Kerberos or Active Directory rights. I’m not aware of any recent specific changes that affect BigFix or Kerberos Auth, but there could well be some kind of setup that’s off-normal in your environment.

Also check for anything else that changed around the same time, especially in DNS or your service logon account setup.

If you can identify which patches introduced the problem, try uninstalling them and see whether that corrects the problem, then engage Microsoft support for workarounds.

1 Like