Granting BES Console access via ``NT Authentication'' to non-Admin

Usage and Config Platform
1

(imported topic written by buck91)

I’m just core-dumping this here in case anybody else as SQL-Server-ignorant

as i should ask the lazyweb. May only apply to SQL Server 2000 [sic, to my

chagrin]

We wanted to grant access to BES Console operations to some people in our

group via NT Authentication of their domain accounts. This was working seam-

lessly enough for those of us initial operators, with no need to enter a password

at the database login prompt for the BFEnterprise database when firing up the

BES Console. But then it wouldn’t work for other users we similarly added using

the Site Admin tool, failing with an ODBC error box saying

Login failed for user …

and code 18456 etc. popping up when NT Authentication was attempted

As those of you who grok this SQL Server security are rolling your eyes back

into your head in immediate comprehension of (if it’s not just an artifact of our

ancient SQL Server set-up, that is), and as we were sorta suspecting: It was

b/c of not having Administrator on the SQL Server host machine: When we look-

ed at the SQL Server Enterprise admin tool’s Security->Logins configuration for

our BigFix SQL Server’s instance, we noted that there were ``standard users’’

defined for all the people we thought were happily NT-Authenticating (but who

obviously weren’t using the SQL Server password in the Properties for those

Logins). Seems we were being Authenticated using the Administrators ``win-

dows user’’, by virtue of our domain creds establishing us in that group. When

the hapless other dude we were trying to grant access to tried to authenticated,

he wasn’t in the Administrators group, so even though there was a ``standard

user’’ with his same (unqualified) user name, and even though the box would

indicate successful logons in its Security eventlog, it wasn’t connecting his Win-

dows creds to the database’s ``standard user’’, no matter the equality (mod-

ulo the domain\ prefix) of the account name

So we deleted his ``standard user’’ account, added an account with the same

login name but checked off Windows authentication against our domain, and

then allowed that new account access to the BFEnterprise database with the

same username (which Windows helpfully provided by default, by stripping the

domain\ prefix) as the one we’d deleted the standard user account of, and with

the same roles (public and bes_console_user)

Now i’ll have to check and see what happens when i replace my own ``standard

user’’ with a ``windows user’’ account. Wonder if i’ll lose access to all my fabu-

lous custom fixlets and presets and what not . . .

2

(imported comment written by BenKus)

Hey buck,

I am not sure if I got all that, but make sure your “default database” in your ODBC settings is “bfenterprise”.

Ben

3

(imported comment written by buck91)

Like i said, i’m a SQL-server-ignoramus (and mostly prefer keeping it that way),

so there’s probably a 2-word-way to say everything i tried saying that would dis-

pel all your confusion and make you say, ``You mean [two-word-way-of-saying-

everything-i-said]? Yeah. Duh. Everybody knows that.’’ But SQL Server argot’s

not in the Hacker’s Dictionary for me to reference yet, so i thought i’d relate my

experience from my own unenlightened perspective, in case it’s the same per-

spective someone may come to it by and, thus, be in the same ignorant condi-

tion as i and maybe, thus again, find what i said useful in just the way i said it

Or maybe i’m just adding to google’s workload (and perhaps sowing the weeds

that may spuriously pop up in Internet searches and annoy rather than help.

Maybe the follow-up is doing the same. Being google-indexed is a weighty re-

sponsiblity, come to think of it)