Remote Site Administrator Question (Security FAQ, Sec. 33)

B

Brian Smith

I have followed Microsoft's Security FAQ paper, Section 33 to create a
remote site administrator workgroup file. Everything seems to be fine except
for one thing. Since it is impossible to get rid of the Admin user and the
Site Administrator account has the ability to assign users to different
groups, as well as clear passwords, what is to prevent the Site
Administrator from giving the Admin user access to other groups, clearing
the password for Admin and giving the database to other people? I have taken
all permissions away from the Users and Admins Groups but I do have other
groups that can read/write data. Is there a way to prevent this from
happening? Also, would it be possible via code to check if the current user
is logged on as Admin and then create a new password, which would hopefully
stop them from using the application a second time?

One last question, when I created the remote workgroup file I notice that
the owner of all objects is now listed as <Unknown>. Is this the way it
should be?

I'd really appreciate if you one of you security gurus could shed some light
on the above for me.

Thanks.

Brian
 
T

TC

Brian said:
I have followed Microsoft's Security FAQ paper, Section 33 to create a
remote site administrator workgroup file.

I haven't looked that up & will therefore answer from general
principles.

Since it is impossible to get rid of the Admin user and the
Site Administrator account has the ability to assign users to different
groups, as well as clear passwords, what is to prevent the Site
Administrator from giving the Admin user access to other groups, clearing
the password for Admin and giving the database to other people?

Yes, that sounds like a scenario. However, even if he couldn't do that,
he could still pick some /other/ user, add them to every possible
group, clear their password, & then distributing the db along with a
sticker: "log on as user Fred with no password". IOW, there is nothing
particularly special about the Admin user in your scenario.

Remember that the only people who have full & unfettered access to an
object in the database, are (1) the owner of that object, and (2) all
members of the Admins group of the workgroup file <<which was in effect
when the database was first created>>.

If you handle the ownership issues correctly, /and/, you ensure that
the Admins group in the distributed workgroup file is /not/ the same as
the one in the workgroup file with which you created the database,
then, no-one in the distributed workgroup file will have (or be able to
acquire) unfettered access to the database.

would it be possible via code to check if the current user
is logged on as Admin and then create a new password, which would hopefully
stop them from using the application a second time?

You can easily check for currentuser() = "admin". However, I think your
whole scenario is misconceived, as stated above.

One last question, when I created the remote workgroup file I notice that
the owner of all objects is now listed as <Unknown>. Is this the way it
should be?

This means that the owner of each object is /not/ a user in the
selected workgroup file. This might or mightn't be right, depending on
the instructions you followed; I haven't checked those so I can not
say.

HTH,
TC
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top