Hi folks,
Hoping someone can help.
I am wondering how you can set up windows ME so only the
users with a user name AND password can log on to my PC.
I have an issue where someone can just hit enter on a user
name and blank password and log on as a new user on my PC.
Is there any one out there who knows how I can limit use
to people that have a username AND password only' I am
hoping that I can set up the PC so that only people with
passwords can get onto the internet.
Thank you in advance for any assistance.Hi,
Can you please post this query to microsoft.public.windowsme.general group.
Thanks
Hari
MCDBA
"benn@.sympatico.ca" <anonymous@.discussions.microsoft.com> wrote in message
news:108b701c43fa5$9c3e9f80$a501280a@.phx
.gbl...
> Hi folks,
> Hoping someone can help.
> I am wondering how you can set up windows ME so only the
> users with a user name AND password can log on to my PC.
> I have an issue where someone can just hit enter on a user
> name and blank password and log on as a new user on my PC.
> Is there any one out there who knows how I can limit use
> to people that have a username AND password only' I am
> hoping that I can set up the PC so that only people with
> passwords can get onto the internet.
> Thank you in advance for any assistance.
Showing posts with label password. Show all posts
Showing posts with label password. Show all posts
Wednesday, March 21, 2012
logon window
Hi,
Whenever I click on a report to open it, it asks me for my Windows user ID
and password. I am connected to my desktop using my domain account and
report server is installed on SQL Server (domain controller as well).
The report is using NT authentication method.
Does anybody know how can I get rid of the login information window?
ThanksHi,
If You are using a shared datasource then rightclick on the datasource
->open
In the credentials tab check what is the option selected it should be "Use
Windows Authentication(integrated security)" If you have windows
authentication for you Sql server. If the option selected in this tab is
"Prompt for credentials" then the report promt for user credentials every
time it launches.
Incase u are not using shared datasource then u canget the above tab from
the data tab of the reportdesigner and then browsing on the datasource
dropdown.
Leme know if this solves ur problem
Thanks,
siaj
"Alex" wrote:
> Hi,
> Whenever I click on a report to open it, it asks me for my Windows user ID
> and password. I am connected to my desktop using my domain account and
> report server is installed on SQL Server (domain controller as well).
> The report is using NT authentication method.
> Does anybody know how can I get rid of the login information window?
> Thanks
>
>|||Make sure that your IE and IIS settings are correct. Within IE go to tools
internet options and then security. You will want to make sure the RS web
site is in your local intranet zone. Once it is there, make sure that the
"User Authentication" section of the settings are set to "Automatic logon
with current username and password." This tells IE to send the username and
password to the server. On IIS make sure that "Integrated Windows
authentication" is checked for the web site and uncheck the remaining boxes.
"Alex" wrote:
> Hi,
> Whenever I click on a report to open it, it asks me for my Windows user ID
> and password. I am connected to my desktop using my domain account and
> report server is installed on SQL Server (domain controller as well).
> The report is using NT authentication method.
> Does anybody know how can I get rid of the login information window?
> Thanks
>
>|||Thanks. This one solved my problem.
"MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> Make sure that your IE and IIS settings are correct. Within IE go to tools
> internet options and then security. You will want to make sure the RS web
> site is in your local intranet zone. Once it is there, make sure that the
> "User Authentication" section of the settings are set to "Automatic logon
> with current username and password." This tells IE to send the username
and
> password to the server. On IIS make sure that "Integrated Windows
> authentication" is checked for the web site and uncheck the remaining
boxes.
>
> "Alex" wrote:
> > Hi,
> >
> > Whenever I click on a report to open it, it asks me for my Windows user
ID
> > and password. I am connected to my desktop using my domain account and
> > report server is installed on SQL Server (domain controller as well).
> > The report is using NT authentication method.
> > Does anybody know how can I get rid of the login information window?
> >
> > Thanks
> >
> >
> >|||I have the same problem... and tried your suggestions with no luck.
Administrators and users can browse the Reports application. Administrators
can view the reports, but users get an authentication prompt.
Both the Reports and ReportServer application use Windows Integrated Auth
and have Anonymous disabled.
What would the difference be if the user can view Reports but not
ReportServer? (I tried https://{server}/ReportServer and still got the prompt)
There's got to be some difference between
"Alex" wrote:
> Thanks. This one solved my problem.
> "MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
> news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> > Make sure that your IE and IIS settings are correct. Within IE go to tools
> > internet options and then security. You will want to make sure the RS web
> > site is in your local intranet zone. Once it is there, make sure that the
> > "User Authentication" section of the settings are set to "Automatic logon
> > with current username and password." This tells IE to send the username
> and
> > password to the server. On IIS make sure that "Integrated Windows
> > authentication" is checked for the web site and uncheck the remaining
> boxes.
> >
> >
> > "Alex" wrote:
> >
> > > Hi,
> > >
> > > Whenever I click on a report to open it, it asks me for my Windows user
> ID
> > > and password. I am connected to my desktop using my domain account and
> > > report server is installed on SQL Server (domain controller as well).
> > > The report is using NT authentication method.
> > > Does anybody know how can I get rid of the login information window?
> > >
> > > Thanks
> > >
> > >
> > >
>
>|||I had to set up the user/group in question with permissions to Reports and
ReportServer in IIS.
"Peter Capazzi" wrote:
> I have the same problem... and tried your suggestions with no luck.
> Administrators and users can browse the Reports application. Administrators
> can view the reports, but users get an authentication prompt.
> Both the Reports and ReportServer application use Windows Integrated Auth
> and have Anonymous disabled.
> What would the difference be if the user can view Reports but not
> ReportServer? (I tried https://{server}/ReportServer and still got the prompt)
> There's got to be some difference between
> "Alex" wrote:
> > Thanks. This one solved my problem.
> >
> > "MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
> > news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> > > Make sure that your IE and IIS settings are correct. Within IE go to tools
> > > internet options and then security. You will want to make sure the RS web
> > > site is in your local intranet zone. Once it is there, make sure that the
> > > "User Authentication" section of the settings are set to "Automatic logon
> > > with current username and password." This tells IE to send the username
> > and
> > > password to the server. On IIS make sure that "Integrated Windows
> > > authentication" is checked for the web site and uncheck the remaining
> > boxes.
> > >
> > >
> > > "Alex" wrote:
> > >
> > > > Hi,
> > > >
> > > > Whenever I click on a report to open it, it asks me for my Windows user
> > ID
> > > > and password. I am connected to my desktop using my domain account and
> > > > report server is installed on SQL Server (domain controller as well).
> > > > The report is using NT authentication method.
> > > > Does anybody know how can I get rid of the login information window?
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> >
> >
> >
Whenever I click on a report to open it, it asks me for my Windows user ID
and password. I am connected to my desktop using my domain account and
report server is installed on SQL Server (domain controller as well).
The report is using NT authentication method.
Does anybody know how can I get rid of the login information window?
ThanksHi,
If You are using a shared datasource then rightclick on the datasource
->open
In the credentials tab check what is the option selected it should be "Use
Windows Authentication(integrated security)" If you have windows
authentication for you Sql server. If the option selected in this tab is
"Prompt for credentials" then the report promt for user credentials every
time it launches.
Incase u are not using shared datasource then u canget the above tab from
the data tab of the reportdesigner and then browsing on the datasource
dropdown.
Leme know if this solves ur problem
Thanks,
siaj
"Alex" wrote:
> Hi,
> Whenever I click on a report to open it, it asks me for my Windows user ID
> and password. I am connected to my desktop using my domain account and
> report server is installed on SQL Server (domain controller as well).
> The report is using NT authentication method.
> Does anybody know how can I get rid of the login information window?
> Thanks
>
>|||Make sure that your IE and IIS settings are correct. Within IE go to tools
internet options and then security. You will want to make sure the RS web
site is in your local intranet zone. Once it is there, make sure that the
"User Authentication" section of the settings are set to "Automatic logon
with current username and password." This tells IE to send the username and
password to the server. On IIS make sure that "Integrated Windows
authentication" is checked for the web site and uncheck the remaining boxes.
"Alex" wrote:
> Hi,
> Whenever I click on a report to open it, it asks me for my Windows user ID
> and password. I am connected to my desktop using my domain account and
> report server is installed on SQL Server (domain controller as well).
> The report is using NT authentication method.
> Does anybody know how can I get rid of the login information window?
> Thanks
>
>|||Thanks. This one solved my problem.
"MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> Make sure that your IE and IIS settings are correct. Within IE go to tools
> internet options and then security. You will want to make sure the RS web
> site is in your local intranet zone. Once it is there, make sure that the
> "User Authentication" section of the settings are set to "Automatic logon
> with current username and password." This tells IE to send the username
and
> password to the server. On IIS make sure that "Integrated Windows
> authentication" is checked for the web site and uncheck the remaining
boxes.
>
> "Alex" wrote:
> > Hi,
> >
> > Whenever I click on a report to open it, it asks me for my Windows user
ID
> > and password. I am connected to my desktop using my domain account and
> > report server is installed on SQL Server (domain controller as well).
> > The report is using NT authentication method.
> > Does anybody know how can I get rid of the login information window?
> >
> > Thanks
> >
> >
> >|||I have the same problem... and tried your suggestions with no luck.
Administrators and users can browse the Reports application. Administrators
can view the reports, but users get an authentication prompt.
Both the Reports and ReportServer application use Windows Integrated Auth
and have Anonymous disabled.
What would the difference be if the user can view Reports but not
ReportServer? (I tried https://{server}/ReportServer and still got the prompt)
There's got to be some difference between
"Alex" wrote:
> Thanks. This one solved my problem.
> "MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
> news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> > Make sure that your IE and IIS settings are correct. Within IE go to tools
> > internet options and then security. You will want to make sure the RS web
> > site is in your local intranet zone. Once it is there, make sure that the
> > "User Authentication" section of the settings are set to "Automatic logon
> > with current username and password." This tells IE to send the username
> and
> > password to the server. On IIS make sure that "Integrated Windows
> > authentication" is checked for the web site and uncheck the remaining
> boxes.
> >
> >
> > "Alex" wrote:
> >
> > > Hi,
> > >
> > > Whenever I click on a report to open it, it asks me for my Windows user
> ID
> > > and password. I am connected to my desktop using my domain account and
> > > report server is installed on SQL Server (domain controller as well).
> > > The report is using NT authentication method.
> > > Does anybody know how can I get rid of the login information window?
> > >
> > > Thanks
> > >
> > >
> > >
>
>|||I had to set up the user/group in question with permissions to Reports and
ReportServer in IIS.
"Peter Capazzi" wrote:
> I have the same problem... and tried your suggestions with no luck.
> Administrators and users can browse the Reports application. Administrators
> can view the reports, but users get an authentication prompt.
> Both the Reports and ReportServer application use Windows Integrated Auth
> and have Anonymous disabled.
> What would the difference be if the user can view Reports but not
> ReportServer? (I tried https://{server}/ReportServer and still got the prompt)
> There's got to be some difference between
> "Alex" wrote:
> > Thanks. This one solved my problem.
> >
> > "MAGrimsley" <MAGrimsley@.discussions.microsoft.com> wrote in message
> > news:11CE3B20-F0A0-4A9C-84D2-2DDDA6B3C226@.microsoft.com...
> > > Make sure that your IE and IIS settings are correct. Within IE go to tools
> > > internet options and then security. You will want to make sure the RS web
> > > site is in your local intranet zone. Once it is there, make sure that the
> > > "User Authentication" section of the settings are set to "Automatic logon
> > > with current username and password." This tells IE to send the username
> > and
> > > password to the server. On IIS make sure that "Integrated Windows
> > > authentication" is checked for the web site and uncheck the remaining
> > boxes.
> > >
> > >
> > > "Alex" wrote:
> > >
> > > > Hi,
> > > >
> > > > Whenever I click on a report to open it, it asks me for my Windows user
> > ID
> > > > and password. I am connected to my desktop using my domain account and
> > > > report server is installed on SQL Server (domain controller as well).
> > > > The report is using NT authentication method.
> > > > Does anybody know how can I get rid of the login information window?
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> >
> >
> >
Friday, March 9, 2012
Logins & password
I need to rebuild SQL Server from Enterprise Edition to Standard Edition.
Is there a way to save the passwords for all SQL logins (SQL
authentication)? I know that restoring master will get the password back
but does it defeat the purpose of changing the SQL Server edition? Thanks!This occur on the same server.
"Flicker" <hthan@.superioraccess.com> wrote in message
news:eI2znzXcDHA.2392@.TK2MSFTNGP10.phx.gbl...
> if you already have the std SQL box you can DTS to transfer logins.
> "Kevin" <kevin@.noemail.com> wrote in message
> news:eom3QuXcDHA.2820@.tk2msftngp13.phx.gbl...
> > I need to rebuild SQL Server from Enterprise Edition to Standard
Edition.
> > Is there a way to save the passwords for all SQL logins (SQL
> > authentication)? I know that restoring master will get the password
back
> > but does it defeat the purpose of changing the SQL Server edition?
> Thanks!
> >
> >
>|||HOW TO: Transfer Logins and Passwords Between Instances of SQL Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q246133#4
Create the stored procedures in the KB article then run sp_help_revlogin in
Query Analyzer with results as text. You can then copy and paste the results
into Notepad and save it. Once you've rebuilt you can run the script to add
your logins with previous SID and passwords
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Kevin" <kevin@.noemail.com> wrote in message
news:eom3QuXcDHA.2820@.tk2msftngp13.phx.gbl...
I need to rebuild SQL Server from Enterprise Edition to Standard Edition.
Is there a way to save the passwords for all SQL logins (SQL
authentication)? I know that restoring master will get the password back
but does it defeat the purpose of changing the SQL Server edition? Thanks!
Is there a way to save the passwords for all SQL logins (SQL
authentication)? I know that restoring master will get the password back
but does it defeat the purpose of changing the SQL Server edition? Thanks!This occur on the same server.
"Flicker" <hthan@.superioraccess.com> wrote in message
news:eI2znzXcDHA.2392@.TK2MSFTNGP10.phx.gbl...
> if you already have the std SQL box you can DTS to transfer logins.
> "Kevin" <kevin@.noemail.com> wrote in message
> news:eom3QuXcDHA.2820@.tk2msftngp13.phx.gbl...
> > I need to rebuild SQL Server from Enterprise Edition to Standard
Edition.
> > Is there a way to save the passwords for all SQL logins (SQL
> > authentication)? I know that restoring master will get the password
back
> > but does it defeat the purpose of changing the SQL Server edition?
> Thanks!
> >
> >
>|||HOW TO: Transfer Logins and Passwords Between Instances of SQL Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q246133#4
Create the stored procedures in the KB article then run sp_help_revlogin in
Query Analyzer with results as text. You can then copy and paste the results
into Notepad and save it. Once you've rebuilt you can run the script to add
your logins with previous SID and passwords
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Kevin" <kevin@.noemail.com> wrote in message
news:eom3QuXcDHA.2820@.tk2msftngp13.phx.gbl...
I need to rebuild SQL Server from Enterprise Edition to Standard Edition.
Is there a way to save the passwords for all SQL logins (SQL
authentication)? I know that restoring master will get the password back
but does it defeat the purpose of changing the SQL Server edition? Thanks!
Login/Account Lock
I have a scenario in my application that I need to know whether the account
is locked or not before the password is reset. If the account is locked the
app should pop up a msg.
how to programmatically determine that the account is locked or not in sql
server 2005.
Some thing like @.@.islocked or @.@.lock_status or any system SP
Can any one help me as this is an urgent case needed immediate response.
Thanks in advance.
Best regards,
venkateshVenkatesh (Venkatesh@.discussions.microsoft.com) writes:
> I have a scenario in my application that I need to know whether the
> account is locked or not before the password is reset. If the account is
> locked the app should pop up a msg.
> how to programmatically determine that the account is locked or not in sql
> server 2005.
> Some thing like @.@.islocked or @.@.lock_status or any system SP
> Can any one help me as this is an urgent case needed immediate response.
sys.server_principals.is_disabled seems like it could be what you are
asking for.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Hi Erland,
Thanks for the immediate response. But I think this will disable the login -
to disable the login we can very well use the below command
alter login [loginname] disable/enable
But what I want is to determine whether account is locked or not. When you
click the properties of a login in the status tab you would see the account
lock out check box. I want how programatically this can be determined
Correct me If I am wrong. In case if your code
sys.server_principals.is_disabled is used to lock the account could you give
me an example.
"Erland Sommarskog" wrote:
> Venkatesh (Venkatesh@.discussions.microsoft.com) writes:
> sys.server_principals.is_disabled seems like it could be what you are
> asking for.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx
>|||You can use select LOGINPROPERTY('test', N'IsLocked').
Thanks!
--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005|||Venkatesh (Venkatesh@.discussions.microsoft.com) writes:
> Thanks for the immediate response. But I think this will disable the
> login - to disable the login we can very well use the below command
> alter login [loginname] disable/enable
> But what I want is to determine whether account is locked or not. When
> you click the properties of a login in the status tab you would see the
> account lock out check box. I want how programatically this can be
> determined
> Correct me If I am wrong. In case if your code
> sys.server_principals.is_disabled is used to lock the account could you
> give me an example.
OK, I admit that I took a gamble on that one.
It seems that Mohit did a better job on reading the manual that you and I
did.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
is locked or not before the password is reset. If the account is locked the
app should pop up a msg.
how to programmatically determine that the account is locked or not in sql
server 2005.
Some thing like @.@.islocked or @.@.lock_status or any system SP
Can any one help me as this is an urgent case needed immediate response.
Thanks in advance.
Best regards,
venkateshVenkatesh (Venkatesh@.discussions.microsoft.com) writes:
> I have a scenario in my application that I need to know whether the
> account is locked or not before the password is reset. If the account is
> locked the app should pop up a msg.
> how to programmatically determine that the account is locked or not in sql
> server 2005.
> Some thing like @.@.islocked or @.@.lock_status or any system SP
> Can any one help me as this is an urgent case needed immediate response.
sys.server_principals.is_disabled seems like it could be what you are
asking for.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Hi Erland,
Thanks for the immediate response. But I think this will disable the login -
to disable the login we can very well use the below command
alter login [loginname] disable/enable
But what I want is to determine whether account is locked or not. When you
click the properties of a login in the status tab you would see the account
lock out check box. I want how programatically this can be determined
Correct me If I am wrong. In case if your code
sys.server_principals.is_disabled is used to lock the account could you give
me an example.
"Erland Sommarskog" wrote:
> Venkatesh (Venkatesh@.discussions.microsoft.com) writes:
> sys.server_principals.is_disabled seems like it could be what you are
> asking for.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx
>|||You can use select LOGINPROPERTY('test', N'IsLocked').
Thanks!
--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005|||Venkatesh (Venkatesh@.discussions.microsoft.com) writes:
> Thanks for the immediate response. But I think this will disable the
> login - to disable the login we can very well use the below command
> alter login [loginname] disable/enable
> But what I want is to determine whether account is locked or not. When
> you click the properties of a login in the status tab you would see the
> account lock out check box. I want how programatically this can be
> determined
> Correct me If I am wrong. In case if your code
> sys.server_principals.is_disabled is used to lock the account could you
> give me an example.
OK, I admit that I took a gamble on that one.
It seems that Mohit did a better job on reading the manual that you and I
did.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
login with diffrent password
Hi
Is it possible that two databases have same login name user but with
diffrent password'
thanksNo. But it is possible (not recommended) for two different logins to exist
each used by the same individual with different passwords. What problem are
you having?
HTH
Jerry
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
> Hi
> Is it possible that two databases have same login name user but with
> diffrent password'
> thanks
>|||No. What would that accomplish?
What if one of them changed their password, and happened to choose the same
password as the other login? How would you differentiate them then?
A
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
> Hi
> Is it possible that two databases have same login name user but with
> diffrent password'
> thanks
>|||In my application,user can create diffrent databases..
if the login name and password are the same,then a user can login to both of
databases...I don't want this..
I want every user can login his database..
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> No. But it is possible (not recommended) for two different logins to
exist
> each used by the same individual with different passwords. What problem
are
> you having?
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
>|||Logins are not database specific; you can only have a login name appear once
per instance.
Perhaps you are talking about users, not logins. There is a difference.
Please see Books Online.
A
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..|||Well unfortunately that is the way SQL Server's security works. One login -
one password maps to one-to-many databases.
HTH
Jerry
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..
> "Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
> news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> exist
> are
>|||I wrote this a few years back...this will help you undestand SQL Server's
security:
SQL Server 2000 Operations Guide - Security Administration
http://www.microsoft.com/technet/pr...in/sqlops3.mspx
HTH
Jerry
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:esKPUt00FHA.2428@.tk2msftngp13.phx.gbl...
> Well unfortunately that is the way SQL Server's security works. One
> login - one password maps to one-to-many databases.
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
>|||The user could still login to multiple databases, even they did have
multiple logins with different passwords. It is possible using ALTER
DATABASE.. to configure a database to SINGLE_USER mode so that only one user
may login at a time. However, there is no feature to restrict a login to
only one database, unless you drop them as a user or deny permissions to all
databases but one. I would suggest that you steer away from a system design
that allows users to create their own databases, becuase the management
requirements of this design could quickly get out of hand.
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..
> "Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
> news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> exist
> are
>|||I know what user does..the question is that you can login to many database
with one login name and password..
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:OSfXer00FHA.3568@.TK2MSFTNGP15.phx.gbl...
> Logins are not database specific; you can only have a login name appear
once
> per instance.
> Perhaps you are talking about users, not logins. There is a difference.
> Please see Books Online.
> A
>
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
both
>|||thanks all for their replying.
If I use application role,I think I can manage the problem..
what's your opinion'
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> No. But it is possible (not recommended) for two different logins to
exist
> each used by the same individual with different passwords. What problem
are
> you having?
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
>
Is it possible that two databases have same login name user but with
diffrent password'
thanksNo. But it is possible (not recommended) for two different logins to exist
each used by the same individual with different passwords. What problem are
you having?
HTH
Jerry
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
> Hi
> Is it possible that two databases have same login name user but with
> diffrent password'
> thanks
>|||No. What would that accomplish?
What if one of them changed their password, and happened to choose the same
password as the other login? How would you differentiate them then?
A
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
> Hi
> Is it possible that two databases have same login name user but with
> diffrent password'
> thanks
>|||In my application,user can create diffrent databases..
if the login name and password are the same,then a user can login to both of
databases...I don't want this..
I want every user can login his database..
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> No. But it is possible (not recommended) for two different logins to
exist
> each used by the same individual with different passwords. What problem
are
> you having?
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
>|||Logins are not database specific; you can only have a login name appear once
per instance.
Perhaps you are talking about users, not logins. There is a difference.
Please see Books Online.
A
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..|||Well unfortunately that is the way SQL Server's security works. One login -
one password maps to one-to-many databases.
HTH
Jerry
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..
> "Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
> news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> exist
> are
>|||I wrote this a few years back...this will help you undestand SQL Server's
security:
SQL Server 2000 Operations Guide - Security Administration
http://www.microsoft.com/technet/pr...in/sqlops3.mspx
HTH
Jerry
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:esKPUt00FHA.2428@.tk2msftngp13.phx.gbl...
> Well unfortunately that is the way SQL Server's security works. One
> login - one password maps to one-to-many databases.
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
>|||The user could still login to multiple databases, even they did have
multiple logins with different passwords. It is possible using ALTER
DATABASE.. to configure a database to SINGLE_USER mode so that only one user
may login at a time. However, there is no feature to restrict a login to
only one database, unless you drop them as a user or deny permissions to all
databases but one. I would suggest that you steer away from a system design
that allows users to create their own databases, becuase the management
requirements of this design could quickly get out of hand.
"perspolis" <rezarms@.hotmail.com> wrote in message
news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
> In my application,user can create diffrent databases..
> if the login name and password are the same,then a user can login to both
> of
> databases...I don't want this..
> I want every user can login his database..
> "Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
> news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> exist
> are
>|||I know what user does..the question is that you can login to many database
with one login name and password..
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:OSfXer00FHA.3568@.TK2MSFTNGP15.phx.gbl...
> Logins are not database specific; you can only have a login name appear
once
> per instance.
> Perhaps you are talking about users, not logins. There is a difference.
> Please see Books Online.
> A
>
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%233pn1p00FHA.3000@.TK2MSFTNGP12.phx.gbl...
both
>|||thanks all for their replying.
If I use application role,I think I can manage the problem..
what's your opinion'
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:eUM2k#z0FHA.3336@.TK2MSFTNGP12.phx.gbl...
> No. But it is possible (not recommended) for two different logins to
exist
> each used by the same individual with different passwords. What problem
are
> you having?
> HTH
> Jerry
> "perspolis" <rezarms@.hotmail.com> wrote in message
> news:%23l9uW8z0FHA.3000@.TK2MSFTNGP12.phx.gbl...
>
Wednesday, March 7, 2012
Login with a case sensitive password with a Stored Procedure
I have a stored procedure that validates a user login against a username and password field.
How can I ensure case sensitivity in the stored procedure for the password field?Hi
How can I ensure case sensitivity in the stored procedure for the password field?Hi
If you cast both the inputted password and the stored password as varbinary, if they are not the same case they will not match.|||OK i tried it but how do I change the the user input from a string a varbinary for the
Stored procedure input parameter ?|||I figured it out.
Thank you, merkin|||If you use MD5 to encrypt the password then it will be case sensitive and won't be crackable if the table becomes visible to a hacker.
Monday, February 20, 2012
Login Problem
Hi All,
I am not able to login into my SQL Server using Query Analyser using a valid
SA Password. But My web application is working fine.
Any Idea why it is happening.
Thanks & Regards
Balaji Prabhu.TBalaji,
Your message this thin... what's the error message ? Are you timing out whi
le attempting to connect ?
Need more info.
I am not able to login into my SQL Server using Query Analyser using a valid
SA Password. But My web application is working fine.
Any Idea why it is happening.
Thanks & Regards
Balaji Prabhu.TBalaji,
Your message this thin... what's the error message ? Are you timing out whi
le attempting to connect ?
Need more info.
login password changed
We have a testing server. Sometimes we need to move some logins and users
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
ThanksI think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> > We have a testing server. Sometimes we need to move some logins and
users
> > from production server to the testing server, I use transfer login or
copy
> > objects dts,
> > Then some of our web pages cannot be acceessed by the logins.
> >
> > And I checked there was no orphaned users.
> >
> > Finally found the password is changed while transfer, change it to
> oringinal
> > password, then it works.
> >
> > My question is why the password changed during transfer or moving logins
> or
> > users?
> > We didn't change it manually at all.
> >
> > Is this a bug ? or is this a problem many users have?
> >
> > Thanks
>|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored proc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SIDs
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> > I think this is done for security reasons. The passwords after transfer
> > gets encrypted that way SA or equivalent user will reset the passwords.
> > Thereby implicit privileges will not be available to the login without the
> > administrator's knowledge.
> >
> > Bhanu.
> >
> >
> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> > > We have a testing server. Sometimes we need to move some logins and
> users
> > > from production server to the testing server, I use transfer login or
> copy
> > > objects dts,
> > > Then some of our web pages cannot be acceessed by the logins.
> > >
> > > And I checked there was no orphaned users.
> > >
> > > Finally found the password is changed while transfer, change it to
> > oringinal
> > > password, then it works.
> > >
> > > My question is why the password changed during transfer or moving logins
> > or
> > > users?
> > > We didn't change it manually at all.
> > >
> > > Is this a bug ? or is this a problem many users have?
> > >
> > > Thanks
> >
> >
>
>|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
irrelevant for SQL server logins.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this problem
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
>> You may avoid this problem by using the master..sp_help_revlogin stored proc
>> available from Microsoft (reference Knowledge Base Article 246133). This
>> stored procedure will generate a script on the source server that can be
>> executed on the target server to create the logins with their original SIDs
>> and passwords.
>> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
>> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
>> > I think this is done for security reasons. The passwords after transfer
>> > gets encrypted that way SA or equivalent user will reset the passwords.
>> > Thereby implicit privileges will not be available to the login without the
>> > administrator's knowledge.
>> >
>> > Bhanu.
>> >
>> >
>> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
>> > > We have a testing server. Sometimes we need to move some logins and
>> users
>> > > from production server to the testing server, I use transfer login or
>> copy
>> > > objects dts,
>> > > Then some of our web pages cannot be acceessed by the logins.
>> > >
>> > > And I checked there was no orphaned users.
>> > >
>> > > Finally found the password is changed while transfer, change it to
>> > oringinal
>> > > password, then it works.
>> > >
>> > > My question is why the password changed during transfer or moving logins
>> > or
>> > > users?
>> > > We didn't change it manually at all.
>> > >
>> > > Is this a bug ? or is this a problem many users have?
>> > >
>> > > Thanks
>> >
>> >
>>|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
â?¢ Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name with
the new domain in the sp_grantlogin statements. Because the integrated logins
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the following
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> > Second I know this stored procedure, it says it works in only domain
> > environment,
> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> > First, actually we have a udl file that we know what the passwords are.
> > The file works good on the production server, but not the testing server,
> > where we moved to. After I changed the password according to it on the
> > testing server, it works. So there is no issue about encrypt and reset. I do
> > user sa or sys admin account to do all the transfers.
> >
> > Second I know this stored procedure, it says it works in only domain
> > environment, while ours is in workgroup enviroment, so guess not work for us.
> > The dba here said we don't want to put sql servers in public domain for
> > security reasons.
> >
> > So really want to know if this is a bug or other users may have this problem
> > too?
> > I mean after transfering log in, password changed'
> > Thanks
> >
> >
> >
> >
> >
> >
> > "TomB" wrote:
> >
> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
> >> available from Microsoft (reference Knowledge Base Article 246133). This
> >> stored procedure will generate a script on the source server that can be
> >> executed on the target server to create the logins with their original SIDs
> >> and passwords.
> >>
> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> >> > I think this is done for security reasons. The passwords after transfer
> >> > gets encrypted that way SA or equivalent user will reset the passwords.
> >> > Thereby implicit privileges will not be available to the login without the
> >> > administrator's knowledge.
> >> >
> >> > Bhanu.
> >> >
> >> >
> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> >> > > We have a testing server. Sometimes we need to move some logins and
> >> users
> >> > > from production server to the testing server, I use transfer login or
> >> copy
> >> > > objects dts,
> >> > > Then some of our web pages cannot be acceessed by the logins.
> >> > >
> >> > > And I checked there was no orphaned users.
> >> > >
> >> > > Finally found the password is changed while transfer, change it to
> >> > oringinal
> >> > > password, then it works.
> >> > >
> >> > > My question is why the password changed during transfer or moving logins
> >> > or
> >> > > users?
> >> > > We didn't change it manually at all.
> >> > >
> >> > > Is this a bug ? or is this a problem many users have?
> >> > >
> >> > > Thanks
> >> >
> >> >
> >>
> >>
> >>
>
>|||That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
need to edit the file so you get the correct machines name in the account name.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQL
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name with
> the new domain in the sp_grantlogin statements. Because the integrated logins
> granted access in the new domain will not have the same SID as the logins in
> the original domain, the database users will be orphaned from these logins.
> To resolve these orphaned users, see the articles referenced in the following
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likely
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
>> > Second I know this stored procedure, it says it works in only domain
>> > environment,
>> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
>> irrelevant for SQL server logins.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>> > First, actually we have a udl file that we know what the passwords are.
>> > The file works good on the production server, but not the testing server,
>> > where we moved to. After I changed the password according to it on the
>> > testing server, it works. So there is no issue about encrypt and reset. I do
>> > user sa or sys admin account to do all the transfers.
>> >
>> > Second I know this stored procedure, it says it works in only domain
>> > environment, while ours is in workgroup enviroment, so guess not work for us.
>> > The dba here said we don't want to put sql servers in public domain for
>> > security reasons.
>> >
>> > So really want to know if this is a bug or other users may have this problem
>> > too?
>> > I mean after transfering log in, password changed'
>> > Thanks
>> >
>> >
>> >
>> >
>> >
>> >
>> > "TomB" wrote:
>> >
>> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
>> >> available from Microsoft (reference Knowledge Base Article 246133). This
>> >> stored procedure will generate a script on the source server that can be
>> >> executed on the target server to create the logins with their original SIDs
>> >> and passwords.
>> >>
>> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
>> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
>> >> > I think this is done for security reasons. The passwords after transfer
>> >> > gets encrypted that way SA or equivalent user will reset the passwords.
>> >> > Thereby implicit privileges will not be available to the login without the
>> >> > administrator's knowledge.
>> >> >
>> >> > Bhanu.
>> >> >
>> >> >
>> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
>> >> > > We have a testing server. Sometimes we need to move some logins and
>> >> users
>> >> > > from production server to the testing server, I use transfer login or
>> >> copy
>> >> > > objects dts,
>> >> > > Then some of our web pages cannot be acceessed by the logins.
>> >> > >
>> >> > > And I checked there was no orphaned users.
>> >> > >
>> >> > > Finally found the password is changed while transfer, change it to
>> >> > oringinal
>> >> > > password, then it works.
>> >> > >
>> >> > > My question is why the password changed during transfer or moving logins
>> >> > or
>> >> > > users?
>> >> > > We didn't change it manually at all.
>> >> > >
>> >> > > Is this a bug ? or is this a problem many users have?
>> >> > >
>> >> > > Thanks
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
> need to edit the file so you get the correct machines name in the account name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
> > Here is what I copied from the article, two paragraphs:
> >
> >
> > Important The SQL Server 2000 destination server cannot be running the
> > 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> > SQL Server 2000 are not available. If you are importing logins from an
> > instance of SQL Server that is on a separate computer, your instance of SQL
> > Server will must be running under a Domain Account to complete the task.
> >
> >
> > Remarks
> > . Review the output script carefully before you run it on the destination
> > SQL Server. If you have to transfer logins to an instance of SQL Server in a
> > different domain than the source instance of SQL Server, edit the script
> > generated by the sp_help_revlogin procedure, and replace the domain name with
> > the new domain in the sp_grantlogin statements. Because the integrated logins
> > granted access in the new domain will not have the same SID as the logins in
> > the original domain, the database users will be orphaned from these logins.
> > To resolve these orphaned users, see the articles referenced in the following
> > bullet item. If you transfer integrated logins between instances of SQL
> > Servers in the same domain, the same SID is used and the user is not likely
> > to be orphaned.
> >
> >
> >
> >
> > "Tibor Karaszi" wrote:
> >
> >> > Second I know this stored procedure, it says it works in only domain
> >> > environment,
> >>
> >> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> >> irrelevant for SQL server logins.
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://www.solidqualitylearning.com/
> >>
> >>
> >> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> >> > First, actually we have a udl file that we know what the passwords are.
> >> > The file works good on the production server, but not the testing server,
> >> > where we moved to. After I changed the password according to it on the
> >> > testing server, it works. So there is no issue about encrypt and reset. I do
> >> > user sa or sys admin account to do all the transfers.
> >> >
> >> > Second I know this stored procedure, it says it works in only domain
> >> > environment, while ours is in workgroup enviroment, so guess not work for us.
> >> > The dba here said we don't want to put sql servers in public domain for
> >> > security reasons.
> >> >
> >> > So really want to know if this is a bug or other users may have this problem
> >> > too?
> >> > I mean after transfering log in, password changed'
> >> > Thanks
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > "TomB" wrote:
> >> >
> >> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
> >> >> available from Microsoft (reference Knowledge Base Article 246133). This
> >> >> stored procedure will generate a script on the source server that can be
> >> >> executed on the target server to create the logins with their original SIDs
> >> >> and passwords.
> >> >>
> >> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> >> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> >> >> > I think this is done for security reasons. The passwords after transfer
> >> >> > gets encrypted that way SA or equivalent user will reset the passwords.
> >> >> > Thereby implicit privileges will not be available to the login without the
> >> >> > administrator's knowledge.
> >> >> >
> >> >> > Bhanu.
> >> >> >
> >> >> >
> >> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> >> >> > > We have a testing server. Sometimes we need to move some logins and
> >> >> users
> >> >> > > from production server to the testing server, I use transfer login or
> >> >> copy
> >> >> > > objects dts,
> >> >> > > Then some of our web pages cannot be acceessed by the logins.
> >> >> > >
> >> >> > > And I checked there was no orphaned users.
> >> >> > >
> >> >> > > Finally found the password is changed while transfer, change it to
> >> >> > oringinal
> >> >> > > password, then it works.
> >> >> > >
> >> >> > > My question is why the password changed during transfer or moving logins
> >> >> > or
> >> >> > > users?
> >> >> > > We didn't change it manually at all.
> >> >> > >
> >> >> > > Is this a bug ? or is this a problem many users have?
> >> >> > >
> >> >> > > Thanks
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
ThanksI think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> > We have a testing server. Sometimes we need to move some logins and
users
> > from production server to the testing server, I use transfer login or
copy
> > objects dts,
> > Then some of our web pages cannot be acceessed by the logins.
> >
> > And I checked there was no orphaned users.
> >
> > Finally found the password is changed while transfer, change it to
> oringinal
> > password, then it works.
> >
> > My question is why the password changed during transfer or moving logins
> or
> > users?
> > We didn't change it manually at all.
> >
> > Is this a bug ? or is this a problem many users have?
> >
> > Thanks
>|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored proc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SIDs
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> > I think this is done for security reasons. The passwords after transfer
> > gets encrypted that way SA or equivalent user will reset the passwords.
> > Thereby implicit privileges will not be available to the login without the
> > administrator's knowledge.
> >
> > Bhanu.
> >
> >
> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> > > We have a testing server. Sometimes we need to move some logins and
> users
> > > from production server to the testing server, I use transfer login or
> copy
> > > objects dts,
> > > Then some of our web pages cannot be acceessed by the logins.
> > >
> > > And I checked there was no orphaned users.
> > >
> > > Finally found the password is changed while transfer, change it to
> > oringinal
> > > password, then it works.
> > >
> > > My question is why the password changed during transfer or moving logins
> > or
> > > users?
> > > We didn't change it manually at all.
> > >
> > > Is this a bug ? or is this a problem many users have?
> > >
> > > Thanks
> >
> >
>
>|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
irrelevant for SQL server logins.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this problem
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
>> You may avoid this problem by using the master..sp_help_revlogin stored proc
>> available from Microsoft (reference Knowledge Base Article 246133). This
>> stored procedure will generate a script on the source server that can be
>> executed on the target server to create the logins with their original SIDs
>> and passwords.
>> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
>> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
>> > I think this is done for security reasons. The passwords after transfer
>> > gets encrypted that way SA or equivalent user will reset the passwords.
>> > Thereby implicit privileges will not be available to the login without the
>> > administrator's knowledge.
>> >
>> > Bhanu.
>> >
>> >
>> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
>> > > We have a testing server. Sometimes we need to move some logins and
>> users
>> > > from production server to the testing server, I use transfer login or
>> copy
>> > > objects dts,
>> > > Then some of our web pages cannot be acceessed by the logins.
>> > >
>> > > And I checked there was no orphaned users.
>> > >
>> > > Finally found the password is changed while transfer, change it to
>> > oringinal
>> > > password, then it works.
>> > >
>> > > My question is why the password changed during transfer or moving logins
>> > or
>> > > users?
>> > > We didn't change it manually at all.
>> > >
>> > > Is this a bug ? or is this a problem many users have?
>> > >
>> > > Thanks
>> >
>> >
>>|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
â?¢ Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name with
the new domain in the sp_grantlogin statements. Because the integrated logins
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the following
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> > Second I know this stored procedure, it says it works in only domain
> > environment,
> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> > First, actually we have a udl file that we know what the passwords are.
> > The file works good on the production server, but not the testing server,
> > where we moved to. After I changed the password according to it on the
> > testing server, it works. So there is no issue about encrypt and reset. I do
> > user sa or sys admin account to do all the transfers.
> >
> > Second I know this stored procedure, it says it works in only domain
> > environment, while ours is in workgroup enviroment, so guess not work for us.
> > The dba here said we don't want to put sql servers in public domain for
> > security reasons.
> >
> > So really want to know if this is a bug or other users may have this problem
> > too?
> > I mean after transfering log in, password changed'
> > Thanks
> >
> >
> >
> >
> >
> >
> > "TomB" wrote:
> >
> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
> >> available from Microsoft (reference Knowledge Base Article 246133). This
> >> stored procedure will generate a script on the source server that can be
> >> executed on the target server to create the logins with their original SIDs
> >> and passwords.
> >>
> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> >> > I think this is done for security reasons. The passwords after transfer
> >> > gets encrypted that way SA or equivalent user will reset the passwords.
> >> > Thereby implicit privileges will not be available to the login without the
> >> > administrator's knowledge.
> >> >
> >> > Bhanu.
> >> >
> >> >
> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> >> > > We have a testing server. Sometimes we need to move some logins and
> >> users
> >> > > from production server to the testing server, I use transfer login or
> >> copy
> >> > > objects dts,
> >> > > Then some of our web pages cannot be acceessed by the logins.
> >> > >
> >> > > And I checked there was no orphaned users.
> >> > >
> >> > > Finally found the password is changed while transfer, change it to
> >> > oringinal
> >> > > password, then it works.
> >> > >
> >> > > My question is why the password changed during transfer or moving logins
> >> > or
> >> > > users?
> >> > > We didn't change it manually at all.
> >> > >
> >> > > Is this a bug ? or is this a problem many users have?
> >> > >
> >> > > Thanks
> >> >
> >> >
> >>
> >>
> >>
>
>|||That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
need to edit the file so you get the correct machines name in the account name.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQL
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name with
> the new domain in the sp_grantlogin statements. Because the integrated logins
> granted access in the new domain will not have the same SID as the logins in
> the original domain, the database users will be orphaned from these logins.
> To resolve these orphaned users, see the articles referenced in the following
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likely
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
>> > Second I know this stored procedure, it says it works in only domain
>> > environment,
>> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
>> irrelevant for SQL server logins.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>> > First, actually we have a udl file that we know what the passwords are.
>> > The file works good on the production server, but not the testing server,
>> > where we moved to. After I changed the password according to it on the
>> > testing server, it works. So there is no issue about encrypt and reset. I do
>> > user sa or sys admin account to do all the transfers.
>> >
>> > Second I know this stored procedure, it says it works in only domain
>> > environment, while ours is in workgroup enviroment, so guess not work for us.
>> > The dba here said we don't want to put sql servers in public domain for
>> > security reasons.
>> >
>> > So really want to know if this is a bug or other users may have this problem
>> > too?
>> > I mean after transfering log in, password changed'
>> > Thanks
>> >
>> >
>> >
>> >
>> >
>> >
>> > "TomB" wrote:
>> >
>> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
>> >> available from Microsoft (reference Knowledge Base Article 246133). This
>> >> stored procedure will generate a script on the source server that can be
>> >> executed on the target server to create the logins with their original SIDs
>> >> and passwords.
>> >>
>> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
>> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
>> >> > I think this is done for security reasons. The passwords after transfer
>> >> > gets encrypted that way SA or equivalent user will reset the passwords.
>> >> > Thereby implicit privileges will not be available to the login without the
>> >> > administrator's knowledge.
>> >> >
>> >> > Bhanu.
>> >> >
>> >> >
>> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
>> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
>> >> > > We have a testing server. Sometimes we need to move some logins and
>> >> users
>> >> > > from production server to the testing server, I use transfer login or
>> >> copy
>> >> > > objects dts,
>> >> > > Then some of our web pages cannot be acceessed by the logins.
>> >> > >
>> >> > > And I checked there was no orphaned users.
>> >> > >
>> >> > > Finally found the password is changed while transfer, change it to
>> >> > oringinal
>> >> > > password, then it works.
>> >> > >
>> >> > > My question is why the password changed during transfer or moving logins
>> >> > or
>> >> > > users?
>> >> > > We didn't change it manually at all.
>> >> > >
>> >> > > Is this a bug ? or is this a problem many users have?
>> >> > >
>> >> > > Thanks
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
> need to edit the file so you get the correct machines name in the account name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
> > Here is what I copied from the article, two paragraphs:
> >
> >
> > Important The SQL Server 2000 destination server cannot be running the
> > 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> > SQL Server 2000 are not available. If you are importing logins from an
> > instance of SQL Server that is on a separate computer, your instance of SQL
> > Server will must be running under a Domain Account to complete the task.
> >
> >
> > Remarks
> > . Review the output script carefully before you run it on the destination
> > SQL Server. If you have to transfer logins to an instance of SQL Server in a
> > different domain than the source instance of SQL Server, edit the script
> > generated by the sp_help_revlogin procedure, and replace the domain name with
> > the new domain in the sp_grantlogin statements. Because the integrated logins
> > granted access in the new domain will not have the same SID as the logins in
> > the original domain, the database users will be orphaned from these logins.
> > To resolve these orphaned users, see the articles referenced in the following
> > bullet item. If you transfer integrated logins between instances of SQL
> > Servers in the same domain, the same SID is used and the user is not likely
> > to be orphaned.
> >
> >
> >
> >
> > "Tibor Karaszi" wrote:
> >
> >> > Second I know this stored procedure, it says it works in only domain
> >> > environment,
> >>
> >> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> >> irrelevant for SQL server logins.
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://www.solidqualitylearning.com/
> >>
> >>
> >> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
> >> > First, actually we have a udl file that we know what the passwords are.
> >> > The file works good on the production server, but not the testing server,
> >> > where we moved to. After I changed the password according to it on the
> >> > testing server, it works. So there is no issue about encrypt and reset. I do
> >> > user sa or sys admin account to do all the transfers.
> >> >
> >> > Second I know this stored procedure, it says it works in only domain
> >> > environment, while ours is in workgroup enviroment, so guess not work for us.
> >> > The dba here said we don't want to put sql servers in public domain for
> >> > security reasons.
> >> >
> >> > So really want to know if this is a bug or other users may have this problem
> >> > too?
> >> > I mean after transfering log in, password changed'
> >> > Thanks
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > "TomB" wrote:
> >> >
> >> >> You may avoid this problem by using the master..sp_help_revlogin stored proc
> >> >> available from Microsoft (reference Knowledge Base Article 246133). This
> >> >> stored procedure will generate a script on the source server that can be
> >> >> executed on the target server to create the logins with their original SIDs
> >> >> and passwords.
> >> >>
> >> >> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> >> >> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> >> >> > I think this is done for security reasons. The passwords after transfer
> >> >> > gets encrypted that way SA or equivalent user will reset the passwords.
> >> >> > Thereby implicit privileges will not be available to the login without the
> >> >> > administrator's knowledge.
> >> >> >
> >> >> > Bhanu.
> >> >> >
> >> >> >
> >> >> > "Ann" <Ann@.discussions.microsoft.com> wrote in message
> >> >> > news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> >> >> > > We have a testing server. Sometimes we need to move some logins and
> >> >> users
> >> >> > > from production server to the testing server, I use transfer login or
> >> >> copy
> >> >> > > objects dts,
> >> >> > > Then some of our web pages cannot be acceessed by the logins.
> >> >> > >
> >> >> > > And I checked there was no orphaned users.
> >> >> > >
> >> >> > > Finally found the password is changed while transfer, change it to
> >> >> > oringinal
> >> >> > > password, then it works.
> >> >> > >
> >> >> > > My question is why the password changed during transfer or moving logins
> >> >> > or
> >> >> > > users?
> >> >> > > We didn't change it manually at all.
> >> >> > >
> >> >> > > Is this a bug ? or is this a problem many users have?
> >> >> > >
> >> >> > > Thanks
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
login password changed
We have a testing server. Sometimes we need to move some logins and users
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
Thanks
I think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks
|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
users[vbcol=seagreen]
copy
> oringinal
> or
>
|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored proc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SIDs
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> users
> copy
>
>
|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
irrelevant for SQL server logins.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...[vbcol=seagreen]
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this problem
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
? Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name with
the new domain in the sp_grantlogin statements. Because the integrated logins
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the following
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>
>
|||That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
need to edit the file so you get the correct machines name in the account name.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...[vbcol=seagreen]
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQL
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name with
> the new domain in the sp_grantlogin statements. Because the integrated logins
> granted access in the new domain will not have the same SID as the logins in
> the original domain, the database users will be orphaned from these logins.
> To resolve these orphaned users, see the articles referenced in the following
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likely
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
> need to edit the file so you get the correct machines name in the account name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
>
>
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
Thanks
I think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks
|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
users[vbcol=seagreen]
copy
> oringinal
> or
>
|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored proc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SIDs
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> users
> copy
>
>
|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
irrelevant for SQL server logins.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...[vbcol=seagreen]
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this problem
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
? Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name with
the new domain in the sp_grantlogin statements. Because the integrated logins
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the following
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> I didn't find such a statement in the KB. Can you elaborate?. And, domain structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>
>
|||That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
need to edit the file so you get the correct machines name in the account name.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...[vbcol=seagreen]
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version of
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQL
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name with
> the new domain in the sp_grantlogin statements. Because the integrated logins
> granted access in the new domain will not have the same SID as the logins in
> the original domain, the database users will be orphaned from these logins.
> To resolve these orphaned users, see the articles referenced in the following
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likely
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes for Windows accounts, you
> need to edit the file so you get the correct machines name in the account name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
>
>
login password changed
We have a testing server. Sometimes we need to move some logins and users
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
ThanksI think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
users[vbcol=seagreen]
copy[vbcol=seagreen]
> oringinal
> or
>|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us
.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored pr
oc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SID
s
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> users
> copy
>
>|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain st
ructure is totally
irrelevant for SQL server logins.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...[vbcol=seagreen]
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I
do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for
us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this probl
em
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
>|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
? Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name wit
h
the new domain in the sp_grantlogin statements. Because the integrated login
s
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the followin
g
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> I didn't find such a statement in the KB. Can you elaborate?. And, domain
structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>
>|||That refers to the DTS method, not the stored procedure method. And, yes for
Windows accounts, you
need to edit the file so you get the correct machines name in the account na
me.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...[vbcol=seagreen]
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version o
f
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQ
L
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in
a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name w
ith
> the new domain in the sp_grantlogin statements. Because the integrated log
ins
> granted access in the new domain will not have the same SID as the logins
in
> the original domain, the database users will be orphaned from these logins
.
> To resolve these orphaned users, see the articles referenced in the follow
ing
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likel
y
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
>|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes f
or Windows accounts, you
> need to edit the file so you get the correct machines name in the account
name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
>
>
from production server to the testing server, I use transfer login or copy
objects dts,
Then some of our web pages cannot be acceessed by the logins.
And I checked there was no orphaned users.
Finally found the password is changed while transfer, change it to oringinal
password, then it works.
My question is why the password changed during transfer or moving logins or
users?
We didn't change it manually at all.
Is this a bug ? or is this a problem many users have?
ThanksI think this is done for security reasons. The passwords after transfer
gets encrypted that way SA or equivalent user will reset the passwords.
Thereby implicit privileges will not be available to the login without the
administrator's knowledge.
Bhanu.
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
> We have a testing server. Sometimes we need to move some logins and users
> from production server to the testing server, I use transfer login or copy
> objects dts,
> Then some of our web pages cannot be acceessed by the logins.
> And I checked there was no orphaned users.
> Finally found the password is changed while transfer, change it to
oringinal
> password, then it works.
> My question is why the password changed during transfer or moving logins
or
> users?
> We didn't change it manually at all.
> Is this a bug ? or is this a problem many users have?
> Thanks|||You may avoid this problem by using the master..sp_help_revlogin stored proc
available from Microsoft (reference Knowledge Base Article 246133). This
stored procedure will generate a script on the source server that can be
executed on the target server to create the logins with their original SIDs
and passwords.
"Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> I think this is done for security reasons. The passwords after transfer
> gets encrypted that way SA or equivalent user will reset the passwords.
> Thereby implicit privileges will not be available to the login without the
> administrator's knowledge.
> Bhanu.
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:4446F314-A347-4EBC-B621-798CFE959B12@.microsoft.com...
users[vbcol=seagreen]
copy[vbcol=seagreen]
> oringinal
> or
>|||First, actually we have a udl file that we know what the passwords are.
The file works good on the production server, but not the testing server,
where we moved to. After I changed the password according to it on the
testing server, it works. So there is no issue about encrypt and reset. I do
user sa or sys admin account to do all the transfers.
Second I know this stored procedure, it says it works in only domain
environment, while ours is in workgroup enviroment, so guess not work for us
.
The dba here said we don't want to put sql servers in public domain for
security reasons.
So really want to know if this is a bug or other users may have this problem
too?
I mean after transfering log in, password changed'
Thanks
"TomB" wrote:
> You may avoid this problem by using the master..sp_help_revlogin stored pr
oc
> available from Microsoft (reference Knowledge Base Article 246133). This
> stored procedure will generate a script on the source server that can be
> executed on the target server to create the logins with their original SID
s
> and passwords.
> "Bhanu" <SQLDBA1999@.yahoo.com> wrote in message
> news:ufoToIhsEHA.3320@.TK2MSFTNGP15.phx.gbl...
> users
> copy
>
>|||> Second I know this stored procedure, it says it works in only domain
> environment,
I didn't find such a statement in the KB. Can you elaborate?. And, domain st
ructure is totally
irrelevant for SQL server logins.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...[vbcol=seagreen]
> First, actually we have a udl file that we know what the passwords are.
> The file works good on the production server, but not the testing server,
> where we moved to. After I changed the password according to it on the
> testing server, it works. So there is no issue about encrypt and reset. I
do
> user sa or sys admin account to do all the transfers.
> Second I know this stored procedure, it says it works in only domain
> environment, while ours is in workgroup enviroment, so guess not work for
us.
> The dba here said we don't want to put sql servers in public domain for
> security reasons.
> So really want to know if this is a bug or other users may have this probl
em
> too?
> I mean after transfering log in, password changed'
> Thanks
>
>
>
> "TomB" wrote:
>|||Here is what I copied from the article, two paragraphs:
Important The SQL Server 2000 destination server cannot be running the
64-bit version of SQL Server 2000. DTS components for the 64-bit version of
SQL Server 2000 are not available. If you are importing logins from an
instance of SQL Server that is on a separate computer, your instance of SQL
Server will must be running under a Domain Account to complete the task.
Remarks
? Review the output script carefully before you run it on the destination
SQL Server. If you have to transfer logins to an instance of SQL Server in a
different domain than the source instance of SQL Server, edit the script
generated by the sp_help_revlogin procedure, and replace the domain name wit
h
the new domain in the sp_grantlogin statements. Because the integrated login
s
granted access in the new domain will not have the same SID as the logins in
the original domain, the database users will be orphaned from these logins.
To resolve these orphaned users, see the articles referenced in the followin
g
bullet item. If you transfer integrated logins between instances of SQL
Servers in the same domain, the same SID is used and the user is not likely
to be orphaned.
"Tibor Karaszi" wrote:
> I didn't find such a statement in the KB. Can you elaborate?. And, domain
structure is totally
> irrelevant for SQL server logins.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:19E05F0B-57C7-41A3-8087-CF0749C6DE15@.microsoft.com...
>
>|||That refers to the DTS method, not the stored procedure method. And, yes for
Windows accounts, you
need to edit the file so you get the correct machines name in the account na
me.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Ann" <Ann@.discussions.microsoft.com> wrote in message
news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...[vbcol=seagreen]
> Here is what I copied from the article, two paragraphs:
>
> Important The SQL Server 2000 destination server cannot be running the
> 64-bit version of SQL Server 2000. DTS components for the 64-bit version o
f
> SQL Server 2000 are not available. If you are importing logins from an
> instance of SQL Server that is on a separate computer, your instance of SQ
L
> Server will must be running under a Domain Account to complete the task.
>
> Remarks
> . Review the output script carefully before you run it on the destination
> SQL Server. If you have to transfer logins to an instance of SQL Server in
a
> different domain than the source instance of SQL Server, edit the script
> generated by the sp_help_revlogin procedure, and replace the domain name w
ith
> the new domain in the sp_grantlogin statements. Because the integrated log
ins
> granted access in the new domain will not have the same SID as the logins
in
> the original domain, the database users will be orphaned from these logins
.
> To resolve these orphaned users, see the articles referenced in the follow
ing
> bullet item. If you transfer integrated logins between instances of SQL
> Servers in the same domain, the same SID is used and the user is not likel
y
> to be orphaned.
>
>
> "Tibor Karaszi" wrote:
>|||Thanks. Yes, I mistook the first paragraph.It is for dts transfer.
But how about the second paragraph, or does it mean there is no problem
using the stored procedure in our workgroup enviroment.
Second I'm just curious, for dts transfer logins, did any users have the
same problem, that passwords are changed?
Thanks
"Tibor Karaszi" wrote:
> That refers to the DTS method, not the stored procedure method. And, yes f
or Windows accounts, you
> need to edit the file so you get the correct machines name in the account
name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Ann" <Ann@.discussions.microsoft.com> wrote in message
> news:AE8D5328-1991-4BED-946D-4430111A3656@.microsoft.com...
>
>
Login Page just refreshes with ASP.NET 2.0 Login Control
I am try to login using the ASP.NET 2.0 Standard Login Control. When I enter the correct userId/Password and hit the Login button, the page just refreshes, no error is displayed. But if I enter wrong userid/password..it give me an error.
Also I check the Membership.ValidateUser() returns true, that means the user is validated, but still I am able to redirect to ReturnURL.?
Is there something wrong with the Authentication, or Creating a cookie. Can somebody shed some light on this,
I have the following machine configuration
Windows XP Pro Service Pack2
IIS 5.1
SQL Server 2000
Visual Studio 2005
DISABLE ANONMYOUS ACCESS IN IIS
ENABLE WINDOWS AUTHENTICATION
I am getting the following output :
Membership.ValidateUser(Login1.UserName, Login1.Password) : - True
HttpContext.Current.User.Identity.Name : - // is blank
User.Identity.IsAuthenticated :- False
User.Identity.AuthenticationType :- // is blank
NOTE : The applicationName is same in web.config as well as in the aspnet_Applications table in SQL Server 2000 membership database.
Do you have an error logged in the SQL Server error log file (name starts with ERRORLOG)?
If not, then you should post the question on an ASP forum.
Thanks
Laurentiu
Login Page just refreshes with ASP.NET 2.0 Login Control
I am try to login using the ASP.NET 2.0 Standard Login Control. When I enter the correct userId/Password and hit the Login button, the page just refreshes, no error is displayed. But if I enter wrong userid/password..it give me an error.
Also I check the Membership.ValidateUser() returns true, that means the user is validated, but still I am able to redirect to ReturnURL.?
Is there something wrong with the Authentication, or Creating a cookie. Can somebody shed some light on this,
I have the following machine configuration
Windows XP Pro Service Pack2
IIS 5.1
SQL Server 2000
Visual Studio 2005
DISABLE ANONMYOUS ACCESS IN IIS
ENABLE WINDOWS AUTHENTICATION
I am getting the following output :
Membership.ValidateUser(Login1.UserName, Login1.Password) : - True
HttpContext.Current.User.Identity.Name : - // is blank
User.Identity.IsAuthenticated :- False
User.Identity.AuthenticationType :- // is blank
NOTE : The applicationName is same in web.config as well as in the aspnet_Applications table in SQL Server 2000 membership database.
Do you have an error logged in the SQL Server error log file (name starts with ERRORLOG)?
If not, then you should post the question on an ASP forum.
Thanks
Laurentiu
Subscribe to:
Posts (Atom)