Showing posts with label builtin. Show all posts
Showing posts with label builtin. Show all posts

Monday, March 12, 2012

Localization and BUILTIN groups

Is there a synonym for the group BUILTIN\Users which can be used for GRANT ... TO and sp_grantlogin/sp_grantdbaccess, but which will work on localized computers?

I have a number of automated unit tests I wish to run on two different computers. The process involves recreating a database if it does not exist and then granting access and privileges to the BUILTIN\Users group.

The problem is that one computer is installed with a Swedish Windows XP Professional (the users group is called BUILTIN\Anv?ndare) and the other is an English WinXP MCE (the group is called BUILTIN\Users) so I cannot easily script this.

An alternative is to be able to retrieve the respective name through a .NET class or the Windows API.

Is any of this possible?

Thanks,
Johan

synonyms can be used only to securables residing inside a schema not principals or users.

you can however rename a login to a more friendly name inside a datbase using sp_grant dbaccess

Examples

This example adds an account for the Windows NT user Corporate\GeorgeW to the current database and gives it the name Georgie.

EXEC sp_grantdbaccess 'Corporate\GeorgeW', 'Georgie'

|||So there's no way to refer to BUILTIN\Users without knowing what language OS the machine has installed?

This works on an English OS only:
execute sp_grantlogin [BUILTIN\Users];
execute sp_grantdbaccess [BUILTIN\Users];.. and this on a Swedish OS:
execute sp_grantlogin [BUILTIN\Anv?ndare];
execute sp_grantdbaccess [BUILTIN\Anv?ndare];|||

run both statement and

put it in a try... catch.. block...

i mean use error handling

|||Good thinking!
Thanks|||

Actually you don't need to use try..catch at all. All Windows operating systems have certain number of well-known groups / users. These are universal and the SIDs for those are also the same across machines/windows OSes. So in your case, just do the following:

declare @.builtin_admins nvarchar(128)

set @.builtin_admins = suser_sname(0x01020000000000052000000020020000)

exec sp_grantdbaccess @.builtin_admins

declare @.builtin_users nvarchar(128)

set @.builtin_users = suser_name(0x01020000000000052000000021020000)

exec sp_grantdbaccess @.builtin_users

The SID values are the well-known values that will not change and you can use that to lookup the name. This will not work for user-defined groups.

|||That does it for me.
Thanks a million.

Friday, March 9, 2012

LocalAdmins, LocalSystem, and the sysadmin role

During SQL Server 2005 installation, several logins are added to the
sysadmin role including:
- local administrator group (BUILTIN\Administrators),
- Local System (NT AUTHORITY\SYSTEM), and
- sa.
A common hardening practice is to later remove the local administrator group
from the sysadmin role, thereby separating server administration from DBMS
administration. However, I don't recall ever seeing the recommendation to
also remove the LocalSystem account from the sysadmin role.
Has anyone seen recommendations to remove BOTH local administrators and
LocalSystem from the sysadmin role for hardening purposes, and - if this
were to be done - what are the consequences?
Thanks in advance (and apologies for re-posting in hopes of a response),
DrewHello Drew,
Yes, generally we remove local administrator group from sysadmin role which
actually prevent accessing sql server who is having system admini privilages
on the server.
Now personally I prefer not to remove Local System as I was facing problem
while using the full-text search. Please refer the following Microsoft
article.
http://support.microsoft.com/kb/317746
Hope this will help you.
Regards,
MB
"DHamre" <dhamre@.comcast.net> wrote in message
news:%23Au%23cyMMHHA.3424@.TK2MSFTNGP02.phx.gbl...
> During SQL Server 2005 installation, several logins are added to the
> sysadmin role including:
> - local administrator group (BUILTIN\Administrators),
> - Local System (NT AUTHORITY\SYSTEM), and
> - sa.
> A common hardening practice is to later remove the local administrator
> group from the sysadmin role, thereby separating server administration
> from DBMS administration. However, I don't recall ever seeing the
> recommendation to also remove the LocalSystem account from the sysadmin
> role.
> Has anyone seen recommendations to remove BOTH local administrators and
> LocalSystem from the sysadmin role for hardening purposes, and - if this
> were to be done - what are the consequences?
> Thanks in advance (and apologies for re-posting in hopes of a response),
> Drew
>

local system question

If I remove builtin\administrators will this prevent local system from being
a potential startup account?
TIA,
John"John Brown" <anonymous@.discussions.microsoft.com> wrote in message
news:670DC55B-F707-41AF-9B1F-18B6DCEDFA89@.microsoft.com...
> If I remove builtin\administrators will this prevent local system from
being a potential startup account?
No
Steve|||Well I don't know if this is the same problem but it may be a clue. I recen
tly ran into trouble with an access front end on a workstation that suddenly
wouldn't connect to the server. It wouldn't connect using the server name
nor would the name show up
in the drop down list. As it turns out it was a hijack virus that two diffe
rent scanners didn't detect. It took control of that machine as it tried to
connect to the server using the name of the server. So I just used the ip
of the server to connect an
d it works. So it may be a virus.|||John,
It doesn't but if your SQL Servers are clustered then you will need to make
sure the cluster account can still access SQL Server. It usually does so by
using the BUILTIN\Administrators logon. There is also a problem with Search
Service:
FIX: Microsoft Search Service May Cause 100% CPU Usage if BUILTIN\Administra
tors Login Is Removed
http://support.microsoft.com/defaul...034&Product=sql
INF: How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/defaul...712&Product=sql
There are probably a few more KB articles I don't remember.
Randy Dyess
www.Database-Security.Info