We're in the process of building a MOSS site and one of the 3rd party tools we're using has a requirement of AD/ADAM as the authentication provider. We would like the user's to manage their own accounts (e.g. resetting passwords, registering new users, etc) so we're going to need WebParts for administering users in an AD/ADAM/LDAP DB.
Are there any SharePoint WebParts out there already to do this?
I came across one today called AD User Editor. It states you can edit nearly any Active Directory property, and it works in multi-domain environments.
From the UI screenshot it appears to use a web part and take on the SharePoint look and feel.
Even better it's on CodePlex so any problems you can fix yourself!
Related
I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
We're currently investigating what kind of authentication we want to use for a sharepoint portal site : Forms Authentication or Windows Authentication. The latter has my preference.
What suprised me (I'm a sharepoint noob), is the fact that MS didn't provide a component/web-part that handles account management when using Windows Authentication.
Do you now how to do this? Without resorting to buying an additional product. Shouldn't it be very easy to access the Active Directory by code (C#)?
Windows Authentication
I echo Justin's thoughts regarding AD management. Adding users to your domain also doesn't necessarily have anything to do with adding them to SharePoint. However perhaps there is an IIS add-on that does this if you wish to pursue it.
If you don't already know, SharePoint can automatically import user profiles from your Active Directory domain. This makes them available for assigning permissions within the sites.
Some additional info from Justin's comment about changing the AD structure to administer security: With SharePoint 2007 you no longer need to rely on Active Directory to manage groups of users. It's possible to also use SharePoint groups (which can contain AD users or AD groups). This works really well when you need to create a group for a purpose that isn't applicable outside SharePoint and you don't want to bug the infrastructure team. The downside is that without education, end users probably won't manage this well and it can become a mess.
Forms Authentication
It's true there is very little provided by Microsoft for managing this. However the Community Kit for SharePoint provides this functionality. From memory I had to tweak their code a bit but I was generally happy with it.
If you are considering this option also read this MSDN article.
It's much easier to just use the regular AD management tools provided with Windows rather than trying to manage your users' permissions through a web interface (for groups and such).
...of course you'll need access to make changes to your AD structure to administer the security.
Another alternative you may want to consider is using Forms Authentication using the Active Directory provider. It'll allow you to use the Forms Auth user admin tools and still authenticate against an Active Directory environment.
IF this is for users who are not a part of your actual domain (i.e. extranet users), I suggest you take a look at ADAM, Active Directory in Application Mode. It behaves the same as regular AD, can be administered through the windows.
Also, take a look at the following codeplex project, ADSelfService, it allows users to edit their own AD profiles. Perhaps you can extend the code yourself to allow admins to edit all profiles.
AdSelfService Project
Can MOSS integrate and get user profiles from multiple Active Directory and/or LDAP stores?
I have seen from Integrating Microsoft SharePoint Server With Oracle Virtual Directory that there may be intermediary products that can help with this.
It looks like Rohati has a solution as well, but is the out of the box without third party products?
Cannot answer for non-AD LDAPs but with with multiple forests where you have a trust, one-way will work, it is no big problem.
You need to do two things, add the people to the people picker, http://technet.microsoft.com/en-us/library/cc262051.aspx, and then run a command to import the user profile information, link on above link. Besure to run the command also on your MySites so that profile is correct.
Alot more information can be found by searching for sharepoint and multiple forests.
Here is one solution SharePoint AD Information Sync, which can let you export AD user files into list. However, the trouble is you need know it just can get user profiles from Active Directory but can not LDAP stores and I am not sure it can do that from multiple Active Directory.
Anyway, it is a ugly solution. Maybe helpful to you.
One way would be to extend your website application and to attach different providers to different zones. I think there're should be something like LDAP Membership Provider you can use. But I guess that's not what you're looking for.
Another way would be to build your own Membership Provider which internally retrieves users, groups from multiple sources.
Our client found a SharePoint 2007 Shared Services Provider User Profile Importer from CodePlex that may help too.
Since the web.config entries only have one entry for hostname, port, userContainer, etc..., it is hard to see how you can do that without using a third party virtual directory product. Oracle can do it but so can Symlabs or OptimalId and probably any other VD on the market. Those are not free. But Penrose is a free LDAP Proxy and my guess is that you should be able to do it with Penrose too.
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.