We have a SQL installation that was setup with Windows Authentication.
The software we will run requires SQL Authentication (Mixed Mode).
When I right click on properties, go to the security tab, click the SQL
Authentication, click on OK and it exits. However, when I go back in
and look at the security tab, it is still set on Windows
Authentication. I tried restarting the SQL services and I get the same
thing.
Ideas?
I have resolved this issue by logging in as the domain admin. I had
previously tried using a local admin account.
jd
JohnDoe wrote:
> We have a SQL installation that was setup with Windows Authentication.
> The software we will run requires SQL Authentication (Mixed Mode).
> When I right click on properties, go to the security tab, click the SQL
> Authentication, click on OK and it exits. However, when I go back in
> and look at the security tab, it is still set on Windows
> Authentication. I tried restarting the SQL services and I get the same
> thing.
> Ideas?
Showing posts with label mixed. Show all posts
Showing posts with label mixed. Show all posts
Thursday, March 29, 2012
Can't Switch to SQL Authentication (Mixed Mode)
We have a SQL installation that was setup with Windows Authentication.
The software we will run requires SQL Authentication (Mixed Mode).
When I right click on properties, go to the security tab, click the SQL
Authentication, click on OK and it exits. However, when I go back in
and look at the security tab, it is still set on Windows
Authentication. I tried restarting the SQL services and I get the same
thing.
Ideas?I have resolved this issue by logging in as the domain admin. I had
previously tried using a local admin account.
jd
JohnDoe wrote:
> We have a SQL installation that was setup with Windows Authentication.
> The software we will run requires SQL Authentication (Mixed Mode).
> When I right click on properties, go to the security tab, click the SQL
> Authentication, click on OK and it exits. However, when I go back in
> and look at the security tab, it is still set on Windows
> Authentication. I tried restarting the SQL services and I get the same
> thing.
> Ideas?
The software we will run requires SQL Authentication (Mixed Mode).
When I right click on properties, go to the security tab, click the SQL
Authentication, click on OK and it exits. However, when I go back in
and look at the security tab, it is still set on Windows
Authentication. I tried restarting the SQL services and I get the same
thing.
Ideas?I have resolved this issue by logging in as the domain admin. I had
previously tried using a local admin account.
jd
JohnDoe wrote:
> We have a SQL installation that was setup with Windows Authentication.
> The software we will run requires SQL Authentication (Mixed Mode).
> When I right click on properties, go to the security tab, click the SQL
> Authentication, click on OK and it exits. However, when I go back in
> and look at the security tab, it is still set on Windows
> Authentication. I tried restarting the SQL services and I get the same
> thing.
> Ideas?
Can't Switch to SQL Authentication (Mixed Mode)
We have a SQL installation that was setup with Windows Authentication.
The software we will run requires SQL Authentication (Mixed Mode).
When I right click on properties, go to the security tab, click the SQL
Authentication, click on OK and it exits. However, when I go back in
and look at the security tab, it is still set on Windows
Authentication. I tried restarting the SQL services and I get the same
thing.
Ideas?I have resolved this issue by logging in as the domain admin. I had
previously tried using a local admin account.
jd
JohnDoe wrote:
> We have a SQL installation that was setup with Windows Authentication.
> The software we will run requires SQL Authentication (Mixed Mode).
> When I right click on properties, go to the security tab, click the SQL
> Authentication, click on OK and it exits. However, when I go back in
> and look at the security tab, it is still set on Windows
> Authentication. I tried restarting the SQL services and I get the same
> thing.
> Ideas?
The software we will run requires SQL Authentication (Mixed Mode).
When I right click on properties, go to the security tab, click the SQL
Authentication, click on OK and it exits. However, when I go back in
and look at the security tab, it is still set on Windows
Authentication. I tried restarting the SQL services and I get the same
thing.
Ideas?I have resolved this issue by logging in as the domain admin. I had
previously tried using a local admin account.
jd
JohnDoe wrote:
> We have a SQL installation that was setup with Windows Authentication.
> The software we will run requires SQL Authentication (Mixed Mode).
> When I right click on properties, go to the security tab, click the SQL
> Authentication, click on OK and it exits. However, when I go back in
> and look at the security tab, it is still set on Windows
> Authentication. I tried restarting the SQL services and I get the same
> thing.
> Ideas?
Thursday, March 8, 2012
Can't remove SA account or delete xp_cmdshell ext stored proc?
I'm trying to make my SQL Server a tad more secure, but I'm unable to remove
SA (I'm running Mixed mode) -- can the SA account only be removed when using
windows Authentication? When I try to remove SA I get "selected user
cannot be dropped because the user owns objects". When I try to delect
xp_cmdshell I get the following error "You tried to delete one or more
system objects. They were not deleted."
I must admit, I'm a little confused, I'm trying to implement Microsofts
security recommendations, but either the documention is not
detailed/accurate or I'm missing something?
Any suggestions?
Thanks, Rob.Hi
You can not remove the SA account. Set a very complicated password for it,
write it down and put it in a safe.
For the xp_ look at
http://support.microsoft.com/defaul...kb;en-us;891984
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Rob R. Ainscough" wrote:
> I'm trying to make my SQL Server a tad more secure, but I'm unable to remo
ve
> SA (I'm running Mixed mode) -- can the SA account only be removed when usi
ng
> windows Authentication? When I try to remove SA I get "selected user
> cannot be dropped because the user owns objects". When I try to delect
> xp_cmdshell I get the following error "You tried to delete one or more
> system objects. They were not deleted."
> I must admit, I'm a little confused, I'm trying to implement Microsofts
> security recommendations, but either the documention is not
> detailed/accurate or I'm missing something?
> Any suggestions?
> Thanks, Rob.
>
>
>|||> I'm trying to make my SQL Server a tad more secure, but I'm unable to
> remove SA (I'm running Mixed mode) -- can the SA account only be removed
> when using windows Authentication? When I try to remove SA I get
> "selected user cannot be dropped because the user owns objects". When I
> try to delect xp_cmdshell I get the following error "You tried to delete
> one or more system objects. They were not deleted."
The sa login account cannot be deleted or renameed, nor it can't be revoked
any permission.
> I must admit, I'm a little confused, I'm trying to implement Microsofts
> security recommendations, but either the documention is not
> detailed/accurate or I'm missing something?
I don't think MS ever mentioned droping the sa account (as it can't be
done). Here are recommendations from Operations Guide: "
The sa account in a production environment should be given a complex
password, made up of uppercase and lowercase letters, symbols, spaces, and
numbers. The sa account should have a complex password, even if the SQL
Server is running in only Windows Authentication Mode. A complex password
protects SQL Server from someone easily getting administrative access to SQL
Server. This also protects the server in the event that an administrator
changes the security authentication mode to Mixed Mode.
Do not use the sa login account in a production environment. Instead, place
each DBA's network user account into a Windows group, create a single SQL
Server login account for the group then add the login account to the
sysadmin fixed server role. "
(http://www.microsoft.com/technet/pr...in/sqlops3.mspx
).
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com|||Thank you for the information.
The book I was reading is Microsoft Press and the authors are Ed Robinson
and Michael James Bond.
I have the SA password complex so no worries there.
I guess I'll leave the xp_cmdshell alone as it seems to be more trouble that
it is worth to remove it.
Should I think about installing URLScan ?
"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
message news:%23BAAU89pFHA.3112@.TK2MSFTNGP12.phx.gbl...
> The sa login account cannot be deleted or renameed, nor it can't be
> revoked any permission.
>
> I don't think MS ever mentioned droping the sa account (as it can't be
> done). Here are recommendations from Operations Guide: "
> The sa account in a production environment should be given a complex
> password, made up of uppercase and lowercase letters, symbols, spaces, and
> numbers. The sa account should have a complex password, even if the SQL
> Server is running in only Windows Authentication Mode. A complex password
> protects SQL Server from someone easily getting administrative access to
> SQL Server. This also protects the server in the event that an
> administrator changes the security authentication mode to Mixed Mode.
> Do not use the sa login account in a production environment. Instead,
> place each DBA's network user account into a Windows group, create a
> single SQL Server login account for the group then add the login account
> to the sysadmin fixed server role. "
> (http://www.microsoft.com/technet/pr...ityLearning.com
>|||> Should I think about installing URLScan ?
Why don't you ask this in some IIS group, with explanation why do you think
you need it?
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
SA (I'm running Mixed mode) -- can the SA account only be removed when using
windows Authentication? When I try to remove SA I get "selected user
cannot be dropped because the user owns objects". When I try to delect
xp_cmdshell I get the following error "You tried to delete one or more
system objects. They were not deleted."
I must admit, I'm a little confused, I'm trying to implement Microsofts
security recommendations, but either the documention is not
detailed/accurate or I'm missing something?
Any suggestions?
Thanks, Rob.Hi
You can not remove the SA account. Set a very complicated password for it,
write it down and put it in a safe.
For the xp_ look at
http://support.microsoft.com/defaul...kb;en-us;891984
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Rob R. Ainscough" wrote:
> I'm trying to make my SQL Server a tad more secure, but I'm unable to remo
ve
> SA (I'm running Mixed mode) -- can the SA account only be removed when usi
ng
> windows Authentication? When I try to remove SA I get "selected user
> cannot be dropped because the user owns objects". When I try to delect
> xp_cmdshell I get the following error "You tried to delete one or more
> system objects. They were not deleted."
> I must admit, I'm a little confused, I'm trying to implement Microsofts
> security recommendations, but either the documention is not
> detailed/accurate or I'm missing something?
> Any suggestions?
> Thanks, Rob.
>
>
>|||> I'm trying to make my SQL Server a tad more secure, but I'm unable to
> remove SA (I'm running Mixed mode) -- can the SA account only be removed
> when using windows Authentication? When I try to remove SA I get
> "selected user cannot be dropped because the user owns objects". When I
> try to delect xp_cmdshell I get the following error "You tried to delete
> one or more system objects. They were not deleted."
The sa login account cannot be deleted or renameed, nor it can't be revoked
any permission.
> I must admit, I'm a little confused, I'm trying to implement Microsofts
> security recommendations, but either the documention is not
> detailed/accurate or I'm missing something?
I don't think MS ever mentioned droping the sa account (as it can't be
done). Here are recommendations from Operations Guide: "
The sa account in a production environment should be given a complex
password, made up of uppercase and lowercase letters, symbols, spaces, and
numbers. The sa account should have a complex password, even if the SQL
Server is running in only Windows Authentication Mode. A complex password
protects SQL Server from someone easily getting administrative access to SQL
Server. This also protects the server in the event that an administrator
changes the security authentication mode to Mixed Mode.
Do not use the sa login account in a production environment. Instead, place
each DBA's network user account into a Windows group, create a single SQL
Server login account for the group then add the login account to the
sysadmin fixed server role. "
(http://www.microsoft.com/technet/pr...in/sqlops3.mspx
).
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com|||Thank you for the information.
The book I was reading is Microsoft Press and the authors are Ed Robinson
and Michael James Bond.
I have the SA password complex so no worries there.
I guess I'll leave the xp_cmdshell alone as it seems to be more trouble that
it is worth to remove it.
Should I think about installing URLScan ?
"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si> wrote in
message news:%23BAAU89pFHA.3112@.TK2MSFTNGP12.phx.gbl...
> The sa login account cannot be deleted or renameed, nor it can't be
> revoked any permission.
>
> I don't think MS ever mentioned droping the sa account (as it can't be
> done). Here are recommendations from Operations Guide: "
> The sa account in a production environment should be given a complex
> password, made up of uppercase and lowercase letters, symbols, spaces, and
> numbers. The sa account should have a complex password, even if the SQL
> Server is running in only Windows Authentication Mode. A complex password
> protects SQL Server from someone easily getting administrative access to
> SQL Server. This also protects the server in the event that an
> administrator changes the security authentication mode to Mixed Mode.
> Do not use the sa login account in a production environment. Instead,
> place each DBA's network user account into a Windows group, create a
> single SQL Server login account for the group then add the login account
> to the sysadmin fixed server role. "
> (http://www.microsoft.com/technet/pr...ityLearning.com
>|||> Should I think about installing URLScan ?
Why don't you ask this in some IIS group, with explanation why do you think
you need it?
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
Sunday, February 12, 2012
Cant get windows authentication in Mixed Mode to work .... any ideas?
Hey all,
I've got SQL 2K running in mixed mode. I created a windows acct (mytest) in the administrator group, and then created a corresponding SQL account (mytest) using the windows authentication. In the EM it comes up as a "Windows User" type of acct. (The account is not a domain account but a workstation one).
I've configured my app to use that account for access to the database but I get the following error message when I send the connection request to the datasource:
Connection Failed:
SQL State:28000
SQL Server Error: 18456
Login failed for user myworkstation\mytest
I can connect just fine using the sql accounts, but it doesn't want to play nice when I need the windows authentication portion to work.
What exactly am I doing wrong?
Any input is greatly appreciated !
Regards,
TammyA couple of things come to mind...
1. If mytest is a member of the workstation Administrators group, then you do not (necessarily) need a separate SQL account for it. The BUILTIN\Administrators account permits all members of the local Administrators group to have access (in the default config anyway).
2. If you have denied access to the BUILTIN\Administrators group, then myWorkstation\mytest will not have access (Deny trumps permit).
3. Just a head check: you said that myworkstation\mytest was NOT a domain account (when you set it up). You didn't by chance login under the domain?
Just my $ .02. It's not much, I'll grant you, but it was what I could come up with.
hmscott|||Mr. Scott !
I'm such an idiot ....
I had forgotten that I denied access to the builtin Administrator account. I turned it back on and VOILA !
Mr. Scott - 1
Tammy - 0
Gracias !
Originally posted by hmscott
A couple of things come to mind...
1. If mytest is a member of the workstation Administrators group, then you do not (necessarily) need a separate SQL account for it. The BUILTIN\Administrators account permits all members of the local Administrators group to have access (in the default config anyway).
2. If you have denied access to the BUILTIN\Administrators group, then myWorkstation\mytest will not have access (Deny trumps permit).
3. Just a head check: you said that myworkstation\mytest was NOT a domain account (when you set it up). You didn't by chance login under the domain?
Just my $ .02. It's not much, I'll grant you, but it was what I could come up with.
hmscott
I've got SQL 2K running in mixed mode. I created a windows acct (mytest) in the administrator group, and then created a corresponding SQL account (mytest) using the windows authentication. In the EM it comes up as a "Windows User" type of acct. (The account is not a domain account but a workstation one).
I've configured my app to use that account for access to the database but I get the following error message when I send the connection request to the datasource:
Connection Failed:
SQL State:28000
SQL Server Error: 18456
Login failed for user myworkstation\mytest
I can connect just fine using the sql accounts, but it doesn't want to play nice when I need the windows authentication portion to work.
What exactly am I doing wrong?
Any input is greatly appreciated !
Regards,
TammyA couple of things come to mind...
1. If mytest is a member of the workstation Administrators group, then you do not (necessarily) need a separate SQL account for it. The BUILTIN\Administrators account permits all members of the local Administrators group to have access (in the default config anyway).
2. If you have denied access to the BUILTIN\Administrators group, then myWorkstation\mytest will not have access (Deny trumps permit).
3. Just a head check: you said that myworkstation\mytest was NOT a domain account (when you set it up). You didn't by chance login under the domain?
Just my $ .02. It's not much, I'll grant you, but it was what I could come up with.
hmscott|||Mr. Scott !
I'm such an idiot ....
I had forgotten that I denied access to the builtin Administrator account. I turned it back on and VOILA !
Mr. Scott - 1
Tammy - 0
Gracias !
Originally posted by hmscott
A couple of things come to mind...
1. If mytest is a member of the workstation Administrators group, then you do not (necessarily) need a separate SQL account for it. The BUILTIN\Administrators account permits all members of the local Administrators group to have access (in the default config anyway).
2. If you have denied access to the BUILTIN\Administrators group, then myWorkstation\mytest will not have access (Deny trumps permit).
3. Just a head check: you said that myworkstation\mytest was NOT a domain account (when you set it up). You didn't by chance login under the domain?
Just my $ .02. It's not much, I'll grant you, but it was what I could come up with.
hmscott
Subscribe to:
Posts (Atom)