2 questions:
When you set up a new System DSN to a SQL Server db, you have the option of
selecting NT Authentication or SQL authentication.
1. I have been told that Microsoft recommends NT authentication. I haven't
been able to find anything on the MS site or BOL which says so, though.
Anyone got a link I could use which says this?
2. If you use NT authentication, your username (whoever happened to sign
into Windows when creating this DSN) is there, grayed out. Does that matter?
Is that name going to be used in any way when this ODBC connection is used
programatically?The best forum for this kind of question would be m.p.access.odbcclientsvr
or m.p.access.externaldata.
NT authentication is recommended because the password used doesn't travel in
clear text over the local network. If you have a virus or a trojan on your
LAN, this is the kind of thing that these malwares can catch.
When you use NT authentication, the active current account of the client
machine is always used for connecting to SQL-Server. The username is not
stored, so if you move the MDB file to another machine or if that you use
another account, the new active account will be used instead of the old one.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OqxxA13eHHA.3960@.TK2MSFTNGP02.phx.gbl...
>2 questions:
> When you set up a new System DSN to a SQL Server db, you have the option
> of selecting NT Authentication or SQL authentication.
> 1. I have been told that Microsoft recommends NT authentication. I haven't
> been able to find anything on the MS site or BOL which says so, though.
> Anyone got a link I could use which says this?
> 2. If you use NT authentication, your username (whoever happened to sign
> into Windows when creating this DSN) is there, grayed out. Does that
> matter? Is that name going to be used in any way when this ODBC connection
> is used programatically?
>|||> The best forum for this kind of question would be m.p.access.odbcclientsvr
> or m.p.access.externaldata.
Even if it's for SQL Server?|||Although I am not using Access, your answer most likely stil applies, so
thanks for the explanation.|||Even if you are using SQL-Server as the backend, your question is only
relevant to the type of client used as the Frontend. Most people using ODBC
links are using Access, hence my suggestion for the forums. However, if you
are using something else as for your frontend, then the best place would be
on a newsgroup about this type of client.
SQL-Server really doesn't care about knowing if the frontend client at the
other side is storing or not the password or if it will reuse the same
username when launched from another machine.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:uZJGnZ4eHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Although I am not using Access, your answer most likely stil applies, so
> thanks for the explanation.
>|||I am not sure what you mean. I am using SQL Server 2000 only. From the
server, (where my software is running), I set up an ODBC connection,
pointing to the database server. I am not using any front end.|||You are in the particular case where both the frontend and the backend are
on the same physical machine. However, for the purpose of etablishing an
ODBC connection and reusing or not the same user account when the client
will reetablish later the connection, this doesn't change anything.
In what context are you using this ODBC connection? Are you using it for
etablishing a linked server or if you are using it for another application?
However, if things are currently working properly, then there is no need to
bother yourself with this any more; particularly if you are already using a
Trusted Connection.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
>|||"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
Disregard the "other forum" suggestion. The basic information provided by
Sylvain applies, regardless of the application using ODBC to connect. It
also applies to any interface used to connect to sql server - odbc, dblib,
ole db, etc.
From a user perspective - the most important reason is that I don't need to
re-enter my security information (userID and password) every time I connect,
nor do I have to manage yet another password to access the dbms.|||> However, if things are currently working properly, then there is no need
> to bother yourself with this any more;
I'm not bothering myself. I'm only continuing this conversation because you
sent me over to an Access group, when I am not using Access.|||Hum, you asked in your OP if it does matter to etablish a DSN with or
without NT authentification when this DSN will be used later
programatically.
However, you didn't provide any info about what is exactly this
programmation; so the exact answer to your original question is *Yes*: it
Does matter because you can use this DSN to reconstruct a new DSN or to
etablish a DSN-Less connection with or without the same parameters.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OBP9yB6eHHA.3948@.TK2MSFTNGP03.phx.gbl...
>> However, if things are currently working properly, then there is no need
>> to bother yourself with this any more;
> I'm not bothering myself. I'm only continuing this conversation because
> you sent me over to an Access group, when I am not using Access.
>|||I think my question was misunderstood.
1. Is there an official Microsoft recommendation to use NT Authentication
rather than SQL Server authentication on the ODBC connection itself. The
answer is Yes, which I found after I posted.
2. When you choose NT authentication, the box at the bottom of that same
screen, where you would type in your username/password, is grayed out. But
you can still see the text of your login name. If grayed out, does this
login name get used in any way by the ODBC connection?|||« If grayed out, does this login name get used in any way by the ODBC
connection? »
No, any user name stored in a DSN will not be used when etablishing a
trusted connection; the current active account will always be used.
If you want to, you can change the rules - for exemple switching the DSN
from a trusted connection a SQL account; however, this is probably not what
you have in mind, otherwise, you wouldn't ask the question here.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:eJAR8$6eHHA.284@.TK2MSFTNGP05.phx.gbl...
>I think my question was misunderstood.
> 1. Is there an official Microsoft recommendation to use NT Authentication
> rather than SQL Server authentication on the ODBC connection itself. The
> answer is Yes, which I found after I posted.
> 2. When you choose NT authentication, the box at the bottom of that same
> screen, where you would type in your username/password, is grayed out. But
> you can still see the text of your login name. If grayed out, does this
> login name get used in any way by the ODBC connection?
>|||Thanks!
> No, any user name stored in a DSN will not be used when etablishing a
> trusted connection; the current active account will always be used.
