BuiltinAdministrator's not SysAdmin yet appear to have DBO on all

Hi All,
I have revoked the BUILTIN\Administrators group membership in the SysAdmin
group of a SQL 2000 server and instead granted the group Process
Admoinistrators and Disk Administrators permissions. When I browse
permissions for the BUILTIN\Administrators group in EM, I see the proper
Server Roles are defined as noted above, however this group appears to have
DBO permissions to all databases on the server, even though those databases
were created by SA. In checking several of my SQL servers I am also seeing
the same thing on each server. Have people seen this before? This would
imply that the Local Admins to the box stil have dbo to all of the databases
,
but they were never granted this permission. Is this just in incorrect
representation within EM?
Thanks,
DaveNo...that's not what would typically happen if you remove
the Builtin\administrators group.
I'm guessing that you mean that the local admins appear to
have db_owner role permissions DBO and db_owner are
different things. DBO is a user and db_owner is a database
role. Users can be members of db_owner fixed database role
which gives them all permissions in the database.
I'm not sure why you think the local admins on the server
have db_owner permissions but one thing to keep in mind is
that permissions are cumulative based upon the users
explicit permissions as well as those inherited from group
membership (Windows groups as well as the server and
database groups).
-Sue
On Sun, 23 Jan 2005 06:33:03 -0800, "DBADave"
<DBADave@.discussions.microsoft.com> wrote:

>Hi All,
>I have revoked the BUILTIN\Administrators group membership in the SysAdmin
>group of a SQL 2000 server and instead granted the group Process
>Admoinistrators and Disk Administrators permissions. When I browse
>permissions for the BUILTIN\Administrators group in EM, I see the proper
>Server Roles are defined as noted above, however this group appears to have
>DBO permissions to all databases on the server, even though those databases
>were created by SA. In checking several of my SQL servers I am also seein
g
>the same thing on each server. Have people seen this before? This would
>imply that the Local Admins to the box stil have dbo to all of the database
s,
>but they were never granted this permission. Is this just in incorrect
>representation within EM?
>Thanks,
>Dave

BUILTIN\Amdministrators & sa login

Hi All ,
can i delete the 2 logins above ? tried deleting sa but could not
i actually deleted the BUILTIN\Administrators when i tried to access the
Enterprise Managers i could not connect anymore , how can i rectify this ?
what's the inital password for sa ? i changed it to sa after deleteing the
BUILTIN\Administrators and when i tried to use SQL server login with id sa &
pwd sa i got error "Login failed for user 'Sa' Reason : Not associated with a
trusted sql server connection' how can i rectify this as well ?
appreciate the advice from anyone
tks & rdgs
maxzsim wrote:
> Hi All ,
>
> can i delete the 2 logins above ? tried deleting sa but could not
You can't delete the "sa" account. Deleting the Adminsitrators group is
not a great idea because you can no longer easily assign users (like the
DBA) to the group for admin access. The group is meaningless if no one
is assigned, so leaving it there without any users should be fine.

> i actually deleted the BUILTIN\Administrators when i tried to access
> the Enterprise Managers i could not connect anymore , how can i
> rectify this ?
You're probably using a login to the server in the SQL EM registration
page that used to be in the administrator group. Why you would delete
the administrators group without first verifying you had a valid admin
account with which to manage the server is a little strange.

> what's the inital password for sa ? i changed it to sa after
> deleteing the BUILTIN\Administrators and when i tried to use SQL
> server login with id sa & pwd sa i got error "Login failed for user
> 'Sa' Reason : Not associated with a trusted sql server connection'
> how can i rectify this as well ?
>
Maybe your server is not set up for mixed-mode security. If not, you can
change the setting, but doing so I believe requires admin access. If you
have another admin account, you can log in and change the "sa" password.
If you don't know your "sa" password and don't have any other admin
accounts, you may be forced to rebuild the master database and reattach
your databases. The 'sa" password is set up during the installation and
has no default value. You could try using an empty password and see if
that works.
David G.
|||Hi David ,
tks for your advice i will try out. Actually i was trying to prevent
someone from loggin using the sa login id
rdgs
"David Gugick" wrote:

> maxzsim wrote:
> You can't delete the "sa" account. Deleting the Adminsitrators group is
> not a great idea because you can no longer easily assign users (like the
> DBA) to the group for admin access. The group is meaningless if no one
> is assigned, so leaving it there without any users should be fine.
>
> You're probably using a login to the server in the SQL EM registration
> page that used to be in the administrator group. Why you would delete
> the administrators group without first verifying you had a valid admin
> account with which to manage the server is a little strange.
>
> Maybe your server is not set up for mixed-mode security. If not, you can
> change the setting, but doing so I believe requires admin access. If you
> have another admin account, you can log in and change the "sa" password.
> If you don't know your "sa" password and don't have any other admin
> accounts, you may be forced to rebuild the master database and reattach
> your databases. The 'sa" password is set up during the installation and
> has no default value. You could try using an empty password and see if
> that works.
>
> --
> David G.
>
|||maxzsim wrote:
> Hi David ,
> tks for your advice i will try out. Actually i was trying to prevent
> someone from loggin using the sa login id
>
The best way to do that is set SQL Server up to use Integrated Security
only. Without SQL Security, no one could log on using "sa" even if they
knew the password. But you need the "sa" account there and the best way
to secure it is to give it a nasty password. You do need at least one
administrator to manage the server. It's better to use integrated
security for this and add the domain user into the Administrators group.
That way, if the employeee should leave and the login removed from the
server, the backup is to enable mixed-mode security and log in using the
"sa" account.
David Gugick
Imceda Software
www.imceda.com

BUILTIN\Amdministrators & sa login

