Authentication Quirk

For some reason that I cannot figure out, some users are prompted for a
username and password when they request data in some reports. They can access
the reports OK, and choose the parameters OK, but then when they try to view
the report, they are prompted for credentials. If they click Cancel, the
report runs fine and the data is retrieved.
Any initial ideas?Do you have the datasource the report is using set to:
Connect Using:
The credentials supplied by the user running the report?
Adrian M.
"Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
news:5D8230E0-EA56-4673-A88F-91E7C54F9DE8@.microsoft.com...
> For some reason that I cannot figure out, some users are prompted for a
> username and password when they request data in some reports. They can
> access
> the reports OK, and choose the parameters OK, but then when they try to
> view
> the report, they are prompted for credentials. If they click Cancel, the
> report runs fine and the data is retrieved.
> Any initial ideas?|||Thanks for replying.
To answer your question, no. The data source has the "Credentials stored
securely in the report server" option selected with the additional "Use as
Windows credentials when connecting to the data source" also selected.
Thanks.
"Adrian M." wrote:
> Do you have the datasource the report is using set to:
> Connect Using:
> The credentials supplied by the user running the report?
> Adrian M.
> "Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
> news:5D8230E0-EA56-4673-A88F-91E7C54F9DE8@.microsoft.com...
> > For some reason that I cannot figure out, some users are prompted for a
> > username and password when they request data in some reports. They can
> > access
> > the reports OK, and choose the parameters OK, but then when they try to
> > view
> > the report, they are prompted for credentials. If they click Cancel, the
> > report runs fine and the data is retrieved.
> >
> > Any initial ideas?
>
>|||hmm, odd...
Some ideas, try the article http://support.microsoft.com/kb/842517
hth
Adrian M.
"Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
news:FBAE3BCE-F1D9-4B02-AAAF-44199ADF3744@.microsoft.com...
> Thanks for replying.
> To answer your question, no. The data source has the "Credentials stored
> securely in the report server" option selected with the additional "Use as
> Windows credentials when connecting to the data source" also selected.
> Thanks.
> "Adrian M." wrote:
>> Do you have the datasource the report is using set to:
>> Connect Using:
>> The credentials supplied by the user running the report?
>> Adrian M.
>> "Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
>> news:5D8230E0-EA56-4673-A88F-91E7C54F9DE8@.microsoft.com...
>> > For some reason that I cannot figure out, some users are prompted for a
>> > username and password when they request data in some reports. They can
>> > access
>> > the reports OK, and choose the parameters OK, but then when they try to
>> > view
>> > the report, they are prompted for credentials. If they click Cancel,
>> > the
>> > report runs fine and the data is retrieved.
>> >
>> > Any initial ideas?
>>|||Thanks for taking the time to help/post Adrian. For some unknown reason, the
problem has allegedly vanished. I say allegedly as a colleague informed me
yesterday that it was now working Ok for him but as I wasn't in the office
yesterday, I won't be able to confirm till Monday.
Fingers crossed.
"Adrian M." wrote:
> hmm, odd...
> Some ideas, try the article http://support.microsoft.com/kb/842517
> hth
> Adrian M.
> "Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
> news:FBAE3BCE-F1D9-4B02-AAAF-44199ADF3744@.microsoft.com...
> > Thanks for replying.
> >
> > To answer your question, no. The data source has the "Credentials stored
> > securely in the report server" option selected with the additional "Use as
> > Windows credentials when connecting to the data source" also selected.
> >
> > Thanks.
> >
> > "Adrian M." wrote:
> >
> >> Do you have the datasource the report is using set to:
> >>
> >> Connect Using:
> >> The credentials supplied by the user running the report?
> >>
> >> Adrian M.
> >>
> >> "Mark Parter" <MarkParter@.discussions.microsoft.com> wrote in message
> >> news:5D8230E0-EA56-4673-A88F-91E7C54F9DE8@.microsoft.com...
> >> > For some reason that I cannot figure out, some users are prompted for a
> >> > username and password when they request data in some reports. They can
> >> > access
> >> > the reports OK, and choose the parameters OK, but then when they try to
> >> > view
> >> > the report, they are prompted for credentials. If they click Cancel,
> >> > the
> >> > report runs fine and the data is retrieved.
> >> >
> >> > Any initial ideas?
> >>
> >>
> >>
>
>

authentication on SQL 2005

I have an installation program that during install was able to authenticate
to SQL 2000 and validate "sa" and password. But it won't do that on SQL
2005. The program installs directly on the same box as that the SQL runs. Is
there any reason why authentication should fail?
Comments Please,
Michael ValeCruzAre you getting an error back? Did you set an SA password when you
installed SQL2k5?|||No error other than invalid user name and password.
Yes the password is valid, I use it to connect with the SQL Server
Management Studio using SQL Server Authentication and the SA is set with
server role "sysadmin"
I am just wondering if there is something in SQL 2000 that is automatically
on that is not turned on in SQL 2005 for this authentication to take place.
"PSPDBA" <williambr@.state.pa.us> wrote in message
news:1147285864.526093.215500@.v46g2000cwv.googlegroups.com...
> Are you getting an error back? Did you set an SA password when you
> installed SQL2k5?
>|||You might want to check that the program isn't sending MachineName\sa
instead of sa. When connecting from the same machine, I can't think of
anything that needs to be turned on. Look through the Surface Area
Configuration Tool and see if theres something that stands out..|||I met install experience when I intalled first SQL Server 2005 and second
SQL Server 2000.
In this situation I think that SA direct to S2K5 by default
"PSPDBA"?? ??? ??:

> You might want to check that the program isn't sending MachineName\sa
> instead of sa. When connecting from the same machine, I can't think of
> anything that needs to be turned on. Look through the Surface Area
> Configuration Tool and see if theres something that stands out..
>

Authentication not working!

Hey there,

I have a table [user] in a SQLExpress database [Database.mdf] in the App_Data folder. There are two columns. [userId] and [password]. I want to authenticate the user who wants to log in through a Login control. the user should have his userId and password in the [user] table. I digged and made my code. but it doesn't work it keeps giving me that the user is not authenticated. i guess it has no errors. please tell me if you find the error. here is the code:

1protected void Login1_Authenticate(object sender, AuthenticateEventArgs e)2 {3 SqlConnection conExpress =new SqlConnection("Data Source=.\\SQLEXPRESS;Initial Catalog=Database;Integrated Security=True;User Instance=False");//Create the server connection45try6 {7string id_user = Login1.UserName.Trim();//Get the username from the control8string pass_user = Login1.Password;//get the Password from the control910 //These are a sql and connection Examples11string sql ="SELECT userId, password FROM user WHERE userId = @.param_Id AND password = @.param_Password";12 SqlCommand comSQL =new SqlCommand(sql, conExpress);//Create the sql command using sql string and sql connection1314 //Add the sql parameters15 comSQL.Parameters.AddWithValue("@.param_Id", id_user);//New on VS 2.016 comSQL.Parameters.AddWithValue("@.param_Password", pass_user);1718string cod_user ="";19string name_user ="";2021//Open database connection22 conExpress.Open();23 SqlDataReader dr = comSQL.ExecuteReader();24while (dr.Read())25 {26 cod_user = dr.GetValue(0).ToString();//The coduser is unique onto database table27 name_user = dr.GetValue(1).ToString();28 }29 conExpress.Close();//Close Database Connection30if (cod_user !="")//The user exist onto database31 {32//Create the session vars33 Session["coduser"] = cod_user;34 Session["nameuser"] = name_user;35 e.Authenticated =true;//Grant the access, Goes to DestinationPageUrl36 }37 }38catch(Exception)//On Login Error39 {40 e.Authenticated =false;//Confirm that you are out41 conExpress.Close();//On any error case, close the database connection42 }43 }

The way I've used the Login control with custom authentication (without MembershipProvider) is

processing the event of the Login Control:

protected

void Login1_LoggingIn(object sender,LoginCancelEventArgs e)

and if the credentials is valid i create the autheentication cookie:

FormsAuthentication.SetAuthCookie(userName,false);

and Redirect to the page user has requested.

If the credentials are wrong I set :

e.Cancel =

true;

and

Login1.FailureText =

"Unable to validate credentials";

I'm not sure this is the right way of doing that, but it works for me.

Hope this will help you.

Cheers,

Yani

sql

Authenticate against Active Directory

We are writing an enterprise application in which the user logs in by entering their username and password in a form. The user will enter their actual Active Directory credentials. I want to pass the username and password to a stored procedure that will check for a valid user account in an Active Directory. In Sql Server 2005 I know I could write a small .NET library that uses System.DirectoryServices , register it in SQL and access it from an stored procedure.

Can it be done in Sql server 2000?

The reason we are not just autheticating in the .NET code of the application is that we found that it does not work on Windows 98 cleints, hence the need to go through sql server.

Thanks

In SQL Server 2000, you can write an extended procedure. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_07_9rxv.asp for additional information on extended stored procedures.

Thanks
Laurentiu

Attempted Brute Force Attacks

It is not uncommon for me to review the event logs of our SQL Server and notice that someone is attempting to figure out the password for one of the SQL user accounts.......especially the "sa" username. But lately our SQL server has to be rebooted to where it is starting to become a nightly thing.

Last night the SQL Server was bombarded with attempted failed connections for 2 hours before it finally gave a blank BSOD. The SQL Server in question is in mixed mode and is a shared server. Strictly using Windows Authentication mode is not an option for us. The server has "beefy" hardware and has all updates and patches.

Sometimes, when I log on the server and notice that an IP address is making such attacks on the server, I put up an IPSEC policy against that IP. But that is not a good solution for reasons I dont think need to be outlined here.

So my question is, what can I do to better protect our SQL Server from these types of attacks? My thought on these attacks is not different than a DDOS that eventually takes the server down.

I have already done TCP/IP Hardening but not sure what else to do.

Thank you all for your replies.That sounds like Blaster to me. First order of business, patch your server, preferably to sp3a.

Next, consider killing port 1434 (and maybe 1433) at your firewall. That means that your SQL Server won't be visible outside the firewall, so this might not be a viable solution.

-PatP|||1434 is NIC Filtered as well as protected by IPSEC and Firewall.

1433 cannot be blocked becuase this is a public SQL Server used by many of our clients.

I already scanned the machine for Blaster and it is not affected. But thank you very much for your reply.|||Another solution might be to implement some form of challenge-response mechanism. For instance, if the access to the SQL Server is via a web page, have that web page (or one of its predecessors) enable the specific IP or MAC address for port 1433 for some arbitrary period of time. If the access is via a two-tier client, use an RPC to do the same thing. This will effecitvely cut off your SQL Server from all but pre-approved machines, and it is much less cumbersome for the user than using VPN to acheive similar results.

-PatP