You know the old adage, "The only secure computer is one that is off, unplugged, in the back of a closet." Securing data has always been a case of how inaccessible you want the data to be. If accessing data easily from anywhere is the main focus of a product, chances are good that security will not be.
I was recently asked to submit some abstracts to a conference in Toronto (absolutely *love* that city, those people rock). It's a hardcore security conference. And they want me to, since I am so into WSS, to focus on WSS security.
Now I am talking hardcore, 300 to 400 level security; threat modeling, hack-this-box kind of stuff. Real white hat/black hat, exploit people.
So, what would I talk about concerning security to this jaded bunch of experts?
How about being prepared for the disgruntled administrator? About *really* securing Central Administration? Or what damage you can do with knowing the server farm account, or content database accounts? Or what nefarious things can be done with policy for web application? I dunno. I have been so busy, so overwhelmed, with documenting all the normal functions of sharepoint, I really haven't had time yet to focus on exploiting it.
And now, in the middle of editing, maybe I should. I know, I am doing something else, but this is how it happens. You never get opportunities when you can do them, only when you are too busy to think about them. But inevitably, those opportunities come up, like a call for papers, months before the actual event takes place.
So, in order to have a job at all in November, I have to find time to respond now.
I'll let you know what I come up with, and whether or not they are accepted, as soon as I can.
Tuesday, August 7, 2007
SharePoint Security? An oxymoron? An after thought?
Subscribe to:
Post Comments (Atom)
6 comments:
Hi,
Just purchased your book and have a question about Sharepoint security. Is this where I should ask?
Basically, I've created a basic WSS site and want clients to have access to subsites but I do not want them to be able to browse "All People" in the "People and Groups" list. I set People and Groups->List Settings->Advanced->Item-level Permissions to "Only their own" and that seem to work. But then I ran into this weird issue where if that client didn't login in first and I set access for them, their User Information record is set to "Created at [date/time] by Administrator". If this happens, that login can not access their own information because the system thinks that they don't own the record. Is there a way to change the "Created at" information to their login so the system will allow access?
Thanks.
Hi HK,
There is as good as anywhere to ask.
The short answer to your question is: No.
The reason is, when an account is created, it's created by someone with administrative rights. Thus the record was created (and therefore owned) by the administrator. There is no out-of -box way of overcoming that, that I know of.
Although, now that you've brought it up, I'll keep pecking at it. ; ) If I find anything, I'll post it here.
Hi,
Thanks for the prompt response! If I can't change the "Created" attribute, is there a way to completely purge the record from the database so that if I login again, the correct "Created" attribute can be created? Right now, if I remove it by "Delete User from Site Collection", the record is gone but if I login using that account again, the old "Created" attribute is still there.
Or alternatively, what's the normal practice for setting up a WSS site so that users can not browse the entire user list via People and Groups->All People?
Thanks.
I don't believe there is an easy way to have a user's information be created *by* them. I think, by definition, the user information is generated by the account that added the user object to the site collection/subsite.
The only way I can think of (rather than specifically allowing no one from the Members group to see the user list) of making it hard for the users to see People and Groups is to take it out of the Quick Launch bar. Then they'd have to really search for it to get to the Users and Groups information. What do you think?
Hi,
The weird thing about WSS is that if I didn't specifically assign that user to a site/sub-site and simply set access to "Authenticated Users", they are able to login and then WSS will set the "Created at" attribute to their user account, not Administrator.
But I think I was trying to do things not according to the "Microsoft Way", setting permissions for specific users so that WSS adds them to the various user lists. I've since switched to using just numbered AD groups so if clients browse People & Groups, all they see are the various numbered groups. So I've switched the Item-level Permissions back to "All items" and everything seems fine now.
Thanks.
::Smacks herself in the forehead, *hard*::
DOH!
hk, I would like to formally apologize for being an idiot. ; )
I knew there was an easier way to keep users from browsing People and Groups, I've simply gotten used to doing thing the hard way. : ( I just wasn't thinking:
Disable the "Browse user information" permission for the permission level used by the group the users are in. This will make them unable to both browse people and groups, as well as block them from being able to get into the user information for a particular user by clicking their author link anywhere, then getting back on the breadcrumb to the People and Groups page.
They can still see and access their own from the welcome menu, but not People and Groups.
Further, since the users can still see the People and Groups link in the quick launch, you may want to remove it so they don't click it then get rebuffed with a no access warning.
And, a further DOH!-- You are right, if a user is part of an AD group, then the user themselves are the creator of their own information-- due to the fact that sharepoint doesn't bother (rather insultingly I think) to create their user information for them until they log in personally. The reason I didn't even think of them is they don't show up on the group list they belong to by default, they only show up in All People. So if people were trying to get to members of a group, they'd only see the AD group name. In that case all user information bits are the balliwick of the account that added them.
Sigh. Thanks for keeping with it hk, and my sincerest apologies if my suggestion about managing the permission is too late (after painstakingly adding all those groups).
Post a Comment