Showing posts with label permissions. Show all posts
Showing posts with label permissions. Show all posts

Wednesday, March 7, 2012

dont permit manual access to database

I've got a java application that connects to a sql server 2000
database.
The application must access with total permissions to database but I
don't want that anybody can insert or delete data with the corporative
administrator of sql server 2000.
How can I lock the corporative administrator in order to not permit
manual manipulation but my application can work properly?
Thanks!There's no way to prevent a sysadmin from accessing a database. You
don't say why you want to do this, but if it's to stop someone seeing
sensitive data, then encryption is probably the best solution:

http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=22

Simon

Friday, February 24, 2012

Domain Recommendations.

Has anyone experienced any SQL difficulties resulting from removing Domain
Admins' permissions from a SQL Server 2k machine. We are toying with the
idea now, mainly to keep the network people out of SQL. Our other option is
to remove the SQL Server from the domain itself. Any advice or information
would be appreciated.
Thanks for your time,
JoeJoe
Very useful site.
http://vyaskn.tripod.com/sql_server_security_best_practices.htm --secu
rity best practices
"Joe" <nospam@.nospam.com> wrote in message
news:ORXpZyykDHA.2772@.TK2MSFTNGP12.phx.gbl...
> Has anyone experienced any SQL difficulties resulting from removing Domain
> Admins' permissions from a SQL Server 2k machine. We are toying with the
> idea now, mainly to keep the network people out of SQL. Our other option
is
> to remove the SQL Server from the domain itself. Any advice or
information
> would be appreciated.
> Thanks for your time,
>
> Joe
>|||Very nice. Thanks for the info.
Joe
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:O#6y73ykDHA.2432@.TK2MSFTNGP10.phx.gbl...
> Joe
> Very useful site.
>
http://vyaskn.tripod.com/sql_server_security_best_practices.htm --secu
> rity best practices
>
> "Joe" <nospam@.nospam.com> wrote in message
> news:ORXpZyykDHA.2772@.TK2MSFTNGP12.phx.gbl...
> > Has anyone experienced any SQL difficulties resulting from removing
Domain
> > Admins' permissions from a SQL Server 2k machine. We are toying with
the
> > idea now, mainly to keep the network people out of SQL. Our other
option
> is
> > to remove the SQL Server from the domain itself. Any advice or
> information
> > would be appreciated.
> >
> > Thanks for your time,
> >
> >
> > Joe
> >
> >
>|||To keep the network folks out of SQL Server (but not the
box itself) you can remove the BUILT/Administrators login
from the SQL Server.
This will remove access to SQL Server for any local
administrators (Domain Admins included). You may want to
add your domain account to the server administrators role
so that you continue to have sa privileges.
Tim
>--Original Message--
>Has anyone experienced any SQL difficulties resulting
from removing Domain
>Admins' permissions from a SQL Server 2k machine. We
are toying with the
>idea now, mainly to keep the network people out of SQL.
Our other option is
>to remove the SQL Server from the domain itself. Any
advice or information
>would be appreciated.
>Thanks for your time,
>
>Joe
>
>.
>|||Is there a danger in removing thier access to the box itself? They have
fried it 3 days in a row.
Thanks,
Joe
"Tim Richardson" <anonymous@.discussions.microsoft.com> wrote in message
news:005f01c39330$66bb73a0$a301280a@.phx.gbl...
> To keep the network folks out of SQL Server (but not the
> box itself) you can remove the BUILT/Administrators login
> from the SQL Server.
> This will remove access to SQL Server for any local
> administrators (Domain Admins included). You may want to
> add your domain account to the server administrators role
> so that you continue to have sa privileges.
> Tim
>
> >--Original Message--
> >Has anyone experienced any SQL difficulties resulting
> from removing Domain
> >Admins' permissions from a SQL Server 2k machine. We
> are toying with the
> >idea now, mainly to keep the network people out of SQL.
> Our other option is
> >to remove the SQL Server from the domain itself. Any
> advice or information
> >would be appreciated.
> >
> >Thanks for your time,
> >
> >
> >Joe
> >
> >
> >.
> >|||Joe,
It's hard for me to say. I've never tried it. I
wouldn't think that it would affect the functioning of
SQL Server unless the service account is configured as a
domain admin. It could affect other things though. I
would only try it on a test machine until you know for
sure.
One thing though, I would imagine that THE Domain
Administrator (as opposed to the Domain Admins group)
will always have access to the box. If you are having
problems with the network folks and are trying to lock
them out, they can probably find their way back in.
Tim
>--Original Message--
>Is there a danger in removing thier access to the box
itself? They have
>fried it 3 days in a row.
>Thanks,
>Joe
>
>"Tim Richardson" <anonymous@.discussions.microsoft.com>
wrote in message
>news:005f01c39330$66bb73a0$a301280a@.phx.gbl...
>> To keep the network folks out of SQL Server (but not
the
>> box itself) you can remove the BUILT/Administrators
login
>> from the SQL Server.
>> This will remove access to SQL Server for any local
>> administrators (Domain Admins included). You may want
to
>> add your domain account to the server administrators
role
>> so that you continue to have sa privileges.
>> Tim
>>
>> >--Original Message--
>> >Has anyone experienced any SQL difficulties resulting
>> from removing Domain
>> >Admins' permissions from a SQL Server 2k machine. We
>> are toying with the
>> >idea now, mainly to keep the network people out of
SQL.
>> Our other option is
>> >to remove the SQL Server from the domain itself. Any
>> advice or information
>> >would be appreciated.
>> >
>> >Thanks for your time,
>> >
>> >
>> >Joe
>> >
>> >
>> >.
>> >
>
>.
>|||There is nothing wrong about removing BUILTIN\Administrators. Of course, the current administrators
using this will complain, but this is what you are after, right?
Just make sure you add some other group first (assuming you use Windows logins in the first place).
I usually create some SQLAdmins group or similar and add that first.
There's a reason why Administrators is there in the first place. Imagine you install SQL Server in
Windows Only mode. No-one would be able to login if it wasn't for the Administrators group being
there.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Joe" <nospam@.nospam.com> wrote in message news:uytKhGzkDHA.3688@.TK2MSFTNGP11.phx.gbl...
> Is there a danger in removing thier access to the box itself? They have
> fried it 3 days in a row.
> Thanks,
> Joe
>
> "Tim Richardson" <anonymous@.discussions.microsoft.com> wrote in message
> news:005f01c39330$66bb73a0$a301280a@.phx.gbl...
> > To keep the network folks out of SQL Server (but not the
> > box itself) you can remove the BUILT/Administrators login
> > from the SQL Server.
> >
> > This will remove access to SQL Server for any local
> > administrators (Domain Admins included). You may want to
> > add your domain account to the server administrators role
> > so that you continue to have sa privileges.
> >
> > Tim
> >
> >
> > >--Original Message--
> > >Has anyone experienced any SQL difficulties resulting
> > from removing Domain
> > >Admins' permissions from a SQL Server 2k machine. We
> > are toying with the
> > >idea now, mainly to keep the network people out of SQL.
> > Our other option is
> > >to remove the SQL Server from the domain itself. Any
> > advice or information
> > >would be appreciated.
> > >
> > >Thanks for your time,
> > >
> > >
> > >Joe
> > >
> > >
> > >.
> > >
>

