My apologies if this has been answered numerous times, but I have yet to find a solution. We are migrating from one BES server to another and by migrating I mean we are only moving clients. We are using a fresh database and new user accounts so I would like to use Windows Authenticaiton for everything. I have a domain account with local rights on the application server(all BF services are set to use this as Logon) and the account has the proper rights within the BF database. My question is on the BF console and the BF admin tool. Assuming ODBC is set up to use Windows Authentication, the only way I have been able to login to the console using Windows authentication is if I have first open the BF admin tool and create what is essentially a “duplicate” SQL account and password to create my private key. Am I incorrect in thinking there is no way to access the console WITHOUT creating this “duplicate” account which just essentially confirms that a-joeuser does indeed have permisions to access the console? Is there a way for site admins to also use Windows authentication? I have tried putting the login name in as Domain\a-joeuser, but it yells at me saying that such characthers are not allowed. Any info is greatly appreciated.
In any case, you will need to have a private key file (that is generated by the BigFix Admin tool)… but you can grant Windows users access using the “bes_console_user” role in the database so that they don’t need to have a separate SQL Server login.
If you are referring to opening the Admin tool and seeing that account, then no. I have one account in BigFix, the admin account. If am I understanding correctly, I should see an account for me in BF Admin tool AFTER I after I add one to the SQL Database with bes_console role?
Nope… sorry… it is more complicated than that… You always need to make the user in BES Admin (in every case)… When you add the user to the database role, you are enabling them to connect to BigFix with their NT credentials, BUT you still need to have a user/key created in BigFix.
Hopefully this will all get better when we enable a closer integration with our user scheme and Active Directory users.