Hi All ,
can i delete the 2 logins above ? tried deleting sa but could not
i actually deleted the BUILTIN\Administrators when i tried to access the
Enterprise Managers i could not connect anymore , how can i rectify this ?
what's the inital password for sa ? i changed it to sa after deleteing the
BUILTIN\Administrators and when i tried to use SQL server login with id sa &
pwd sa i got error "Login failed for user 'Sa' Reason : Not associated with a
trusted sql server connection' how can i rectify this as well ?
appreciate the advice from anyone
tks & rdgsmaxzsim wrote:
> Hi All ,
>
> can i delete the 2 logins above ? tried deleting sa but could not
You can't delete the "sa" account. Deleting the Adminsitrators group is
not a great idea because you can no longer easily assign users (like the
DBA) to the group for admin access. The group is meaningless if no one
is assigned, so leaving it there without any users should be fine.
> i actually deleted the BUILTIN\Administrators when i tried to access
> the Enterprise Managers i could not connect anymore , how can i
> rectify this ?
You're probably using a login to the server in the SQL EM registration
page that used to be in the administrator group. Why you would delete
the administrators group without first verifying you had a valid admin
account with which to manage the server is a little strange.
> what's the inital password for sa ? i changed it to sa after
> deleteing the BUILTIN\Administrators and when i tried to use SQL
> server login with id sa & pwd sa i got error "Login failed for user
> 'Sa' Reason : Not associated with a trusted sql server connection'
> how can i rectify this as well ?
>
Maybe your server is not set up for mixed-mode security. If not, you can
change the setting, but doing so I believe requires admin access. If you
have another admin account, you can log in and change the "sa" password.
If you don't know your "sa" password and don't have any other admin
accounts, you may be forced to rebuild the master database and reattach
your databases. The 'sa" password is set up during the installation and
has no default value. You could try using an empty password and see if
that works.
David G.|||Hi David ,
tks for your advice i will try out. Actually i was trying to prevent
someone from loggin using the sa login id
rdgs
"David Gugick" wrote:
> maxzsim wrote:
> > Hi All ,
> >
> >
> > can i delete the 2 logins above ? tried deleting sa but could not
> You can't delete the "sa" account. Deleting the Adminsitrators group is
> not a great idea because you can no longer easily assign users (like the
> DBA) to the group for admin access. The group is meaningless if no one
> is assigned, so leaving it there without any users should be fine.
> >
> > i actually deleted the BUILTIN\Administrators when i tried to access
> > the Enterprise Managers i could not connect anymore , how can i
> > rectify this ?
> You're probably using a login to the server in the SQL EM registration
> page that used to be in the administrator group. Why you would delete
> the administrators group without first verifying you had a valid admin
> account with which to manage the server is a little strange.
> >
> > what's the inital password for sa ? i changed it to sa after
> > deleteing the BUILTIN\Administrators and when i tried to use SQL
> > server login with id sa & pwd sa i got error "Login failed for user
> > 'Sa' Reason : Not associated with a trusted sql server connection'
> > how can i rectify this as well ?
> >
> Maybe your server is not set up for mixed-mode security. If not, you can
> change the setting, but doing so I believe requires admin access. If you
> have another admin account, you can log in and change the "sa" password.
> If you don't know your "sa" password and don't have any other admin
> accounts, you may be forced to rebuild the master database and reattach
> your databases. The 'sa" password is set up during the installation and
> has no default value. You could try using an empty password and see if
> that works.
>
> --
> David G.
>|||maxzsim wrote:
> Hi David ,
> tks for your advice i will try out. Actually i was trying to prevent
> someone from loggin using the sa login id
>
The best way to do that is set SQL Server up to use Integrated Security
only. Without SQL Security, no one could log on using "sa" even if they
knew the password. But you need the "sa" account there and the best way
to secure it is to give it a nasty password. You do need at least one
administrator to manage the server. It's better to use integrated
security for this and add the domain user into the Administrators group.
That way, if the employeee should leave and the login removed from the
server, the backup is to enable mixed-mode security and log in using the
"sa" account.
--
David Gugick
Imceda Software
www.imceda.com

BUILTIN\Amdministrators & sa login

Hi All ,
can i delete the 2 logins above ? tried deleting sa but could not
i actually deleted the BUILTIN\Administrators when i tried to access the
Enterprise Managers i could not connect anymore , how can i rectify this ?
what's the inital password for sa ? i changed it to sa after deleteing the
BUILTIN\Administrators and when i tried to use SQL server login with id sa
&
pwd sa i got error "Login failed for user 'Sa' Reason : Not associated with
a
trusted sql server connection' how can i rectify this as well ?
appreciate the advice from anyone
tks & rdgsmaxzsim wrote:
> Hi All ,
>
> can i delete the 2 logins above ? tried deleting sa but could not
You can't delete the "sa" account. Deleting the Adminsitrators group is
not a great idea because you can no longer easily assign users (like the
DBA) to the group for admin access. The group is meaningless if no one
is assigned, so leaving it there without any users should be fine.

> i actually deleted the BUILTIN\Administrators when i tried to access
> the Enterprise Managers i could not connect anymore , how can i
> rectify this ?
You're probably using a login to the server in the SQL EM registration
page that used to be in the administrator group. Why you would delete
the administrators group without first verifying you had a valid admin
account with which to manage the server is a little strange.

> what's the inital password for sa ? i changed it to sa after
> deleteing the BUILTIN\Administrators and when i tried to use SQL
> server login with id sa & pwd sa i got error "Login failed for user
> 'Sa' Reason : Not associated with a trusted sql server connection'
> how can i rectify this as well ?
>
Maybe your server is not set up for mixed-mode security. If not, you can
change the setting, but doing so I believe requires admin access. If you
have another admin account, you can log in and change the "sa" password.
If you don't know your "sa" password and don't have any other admin
accounts, you may be forced to rebuild the master database and reattach
your databases. The 'sa" password is set up during the installation and
has no default value. You could try using an empty password and see if
that works.
David G.|||Hi David ,
tks for your advice i will try out. Actually i was trying to prevent
someone from loggin using the sa login id
rdgs
"David Gugick" wrote:

> maxzsim wrote:
> You can't delete the "sa" account. Deleting the Adminsitrators group is
> not a great idea because you can no longer easily assign users (like the
> DBA) to the group for admin access. The group is meaningless if no one
> is assigned, so leaving it there without any users should be fine.
>
> You're probably using a login to the server in the SQL EM registration
> page that used to be in the administrator group. Why you would delete
> the administrators group without first verifying you had a valid admin
> account with which to manage the server is a little strange.
>
> Maybe your server is not set up for mixed-mode security. If not, you can
> change the setting, but doing so I believe requires admin access. If you
> have another admin account, you can log in and change the "sa" password.
> If you don't know your "sa" password and don't have any other admin
> accounts, you may be forced to rebuild the master database and reattach
> your databases. The 'sa" password is set up during the installation and
> has no default value. You could try using an empty password and see if
> that works.
>
> --
> David G.
>|||maxzsim wrote:
> Hi David ,
> tks for your advice i will try out. Actually i was trying to prevent
> someone from loggin using the sa login id
>
The best way to do that is set SQL Server up to use Integrated Security
only. Without SQL Security, no one could log on using "sa" even if they
knew the password. But you need the "sa" account there and the best way
to secure it is to give it a nasty password. You do need at least one
administrator to manage the server. It's better to use integrated
security for this and add the domain user into the Administrators group.
That way, if the employeee should leave and the login removed from the
server, the backup is to enable mixed-mode security and log in using the
"sa" account.
David Gugick
Imceda Software
www.imceda.com

BUILTIN\Administrators vs System Administrator

Hello all,

does someone know where to find information regarding what is accesible to a BUILTIN\Administrator which is not accesible to a System Administrator?

Somewhere I have read that a System Administrator can not see the "All users' folders (i.e. the collection of "My folder"s for all users of the Report Server) but I have also experienced a behaviour which has surprised me: as a System Administrator with all permissions I cann't even see folders that a BUILTIN\Administrator can.

Does it mean that a System Administrator can not really manage all the resources of a Report Server?

Any ideas will be welcomed. Many thanks.

Firstly I would like to ask from where you have read the information, rather than replying you to with generic answers in this topic.

As one of the best practices is to remove the Builtin\Administrators as a part of security breakdown involving the sysadmin role. By default (from installation), the NT group BUILTIN\Administrators is granted sysadmin rights to SQL Server because it is made a member of the syadmin role. The BUILTIN\Administrators group corresponds to the local Administrators group for the server.