Domain Permission Issues

If you can assist -- I need to find and read a whitepaper or the like about "Domain Permissions". It seems that I continually have trouble with permission issues when attempting connectivity to any SQL database.

I do have some good reading materials about Windows authenication and authorization, but the Domain Permission piece of the puzzle is still missing.

If you know of some good on line articles to read, please post the URL's. Thanks in advance for the advice.

[The last episode says it all. I logged on to a server (W2K Server) as the administrator (machine level), installed SQL Server 2000 (Developer) cleanly, using Local System and Windows Authentication. Using Enterprise Mgr attempted to open the server to add a database and got the error message that the connection could not be made. However, when using Enterprise Mgr from another machine (logged in as me with domain admin rights) to open that server, there was not any problem. I do realize that if I had logged in with the domain admin rights there would not have been a problem, but that is not the issue. I want to learn the "why" behind why the original attempt did not work]I'll take a wild swing at this one.

By default in SQL Server, any member of the local adminstrators group on the local box will be granted admin rights on the SQL Server (by the BUILTIN\Administrators login). Normally, Domain Admins are considered members of the local adminsitrators group of any server that is a member of a domain. It sounds as if you logged into the first machine with a regular Domain Users account, or a local account that would normally not have rights on any network resource. Does this help?

Domain Group Members and Database Roles

