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
Related
We have a SharePoint 2010 extranet web application that uses claims authentication.
The Intranet zone is using mixed authentication (NTLM against internal AD and FBA against a separate AD).
The Extranet zone uses FBA only against the separate AD.
We have sites that have NTLM users in the Members SharePoint group. We have librarys with "Person" colums limited to the Members group. We would like to allow FBA users to pick NTLM users that are in the Members group when fillng in item metadata. The problem is that the FBA users can see the NTLM users in the people picker but when they select them, the user is not resolved. I realize we could probably work around this by adding NTLM to the Extranet zone but prefer not to do this if possible.
My questions are:
Is this a scenario where a custom claims provider would be appropriate?
Is this a problem that could be resolved with the peoplepicker-searchadforests property? (I've not been able to get my head around a real world example where this property is in play)
This is how I understood that the people picker works. I'm not 100% sure so don't take it for absolute truth :)
Basically, in the context of the Extranet application, all standard pickers are completely unaware that the internal AD exists. The "hits" you get in the people picker are found in SiteUsers list and/or profile database.
"Is this a problem that could be resolved with the peoplepicker-searchadforests property?"
I don't think so, I think that even if you are able to make the people picker search other ADs might give some pretty weird results, like being able to add a persons permission to some object, but with the FBA claim prefix, which does not equal the user when logged in using NTLM. (A user signed in with NTLM and Claims is technically different users.)
"Is this a scenario where a custom claims provider would be appropriate?"
I don't think so :(
One trick that you can do for people picker that YOU create (i.e. you have a custom page or webpart or something with a people picker), there are several properties you can set to change from where the users are retrieved. For example you can set a property like "WebApplication" or similar that basically make the picker work as if in the context of the internal application despite the current user being logged in on the external app.
What I'm thinking is maybe there is some way to enable the NTLM membership provider on the extranet application, but without actually enabling end user authentication with it. It doesn't sound impossible but I'm not sure exactly how that would be done though.
I currently have a web config file in a web service that is using the following code snippet so that it can access resources on Sharepoint
<identity impersonate="true" userName="[domain admin]" password="[password]"/>
Clearly this situation is not a good idea and we are currently replacing this with the correct way of doing things. However, in the mean time we are creating a new domain user that is NOT the domain admin and using that as a stop gap. The domain admin was used as people were too lazy to determine the right security levels required and a domain admin will be guaranteed access to every resource.
My question is: What is the minimum level of security that this domain user requires in order to continue accessing the Sharepoint Web Service? What sort of things should I be thinking about?
What web service are you talking about exactly? SharePoint web services are permissions aware, just like any other module, so it is different if you want to say read items or create a site. You need to know first what you are trying to accomplish and then give the user the exact permissions to do that
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.
I've been tasked with creating a SharePoint web part for our new web site. One of the things it needs to know is which AD groups the current user belongs to (each site user will belong to one or more special security groups within the domain.) Is there a part of the SharePoint API that exposes this information, or do I need to query AD directly?
I would just do an LDAP query directly. This is much simpler and the LDAP interface to Active Directory is well documented.
Check out these .NET namespaces.
System.DirectoryServices
System.DirectoryServices.AccountManagement
System.DirectoryServices.ActiveDirectory