BUILTIN\administrators translation

Hi,
I have a line of code in an application
"sp_revokelogin [BUILTIN\Administrators]"
which fails on installations on German XP but works OK for English.
Is there a translation for 'BUILTIN'? I have tried
[BUILTIN\Administratoren] but that doesn't help - always get the message
" Windows NT user or group 'BUILTIN\Administratoren' not
found. Check the name again"
Hope someone with a German server can help!
(I also need the corresponding names for French, Spanish etc.)BUILTIN\Administrators has a "well known" SID so you could use this
declare @.builtin nvarchar(128)
select @.builtin = suser_sname(0x01020000000000052000000020
020000)
exec sp_revokelogin @.builtin
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"quilkin" <quilkin@.discussions.microsoft.com> wrote in message
news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
> Hi,
> I have a line of code in an application
> "sp_revokelogin [BUILTIN\Administrators]"
> which fails on installations on German XP but works OK for English.
> Is there a translation for 'BUILTIN'? I have tried
> [BUILTIN\Administratoren] but that doesn't help - always get the messa
ge
> " Windows NT user or group 'BUILTIN\Administratoren' not
> found. Check the name again"
> Hope someone with a German server can help!
> (I also need the corresponding names for French, Spanish etc.)
>|||Jasper,
That works fine, thanks.
I knew there'd be a simple answer.
"Jasper Smith" wrote:

> BUILTIN\Administrators has a "well known" SID so you could use this
> declare @.builtin nvarchar(128)
> select @.builtin = suser_sname(0x01020000000000052000000020
020000)
> exec sp_revokelogin @.builtin
> --
> HTH
> Jasper Smith (SQL Server MVP)
> http://www.sqldbatips.com
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "quilkin" <quilkin@.discussions.microsoft.com> wrote in message
> news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
>
>

BUILTIN\administrators translation

Hi,
I have a line of code in an application
"sp_revokelogin [BUILTIN\Administrators]"
which fails on installations on German XP but works OK for English.
Is there a translation for 'BUILTIN'? I have tried
[BUILTIN\Administratoren] but that doesn't help - always get the message
" Windows NT user or group 'BUILTIN\Administratoren' not
found. Check the name again"
Hope someone with a German server can help!
(I also need the corresponding names for French, Spanish etc.)
BUILTIN\Administrators has a "well known" SID so you could use this
declare @.builtin nvarchar(128)
select @.builtin = suser_sname(0x01020000000000052000000020020000)
exec sp_revokelogin @.builtin
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"quilkin" <quilkin@.discussions.microsoft.com> wrote in message
news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
> Hi,
> I have a line of code in an application
> "sp_revokelogin [BUILTIN\Administrators]"
> which fails on installations on German XP but works OK for English.
> Is there a translation for 'BUILTIN'? I have tried
> [BUILTIN\Administratoren] but that doesn't help - always get the message
> " Windows NT user or group 'BUILTIN\Administratoren' not
> found. Check the name again"
> Hope someone with a German server can help!
> (I also need the corresponding names for French, Spanish etc.)
>
|||Jasper,
That works fine, thanks.
I knew there'd be a simple answer.
"Jasper Smith" wrote:

> BUILTIN\Administrators has a "well known" SID so you could use this
> declare @.builtin nvarchar(128)
> select @.builtin = suser_sname(0x01020000000000052000000020020000)
> exec sp_revokelogin @.builtin
> --
> HTH
> Jasper Smith (SQL Server MVP)
> http://www.sqldbatips.com
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "quilkin" <quilkin@.discussions.microsoft.com> wrote in message
> news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
>
>

BUILTIN\administrators translation

Hi,
I have a line of code in an application
"sp_revokelogin [BUILTIN\Administrators]"
which fails on installations on German XP but works OK for English.
Is there a translation for 'BUILTIN'? I have tried
[BUILTIN\Administratoren] but that doesn't help - always get the message
" Windows NT user or group 'BUILTIN\Administratoren' not
found. Check the name again"
Hope someone with a German server can help!
(I also need the corresponding names for French, Spanish etc.)BUILTIN\Administrators has a "well known" SID so you could use this
declare @.builtin nvarchar(128)
select @.builtin = suser_sname(0x01020000000000052000000020020000)
exec sp_revokelogin @.builtin
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"quilkin" <quilkin@.discussions.microsoft.com> wrote in message
news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
> Hi,
> I have a line of code in an application
> "sp_revokelogin [BUILTIN\Administrators]"
> which fails on installations on German XP but works OK for English.
> Is there a translation for 'BUILTIN'? I have tried
> [BUILTIN\Administratoren] but that doesn't help - always get the message
> " Windows NT user or group 'BUILTIN\Administratoren' not
> found. Check the name again"
> Hope someone with a German server can help!
> (I also need the corresponding names for French, Spanish etc.)
>|||Jasper,
That works fine, thanks.
I knew there'd be a simple answer.
"Jasper Smith" wrote:
> BUILTIN\Administrators has a "well known" SID so you could use this
> declare @.builtin nvarchar(128)
> select @.builtin = suser_sname(0x01020000000000052000000020020000)
> exec sp_revokelogin @.builtin
> --
> HTH
> Jasper Smith (SQL Server MVP)
> http://www.sqldbatips.com
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "quilkin" <quilkin@.discussions.microsoft.com> wrote in message
> news:72599A0C-028D-47A1-B63E-120EDC4C1065@.microsoft.com...
> > Hi,
> > I have a line of code in an application
> > "sp_revokelogin [BUILTIN\Administrators]"
> > which fails on installations on German XP but works OK for English.
> > Is there a translation for 'BUILTIN'? I have tried
> > [BUILTIN\Administratoren] but that doesn't help - always get the message
> > " Windows NT user or group 'BUILTIN\Administratoren' not
> > found. Check the name again"
> > Hope someone with a German server can help!
> > (I also need the corresponding names for French, Spanish etc.)
> >
>
>

BUILTIN\Administrators not recognized - rsUnknownUserName

Hello all,

We recently moved our Team Foundation Server from one server to another, of course the reporting services was also included in that move.

On the new server, we are not able to change Reporting Services security parameters anymore, we get this error :
User or group ? BUILTIN\Administrators not recognized. (rsUnknownUserName)

The old server was an english windows 2003, the new one a french version, i guess the problem is related. The BUILTIN\Administrators group name on the new server is "BUILTIN\Administrateurs".

Is there a way to change security params without getting this error ? How can we remove from Reporting Services this reference to BUILDTIN\Administrators ? I've tried to modify the table Users directly in ReportServer DB without any success..

Please help !
Alexandre

Ok I was finally able to solve the problem ! I connected to my Reporting Services server using SQL Server Management Studio and not Reporting Services administration website. In the root folder permissions, I removed the reference to BUILTIN\Administrators and added the one to BUILTIN\Administrateurs, and it worked !

Alexandre

builtin\administrators login and database access

