Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Access to Private Documents

  Asked By: Griffin    Date: Apr 07    Category: Sharepoint    Views: 1361

Here's a question that I haven't been able to find a consistent
on -- who exactly can access the Private Documents folder on a My
Site? Documentation I've read from MS on this indicates that only
user can access it, since it's tied to a SID. However, I've got
admin privileges on our SPS server, and I can see into other people's
Private Documents folders, modify the docs, etc. Is that the way
supposed to work, and does that mean that anybody w/ domain admin
rights can see into all Private Documents also?



13 Answers Found

Answer #1    Answered By: Kareem Flynn     Answered On: Apr 07

That has been our experience as well. Anyone with admin access  to the
web server  can view private  docs on any personal site.

Answer #2    Answered By: Tyron Calderon     Answered On: Apr 07

Domain Admins rule! What you are seing is by design. If you do not trust your
domain admins, access  to the Private Documents is just a minor issue on your

Answer #3    Answered By: Irvin Foley     Answered On: Apr 07

I disagree. This came up in my organization when we realized the LAN
support group (30+ people) had access  to private  doc libraries,
including those of high level executives who were storing highly
confidential docs  on their personal sites. I won't go into details but
I am sure you can imagine what can happen with that situation. Plus no
executive would be comfortable knowing a large group of people could see
their files. This dives into politics more so than domain  admin's

Answer #4    Answered By: Deonte Stein     Answered On: Apr 07

I agree that it is politics. It would seem to me that the LAN support group were
all domain  admins. Shades of NT 4.0. With Active Directory granular delegation,
the domain admins group should be REALLY small! Lets see, there would be me and.
. . Nope, just me!

Answer #5    Answered By: Stephon Valentine     Answered On: Apr 07

You can change this behavior so that local admins don't have this access  through WSS SP2 which was just released or by applying the following hotfix: http://support.microsoft.com/kb/892295/

I'm unsure how much this changes the Domain Admin permission on your site.

Answer #6    Answered By: Leif Cardenas     Answered On: Apr 07

It would change Domain Admin permissions because they only get permissions on
the local box by being added to the Administrators group.
Interesting that Microsoft addresses it as a "problem" that some are
experiencing rather than a preference that some would like to be able to opt out
or in.

Answer #7    Answered By: Jasper Hatfield     Answered On: Apr 07

It actually really comes down to who is an admin on the server. By
default, the domain  admins are added to the server's Administrators
group. However, you could technically remove the Domain Admins group
from the server's Admins group. Then, only the members of the server's
Admins group would have access  to the private  docs.

Answer #8    Answered By: Rashawn Hopper     Answered On: Apr 07

If I was involved with the domain  design, Group Policies would control the
membership with restricted groups. Your change would only persist for 90 minutes
or so. But you still have server  admins with full access  to everything. And just
to confuse things, they do not show up in the SPS pages having any rights at

Answer #9    Answered By: Horace Coffey     Answered On: Apr 07

Unless of course scripts autorun periodically and re-add the domain
admin group. (Had that happen too!)

Answer #10    Answered By: Rigoberto Beard     Answered On: Apr 07

i jumped right ON that patch.. we have similar issues, power hungry domain  admins (nosey too if ya ask me).

works as expected - i locked myself out in no time at all!

i wonder if they snuck in support for sql 2005 with this one? anyone know?

Answer #11    Answered By: Alphonso Mckay     Answered On: Apr 07

well.. considering that most enterprises still have YET to grasp that your everyday user account should not have escalated rights. in unix land we call this 'su' or 'sudo'...

"run as" works just fine when you need escalated priveledges - and it will do 2 things:
-keep you from making changes unforseen by your escalated rights (say installing something that makes irreversible changes to your AD)
-allow you to have the "user" experience

my 2 cents..

Answer #12    Answered By: Daron Oneill     Answered On: Apr 07

"run as" also does not use a local profile or pstores.exe.

Answer #13    Answered By: M Juarez     Answered On: Apr 07

>runas /?


RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
/user:<UserName> program

RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
/smartcard [/user:<UserName>] program

/noprofile specifies that the user's profile should not be loaded.
This causes the application to load more quickly, but
can cause some applications to malfunction.
/profile specifies that the user's profile should be loaded.
This is the default.
/env to use current environment instead of user's.
/netonly use if the credentials specified are for remote
 access  only.
/savecred to use credentials previously saved by the user.
This option is not available on Windows XP Home Edition
and will be ignored.
/smartcard use if the credentials are to be supplied from a
/user <UserName> should be in form USER@DOMAIN or DOMAIN\USER
program command line for EXE. See below for examples

> runas /noprofile /user:mymachine\administrator cmd
> runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
> runas /env /user:user@... "notepad \"my file.txt\""

NOTE: Enter user's password only when prompted.
NOTE: USER@DOMAIN is not compatible with /netonly.
NOTE: /profile is not compatible with /netonly.

Didn't find what you were looking for? Find more on Access to Private Documents Or get search suggestion and latest updates.