Tuesday, March 27, 2012

Do I need two login ID's?

In installed SQL Server under my Win2003 Server userID, specifying NT
authentication. Then I down loaded MS JDBC, which requires Mixed mode
authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
can log in to the db using windows authentication, but my user ID and
password don't work under SQL Server authentication. I need a login ID that
works under SQL Server authentication so I can login via JDBC. Do I need to
establish another ID for this? Can it be the same as the windows ID?
Thanks
Jim
Jim Shaw wrote:
> In installed SQL Server under my Win2003 Server userID, specifying NT
> authentication. Then I down loaded MS JDBC, which requires Mixed
mode
> authentication, so I modifyed SQL Server to that. Now in Query
analyzer, I
> can log in to the db using windows authentication, but my user ID and
> password don't work under SQL Server authentication. I need a login
ID that
> works under SQL Server authentication so I can login via JDBC. Do I
need to
> establish another ID for this? Can it be the same as the windows ID?
The administrator user name is 'sa' and the default password is blank.
You can use that for SQL authentication. Or you can log in using
Windows authentication with jTDS or one of the commercial drivers.
Alin,
The jTDS Project.
|||You can (should) create a new SQL login to be used for JDBC.
Make sure that the sa login has a strong password
(alphanumeric, special characters, no known words) and then
hide that one away somewhere. Then create a new SQL login
that you can use for your SQL login connections. You don't
want to use the sa login for applications or daily use due
to security risks. Give the new SQL login just the
permissions it needs for the application.
-Sue
On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>In installed SQL Server under my Win2003 Server userID, specifying NT
>authentication. Then I down loaded MS JDBC, which requires Mixed mode
>authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
>can log in to the db using windows authentication, but my user ID and
>password don't work under SQL Server authentication. I need a login ID that
>works under SQL Server authentication so I can login via JDBC. Do I need to
>establish another ID for this? Can it be the same as the windows ID?
>Thanks
>Jim
>
|||Thanks Sue;
A good answer to my question. It will work for applications having only one
common role for all users.
Now I'm wondering what the best practice is for multiple roles at the
application level of abstraction, e.g., A Compensation System having roles
of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
1. I can do an application level login and manage the roles at the
application level; or,
2. Pass the authentication data in the application's connect to SQL Server
and manage the roles in the database; or,
3. Have multiple sub-applications, each with its own authentication, one for
each application defined role.
Any thoughts on this? I think I like #3 best. Makes development easier I
think. Maybe a combination of #2 & #3 ?
Thanks
Jim
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.4ax.com... [vbcol=seagreen]
> You can (should) create a new SQL login to be used for JDBC.
> Make sure that the sa login has a strong password
> (alphanumeric, special characters, no known words) and then
> hide that one away somewhere. Then create a new SQL login
> that you can use for your SQL login connections. You don't
> want to use the sa login for applications or daily use due
> to security risks. Give the new SQL login just the
> permissions it needs for the application.
> -Sue
> On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
> <jeshaw2@.comcast.net> wrote:
I[vbcol=seagreen]
that[vbcol=seagreen]
to
>
|||Not really. I just don't know enough specifics about your
application or security needs to say. At a high level, I'd
tend to go with first whatever provides the best security.
Next I'd go with ease of maintenance. I'd probably consider
ease of programming last. Years ago, programming everything
using the sa login and a blank password was the easiest for
development and used quite often. That certainly didn't work
out well. With business needs changing and issues such as
sarbanes oxley, I'd go more with whatever serves those areas
best.
-Sue
On Thu, 10 Feb 2005 11:32:04 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>Thanks Sue;
>A good answer to my question. It will work for applications having only one
>common role for all users.
>Now I'm wondering what the best practice is for multiple roles at the
>application level of abstraction, e.g., A Compensation System having roles
>of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
>1. I can do an application level login and manage the roles at the
>application level; or,
>2. Pass the authentication data in the application's connect to SQL Server
>and manage the roles in the database; or,
>3. Have multiple sub-applications, each with its own authentication, one for
>each application defined role.
>Any thoughts on this? I think I like #3 best. Makes development easier I
>think. Maybe a combination of #2 & #3 ?
>Thanks
>Jim
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
>news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.4ax.com.. .
>I
>that
>to
>

No comments:

Post a Comment