How do I remove db_owner access from the
builtin\administrators sql login?
The db_owner and sysadmin roles have been assigned to the
windows domain account that starts SQL Server and the sa
login for all db's.
I need to remove this for secutiry/legal reason.
Any problems if I just remove the builtin\administrators
login?
Thanks."Matt Troska" <matt.troska@.co.mcleod.mn.us> wrote in message
news:495f01c3e42f$efd44e50$a501280a@.phx.gbl...

quote:

---

> How do I remove db_owner access from the
> builtin\administrators sql login?

---

You don't want to do that...

quote:

---

> The db_owner and sysadmin roles have been assigned to the
> windows domain account that starts SQL Server and the sa
> login for all db's.
> I need to remove this for secutiry/legal reason.
> Any problems if I just remove the builtin\administrators
> login?

---

That's the correct approach, as long as you've granted another group/user
sysadmin equivalence, then you can safely delete the builtin\administrators
group.
After I install SQL Server and setup the security, deleting the
builtin\administrators group is usually one of the first steps I take.
Steve

BUILTIN\Administrators Login

I would like to remove the BUILTIN\Administrators Login
from SQL Server 2000 for security purposes.
Will there be any problems with SQL Server 2000 running
properly if I do this?
Thank you.Whether you get problems or not depends. The following
article has an more information section with links to some
issues that could come up:
INF: How to impede Windows NT administrators from
administering a clustered instance of SQL Server
http://support.microsoft.com/?id=263712
-Sue
On Mon, 22 Mar 2004 12:58:47 -0800, "Mike"
<anonymous@.discussions.microsoft.com> wrote:

>I would like to remove the BUILTIN\Administrators Login
>from SQL Server 2000 for security purposes.
>Will there be any problems with SQL Server 2000 running
>properly if I do this?
>Thank you.|||Hi,
I had problems in the below when I removed "Syadmin role" from
BuildIN/Administrators. So I have given back the sysadmin role to solve the
issue.
1. FULL Text Indexing
2. Maintenance Plans
So do a test in test server for couple of weeks and then implement in
Production server.
Known issues after removal ,
Some things to be aware of:
Q237604 PRB: SQL Server Agent Does Not Start and Displays Error 18456
Q295034 FIX: MSSearch Takes 100% CPU if BUILTIN\Administrators Removed
Q317746 PRB: SQL Server Full-Text Search Does Not Populate Catalogs
Thanks
Hari
MCDBA
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:d9mu5054kffi4f8olts36mpa8du6um98q9@.
4ax.com...
> Whether you get problems or not depends. The following
> article has an more information section with links to some
> issues that could come up:
> INF: How to impede Windows NT administrators from
> administering a clustered instance of SQL Server
> http://support.microsoft.com/?id=263712
> -Sue
> On Mon, 22 Mar 2004 12:58:47 -0800, "Mike"
> <anonymous@.discussions.microsoft.com> wrote:
>
>

BUILTIN\ADMINISTRATORS EVENT 6013

I have been getting a weird SQL event message the applications event log. I
am running
sql 2000 sp 3a
windows 2003 standard server sp1
I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
when removing this account. I was told the NT AUTHORITY\SYSTEM account can
lead to sql injection attacks. Some say just add the builtin administrators
account back but it goes against best practices and I would like to work
around it. iS this possible... Seems like I have been running into more
problems by removing this account. Any help is appreciated.
Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
Error state: 1, Severity: 14
Source: Microsoft OLE DB Provider for SQL Server
Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
0000: 2d 20 43 6f 64 65 3a 20 - Code:
0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0010: 30 30 30 30 30 34 39 31 00000491
0018: 2d 20 43 61 6c 6c 3a 20 - Call:
0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0028: 30 30 30 30 30 33 39 37 00000397
0030: 2d 20 50 49 44 3a 20 20 - PID:
0038: 30 30 30 30 32 38 38 30 00002880
0040: 2d 20 54 49 44 3a 20 20 - TID:
0048: 30 30 30 30 34 38 30 34 00004804
0050: 2d 20 43 4d 44 3a 20 20 - CMD:
0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
0060: 57 53 5c 53 79 73 74 65 WS\Syste
0068: 6d 33 32 5c 76 73 73 76 m32\vssv
0070: 63 2e 65 78 65 20 20 20 c.exe
0078: 2d 20 55 73 65 72 3a 20 - User:
0080: 4e 54 20 41 55 54 48 4f NT AUTHO
0088: 52 49 54 59 5c 53 59 53 RITY\SYS
0090: 54 45 4d 20 20 20 20 20 TEMvssvc.exe is the Volume Shadow Copy service I believe. I don't know why
it would be trying to connect to the SQL instance but I haven't really
played with it much so it may need to for some reason (it's a legit
Microsoft service). Anyway, it would appear it's running under the
local system account, which is fine, and if you want that functionality
to work you can just sp_grantlogin to 'NT AUTHORITY\SYSTEM'. This is
different to granting all local admins (ie. 'BUILTIN\Administrators')
sysadmin privileges (which I wouldn't recommend), but some apps (mostly
services like Microsoft Search (full-text) on SQL 2000 boxes for
instance) need to talk to SQL Server and typically use the local system
account. I wouldn't see that as a big security hole.
SQL Injection has nothing to do with granting 'NT AUTHORITY\SYSTEM' a
login to the SQL instance. If the SQL Server service is running under
an admin account (like the local system account for instance, which is
pretty common) then if an attacker exploits some weakness in a user
application (that doesn't validate the T-SQL code it's sending to the
SQL server) then they can use a SQL injection attack to take control of
the box (because SQL Server would do what they asked it to, within the
permissions granted to their SQL login, and that might mean some Windows
admin function, which the SQL instance could do if it was a local admin,
like local system).
SQL injection is a possible factor in poorly written applications that
use SQL Server on the back-end. It is not related to which logins can
connect to your SQL instance, but is more relevant to the account under
which your SQL instance runs on the OS (and which login to the SQL box
the poorly written SQL app uses - hopefully not a sysadmin login).
*mike hodgson*
http://sqlnerd.blogspot.com
JD wrote:

