Hi
i am new in mssql7.Using sp_password i put login password
for the server.How can i put a password for a particular
database in the server.
Thank you.
Passwords & Logins are specific to Servers. Databases simply have users. So,
there is no such thing as passwords for database users.
Anith
Showing posts with label password. Show all posts
Showing posts with label password. Show all posts
Monday, March 12, 2012
Password's case sensitivity
Hi,
somehow my Sql Server's passwors are not case sensitive. I thought sql
server's login passwords are case sensitive.
Am I worng?
How do I change my SQL Server back to the case sensitive passwords?
Please help..
Thank you
SamHi
Passwords case sensitivity is based on the collation of the installation. If
you install with a non-case sensitive collation, the password will not be
cases sensitive.
Regards
Mike
"sam" wrote:
> Hi,
> somehow my Sql Server's passwors are not case sensitive. I thought sql
> server's login passwords are case sensitive.
> Am I worng?
> How do I change my SQL Server back to the case sensitive passwords?
> Please help..
> Thank you
> Sam|||Password case-sensitivity is determined by the default collation for the SQL
Server instance. It appears you have a case-insensitive collation.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:BDB6FA4B-D047-438F-A850-0E3FD0A8F49B@.microsoft.com...
> Hi,
> somehow my Sql Server's passwors are not case sensitive. I thought sql
> server's login passwords are case sensitive.
> Am I worng?
> How do I change my SQL Server back to the case sensitive passwords?
> Please help..
> Thank you
> Sam|||Thank you for your response. I think the Earlier I used all the SQL servers
which are upgraded from 7.0 to 2K and so the defautl collation of 7.0 was a
case sensitive. (Not usre right now).
But if I want to keep all my client data and other code to be case
-insensitive but all my login passwords to be case sensitive , can I do that
?
How can I do that?
Please let me know..
Thank you again..
Sam
"Dan Guzman" wrote:
> Password case-sensitivity is determined by the default collation for the S
QL
> Server instance. It appears you have a case-insensitive collation.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:BDB6FA4B-D047-438F-A850-0E3FD0A8F49B@.microsoft.com...
>
>|||To change the instance default collation after installation, you'll need to
either reinstall or rebuild the master database. This will create new
master, msdb and model databases.
Although you can run with mixed collations, this can lead to problems. The
tempdb collation will be the instance default so you might get errors due to
collation conflicts when using temp tables.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:96622B87-A747-4E23-8593-27221C2C10BD@.microsoft.com...[vbcol=seagreen]
> Thank you for your response. I think the Earlier I used all the SQL
> servers
> which are upgraded from 7.0 to 2K and so the defautl collation of 7.0 was
> a
> case sensitive. (Not usre right now).
> But if I want to keep all my client data and other code to be case
> -insensitive but all my login passwords to be case sensitive , can I do
> that?
> How can I do that?
> Please let me know..
> Thank you again..
> Sam
> "Dan Guzman" wrote:
>|||Thanks Dan,
But I think I did not put my question clearly. My Apologies.
I want to keep the collation of all the DBs on the server same as what I
have at present (case in-sensitive) but only all my login passwords should b
e
case sensitive.
Can I do that?
How?
Thank you
Sam
"Dan Guzman" wrote:
> To change the instance default collation after installation, you'll need t
o
> either reinstall or rebuild the master database. This will create new
> master, msdb and model databases.
> Although you can run with mixed collations, this can lead to problems. Th
e
> tempdb collation will be the instance default so you might get errors due
to
> collation conflicts when using temp tables.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:96622B87-A747-4E23-8593-27221C2C10BD@.microsoft.com...
>
>|||Running mixed collations is the only way to have case-sensitive passwords
and case-insensitive user database collations. The default collation of
your existing databases will not be changed after you reattach following a
master database rebuild or SQL Server reinstall.
However, as I mentioned in my previous response, mixed collations will have
other consequences. If you feel compelled to try this, be sure to
thoroughly test your applications before implementing this in production.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:B4EB814F-DCAD-4AF1-AB66-11C821BFD09D@.microsoft.com...[vbcol=seagreen]
> Thanks Dan,
> But I think I did not put my question clearly. My Apologies.
> I want to keep the collation of all the DBs on the server same as what I
> have at present (case in-sensitive) but only all my login passwords should
> be
> case sensitive.
> Can I do that?
> How?
> Thank you
> Sam
> "Dan Guzman" wrote:
>|||I understand your concern and thank you for your response.
Bu insterad of rebuilding my master database, Can I change the collation of
the password column of the sysxlogin table?
This is just a guess. I think you must have thought of this but I still want
to ask you this question.
"Dan Guzman" wrote:
> Running mixed collations is the only way to have case-sensitive passwords
> and case-insensitive user database collations. The default collation of
> your existing databases will not be changed after you reattach following a
> master database rebuild or SQL Server reinstall.
> However, as I mentioned in my previous response, mixed collations will hav
e
> other consequences. If you feel compelled to try this, be sure to
> thoroughly test your applications before implementing this in production.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:B4EB814F-DCAD-4AF1-AB66-11C821BFD09D@.microsoft.com...
>
>|||> Bu insterad of rebuilding my master database, Can I change the collation
> of
> the password column of the sysxlogin table?
Changing system table schema is not supported so you would this is at your
own risk. The supported method is a mixed collation environment with a
case-sensitive instance default collation and case-insensitive collation for
user databases. Of course, mixed collation caveats apply.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:D516F2B3-79BF-414E-B005-88AB683F5DD5@.microsoft.com...[vbcol=seagreen]
>I understand your concern and thank you for your response.
> Bu insterad of rebuilding my master database, Can I change the collation
> of
> the password column of the sysxlogin table?
> This is just a guess. I think you must have thought of this but I still
> want
> to ask you this question.
> "Dan Guzman" wrote:
>|||Thank you Dan,
I will try this in the development environment and then see how it works
before changing the collation for any thing else.
Thank you once again for your time and response.
Sam
"Dan Guzman" wrote:
> Changing system table schema is not supported so you would this is at your
> own risk. The supported method is a mixed collation environment with a
> case-sensitive instance default collation and case-insensitive collation f
or
> user databases. Of course, mixed collation caveats apply.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:D516F2B3-79BF-414E-B005-88AB683F5DD5@.microsoft.com...
>
>
somehow my Sql Server's passwors are not case sensitive. I thought sql
server's login passwords are case sensitive.
Am I worng?
How do I change my SQL Server back to the case sensitive passwords?
Please help..
Thank you
SamHi
Passwords case sensitivity is based on the collation of the installation. If
you install with a non-case sensitive collation, the password will not be
cases sensitive.
Regards
Mike
"sam" wrote:
> Hi,
> somehow my Sql Server's passwors are not case sensitive. I thought sql
> server's login passwords are case sensitive.
> Am I worng?
> How do I change my SQL Server back to the case sensitive passwords?
> Please help..
> Thank you
> Sam|||Password case-sensitivity is determined by the default collation for the SQL
Server instance. It appears you have a case-insensitive collation.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:BDB6FA4B-D047-438F-A850-0E3FD0A8F49B@.microsoft.com...
> Hi,
> somehow my Sql Server's passwors are not case sensitive. I thought sql
> server's login passwords are case sensitive.
> Am I worng?
> How do I change my SQL Server back to the case sensitive passwords?
> Please help..
> Thank you
> Sam|||Thank you for your response. I think the Earlier I used all the SQL servers
which are upgraded from 7.0 to 2K and so the defautl collation of 7.0 was a
case sensitive. (Not usre right now).
But if I want to keep all my client data and other code to be case
-insensitive but all my login passwords to be case sensitive , can I do that
?
How can I do that?
Please let me know..
Thank you again..
Sam
"Dan Guzman" wrote:
> Password case-sensitivity is determined by the default collation for the S
QL
> Server instance. It appears you have a case-insensitive collation.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:BDB6FA4B-D047-438F-A850-0E3FD0A8F49B@.microsoft.com...
>
>|||To change the instance default collation after installation, you'll need to
either reinstall or rebuild the master database. This will create new
master, msdb and model databases.
Although you can run with mixed collations, this can lead to problems. The
tempdb collation will be the instance default so you might get errors due to
collation conflicts when using temp tables.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:96622B87-A747-4E23-8593-27221C2C10BD@.microsoft.com...[vbcol=seagreen]
> Thank you for your response. I think the Earlier I used all the SQL
> servers
> which are upgraded from 7.0 to 2K and so the defautl collation of 7.0 was
> a
> case sensitive. (Not usre right now).
> But if I want to keep all my client data and other code to be case
> -insensitive but all my login passwords to be case sensitive , can I do
> that?
> How can I do that?
> Please let me know..
> Thank you again..
> Sam
> "Dan Guzman" wrote:
>|||Thanks Dan,
But I think I did not put my question clearly. My Apologies.
I want to keep the collation of all the DBs on the server same as what I
have at present (case in-sensitive) but only all my login passwords should b
e
case sensitive.
Can I do that?
How?
Thank you
Sam
"Dan Guzman" wrote:
> To change the instance default collation after installation, you'll need t
o
> either reinstall or rebuild the master database. This will create new
> master, msdb and model databases.
> Although you can run with mixed collations, this can lead to problems. Th
e
> tempdb collation will be the instance default so you might get errors due
to
> collation conflicts when using temp tables.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:96622B87-A747-4E23-8593-27221C2C10BD@.microsoft.com...
>
>|||Running mixed collations is the only way to have case-sensitive passwords
and case-insensitive user database collations. The default collation of
your existing databases will not be changed after you reattach following a
master database rebuild or SQL Server reinstall.
However, as I mentioned in my previous response, mixed collations will have
other consequences. If you feel compelled to try this, be sure to
thoroughly test your applications before implementing this in production.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:B4EB814F-DCAD-4AF1-AB66-11C821BFD09D@.microsoft.com...[vbcol=seagreen]
> Thanks Dan,
> But I think I did not put my question clearly. My Apologies.
> I want to keep the collation of all the DBs on the server same as what I
> have at present (case in-sensitive) but only all my login passwords should
> be
> case sensitive.
> Can I do that?
> How?
> Thank you
> Sam
> "Dan Guzman" wrote:
>|||I understand your concern and thank you for your response.
Bu insterad of rebuilding my master database, Can I change the collation of
the password column of the sysxlogin table?
This is just a guess. I think you must have thought of this but I still want
to ask you this question.
"Dan Guzman" wrote:
> Running mixed collations is the only way to have case-sensitive passwords
> and case-insensitive user database collations. The default collation of
> your existing databases will not be changed after you reattach following a
> master database rebuild or SQL Server reinstall.
> However, as I mentioned in my previous response, mixed collations will hav
e
> other consequences. If you feel compelled to try this, be sure to
> thoroughly test your applications before implementing this in production.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:B4EB814F-DCAD-4AF1-AB66-11C821BFD09D@.microsoft.com...
>
>|||> Bu insterad of rebuilding my master database, Can I change the collation
> of
> the password column of the sysxlogin table?
Changing system table schema is not supported so you would this is at your
own risk. The supported method is a mixed collation environment with a
case-sensitive instance default collation and case-insensitive collation for
user databases. Of course, mixed collation caveats apply.
Hope this helps.
Dan Guzman
SQL Server MVP
"sam" <sam@.discussions.microsoft.com> wrote in message
news:D516F2B3-79BF-414E-B005-88AB683F5DD5@.microsoft.com...[vbcol=seagreen]
>I understand your concern and thank you for your response.
> Bu insterad of rebuilding my master database, Can I change the collation
> of
> the password column of the sysxlogin table?
> This is just a guess. I think you must have thought of this but I still
> want
> to ask you this question.
> "Dan Guzman" wrote:
>|||Thank you Dan,
I will try this in the development environment and then see how it works
before changing the collation for any thing else.
Thank you once again for your time and response.
Sam
"Dan Guzman" wrote:
> Changing system table schema is not supported so you would this is at your
> own risk. The supported method is a mixed collation environment with a
> case-sensitive instance default collation and case-insensitive collation f
or
> user databases. Of course, mixed collation caveats apply.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "sam" <sam@.discussions.microsoft.com> wrote in message
> news:D516F2B3-79BF-414E-B005-88AB683F5DD5@.microsoft.com...
>
>
Passwords
How would i set a Database password that NOONE could see the Database layouts or field names and Data....i mean obviously there are hackers that can get programs to "Bust" into Most database but in general how would i prevent someone from looking at the layout and information?
My next question is a tough one, I THINK......I have a front end of VB6,......i want the back end to be SQL Server or SQL Sever Express 2005 When someone goes to login into my software product i would like to check a DB of valid User Names and Passwords... Now if I SQL Server running on TRUE Server, ie Win 2003 Server....could 50 people login at the same time to my software from 50 different PC accross the network? Is that what SQL Server means by Connections? or could everyone use the "sa" login?
My application handles all the locking and unlocking of databases and records in the DB...so i dont have to rely on SQL Server for that....essentionally SQL Server is a Data DUmp for me.......what does everyone think?
Also.....can you re-distribute the MDF files aka..Databases....like you would Access without having SQL Server installed....? If your front end is VB6 and the MDF will that work? b/c the software validates its login with the list in the DB not what SQL Considers a Login....Just like you can take a Access DB named "Test.MDB" rename it "Test.xxx" and re-distribute that wo whoever you want and they dont need the Access runtime to operate the VB6 software....obviously Access uses JET ...what does SQL Server Use.....couldnt you do the same thing with SQL Server?
Thanks All!!!
moving the thread to the database engine forum.|||If you distribute an application and database anyone having the binaries of those will be able to hack your application. Obfuscating might delay hacking.
What I have understood you will need SQL 2005 Express to be installed to attach mdf files.
According to documentation there is no limit for connections, you will need to configure it to allow remote connections though.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;914277
I would use SQL servers ability to lock/unlock data rather than program it myself.
|||hi . did u get the answer?I have same problem . please send me if u find|||
dragonsbb16 wrote:
1 How would i set a Database password that NOONE could see the Database layouts or field names and Data....i mean obviously there are hackers that can get programs to "Bust" into Most database but in general how would i prevent someone from looking at the layout and information?
2 My next question is a tough one, I THINK......I have a front end of VB6,......i want the back end to be SQL Server or SQL Sever Express 2005 When someone goes to login into my software product i would like to check a DB of valid User Names and Passwords... Now if I SQL Server running on TRUE Server, ie Win 2003 Server....could 50 people login at the same time to my software from 50 different PC accross the network? Is that what SQL Server means by Connections? or could everyone use the "sa" login?
My application handles all the locking and unlocking of databases and records in the DB...so i dont have to rely on SQL Server for that....essentionally SQL Server is a Data DUmp for me.......what does everyone think?
Also.....can you re-distribute the MDF files aka..Databases....like you would Access without having SQL Server installed....? If your front end is VB6 and the MDF will that work? b/c the software validates its login with the list in the DB not what SQL Considers a Login....Just like you can take a Access DB named "Test.MDB" rename it "Test.xxx" and re-distribute that wo whoever you want and they dont need the Access runtime to operate the VB6 software....obviously Access uses JET ...what does SQL Server Use.....couldnt you do the same thing with SQL Server?
Thanks All!!!
Edit : CONDENSED ANSWER - Lost long post due Session Timeout :(
1. You can grant to right to accounts to "view definitions" to various objects. Check "Permissions" in BOL
2. You can use ONE Account to Acces the DB and then check inside the DB if there is a User created for this person. This is used for most Forums for example. Security Tips : DONT give SA Accounts to everyone. 2. Storing Passwords in SQL Server you should take a look at Hashing (and Salting them)
3. Can be done. Ask yourself the important question : How likely is it that someone will mess with my data while i am messing with it and how long will it take to mess with it? If the answer is even the slightest "could be" then you need to think about locking. Either way. You will allways "piss off" one guy.. So you take the pick which one. Also for some applications locking is harder to implement (for example web access with connections that are closed between page calls). See Timestamp fields. and optimistic and pessimistic locking
4. To open a SQL 2005 mdf file you need any Version of SQL 2005. But express is free and can be downloaded. Check the installation instructions for command line installations if you wish to include it in a setup package.
Password: case sensitive
I installed SQL 2000 with default sort order. I though the password for SQL
logins is case-sensitive but it is not. Is that correct?
Thanks.Yes ...the passwords are not case sensitive... because of the collation
level . I beleive you might be able to change the collation for the password
column in sysxlogins table. Not tried it out but might be interesting if it
can be done
<Flicker> wrote in message news:OGqSaLqkDHA.708@.TK2MSFTNGP10.phx.gbl...
> I installed SQL 2000 with default sort order. I though the password for
SQL
> logins is case-sensitive but it is not. Is that correct?
> Thanks.
>
logins is case-sensitive but it is not. Is that correct?
Thanks.Yes ...the passwords are not case sensitive... because of the collation
level . I beleive you might be able to change the collation for the password
column in sysxlogins table. Not tried it out but might be interesting if it
can be done
<Flicker> wrote in message news:OGqSaLqkDHA.708@.TK2MSFTNGP10.phx.gbl...
> I installed SQL 2000 with default sort order. I though the password for
SQL
> logins is case-sensitive but it is not. Is that correct?
> Thanks.
>
Password validation failed
Hello Group,
we got the following message when running execute sp_adduser
Server: Msg 15118, Level 16, State 1, Line 1
Password validation failed. The password does not meet Windows policy
requirements because it is not complex enough.
Server: Msg 15007, Level 16, State 1, Procedure sp_adduser, Line 15
is there a way to turn this off on sql server(2005sp2) level.
Thanks in advancedTal shalom
Firstv of all in SQL Server 2005 using CREATE USER ... is recommended way
instead of sp_adduser.
Now regarding to the error you are getting, it is because you created LOGIN
with 'weak' password.
Please run in query builder (take a look at CHECK_POLICY=OFF parameter in
the BOL)
create login tal with password ='t',
go
create user Joe for login tal
drop user joe
drop login tal
"Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
news:%23sZnW6gkHHA.3452@.TK2MSFTNGP04.phx.gbl...
> Hello Group,
> we got the following message when running execute sp_adduser
> Server: Msg 15118, Level 16, State 1, Line 1
> Password validation failed. The password does not meet Windows policy
> requirements because it is not complex enough.
> Server: Msg 15007, Level 16, State 1, Procedure sp_adduser, Line 15
> is there a way to turn this off on sql server(2005sp2) level.
> Thanks in advanced
>
>
>
>|||Shalom Uri,
Thanks for the answer. I understand that CHECK_POLICY=OFF can be done per
individual login . However can it be done on the SERVER level for ALL
logins. This would help us not nodify the
code when migrationg from SQL 2000 to SQL 2005
Thanks in advanced
Tal,
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eApc3BhkHHA.2272@.TK2MSFTNGP02.phx.gbl...
> Tal shalom
> Firstv of all in SQL Server 2005 using CREATE USER ... is recommended
> way instead of sp_adduser.
> Now regarding to the error you are getting, it is because you created
> LOGIN with 'weak' password.
> Please run in query builder (take a look at CHECK_POLICY=OFF parameter in
> the BOL)
> create login tal with password ='t',
> go
> create user Joe for login tal
> drop user joe
> drop login tal
>
>
> "Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
> news:%23sZnW6gkHHA.3452@.TK2MSFTNGP04.phx.gbl...
>|||Hi Tal
By default CHECK_POLICY=ON.CHECK_POLICY are only enforced on Windows Server
2003 so I have no idea how to change it .
"Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
news:%23n$ddThkHHA.4904@.TK2MSFTNGP05.phx.gbl...
> Shalom Uri,
> Thanks for the answer. I understand that CHECK_POLICY=OFF can be done per
> individual login . However can it be done on the SERVER level for ALL
> logins. This would help us not nodify the
> code when migrationg from SQL 2000 to SQL 2005
> Thanks in advanced
> Tal,
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:eApc3BhkHHA.2272@.TK2MSFTNGP02.phx.gbl...
>
we got the following message when running execute sp_adduser
Server: Msg 15118, Level 16, State 1, Line 1
Password validation failed. The password does not meet Windows policy
requirements because it is not complex enough.
Server: Msg 15007, Level 16, State 1, Procedure sp_adduser, Line 15
is there a way to turn this off on sql server(2005sp2) level.
Thanks in advancedTal shalom
Firstv of all in SQL Server 2005 using CREATE USER ... is recommended way
instead of sp_adduser.
Now regarding to the error you are getting, it is because you created LOGIN
with 'weak' password.
Please run in query builder (take a look at CHECK_POLICY=OFF parameter in
the BOL)
create login tal with password ='t',
go
create user Joe for login tal
drop user joe
drop login tal
"Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
news:%23sZnW6gkHHA.3452@.TK2MSFTNGP04.phx.gbl...
> Hello Group,
> we got the following message when running execute sp_adduser
> Server: Msg 15118, Level 16, State 1, Line 1
> Password validation failed. The password does not meet Windows policy
> requirements because it is not complex enough.
> Server: Msg 15007, Level 16, State 1, Procedure sp_adduser, Line 15
> is there a way to turn this off on sql server(2005sp2) level.
> Thanks in advanced
>
>
>
>|||Shalom Uri,
Thanks for the answer. I understand that CHECK_POLICY=OFF can be done per
individual login . However can it be done on the SERVER level for ALL
logins. This would help us not nodify the
code when migrationg from SQL 2000 to SQL 2005
Thanks in advanced
Tal,
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:eApc3BhkHHA.2272@.TK2MSFTNGP02.phx.gbl...
> Tal shalom
> Firstv of all in SQL Server 2005 using CREATE USER ... is recommended
> way instead of sp_adduser.
> Now regarding to the error you are getting, it is because you created
> LOGIN with 'weak' password.
> Please run in query builder (take a look at CHECK_POLICY=OFF parameter in
> the BOL)
> create login tal with password ='t',
> go
> create user Joe for login tal
> drop user joe
> drop login tal
>
>
> "Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
> news:%23sZnW6gkHHA.3452@.TK2MSFTNGP04.phx.gbl...
>|||Hi Tal
By default CHECK_POLICY=ON.CHECK_POLICY are only enforced on Windows Server
2003 so I have no idea how to change it .
"Tal Bar-Or" <tal_baror@.hotmail.com> wrote in message
news:%23n$ddThkHHA.4904@.TK2MSFTNGP05.phx.gbl...
> Shalom Uri,
> Thanks for the answer. I understand that CHECK_POLICY=OFF can be done per
> individual login . However can it be done on the SERVER level for ALL
> logins. This would help us not nodify the
> code when migrationg from SQL 2000 to SQL 2005
> Thanks in advanced
> Tal,
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:eApc3BhkHHA.2272@.TK2MSFTNGP02.phx.gbl...
>
password synchronization - newbie question
We are using SQL Server authentication in a new W2k system that is replacing
a legacy UNIX system. I have a script that successfully recreates the user
accounts, but of course I have to default the password. Our security folks w
ill never agree to such a s
cheme, especially since I have read on this newsgroup that there is no way t
o force the users to change their passwords the first time they log on. Is t
here any way to port the users' UNIX passwords to SQL Server 2000? I can cap
ture the encrypted UNIX pas
swords, and was hoping there was a way to use them to populate the "password
" field of the master.sysxlogins table. Is the encryption used for UNIX in
any way compatible or "translate-able" to the encryption used by SQL Server?
This would probably be much easier if we were using Windows authentication,
but for our particular implementation, we have some other compelling reasons
not to.No the encryption algorithm is not going to be the same as any Unix based
system.
I would think that if you're writing a custom application you could force
the users to execute sp_password
at the same interval as the Unix system. But, if the users are simply
using Query Analyser and the other SQL tools,
there's no way to force this.
Yukon, the next release may address password policy enforcement that would
resolve issues like this.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thank you, Kevin. I'll talk to our developers about adding a call to sp_pass
word.
a legacy UNIX system. I have a script that successfully recreates the user
accounts, but of course I have to default the password. Our security folks w
ill never agree to such a s
cheme, especially since I have read on this newsgroup that there is no way t
o force the users to change their passwords the first time they log on. Is t
here any way to port the users' UNIX passwords to SQL Server 2000? I can cap
ture the encrypted UNIX pas
swords, and was hoping there was a way to use them to populate the "password
" field of the master.sysxlogins table. Is the encryption used for UNIX in
any way compatible or "translate-able" to the encryption used by SQL Server?
This would probably be much easier if we were using Windows authentication,
but for our particular implementation, we have some other compelling reasons
not to.No the encryption algorithm is not going to be the same as any Unix based
system.
I would think that if you're writing a custom application you could force
the users to execute sp_password
at the same interval as the Unix system. But, if the users are simply
using Query Analyser and the other SQL tools,
there's no way to force this.
Yukon, the next release may address password policy enforcement that would
resolve issues like this.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thank you, Kevin. I'll talk to our developers about adding a call to sp_pass
word.
password storage
Hi everybody
I am working on a school project where I am writing a software for course registration. I have different users Students, Faculty, and Administrator. They are allowed to log in using their ID and password. I was wondering how could i store password and userID securly. Should I store it in the individual table or separately?
Any suggestion is appreciated. Also, if somebody has worked on this kind of project, please let me know.
Thanks a lot[I am using SQL 2000.|||You need to use what is known as "one-way" encryption. The good news is that this is simpler than "two-way" encryption where it is must be possible to both encypt and decrypt a text string. In one-way encryption you apply a function to encrypt the string, and then store the encrypted result in your table. When someone submits their password to log in, you apply the same encryption function to their password and then compare it to the encrypted version stored with their personal record. If the two match, you let the dude in.
There are some built-in encryption functions within SQL Server which are simple to use. I think they are called dbencrypt and dbcompare, or something similiar. The disadvantage with these is that they are undocumented functions, and if you upgrade your database to a new version of sql server Microsoft does not guarantee that it will use the same encryption algorythm in future versions. The result (and this has happened in past upgrades...) is that the passwords your users submit no longer match the versions stored in your database. They must all be reset and new ones must be entered.
You can write your own one-way encryption algorythm, or I have one that you can use that is more secure than the one supplied with SQL Server. (The built-in function has been cracked and the solution is available on the internet.)
blindman
I am working on a school project where I am writing a software for course registration. I have different users Students, Faculty, and Administrator. They are allowed to log in using their ID and password. I was wondering how could i store password and userID securly. Should I store it in the individual table or separately?
Any suggestion is appreciated. Also, if somebody has worked on this kind of project, please let me know.
Thanks a lot[I am using SQL 2000.|||You need to use what is known as "one-way" encryption. The good news is that this is simpler than "two-way" encryption where it is must be possible to both encypt and decrypt a text string. In one-way encryption you apply a function to encrypt the string, and then store the encrypted result in your table. When someone submits their password to log in, you apply the same encryption function to their password and then compare it to the encrypted version stored with their personal record. If the two match, you let the dude in.
There are some built-in encryption functions within SQL Server which are simple to use. I think they are called dbencrypt and dbcompare, or something similiar. The disadvantage with these is that they are undocumented functions, and if you upgrade your database to a new version of sql server Microsoft does not guarantee that it will use the same encryption algorythm in future versions. The result (and this has happened in past upgrades...) is that the passwords your users submit no longer match the versions stored in your database. They must all be reset and new ones must be entered.
You can write your own one-way encryption algorythm, or I have one that you can use that is more secure than the one supplied with SQL Server. (The built-in function has been cracked and the solution is available on the internet.)
blindman
password storage
hai all!
i am going to store my user details to login from vb.net in a user table in sql.i would like to disguise the password column with dots or stars.how do i do that?kindly help.its urgent.i also need to compare the password right.so it should be readable by the program
i doubt if you can revert back to the original string from "dots or stars", what you could is to use an encrypting function...you may create your own or find one on the net|||
thanks yaar
give me some more info yaar|||That would depend on how you want to encrypt it. one way or 2 way?
and syntax will differ from language to language :)
cheers
i am going to store my user details to login from vb.net in a user table in sql.i would like to disguise the password column with dots or stars.how do i do that?kindly help.its urgent.i also need to compare the password right.so it should be readable by the program
Quote:
Originally Posted by pangsans
hai all!
i am going to store my user details to login from vb.net in a user table in sql.i would like to disguise the password column with dots or stars.how do i do that?kindly help.its urgent.i also need to compare the password right.so it should be readable by the program
i doubt if you can revert back to the original string from "dots or stars", what you could is to use an encrypting function...you may create your own or find one on the net|||
Quote:
Originally Posted by ck9663
i doubt if you can revert back to the original string from "dots or stars", what you could is to use an encrypting function...you may create your own or find one on the net
thanks yaar
give me some more info yaar|||That would depend on how you want to encrypt it. one way or 2 way?
and syntax will differ from language to language :)
cheers
password sql 2005
I am creating an db login called test to test some sripts. When I try to set
that password it says password validation failed. The password does not meet
windows policy requirenments because it is too short.
In sql 2005 is the password policy based on your windwows policy?
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to set
> that password it says password validation failed. The password does not meet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
>
It can be, but doesn't HAVE to be. Study the options that are available
when you create a new login.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I think that this is the behvior if the OS is windows 2003. In any
case you can use the option CHECK_POLICY = OFF when you create the
login. Here is an example:
CREATE LOGIN MyLogin WITH PASSWORD = 'MyPass', CHECK_POLICY = OFF
Adi
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to set
> that password it says password validation failed. The password does not meet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
that password it says password validation failed. The password does not meet
windows policy requirenments because it is too short.
In sql 2005 is the password policy based on your windwows policy?
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to set
> that password it says password validation failed. The password does not meet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
>
It can be, but doesn't HAVE to be. Study the options that are available
when you create a new login.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I think that this is the behvior if the OS is windows 2003. In any
case you can use the option CHECK_POLICY = OFF when you create the
login. Here is an example:
CREATE LOGIN MyLogin WITH PASSWORD = 'MyPass', CHECK_POLICY = OFF
Adi
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to set
> that password it says password validation failed. The password does not meet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
password sql 2005
I am creating an db login called test to test some sripts. When I try to se
t
that password it says password validation failed. The password does not mee
t
windows policy requirenments because it is too short.
In sql 2005 is the password policy based on your windwows policy?stoney wrote:
> I am creating an db login called test to test some sripts. When I try to
set
> that password it says password validation failed. The password does not m
eet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
>
It can be, but doesn't HAVE to be. Study the options that are available
when you create a new login.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I think that this is the behvior if the OS is windows 2003. In any
case you can use the option CHECK_POLICY = OFF when you create the
login. Here is an example:
CREATE LOGIN MyLogin WITH PASSWORD = 'MyPass', CHECK_POLICY = OFF
Adi
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to
set
> that password it says password validation failed. The password does not m
eet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
t
that password it says password validation failed. The password does not mee
t
windows policy requirenments because it is too short.
In sql 2005 is the password policy based on your windwows policy?stoney wrote:
> I am creating an db login called test to test some sripts. When I try to
set
> that password it says password validation failed. The password does not m
eet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
>
It can be, but doesn't HAVE to be. Study the options that are available
when you create a new login.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I think that this is the behvior if the OS is windows 2003. In any
case you can use the option CHECK_POLICY = OFF when you create the
login. Here is an example:
CREATE LOGIN MyLogin WITH PASSWORD = 'MyPass', CHECK_POLICY = OFF
Adi
stoney wrote:
> I am creating an db login called test to test some sripts. When I try to
set
> that password it says password validation failed. The password does not m
eet
> windows policy requirenments because it is too short.
> In sql 2005 is the password policy based on your windwows policy?
Password security
Have SQL 7.0 running on a Windows 2000 server. Users
access the database on a front end client that utilizes
SQL authentication. I see no password restriction
properties anywhere. I need to set some restrictions,
such as password expiration in 90 days, unique password
requirements, and minimum password lengths. Where do I
set up these restrictions? I can't find anything.Those options are not availble for SQL logins in SQL 7 or 2000. Odds are
we'll have it for the next major release.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
access the database on a front end client that utilizes
SQL authentication. I see no password restriction
properties anywhere. I need to set some restrictions,
such as password expiration in 90 days, unique password
requirements, and minimum password lengths. Where do I
set up these restrictions? I can't find anything.Those options are not availble for SQL logins in SQL 7 or 2000. Odds are
we'll have it for the next major release.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Friday, March 9, 2012
Password Role
In our Oracle DB's we have a role that we assign to users to set up password
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPMThis is why your applications should support Windows logins (i.e., give a Windows user or group
permission to login to SQL Server). In such Case, Windows handles this for you.
There is currently no support for password aging or policies for SQL server logins. There will be in
next version, though.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up password
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempts
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>> In our Oracle DB's we have a role that we assign to users to set up
>> password
>> limitations, see below
>> Expire in 90 days
>> Lock 5 days after expiration
>> Keep 5 passwords (not to reuse)
>> Keep passwords for unlimited time
>> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
>> character and at least 8 characters long Lock after 5 failed login
>> attempts
>> Lock for 30 days
>> can this be replicated in MS SQL Svr?
>> Thanks for any help,
>> MPM
>
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPMThis is why your applications should support Windows logins (i.e., give a Windows user or group
permission to login to SQL Server). In such Case, Windows handles this for you.
There is currently no support for password aging or policies for SQL server logins. There will be in
next version, though.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up password
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempts
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>> In our Oracle DB's we have a role that we assign to users to set up
>> password
>> limitations, see below
>> Expire in 90 days
>> Lock 5 days after expiration
>> Keep 5 passwords (not to reuse)
>> Keep passwords for unlimited time
>> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
>> character and at least 8 characters long Lock after 5 failed login
>> attempts
>> Lock for 30 days
>> can this be replicated in MS SQL Svr?
>> Thanks for any help,
>> MPM
>
Password Role
In our Oracle DB's we have a role that we assign to users to set up password
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPM
This is why your applications should support Windows logins (i.e., give a Windows user or group
permission to login to SQL Server). In such Case, Windows handles this for you.
There is currently no support for password aging or policies for SQL server logins. There will be in
next version, though.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up password
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempts
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM
|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPM
This is why your applications should support Windows logins (i.e., give a Windows user or group
permission to login to SQL Server). In such Case, Windows handles this for you.
There is currently no support for password aging or policies for SQL server logins. There will be in
next version, though.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up password
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempts
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM
|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>
Password Role
In our Oracle DB's we have a role that we assign to users to set up password
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPMThis is why your applications should support Windows logins (i.e., give a Wi
ndows user or group
permission to login to SQL Server). In such Case, Windows handles this for y
ou.
There is currently no support for password aging or policies for SQL server
logins. There will be in
next version, though.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up passwo
rd
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempt
s
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>
limitations, see below
Expire in 90 days
Lock 5 days after expiration
Keep 5 passwords (not to reuse)
Keep passwords for unlimited time
Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
character and at least 8 characters long Lock after 5 failed login attempts
Lock for 30 days
can this be replicated in MS SQL Svr?
Thanks for any help,
MPMThis is why your applications should support Windows logins (i.e., give a Wi
ndows user or group
permission to login to SQL Server). In such Case, Windows handles this for y
ou.
There is currently no support for password aging or policies for SQL server
logins. There will be in
next version, though.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
> In our Oracle DB's we have a role that we assign to users to set up passwo
rd
> limitations, see below
> Expire in 90 days
> Lock 5 days after expiration
> Keep 5 passwords (not to reuse)
> Keep passwords for unlimited time
> Enforce Password compliance, i.e. at least 1 Caps, 1 number, 1 special
> character and at least 8 characters long Lock after 5 failed login attempt
s
> Lock for 30 days
> can this be replicated in MS SQL Svr?
> Thanks for any help,
> MPM|||Hello Tibor,
In regards to MPM's question. If I use the windows log ins but want to
limit the users access via stored procdures is there a simple method of
accomplishing this? Currently my applcation uses several hunderd stored
procedures. Manaully setting them all is almost impossible which leave
creating a program to do it but every time a change is made to the
application all the user permissions have to be updated.
Also I am assuming SQL 2005 which should be release in Nov will have the
aging MPM talked about, will they also have a better way of setting security
for accessing selected data?
Regards,
John
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:Ouu1xoujFHA.476@.TK2MSFTNGP14.phx.gbl...
> This is why your applications should support Windows logins (i.e., give a
> Windows user or group permission to login to SQL Server). In such Case,
> Windows handles this for you.
> There is currently no support for password aging or policies for SQL
> server logins. There will be in next version, though.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "MANCPOLYMAN" <MANCPOLYMAN@.discussions.microsoft.com> wrote in message
> news:B86CA4E2-733F-4F9B-907B-BF02C678EFC3@.microsoft.com...
>
Password Required on Open of Linked Access mdb file
Any help would be great. I have an mdb file that is linked
to a table on my SQL Server which resides on a corporate
Web Server. I have a non-Windows Authenticated username
and password to the SQL Server database, so I have to
enter the password everytime I open the Access database
that links to the SQL Server. Is there anywhere to store
my password so that I can bypass having to enter it
everytime I open a linked mdb? Thanks!That information is stored in the tabledef properties of the linked
tables. One solution to this problem is to write code when the
application starts up. The code creates new tabledef objects,
supplying the user name and password (which you can collect from a
form). When the application shuts down, delete the tabledef objects.
This way security information persists only for the life of the
application instead of being permanently cached with the linked
tables.
--mary
On Mon, 3 May 2004 16:01:07 -0700, "mj"
<anonymous@.discussions.microsoft.com> wrote:
>Any help would be great. I have an mdb file that is linked
>to a table on my SQL Server which resides on a corporate
>Web Server. I have a non-Windows Authenticated username
>and password to the SQL Server database, so I have to
>enter the password everytime I open the Access database
>that links to the SQL Server. Is there anywhere to store
>my password so that I can bypass having to enter it
>everytime I open a linked mdb? Thanks!
to a table on my SQL Server which resides on a corporate
Web Server. I have a non-Windows Authenticated username
and password to the SQL Server database, so I have to
enter the password everytime I open the Access database
that links to the SQL Server. Is there anywhere to store
my password so that I can bypass having to enter it
everytime I open a linked mdb? Thanks!That information is stored in the tabledef properties of the linked
tables. One solution to this problem is to write code when the
application starts up. The code creates new tabledef objects,
supplying the user name and password (which you can collect from a
form). When the application shuts down, delete the tabledef objects.
This way security information persists only for the life of the
application instead of being permanently cached with the linked
tables.
--mary
On Mon, 3 May 2004 16:01:07 -0700, "mj"
<anonymous@.discussions.microsoft.com> wrote:
>Any help would be great. I have an mdb file that is linked
>to a table on my SQL Server which resides on a corporate
>Web Server. I have a non-Windows Authenticated username
>and password to the SQL Server database, so I have to
>enter the password everytime I open the Access database
>that links to the SQL Server. Is there anywhere to store
>my password so that I can bypass having to enter it
>everytime I open a linked mdb? Thanks!
Password Required on Open of Linked Access mdb file
Any help would be great. I have an mdb file that is linked
to a table on my SQL Server which resides on a corporate
Web Server. I have a non-Windows Authenticated username
and password to the SQL Server database, so I have to
enter the password everytime I open the Access database
that links to the SQL Server. Is there anywhere to store
my password so that I can bypass having to enter it
everytime I open a linked mdb? Thanks!
That information is stored in the tabledef properties of the linked
tables. One solution to this problem is to write code when the
application starts up. The code creates new tabledef objects,
supplying the user name and password (which you can collect from a
form). When the application shuts down, delete the tabledef objects.
This way security information persists only for the life of the
application instead of being permanently cached with the linked
tables.
--mary
On Mon, 3 May 2004 16:01:07 -0700, "mj"
<anonymous@.discussions.microsoft.com> wrote:
>Any help would be great. I have an mdb file that is linked
>to a table on my SQL Server which resides on a corporate
>Web Server. I have a non-Windows Authenticated username
>and password to the SQL Server database, so I have to
>enter the password everytime I open the Access database
>that links to the SQL Server. Is there anywhere to store
>my password so that I can bypass having to enter it
>everytime I open a linked mdb? Thanks!
to a table on my SQL Server which resides on a corporate
Web Server. I have a non-Windows Authenticated username
and password to the SQL Server database, so I have to
enter the password everytime I open the Access database
that links to the SQL Server. Is there anywhere to store
my password so that I can bypass having to enter it
everytime I open a linked mdb? Thanks!
That information is stored in the tabledef properties of the linked
tables. One solution to this problem is to write code when the
application starts up. The code creates new tabledef objects,
supplying the user name and password (which you can collect from a
form). When the application shuts down, delete the tabledef objects.
This way security information persists only for the life of the
application instead of being permanently cached with the linked
tables.
--mary
On Mon, 3 May 2004 16:01:07 -0700, "mj"
<anonymous@.discussions.microsoft.com> wrote:
>Any help would be great. I have an mdb file that is linked
>to a table on my SQL Server which resides on a corporate
>Web Server. I have a non-Windows Authenticated username
>and password to the SQL Server database, so I have to
>enter the password everytime I open the Access database
>that links to the SQL Server. Is there anywhere to store
>my password so that I can bypass having to enter it
>everytime I open a linked mdb? Thanks!
Password question
Morning,
Yesterday I got a call from a developer, telling me that the MSSQL Login
(for a application) that I set up for him on ServerA was not letting him
login. This exact same MSSQL Login was also set up on ServerB and it works
fine. After, a bit of time, of looking into it I stumbled on the problem and
fix. The fix was the password length for the SQL Server login account.
According to BOL, the password can be from 1 to 128 & alpha-numeric. The
password was a 19 alpha-numeric character password. This worked with no
problems on ServerB but failed on ServerA.
ServerB is a Windows 2000 server while ServerA is NT4 SP6.
So, I'm thinking that even though this was a MSSQL login and not a OS login,
the OS layer is playing a role in the authentication process. Does anyone
know if this is so and what are the limitations of NT4 password length?
Thanks for you time,I forgot to add, both are SQL2000 SP3.
"JoeyDBA" <JoeyDBA@.yahoo.com> wrote in message
news:uQErEJmbEHA.716@.TK2MSFTNGP11.phx.gbl...
> Morning,
> Yesterday I got a call from a developer, telling me that the MSSQL Login
> (for a application) that I set up for him on ServerA was not letting him
> login. This exact same MSSQL Login was also set up on ServerB and it works
> fine. After, a bit of time, of looking into it I stumbled on the problem
and
> fix. The fix was the password length for the SQL Server login account.
> According to BOL, the password can be from 1 to 128 & alpha-numeric. The
> password was a 19 alpha-numeric character password. This worked with no
> problems on ServerB but failed on ServerA.
> ServerB is a Windows 2000 server while ServerA is NT4 SP6.
> So, I'm thinking that even though this was a MSSQL login and not a OS
login,
> the OS layer is playing a role in the authentication process. Does anyone
> know if this is so and what are the limitations of NT4 password length?
> Thanks for you time,
>|||If it's a SQL login account we don't interact with the OS.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||As Kevin already pointed out, a SQL Login doesn't interact
with the OS.
One possibility, If the server uses a case-sensitive
collation, then your passwords are case sensitive as well.
-Sue
On Tue, 20 Jul 2004 09:02:59 -0500, "JoeyDBA"
<JoeyDBA@.yahoo.com> wrote:
>Morning,
>Yesterday I got a call from a developer, telling me that the MSSQL Login
>(for a application) that I set up for him on ServerA was not letting him
>login. This exact same MSSQL Login was also set up on ServerB and it works
>fine. After, a bit of time, of looking into it I stumbled on the problem an
d
>fix. The fix was the password length for the SQL Server login account.
>According to BOL, the password can be from 1 to 128 & alpha-numeric. The
>password was a 19 alpha-numeric character password. This worked with no
>problems on ServerB but failed on ServerA.
>ServerB is a Windows 2000 server while ServerA is NT4 SP6.
>So, I'm thinking that even though this was a MSSQL login and not a OS login
,
>the OS layer is playing a role in the authentication process. Does anyone
>know if this is so and what are the limitations of NT4 password length?
>Thanks for you time,
>|||ok - thanks for the feed back. I'll go back and play with it again.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:8SC7MkobEHA.2924@.cpmsftngxa06.phx.gbl...
> If it's a SQL login account we don't interact with the OS.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
Yesterday I got a call from a developer, telling me that the MSSQL Login
(for a application) that I set up for him on ServerA was not letting him
login. This exact same MSSQL Login was also set up on ServerB and it works
fine. After, a bit of time, of looking into it I stumbled on the problem and
fix. The fix was the password length for the SQL Server login account.
According to BOL, the password can be from 1 to 128 & alpha-numeric. The
password was a 19 alpha-numeric character password. This worked with no
problems on ServerB but failed on ServerA.
ServerB is a Windows 2000 server while ServerA is NT4 SP6.
So, I'm thinking that even though this was a MSSQL login and not a OS login,
the OS layer is playing a role in the authentication process. Does anyone
know if this is so and what are the limitations of NT4 password length?
Thanks for you time,I forgot to add, both are SQL2000 SP3.
"JoeyDBA" <JoeyDBA@.yahoo.com> wrote in message
news:uQErEJmbEHA.716@.TK2MSFTNGP11.phx.gbl...
> Morning,
> Yesterday I got a call from a developer, telling me that the MSSQL Login
> (for a application) that I set up for him on ServerA was not letting him
> login. This exact same MSSQL Login was also set up on ServerB and it works
> fine. After, a bit of time, of looking into it I stumbled on the problem
and
> fix. The fix was the password length for the SQL Server login account.
> According to BOL, the password can be from 1 to 128 & alpha-numeric. The
> password was a 19 alpha-numeric character password. This worked with no
> problems on ServerB but failed on ServerA.
> ServerB is a Windows 2000 server while ServerA is NT4 SP6.
> So, I'm thinking that even though this was a MSSQL login and not a OS
login,
> the OS layer is playing a role in the authentication process. Does anyone
> know if this is so and what are the limitations of NT4 password length?
> Thanks for you time,
>|||If it's a SQL login account we don't interact with the OS.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||As Kevin already pointed out, a SQL Login doesn't interact
with the OS.
One possibility, If the server uses a case-sensitive
collation, then your passwords are case sensitive as well.
-Sue
On Tue, 20 Jul 2004 09:02:59 -0500, "JoeyDBA"
<JoeyDBA@.yahoo.com> wrote:
>Morning,
>Yesterday I got a call from a developer, telling me that the MSSQL Login
>(for a application) that I set up for him on ServerA was not letting him
>login. This exact same MSSQL Login was also set up on ServerB and it works
>fine. After, a bit of time, of looking into it I stumbled on the problem an
d
>fix. The fix was the password length for the SQL Server login account.
>According to BOL, the password can be from 1 to 128 & alpha-numeric. The
>password was a 19 alpha-numeric character password. This worked with no
>problems on ServerB but failed on ServerA.
>ServerB is a Windows 2000 server while ServerA is NT4 SP6.
>So, I'm thinking that even though this was a MSSQL login and not a OS login
,
>the OS layer is playing a role in the authentication process. Does anyone
>know if this is so and what are the limitations of NT4 password length?
>Thanks for you time,
>|||ok - thanks for the feed back. I'll go back and play with it again.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:8SC7MkobEHA.2924@.cpmsftngxa06.phx.gbl...
> If it's a SQL login account we don't interact with the OS.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
Password protection on subscription-based Excel reports
I know RS doesn't offer this now.
I'm trying to figure out a workaround.
I need to:
-run a report on a schedule
-render it to excel
-password protect it
-email it
Subscriptions would be fine if it weren't for the password issue.
I've got DotNet code create the reprot and render it as an Excel
spreadsheet.
I've got code to password-protect the spreadsheet.
I want code to control the above code - to run at a certain time and
then deliver it via email. But it doesn't look like the Subscriptions
object will do this. Subscriptions appears to create the report and
deliver it, but not allow intervention for something like password
protection.My suggestion is that you use a script outside of Reporting Services to send
the mail. You can use CDO or .NET web mail. YOu can then schedule this using
Windows scheduler.
Try using the following code in a VB Console Application (you need to add a
reference of System.Web.dll to your project):
Imports System.Web.Mail
Module Module1
Dim oMail As MailMessage = New MailMessage
Sub Main()
oMail.From = "user@.mydomain.com"
oMail.To = "administrator@.classroom.com"
oMail.Subject = "Sending Using Web Mail"
oMail.BodyFormat = MailFormat.Text
oMail.Body = "Password protected file."
Dim myfile As String = "c:\Myfile.xls"
Dim oAttachment As MailAttachment = New MailAttachment(myfile)
oMail.Attachments.Add(oAttachment)
SmtpMail.SmtpServer = "10.1.1.200"
SmtpMail.Send(oMail)
oMail = Nothing
oAttachment = Nothing
End Sub
End Module
HTH
Charles Kangai, MCT, MCDBA
"Jay" wrote:
> I know RS doesn't offer this now.
> I'm trying to figure out a workaround.
> I need to:
> -run a report on a schedule
> -render it to excel
> -password protect it
> -email it
> Subscriptions would be fine if it weren't for the password issue.
> I've got DotNet code create the reprot and render it as an Excel
> spreadsheet.
> I've got code to password-protect the spreadsheet.
> I want code to control the above code - to run at a certain time and
> then deliver it via email. But it doesn't look like the Subscriptions
> object will do this. Subscriptions appears to create the report and
> deliver it, but not allow intervention for something like password
> protection.
>|||The best solution here is to create a custom delivery extension.
--
Peter Blackburn
Windows Server Systems - SQL Server MVP
Hitchhiker's Guide to SQL Server 2000 Reporting Services
http://www.sqlreportingservices.net
"Jay" <jaytaylor_it@.hotmail.com> wrote in message
news:a737af3c.0411291503.60317abc@.posting.google.com...
>I know RS doesn't offer this now.
> I'm trying to figure out a workaround.
> I need to:
> -run a report on a schedule
> -render it to excel
> -password protect it
> -email it
> Subscriptions would be fine if it weren't for the password issue.
> I've got DotNet code create the reprot and render it as an Excel
> spreadsheet.
> I've got code to password-protect the spreadsheet.
> I want code to control the above code - to run at a certain time and
> then deliver it via email. But it doesn't look like the Subscriptions
> object will do this. Subscriptions appears to create the report and
> deliver it, but not allow intervention for something like password
> protection.|||Thanks. This looks like the way to go. I think I"ll have to go outside RS. I
don't think a delivery extension can handle this.
"Charles Kangai" wrote:
> My suggestion is that you use a script outside of Reporting Services to send
> the mail. You can use CDO or .NET web mail. YOu can then schedule this using
> Windows scheduler.
> Try using the following code in a VB Console Application (you need to add a
> reference of System.Web.dll to your project):
> Imports System.Web.Mail
> Module Module1
> Dim oMail As MailMessage = New MailMessage
> Sub Main()
> oMail.From = "user@.mydomain.com"
> oMail.To = "administrator@.classroom.com"
> oMail.Subject = "Sending Using Web Mail"
> oMail.BodyFormat = MailFormat.Text
> oMail.Body = "Password protected file."
> Dim myfile As String = "c:\Myfile.xls"
> Dim oAttachment As MailAttachment = New MailAttachment(myfile)
> oMail.Attachments.Add(oAttachment)
> SmtpMail.SmtpServer = "10.1.1.200"
> SmtpMail.Send(oMail)
> oMail = Nothing
> oAttachment = Nothing
> End Sub
> End Module
>
> HTH
> Charles Kangai, MCT, MCDBA
>
> "Jay" wrote:
> > I know RS doesn't offer this now.
> >
> > I'm trying to figure out a workaround.
> >
> > I need to:
> >
> > -run a report on a schedule
> > -render it to excel
> > -password protect it
> > -email it
> >
> > Subscriptions would be fine if it weren't for the password issue.
> >
> > I've got DotNet code create the reprot and render it as an Excel
> > spreadsheet.
> > I've got code to password-protect the spreadsheet.
> >
> > I want code to control the above code - to run at a certain time and
> > then deliver it via email. But it doesn't look like the Subscriptions
> > object will do this. Subscriptions appears to create the report and
> > deliver it, but not allow intervention for something like password
> > protection.
> >|||Thanks. I don't get it, though - it looks like whatever custom delivery
extension I'd create, I'd still need to use RS's CreateSubscription method.
How woud I be able to insert password protection into the process when the
subscription kicks off?
"Peter Blackburn (www.sqlreportingservice" wrote:
> The best solution here is to create a custom delivery extension.
> --
> Peter Blackburn
> Windows Server Systems - SQL Server MVP
> Hitchhiker's Guide to SQL Server 2000 Reporting Services
> http://www.sqlreportingservices.net
>
> "Jay" <jaytaylor_it@.hotmail.com> wrote in message
> news:a737af3c.0411291503.60317abc@.posting.google.com...
> >I know RS doesn't offer this now.
> >
> > I'm trying to figure out a workaround.
> >
> > I need to:
> >
> > -run a report on a schedule
> > -render it to excel
> > -password protect it
> > -email it
> >
> > Subscriptions would be fine if it weren't for the password issue.
> >
> > I've got DotNet code create the reprot and render it as an Excel
> > spreadsheet.
> > I've got code to password-protect the spreadsheet.
> >
> > I want code to control the above code - to run at a certain time and
> > then deliver it via email. But it doesn't look like the Subscriptions
> > object will do this. Subscriptions appears to create the report and
> > deliver it, but not allow intervention for something like password
> > protection.
>
>
I'm trying to figure out a workaround.
I need to:
-run a report on a schedule
-render it to excel
-password protect it
-email it
Subscriptions would be fine if it weren't for the password issue.
I've got DotNet code create the reprot and render it as an Excel
spreadsheet.
I've got code to password-protect the spreadsheet.
I want code to control the above code - to run at a certain time and
then deliver it via email. But it doesn't look like the Subscriptions
object will do this. Subscriptions appears to create the report and
deliver it, but not allow intervention for something like password
protection.My suggestion is that you use a script outside of Reporting Services to send
the mail. You can use CDO or .NET web mail. YOu can then schedule this using
Windows scheduler.
Try using the following code in a VB Console Application (you need to add a
reference of System.Web.dll to your project):
Imports System.Web.Mail
Module Module1
Dim oMail As MailMessage = New MailMessage
Sub Main()
oMail.From = "user@.mydomain.com"
oMail.To = "administrator@.classroom.com"
oMail.Subject = "Sending Using Web Mail"
oMail.BodyFormat = MailFormat.Text
oMail.Body = "Password protected file."
Dim myfile As String = "c:\Myfile.xls"
Dim oAttachment As MailAttachment = New MailAttachment(myfile)
oMail.Attachments.Add(oAttachment)
SmtpMail.SmtpServer = "10.1.1.200"
SmtpMail.Send(oMail)
oMail = Nothing
oAttachment = Nothing
End Sub
End Module
HTH
Charles Kangai, MCT, MCDBA
"Jay" wrote:
> I know RS doesn't offer this now.
> I'm trying to figure out a workaround.
> I need to:
> -run a report on a schedule
> -render it to excel
> -password protect it
> -email it
> Subscriptions would be fine if it weren't for the password issue.
> I've got DotNet code create the reprot and render it as an Excel
> spreadsheet.
> I've got code to password-protect the spreadsheet.
> I want code to control the above code - to run at a certain time and
> then deliver it via email. But it doesn't look like the Subscriptions
> object will do this. Subscriptions appears to create the report and
> deliver it, but not allow intervention for something like password
> protection.
>|||The best solution here is to create a custom delivery extension.
--
Peter Blackburn
Windows Server Systems - SQL Server MVP
Hitchhiker's Guide to SQL Server 2000 Reporting Services
http://www.sqlreportingservices.net
"Jay" <jaytaylor_it@.hotmail.com> wrote in message
news:a737af3c.0411291503.60317abc@.posting.google.com...
>I know RS doesn't offer this now.
> I'm trying to figure out a workaround.
> I need to:
> -run a report on a schedule
> -render it to excel
> -password protect it
> -email it
> Subscriptions would be fine if it weren't for the password issue.
> I've got DotNet code create the reprot and render it as an Excel
> spreadsheet.
> I've got code to password-protect the spreadsheet.
> I want code to control the above code - to run at a certain time and
> then deliver it via email. But it doesn't look like the Subscriptions
> object will do this. Subscriptions appears to create the report and
> deliver it, but not allow intervention for something like password
> protection.|||Thanks. This looks like the way to go. I think I"ll have to go outside RS. I
don't think a delivery extension can handle this.
"Charles Kangai" wrote:
> My suggestion is that you use a script outside of Reporting Services to send
> the mail. You can use CDO or .NET web mail. YOu can then schedule this using
> Windows scheduler.
> Try using the following code in a VB Console Application (you need to add a
> reference of System.Web.dll to your project):
> Imports System.Web.Mail
> Module Module1
> Dim oMail As MailMessage = New MailMessage
> Sub Main()
> oMail.From = "user@.mydomain.com"
> oMail.To = "administrator@.classroom.com"
> oMail.Subject = "Sending Using Web Mail"
> oMail.BodyFormat = MailFormat.Text
> oMail.Body = "Password protected file."
> Dim myfile As String = "c:\Myfile.xls"
> Dim oAttachment As MailAttachment = New MailAttachment(myfile)
> oMail.Attachments.Add(oAttachment)
> SmtpMail.SmtpServer = "10.1.1.200"
> SmtpMail.Send(oMail)
> oMail = Nothing
> oAttachment = Nothing
> End Sub
> End Module
>
> HTH
> Charles Kangai, MCT, MCDBA
>
> "Jay" wrote:
> > I know RS doesn't offer this now.
> >
> > I'm trying to figure out a workaround.
> >
> > I need to:
> >
> > -run a report on a schedule
> > -render it to excel
> > -password protect it
> > -email it
> >
> > Subscriptions would be fine if it weren't for the password issue.
> >
> > I've got DotNet code create the reprot and render it as an Excel
> > spreadsheet.
> > I've got code to password-protect the spreadsheet.
> >
> > I want code to control the above code - to run at a certain time and
> > then deliver it via email. But it doesn't look like the Subscriptions
> > object will do this. Subscriptions appears to create the report and
> > deliver it, but not allow intervention for something like password
> > protection.
> >|||Thanks. I don't get it, though - it looks like whatever custom delivery
extension I'd create, I'd still need to use RS's CreateSubscription method.
How woud I be able to insert password protection into the process when the
subscription kicks off?
"Peter Blackburn (www.sqlreportingservice" wrote:
> The best solution here is to create a custom delivery extension.
> --
> Peter Blackburn
> Windows Server Systems - SQL Server MVP
> Hitchhiker's Guide to SQL Server 2000 Reporting Services
> http://www.sqlreportingservices.net
>
> "Jay" <jaytaylor_it@.hotmail.com> wrote in message
> news:a737af3c.0411291503.60317abc@.posting.google.com...
> >I know RS doesn't offer this now.
> >
> > I'm trying to figure out a workaround.
> >
> > I need to:
> >
> > -run a report on a schedule
> > -render it to excel
> > -password protect it
> > -email it
> >
> > Subscriptions would be fine if it weren't for the password issue.
> >
> > I've got DotNet code create the reprot and render it as an Excel
> > spreadsheet.
> > I've got code to password-protect the spreadsheet.
> >
> > I want code to control the above code - to run at a certain time and
> > then deliver it via email. But it doesn't look like the Subscriptions
> > object will do this. Subscriptions appears to create the report and
> > deliver it, but not allow intervention for something like password
> > protection.
>
>
Password protection
Basic, I know.....
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Password protection
Basic, I know.....
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".
Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>
|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".
Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>
|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Subscribe to:
Posts (Atom)