Greetings...
I have a SQL2005 Express database where I have created 3 user defined
database roles, granted those db roles all the required permissions on the
required db objects, and made a few (Domain\Group) groups login members of
those database roles. The 3 roles are for high, medium, and low rights.
When a user logins with Windows NT authority, I can determine their identity
with
SUSER_SNAME(), but how can I easily determine what role or roles the user,
not the group, belongs to? The user would not have a principal_id, but the
group does. There's got to be a way to know what role the USER is in, isn't
there?
DaveHi
Try
sys.database_role_members catalog view
"DGardner" <DGardner@.discussions.microsoft.com> wrote in message
news:2BE1DB54-0A86-4CF8-A916-0666AD0790AF@.microsoft.com...
> Greetings...
> I have a SQL2005 Express database where I have created 3 user defined
> database roles, granted those db roles all the required permissions on the
> required db objects, and made a few (Domain\Group) groups login members of
> those database roles. The 3 roles are for high, medium, and low rights.
> When a user logins with Windows NT authority, I can determine their
> identity
> with
> SUSER_SNAME(), but how can I easily determine what role or roles the user,
> not the group, belongs to? The user would not have a principal_id, but the
> group does. There's got to be a way to know what role the USER is in,
> isn't
> there?
> Dave|||Uri,
that view is not too informative... I finally got this query to work for
what I want:
Select name as Roles
From sys.database_principals
Where type='R' And is_fixed_role=0 And principal_id<>0
But I wouldn't call this 'easy' or intuitive...
Dave
"Uri Dimant" wrote:

> Hi
> Try
> sys.database_role_members catalog view
>
> "DGardner" <DGardner@.discussions.microsoft.com> wrote in message
> news:2BE1DB54-0A86-4CF8-A916-0666AD0790AF@.microsoft.com...
>
>|||Hi Dave.
Try with the IS_MEMBER function
Regards
Antonio Soto
Solid Quality Learning
http://www.sqlu.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"DGardner" <DGardner@.discussions.microsoft.com> escribi en el mensaje
news:2BE1DB54-0A86-4CF8-A916-0666AD0790AF@.microsoft.com...
> Greetings...
> I have a SQL2005 Express database where I have created 3 user defined
> database roles, granted those db roles all the required permissions on the
> required db objects, and made a few (Domain\Group) groups login members of
> those database roles. The 3 roles are for high, medium, and low rights.
> When a user logins with Windows NT authority, I can determine their
> identity
> with
> SUSER_SNAME(), but how can I easily determine what role or roles the user,
> not the group, belongs to? The user would not have a principal_id, but the
> group does. There's got to be a way to know what role the USER is in,
> isn't
> there?
> Dave|||Antonio,
Sorry... IS_MEMBER() doesn't work either. Although the group is assigned to
the role, the individual user who is a member of the group is not, and so
IS_MEMBER() returns 0 every time. It looks like the query I constructed is
the only way to get the info I want.
Dave
"Antonio Soto" wrote:

> Hi Dave.
> Try with the IS_MEMBER function
> Regards
> --
> Antonio Soto
> Solid Quality Learning
> http://www.sqlu.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
> "DGardner" <DGardner@.discussions.microsoft.com> escribió en el mensaje
> news:2BE1DB54-0A86-4CF8-A916-0666AD0790AF@.microsoft.com...
>
>