Showing posts with label john. Show all posts
Showing posts with label john. Show all posts

Monday, March 26, 2012

Login failed for user (null). Reason: Not associated with a trusted SQL Server connection.

Anyone,

I have a user "john" whose machine is part of the "job" domain. He is
trying to establish an odbc connection to an MS SQL 2000 server on the
"school" domain. He uses Windows authentication to establish the odbc
connection however it gives the error "Login failed for user '(null)'.
Reason: Not associated with a trusted SQL Server connection."

I am guessing that the odbc connection is trying to pass the
credentials of job\john to the sql server. And since the sql server
is on the school domain it expects the credentials of school\john. Is
there anyway to specify the username and password so that this will
work even though the servers are on different domains without having
to trust the domains? Thanks in advance for
any help on this!!

TonyTo log into SQL Server, the user needs a SQL Server login. If your SQL
Server is set up to use NT Authentication or mixed mode authentication on
the Schools domain, then give John a login on the Schools domain and have
him login using those credentials.

"TBone" <tony.despain@.gmail.com> wrote in message
news:64b1ef71.0411261033.1044c9e9@.posting.google.c om...
> Anyone,
> I have a user "john" whose machine is part of the "job" domain. He is
> trying to establish an odbc connection to an MS SQL 2000 server on the
> "school" domain. He uses Windows authentication to establish the odbc
> connection however it gives the error "Login failed for user '(null)'.
> Reason: Not associated with a trusted SQL Server connection."
> I am guessing that the odbc connection is trying to pass the
> credentials of job\john to the sql server. And since the sql server
> is on the school domain it expects the credentials of school\john. Is
> there anyway to specify the username and password so that this will
> work even though the servers are on different domains without having
> to trust the domains? Thanks in advance for
> any help on this!!
> Tony|||Hi

The school domain needs to trust the job domain to allow this to occur. You
could use SQL Server authentication instead if you don't want this trust to
occur.

John

"TBone" <tony.despain@.gmail.com> wrote in message
news:64b1ef71.0411261033.1044c9e9@.posting.google.c om...
> Anyone,
> I have a user "john" whose machine is part of the "job" domain. He is
> trying to establish an odbc connection to an MS SQL 2000 server on the
> "school" domain. He uses Windows authentication to establish the odbc
> connection however it gives the error "Login failed for user '(null)'.
> Reason: Not associated with a trusted SQL Server connection."
> I am guessing that the odbc connection is trying to pass the
> credentials of job\john to the sql server. And since the sql server
> is on the school domain it expects the credentials of school\john. Is
> there anyway to specify the username and password so that this will
> work even though the servers are on different domains without having
> to trust the domains? Thanks in advance for
> any help on this!!
> Tony

Monday, March 12, 2012

login case senssitive

I would like to have a login page that is case senssitive. Right now the userName field in DB store Example :"John", but it allow the user to log in even if he types "john". Is the any SQL statement that select only if if name match and the case are match?::Is the any SQL statement that select only if if name match and the case are match?

=

I assume you use "Like". "Like" ignores case.

Now- otos - does your request make sense? I mean

::I would like to have a login page that is case senssitive. Right now the userName field in
::DB store Example :"John",

If "John" and "john" are different users, you open pandora's box for people mixing this up.

Our security systems ware case insensitive and store - besides the "DisplayName" also a "UniqueName" (name in lower cases), which triggers a unique constraint.

Having two users that differentiate their name only by casing sounds to me like a terrific bad idea. I can imagine the support calls coming in.|||The reason for case sensitive is because later on in my application i am using the user name and it has to be at certain form.
my select statement is:
"SELECT* FROM[FrenchRoast].[shikozel_db].[Chef] WHERE (([Chef].[Name] = @.Name) AND ([Chef].[Password] = @.password))"

I dont use like.
thank you.help...|||::The reason for case sensitive is because later on in my application i am using the user
::name and it has to be at certain form.

With all respect, this is no rason to make logins case sensitive. All my arguments are true - you willget into trouble with people spelling their name wrong when logging in.

Btw - if this:

::AND ([Chef].[Password] = @.password))"

indicates that you store the password in clear text in the database, then PLEASE get an introduction book on security. Storing the paswords in the database opens you up for a lot of not-funny things, including a tremendous amount of legal liability in case something does go wrong - without any legal defence, as it is gross neglect. Passwords should never ever be stored in the database.|||thank you for your comment. Where should i store passwords? any tutorial or books?|||::Where should i store passwords?

You should never ever store passwords. Look at how modern operating systems do it - they also never store passwords.|||Thona is correct, case sensitive passwords are a bad design and clear text pw's are equally as bad from a security stand point, so I recommend you read up on MD5.