Is it possible to create a site on demand? So in the response of an event, such as button click. I want users to be able to see one site (all users), but users with assigned to a certain group will see two sites.
Also, when would I want to create a seperate web application?
Thanks
Let's try to clear this up.
First, yes it's possible to create sites and webs programmatically, and in that sense you can do it in a click of a button event.
The second part of your question is not related to creating a sub site, it's related to permissions. Sub sites in SharePoint can have different permissions for different users.
So yes, users assigned to a certain group can see sub sites that others can't.
The third question can be answered by this Technet article.
Hope this helps.
Yes, you could use 2 seperate SharePoint web applications to provide access to a single site collection using different authentication providers. Enabling anonymous access for one web app and windows authentication for the other, you could use SharePoint authorisation to setup different permissions on site and pages for anonymous users as noted by Magnus.
Related
I was wondering if there was a simple way to allow users to request access to specific groups in sharepoint? i.e Users have a button on a page they can click to join or leave a specific group. Allowing them to self serve access?
Ive looked through the literature and cant see anthing obvious.
Kind Regards
Ive tried lookign through the site permissions options but these are centred around site owners adding users not users adding themselves. Ive also tried a number of button set ups but im wondering if i have to set up a power app to do this?
Per my knowledge, there is no OOTB or easy way to let users adding permission to themselves.
If you want to realize your needs, I suggest that you can customize your needs through Partner.
You can configure self service group membership when you create the SharePoint group like this:
Note how users can request to join or leave the group and requests are setup to auto accept? That should address your issue.
I'm curious about the best/most efficient way to do this.
I've already set up my sharepoint 2010 site, and it is configured to use FBA. What i'd like to do is allow users to create their own accounts by filling out a form (the form will sit on a public sharepoint site, and filling it out creates a user in the membership database which is used for validation to enter the FBA sharepoint site).
I'm familiar with using the asp CreateWizard tool to build user accounts as part of a .Net web application, but I'm not sure on how to develop this as a webpart for use in a sharepoint site, as a webpart doesn't have the config file to store connection string and membership/role provider info.
Can this user creation form be put in a webpart and deployed to other sites, or is there another/better way to add this functionality to sharepoint (allowing users to register/create their own FBA accounts for access)?
There's nothing not much difference between SharePoint and regular ASP.Net for this.
The membership provider will need to be configured in the SharePoint web.config, including connection strings. However, it does not actually need to be used for login, so you can still create users in that membership provide from a different site.
I use a slightly different approach though - set up an anonymously accessible page in your site (in layouts is probably easiest, though a page within a site may be better for branding) and put controls on that page to create (and log in) a new user. You will need to call EnsureUser and possibly CreateUserProfile to give the new user access to anything, but aside from that it's all standard .net.
I have enabled anonymous users on the farm and on the entire site.
I also have Windows Authentication turned on.
Whenever an anonymous user attempts to view the site, they are prompted to log in.
And they get prompted to login on every single page they view.
I would like to allow users to log in via Windows Authentication, (perhaps through a special page), but anonymous users should not get prompted to put in their password ever.
Does that mean I need to switch to forms based authentication for the entire site, or is there an option in 2010 to somehow get Windows Authentication and allowing anonymous users to live harmoniously.
It could be because some of the file is not published. For ex, if master page, CSS stylesheet or any image is unpublished, it will prompt the user for login.
Make sure everything is published and it will work.
You need to see if it is anything on this path http://server/_catalogs/masterpage/Forms/AllItems.aspx
that it is not published.
You must publish everything
May be you missed some of the configuration steps .So i wish if you take a look to the following article
SP2010 Branding Tip #9 – Turn on Anonymous Access
Regards
I assume that you are using the Publishing Site Template for the public site and hence the default.aspx (the welcome page of all the subsites) is not published so you would need to start the approval workflow publish the pages and any other assets (master page, css, images etc)
You need to do some prepwork to set the site up using two web applications, both with different authentication methods. You can't run SharePoint effectively for Windows users and anonymous (or Forms based authentication) at the same time.
Essentialy:
Create your SharePoint site for internal users using Windows Authentication
Extend the site to a new site (using the same content database) but using anonymous or forms based authentication (whichever makes sense for you)
A MSDN article can be found here on this:
http://msdn.microsoft.com/en-us/library/ff648385.aspx
You can also read Andrew Connell's blog about this (he talks about Forms based authentication but you can do the same with anonymous access)
http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx
Basically you want dual authentication, Windows for one set of users and anonymous or FBA for another (and each access the site using a different URL)
Hope that helps.
Just need to use find a simple way to have AD authenticate as the login for a Sharepoint site. This fairly quick and simple to get going ?
Thanks!
For SharePoint 2007, see this article. You probably want to set it up to do Windows integrated authentication with NTLM. Getting authentication working is probably not too hard, getting your site setup the way you want with permissions/authorization working probably isn't. Depends on how complex your site is. I wasn't directly involved but I know that it took a few months to get our intranet up and bug free.
One recommendation that I would have is to use AD groups or SharePoint groups that contain AD groups rather than individuals to control access. It's much easier to clean up AD group membership when an individual leaves than to track down all the places where you've given them individual access (including membership in SharePoint groups).
You need your server to be part of the domain before installing SharePoint.
If you do that, the default configuration will be AD authentication.
Here is a decent discussion of SharePoint security links
http://blogs.msdn.com/joelo/archive/2007/06/29/sharepoint-groups-permissions-site-security-and-depreciated-site-groups.aspx
Essentially, you will either need to add users to the appropriate SharePoint group. The defaults for a site are generally xxx_Visitor, xxx_Members and xxx_Owners, with each group having increasing security rights.
You can either add an AD domain to these groups or else add individual AD users
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.