>I have been getting a weird SQL event message the applications event log. I
>am running
>sql 2000 sp 3a
>windows 2003 standard server sp1
>I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
>when removing this account. I was told the NT AUTHORITY\SYSTEM account can
>lead to sql injection attacks. Some say just add the builtin administrators
>account back but it goes against best practices and I would like to work
>around it. iS this possible... Seems like I have been running into more
>problems by removing this account. Any help is appreciated.
>Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
>= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
>Error state: 1, Severity: 14
>Source: Microsoft OLE DB Provider for SQL Server
>Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
>
>0000: 2d 20 43 6f 64 65 3a 20 - Code:
>0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
>0010: 30 30 30 30 30 34 39 31 00000491
>0018: 2d 20 43 61 6c 6c 3a 20 - Call:
>0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
>0028: 30 30 30 30 30 33 39 37 00000397
>0030: 2d 20 50 49 44 3a 20 20 - PID:
>0038: 30 30 30 30 32 38 38 30 00002880
>0040: 2d 20 54 49 44 3a 20 20 - TID:
>0048: 30 30 30 30 34 38 30 34 00004804
>0050: 2d 20 43 4d 44 3a 20 20 - CMD:
>0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
>0060: 57 53 5c 53 79 73 74 65 WS\Syste
>0068: 6d 33 32 5c 76 73 73 76 m32\vssv
>0070: 63 2e 65 78 65 20 20 20 c.exe
>0078: 2d 20 55 73 65 72 3a 20 - User:
>0080: 4e 54 20 41 55 54 48 4f NT AUTHO
>0088: 52 49 54 59 5c 53 59 53 RITY\SYS
>0090: 54 45 4d 20 20 20 20 20 TEM
>
>|||Thank you for your response. That did shed some light on the problem. Seems
like are backup admin selected to backup with veritas sql client and had it
misconfigured.
JD
"Mike Hodgson" <e1minst3r@.gmail.com> wrote in message news:%23Vlz6S0OGHA.183
2@.TK2MSFTNGP11.phx.gbl...
vssvc.exe is the Volume Shadow Copy service I believe. I don't know why it
would be trying to connect to the SQL instance but I haven't really played w
ith it much so it may need to for some reason (it's a legit Microsoft servic
e). Anyway, it would appear it's running under the local system account, wh
ich is fine, and if you want that functionality to work you can just sp_gran
tlogin to 'NT AUTHORITY\SYSTEM'. This is different to granting all local ad
mins (ie. 'BUILTIN\Administrators') sysadmin privileges (which I wouldn't re
commend), but some apps (mostly services like Microsoft Search (full-text) o
n SQL 2000 boxes for instance) need to talk to SQL Server and typically use
the local system account. I wouldn't see that as a big security hole.
SQL Injection has nothing to do with granting 'NT AUTHORITY\SYSTEM' a login
to the SQL instance. If the SQL Server service is running under an admin ac
count (like the local system account for instance, which is pretty common) t
hen if an attacker exploits some weakness in a user application (that doesn'
t validate the T-SQL code it's sending to the SQL server) then they can use
a SQL injection attack to take control of the box (because SQL Server would
do what they asked it to, within the permissions granted to their SQL login,
and that might mean some Windows admin function, which the SQL instance cou
ld do if it was a local admin, like local system).
SQL injection is a possible factor in poorly written applications that use S
QL Server on the back-end. It is not related to which logins can connect to
your SQL instance, but is more relevant to the account under which your SQL
instance runs on the OS (and which login to the SQL box the poorly written
SQL app uses - hopefully not a sysadmin login).
mike hodgson
http://sqlnerd.blogspot.com
JD wrote:
I have been getting a weird SQL event message the applications event log. I
am running
sql 2000 sp 3a
windows 2003 standard server sp1
I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
when removing this account. I was told the NT AUTHORITY\SYSTEM account can
lead to sql injection attacks. Some say just add the builtin administrators
account back but it goes against best practices and I would like to work
around it. iS this possible... Seems like I have been running into more
problems by removing this account. Any help is appreciated.
Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
Error state: 1, Severity: 14
Source: Microsoft OLE DB Provider for SQL Server
Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
0000: 2d 20 43 6f 64 65 3a 20 - Code:
0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0010: 30 30 30 30 30 34 39 31 00000491
0018: 2d 20 43 61 6c 6c 3a 20 - Call:
0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0028: 30 30 30 30 30 33 39 37 00000397
0030: 2d 20 50 49 44 3a 20 20 - PID:
0038: 30 30 30 30 32 38 38 30 00002880
0040: 2d 20 54 49 44 3a 20 20 - TID:
0048: 30 30 30 30 34 38 30 34 00004804
0050: 2d 20 43 4d 44 3a 20 20 - CMD:
0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
0060: 57 53 5c 53 79 73 74 65 WS\Syste
0068: 6d 33 32 5c 76 73 73 76 m32\vssv
0070: 63 2e 65 78 65 20 20 20 c.exe
0078: 2d 20 55 73 65 72 3a 20 - User:
0080: 4e 54 20 41 55 54 48 4f NT AUTHO
0088: 52 49 54 59 5c 53 59 53 RITY\SYS
0090: 54 45 4d 20 20 20 20 20 TEM

BUILTIN\Administrators Account

I was told to give reasons why we keep
the 'BUILTIN\Administrators' Account and I came up with
the following. If there are any other reasons please let
me know. May be there is no reason to keep this account.
The server is set to SQL Server & Windows Authentication.
Thanks.
1- If the domain controller fails and/or the server
becomes as 'Stand alone' server, we may be locked out of
the SQL Server.
2- Removing this account leaves us to use only 'sa'
account to log on to the server in case of a failure. If
the 'sa' password is not available, we will be locked out
of SQL Server.
3- If 'sa' password gets out of sync, we will be locked
out of SQL Server.Hi Dan,
If you keep BUILTIN\Administrators in your logins account you actually give
SysAdmin rights to any local administrator in your or trusted domain, so
it's highly recommended to delete this account from logins, but nobody
prevent you from putting local\Administrator account for purposes you
already described.
Regards,
Daniel
"Dan" <anonymous@.discussions.microsoft.com> wrote in message
news:224801c52e44$b057b900$a401280a@.phx.gbl...
> I was told to give reasons why we keep
> the 'BUILTIN\Administrators' Account and I came up with
> the following. If there are any other reasons please let
> me know. May be there is no reason to keep this account.
> The server is set to SQL Server & Windows Authentication.
> Thanks.
> 1- If the domain controller fails and/or the server
> becomes as 'Stand alone' server, we may be locked out of
> the SQL Server.
> 2- Removing this account leaves us to use only 'sa'
> account to log on to the server in case of a failure. If
> the 'sa' password is not available, we will be locked out
> of SQL Server.
> 3- If 'sa' password gets out of sync, we will be locked
> out of SQL Server.|||You can remove the builtin\administrators group from SQL
Server. However, under some scenarios, this can cause
problems. Whether you experience problems or not depends.
The following article has a more information section with
links to some issues that could come up:
INF: How to impede Windows NT administrators from
administering a clustered instance of SQL Server
http://support.microsoft.com/?id=263712
-Sue
On Mon, 21 Mar 2005 10:35:00 -0800, "Dan"
<anonymous@.discussions.microsoft.com> wrote:

>I was told to give reasons why we keep
>the 'BUILTIN\Administrators' Account and I came up with
>the following. If there are any other reasons please let
>me know. May be there is no reason to keep this account.
>The server is set to SQL Server & Windows Authentication.
>Thanks.
>1- If the domain controller fails and/or the server
>becomes as 'Stand alone' server, we may be locked out of
>the SQL Server.
>2- Removing this account leaves us to use only 'sa'
>account to log on to the server in case of a failure. If
>the 'sa' password is not available, we will be locked out
>of SQL Server.
>3- If 'sa' password gets out of sync, we will be locked
>out of SQL Server.

BUILTIN\Administrators Account

Hi all,
I'm running sql server 2000. I'm wondering if I can
remove the BUILTIN\Administors in sql server. Would it
cause any problem to sql server? is ther anything running
behind sql server using this account?
Thanks,
ttThere should be no problem, as long as you are use either the 'sa' account
or have created other administrative account directly in SQL.
BUILTIN\Administers group will give any administrative login account (on the
computer) full admin rights to SQL Server. So as long as you don't want any
joe-blow admin messing with your SQL Server, remove it.
my two cents and yes, my name really is Joe.
"tt" <anonymous@.discussions.microsoft.com> wrote in message
news:2aab201c465f3$63e81930$a301280a@.phx
.gbl...
> Hi all,
> I'm running sql server 2000. I'm wondering if I can
> remove the BUILTIN\Administors in sql server. Would it
> cause any problem to sql server? is ther anything running
> behind sql server using this account?
> Thanks,
> tt|||You'll want to specify another group as SQL system Admins prior to dropping
this group.
263712 INF: How to impede Windows NT administrators from administering a
http://support.microsoft.com/?id=263712
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||We've removed the builtin group from all our production servers without any
issues and as referred ensure your login or referred logins has required pr
ivileges in order to hand SQL Server.
--
--
Satya SKJ
"Kevin McDonnell [MSFT]" wrote:

> You'll want to specify another group as SQL system Admins prior to droppin
g
> this group.
> 263712 INF: How to impede Windows NT administrators from administering a
> http://support.microsoft.com/?id=263712
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Hello,
I would like to remove sysadmin privleges on the "BUILTIN\Administrators" gr
oup on my SQL Server...but before I do - I have a question:
If I remove sysadmin privleges and am not happy w/ how this affects my serve
r - is there an easy way to put my system back to the way it was? I'd imagin
e that if all I did was remove it from sysadmin in EM then all I have to do
is grant sysadmin back agai
n. Is this correct?
I'd appreciate any feedback...
Thanks!
John
"Satya SKJ" wrote:
[vbcol=seagreen]
> We've removed the builtin group from all our production servers without an
y issues and as referred ensure your login or referred logins has required
privileges in order to hand SQL Server.
> --
> --
> Satya SKJ
>
> "Kevin McDonnell [MSFT]" wrote:
>|||You can execute the following in Query Analyzer:
EXEC sp_grantlogin 'BUILTIN\Administrators'
By default, the group is a member of the sysadmins sql
server role. If you wanted this back as well, you could
execute the following:
EXEC sp_addsrvrolemember 'BUILTIN\Administrators' ,
'sysadmin'
-Sue
On Mon, 2 Aug 2004 10:19:02 -0700, John P
<JohnP@.discussions.microsoft.com> wrote:

>Hello,
>I would like to remove sysadmin privleges on the "BUILTIN\Administrators" g
roup on my SQL Server...but before I do - I have a question:
>If I remove sysadmin privleges and am not happy w/ how this affects my server - is
there an easy way to put my system back to the way it was? I'd imagine that if all I
did was remove it from sysadmin in EM then all I have to do is grant sysadmin back
aga
in. Is this correct?[vbcol=seagreen]
>I'd appreciate any feedback...
>Thanks!
>John
>"Satya SKJ" wrote:
>

BUILTIN\Administrators Account

I was told to give reasons why we keep
the 'BUILTIN\Administrators' Account and I came up with
the following. If there are any other reasons please let
me know. May be there is no reason to keep this account.
The server is set to SQL Server & Windows Authentication.
Thanks.
1- If the domain controller fails and/or the server
becomes as 'Stand alone' server, we may be locked out of
the SQL Server.
2- Removing this account leaves us to use only 'sa'
account to log on to the server in case of a failure. If
the 'sa' password is not available, we will be locked out
of SQL Server.
3- If 'sa' password gets out of sync, we will be locked
out of SQL Server.
Hi Dan,
If you keep BUILTIN\Administrators in your logins account you actually give
SysAdmin rights to any local administrator in your or trusted domain, so
it's highly recommended to delete this account from logins, but nobody
prevent you from putting local\Administrator account for purposes you
already described.
Regards,
Daniel
"Dan" <anonymous@.discussions.microsoft.com> wrote in message
news:224801c52e44$b057b900$a401280a@.phx.gbl...
> I was told to give reasons why we keep
> the 'BUILTIN\Administrators' Account and I came up with
> the following. If there are any other reasons please let
> me know. May be there is no reason to keep this account.
> The server is set to SQL Server & Windows Authentication.
> Thanks.
> 1- If the domain controller fails and/or the server
> becomes as 'Stand alone' server, we may be locked out of
> the SQL Server.
> 2- Removing this account leaves us to use only 'sa'
> account to log on to the server in case of a failure. If
> the 'sa' password is not available, we will be locked out
> of SQL Server.
> 3- If 'sa' password gets out of sync, we will be locked
> out of SQL Server.
|||You can remove the builtin\administrators group from SQL
Server. However, under some scenarios, this can cause
problems. Whether you experience problems or not depends.
The following article has a more information section with
links to some issues that could come up:
INF: How to impede Windows NT administrators from
administering a clustered instance of SQL Server
http://support.microsoft.com/?id=263712
-Sue
On Mon, 21 Mar 2005 10:35:00 -0800, "Dan"
<anonymous@.discussions.microsoft.com> wrote:

>I was told to give reasons why we keep
>the 'BUILTIN\Administrators' Account and I came up with
>the following. If there are any other reasons please let
>me know. May be there is no reason to keep this account.
>The server is set to SQL Server & Windows Authentication.
>Thanks.
>1- If the domain controller fails and/or the server
>becomes as 'Stand alone' server, we may be locked out of
>the SQL Server.
>2- Removing this account leaves us to use only 'sa'
>account to log on to the server in case of a failure. If
>the 'sa' password is not available, we will be locked out
>of SQL Server.
>3- If 'sa' password gets out of sync, we will be locked
>out of SQL Server.

BUILTIN\Administrators Account

I was told to give reasons why we keep
the 'BUILTIN\Administrators' Account and I came up with
the following. If there are any other reasons please let
me know. May be there is no reason to keep this account.
The server is set to SQL Server & Windows Authentication.
Thanks.
1- If the domain controller fails and/or the server
becomes as 'Stand alone' server, we may be locked out of
the SQL Server.
2- Removing this account leaves us to use only 'sa'
account to log on to the server in case of a failure. If
the 'sa' password is not available, we will be locked out
of SQL Server.
3- If 'sa' password gets out of sync, we will be locked
out of SQL Server.Hi Dan,
If you keep BUILTIN\Administrators in your logins account you actually give
SysAdmin rights to any local administrator in your or trusted domain, so
it's highly recommended to delete this account from logins, but nobody
prevent you from putting local\Administrator account for purposes you
already described.
Regards,
Daniel
"Dan" <anonymous@.discussions.microsoft.com> wrote in message
news:224801c52e44$b057b900$a401280a@.phx.gbl...
> I was told to give reasons why we keep
> the 'BUILTIN\Administrators' Account and I came up with
> the following. If there are any other reasons please let
> me know. May be there is no reason to keep this account.
> The server is set to SQL Server & Windows Authentication.
> Thanks.
> 1- If the domain controller fails and/or the server
> becomes as 'Stand alone' server, we may be locked out of
> the SQL Server.
> 2- Removing this account leaves us to use only 'sa'
> account to log on to the server in case of a failure. If
> the 'sa' password is not available, we will be locked out
> of SQL Server.
> 3- If 'sa' password gets out of sync, we will be locked
> out of SQL Server.|||You can remove the builtin\administrators group from SQL
Server. However, under some scenarios, this can cause
problems. Whether you experience problems or not depends.
The following article has a more information section with
links to some issues that could come up:
INF: How to impede Windows NT administrators from
administering a clustered instance of SQL Server
http://support.microsoft.com/?id=263712
-Sue
On Mon, 21 Mar 2005 10:35:00 -0800, "Dan"
<anonymous@.discussions.microsoft.com> wrote:
>I was told to give reasons why we keep
>the 'BUILTIN\Administrators' Account and I came up with
>the following. If there are any other reasons please let
>me know. May be there is no reason to keep this account.
>The server is set to SQL Server & Windows Authentication.
>Thanks.
>1- If the domain controller fails and/or the server
>becomes as 'Stand alone' server, we may be locked out of
>the SQL Server.
>2- Removing this account leaves us to use only 'sa'
>account to log on to the server in case of a failure. If
>the 'sa' password is not available, we will be locked out
>of SQL Server.
>3- If 'sa' password gets out of sync, we will be locked
>out of SQL Server.

Builtin\Administrators

I have a rogue co-worker who wants to support SQL buit doesn't know
how. This person is a domain admin so it's difficut to keep him from
accessing and "doing stuff" with SQL server.
I want to SAFELY deny access to the builtin\administrator login but I
want to be sure I don't deny access to people who need it.
Here are a few steps I think I nned to take in order to secure my
instance:
1. Review the local administrators group membership on the server and
remove any unnecesary members.
2. Create a local group and add the network admins that need access to
SQL to the group
3. Create a role/user (not sure which is best) and map the local group
to this login
4. Restrict login based on fixed server/database roles
Any asistance is appreciated.
I always remove BUILTIN\Administrators not only from sysadmin but from the
entire SQL Server instance. If there are some services, like FullText Search,
that may be using these permissions, I give them a Windows account instead.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"NC3" wrote:

> I have a rogue co-worker who wants to support SQL buit doesn't know
> how. This person is a domain admin so it's difficut to keep him from
> accessing and "doing stuff" with SQL server.
> I want to SAFELY deny access to the builtin\administrator login but I
> want to be sure I don't deny access to people who need it.
> Here are a few steps I think I nned to take in order to secure my
> instance:
> 1. Review the local administrators group membership on the server and
> remove any unnecesary members.
> 2. Create a local group and add the network admins that need access to
> SQL to the group
> 3. Create a role/user (not sure which is best) and map the local group
> to this login
> 4. Restrict login based on fixed server/database roles
> Any asistance is appreciated.
>
|||While I respect the advice given and acknowledge you need to do those
things, frankly you have a people problem, not a database problem.
I suggest that if he is doing things that has gotten your attention, and
won't stop, you need to take it up with your manager. If you don't and just
deny him access, it is likely HE will take it up wit HIS manager and then,
you'll have a completly different mess.
"NC3" <ncoleman3@.yahoo.com> wrote in message
news:1194973802.571321.51230@.o3g2000hsb.googlegrou ps.com...
>I have a rogue co-worker who wants to support SQL buit doesn't know
> how. This person is a domain admin so it's difficut to keep him from
> accessing and "doing stuff" with SQL server.
> I want to SAFELY deny access to the builtin\administrator login but I
> want to be sure I don't deny access to people who need it.
> Here are a few steps I think I nned to take in order to secure my
> instance:
> 1. Review the local administrators group membership on the server and
> remove any unnecesary members.
> 2. Create a local group and add the network admins that need access to
> SQL to the group
> 3. Create a role/user (not sure which is best) and map the local group
> to this login
> 4. Restrict login based on fixed server/database roles
> Any asistance is appreciated.
>

BUILTIN\Administrators

Dear All,
Can someone tell me what this actually is and what it,
more importantly where I would get it changed.
The reason is that a user (an ex developer) can give
themselves SA rights although through there NT
Authorization however they are not an administrator and
should not be allowed to access any of the server security
properies.
The only theory I have is that the BUILTIN\Administrators
is allowing SA access as its the only group I currently
have.
Thanks for reading
Peter
There are several ways to work around this:
1. Remove the exdevelopers from the NT administrators group and change the
password of local administrator account on the server machine.
2. An extreme solution, which I have used on my local server is to delete
this group from SQL Server. You can then add individaully or by another
group that you can control who has sa access on the server. I would
recommend you test this solution well before trying it in production.
Amol.
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:b57301c43762$44127700$a101280a@.phx.gbl...
> Dear All,
> Can someone tell me what this actually is and what it,
> more importantly where I would get it changed.
> The reason is that a user (an ex developer) can give
> themselves SA rights although through there NT
> Authorization however they are not an administrator and
> should not be allowed to access any of the server security
> properies.
> The only theory I have is that the BUILTIN\Administrators
> is allowing SA access as its the only group I currently
> have.
> Thanks for reading
> Peter
>
|||Thanks Amol
Peter

>--Original Message--
>There are several ways to work around this:
>1. Remove the exdevelopers from the NT administrators
group and change the
>password of local administrator account on the server
machine.
>2. An extreme solution, which I have used on my local
server is to delete
>this group from SQL Server. You can then add individaully
or by another
>group that you can control who has sa access on the
server. I would
>recommend you test this solution well before trying it in
production.
>Amol.
>
>"Peter" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:b57301c43762$44127700$a101280a@.phx.gbl...
security[vbcol=seagreen]
BUILTIN\Administrators
>
>.
>
|||The second solution is potentially dangerous. Services, such as the Full
Text engine require the BUILTIN\Administrators group to be given access to
SQL Server...
Cheers,
James Goodman
"Amol Kasbekar" <apk@.nospam.com> wrote in message
news:%23vclye2NEHA.3944@.tk2msftngp13.phx.gbl...
> There are several ways to work around this:
> 1. Remove the exdevelopers from the NT administrators group and change the
> password of local administrator account on the server machine.
> 2. An extreme solution, which I have used on my local server is to delete
> this group from SQL Server. You can then add individaully or by another
> group that you can control who has sa access on the server. I would
> recommend you test this solution well before trying it in production.
> Amol.
>
> "Peter" <anonymous@.discussions.microsoft.com> wrote in message
> news:b57301c43762$44127700$a101280a@.phx.gbl...
>

BUILTIN\Administrators

Dear All,
Can someone tell me what this actually is and what it,
more importantly where I would get it changed.
The reason is that a user (an ex developer) can give
themselves SA rights although through there NT
Authorization however they are not an administrator and
should not be allowed to access any of the server security
properies.
The only theory I have is that the BUILTIN\Administrators
is allowing SA access as its the only group I currently
have.
Thanks for reading
PeterThere are several ways to work around this:
1. Remove the exdevelopers from the NT administrators group and change the
password of local administrator account on the server machine.
2. An extreme solution, which I have used on my local server is to delete
this group from SQL Server. You can then add individaully or by another
group that you can control who has sa access on the server. I would
recommend you test this solution well before trying it in production.
Amol.
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:b57301c43762$44127700$a101280a@.phx.gbl...
> Dear All,
> Can someone tell me what this actually is and what it,
> more importantly where I would get it changed.
> The reason is that a user (an ex developer) can give
> themselves SA rights although through there NT
> Authorization however they are not an administrator and
> should not be allowed to access any of the server security
> properies.
> The only theory I have is that the BUILTIN\Administrators
> is allowing SA access as its the only group I currently
> have.
> Thanks for reading
> Peter
>|||Thanks Amol
Peter
>--Original Message--
>There are several ways to work around this:
>1. Remove the exdevelopers from the NT administrators
group and change the
>password of local administrator account on the server
machine.
>2. An extreme solution, which I have used on my local
server is to delete
>this group from SQL Server. You can then add individaully
or by another
>group that you can control who has sa access on the
server. I would
>recommend you test this solution well before trying it in
production.
>Amol.
>
>"Peter" <anonymous@.discussions.microsoft.com> wrote in
message
>news:b57301c43762$44127700$a101280a@.phx.gbl...
>> Dear All,
>> Can someone tell me what this actually is and what it,
>> more importantly where I would get it changed.
>> The reason is that a user (an ex developer) can give
>> themselves SA rights although through there NT
>> Authorization however they are not an administrator and
>> should not be allowed to access any of the server
security
>> properies.
>> The only theory I have is that the
BUILTIN\Administrators
>> is allowing SA access as its the only group I currently
>> have.
>> Thanks for reading
>> Peter
>
>.
>|||The second solution is potentially dangerous. Services, such as the Full
Text engine require the BUILTIN\Administrators group to be given access to
SQL Server...
--
Cheers,
James Goodman
"Amol Kasbekar" <apk@.nospam.com> wrote in message
news:%23vclye2NEHA.3944@.tk2msftngp13.phx.gbl...
> There are several ways to work around this:
> 1. Remove the exdevelopers from the NT administrators group and change the
> password of local administrator account on the server machine.
> 2. An extreme solution, which I have used on my local server is to delete
> this group from SQL Server. You can then add individaully or by another
> group that you can control who has sa access on the server. I would
> recommend you test this solution well before trying it in production.
> Amol.
>
> "Peter" <anonymous@.discussions.microsoft.com> wrote in message
> news:b57301c43762$44127700$a101280a@.phx.gbl...
> > Dear All,
> >
> > Can someone tell me what this actually is and what it,
> > more importantly where I would get it changed.
> >
> > The reason is that a user (an ex developer) can give
> > themselves SA rights although through there NT
> > Authorization however they are not an administrator and
> > should not be allowed to access any of the server security
> > properies.
> >
> > The only theory I have is that the BUILTIN\Administrators
> > is allowing SA access as its the only group I currently
> > have.
> >
> > Thanks for reading
> > Peter
> >
>

Builtin\Administrators

I have a rogue co-worker who wants to support SQL buit doesn't know
how. This person is a domain admin so it's difficut to keep him from
accessing and "doing stuff" with SQL server.
I want to SAFELY deny access to the builtin\administrator login but I
want to be sure I don't deny access to people who need it.
Here are a few steps I think I nned to take in order to secure my
instance:
1. Review the local administrators group membership on the server and
remove any unnecesary members.
2. Create a local group and add the network admins that need access to
SQL to the group
3. Create a role/user (not sure which is best) and map the local group
to this login
4. Restrict login based on fixed server/database roles
Any asistance is appreciated.I always remove BUILTIN\Administrators not only from sysadmin but from the
entire SQL Server instance. If there are some services, like FullText Search,
that may be using these permissions, I give them a Windows account instead.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"NC3" wrote:
> I have a rogue co-worker who wants to support SQL buit doesn't know
> how. This person is a domain admin so it's difficut to keep him from
> accessing and "doing stuff" with SQL server.
> I want to SAFELY deny access to the builtin\administrator login but I
> want to be sure I don't deny access to people who need it.
> Here are a few steps I think I nned to take in order to secure my
> instance:
> 1. Review the local administrators group membership on the server and
> remove any unnecesary members.
> 2. Create a local group and add the network admins that need access to
> SQL to the group
> 3. Create a role/user (not sure which is best) and map the local group
> to this login
> 4. Restrict login based on fixed server/database roles
> Any asistance is appreciated.
>|||Hello!
Local Administrators Windows group has nothing to do with Domain Admins
group. They are different stuff. As your co-worker is in the Domain Admins
group (according to your saying he was a domain admin) and the mentioned
group must be a member of the sysadmin fixed server role. So it would not
make any difference if you remove Local Admin group in SQL Server Windows
Logins. He would be able to connect to your instance (I assume there is a
Domain Admins login in SQL Server Logins)
If your SQL Server is in a domain environment, then you better use domain
accounts to connect to your instance. BUILTIN\Administrators should be
deleted in many cases however this rule does not apply to ALL cases. First,
ensure that there is nothing using this account related to your SQL Server
instance. After ensuring this, you can delete it safely.
Why don't you explicitly deny him connecting to your SQL Server if he is the
only problem?
In which group is your account? You can remove Domain Admins from the Logins
if you are not in that group and if there is no one connecting to your SQL
Server in that group.
--
Ekrem Önsoy
"NC3" <ncoleman3@.yahoo.com> wrote in message
news:1194973802.571321.51230@.o3g2000hsb.googlegroups.com...
>I have a rogue co-worker who wants to support SQL buit doesn't know
> how. This person is a domain admin so it's difficut to keep him from
> accessing and "doing stuff" with SQL server.
> I want to SAFELY deny access to the builtin\administrator login but I
> want to be sure I don't deny access to people who need it.
> Here are a few steps I think I nned to take in order to secure my
> instance:
> 1. Review the local administrators group membership on the server and
> remove any unnecesary members.
> 2. Create a local group and add the network admins that need access to
> SQL to the group
> 3. Create a role/user (not sure which is best) and map the local group
> to this login
> 4. Restrict login based on fixed server/database roles
> Any asistance is appreciated.
>|||While I respect the advice given and acknowledge you need to do those
things, frankly you have a people problem, not a database problem.
I suggest that if he is doing things that has gotten your attention, and
won't stop, you need to take it up with your manager. If you don't and just
deny him access, it is likely HE will take it up wit HIS manager and then,
you'll have a completly different mess.
"NC3" <ncoleman3@.yahoo.com> wrote in message
news:1194973802.571321.51230@.o3g2000hsb.googlegroups.com...
>I have a rogue co-worker who wants to support SQL buit doesn't know
> how. This person is a domain admin so it's difficut to keep him from
> accessing and "doing stuff" with SQL server.
> I want to SAFELY deny access to the builtin\administrator login but I
> want to be sure I don't deny access to people who need it.
> Here are a few steps I think I nned to take in order to secure my
> instance:
> 1. Review the local administrators group membership on the server and
> remove any unnecesary members.
> 2. Create a local group and add the network admins that need access to
> SQL to the group
> 3. Create a role/user (not sure which is best) and map the local group
> to this login
> 4. Restrict login based on fixed server/database roles
> Any asistance is appreciated.
>