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
Related
As a follow-up question to REST API to manage users on skype for business, I would like to understand how the Sharepoint Server User API differs from MS Graph API for Users. The Graph documentation indicates that we could use it to manage Sharepoint users the same way we would Office 365 users. However, there are standalone Sharepoint installations (like versions e.g. 2007, 2010, etc.,) which don't fall under Office 365 plans.
The Graph API Docs linked above says the User resource represents an "Azure AD user account". However, the Sharepoint User doc says it represents a "user in Microsoft SharePoint Foundation." Are these users entirely different from each other?
All we're looking to do is manage users for our clients some of whom have subscriptions to Office 365 and some who just use standalone Sharepoint setup. We are not bothered about application specific features like Accessing the sharepoint files, sites or even managing Word documents, Excel sheets, etc., So, does the Graph API support managing users in such cases as well?
That API is only for SharePoint 2013+
The user management REST API linked in your question is specifically for SharePoint 2013, and presumably works in SharePoint 2016 as well. This is regardless of whether the SharePoint environment is on premises or in the cloud.
Office 365 is currently a subset of SharePoint 2013/2016 in terms features and functionality.
Note that SharePoint 2007 and 2010 will not have this API.
SharePoint users and Azure AD accounts are not synonymous
Consider that SharePoint and AD can exist independently of each other.
SharePoint does not need to use Azure Active Directory for authentication. It can use a traditional on-premises or cloud-hosted Active Directory, or theoretically (starting with version 2010) can use any claims-based authentication provider aside from Active Directory.
SharePoint 2007 and 2010 could also support simple forms based authentication as well as custom authentication providers, but as noted previously, neither of those versions of SharePoint expose the REST API in question.
AD = Authentication; SharePoint User = Authorization
Azure AD is a claim provider. A claim provider is used for authentication; when you log on to SharePoint, SharePoint relies on Active Directory to determine that you are who you say you are. A user's SharePoint account is used for authorization; the SharePoint account is granted access to content within SharePoint on a site by site basis.
Information in AD vs information in SharePoint
When using Azure AD for authentication, there are usually some areas of overlap between the data in SharePoint and the data in AD.
SharePoint's user profile service is usually set up to synchronize data from Active Directory to SharePoint, so that AD serves as the master data set for things like user display name and title. However, not all information is necessarily sync'd from AD to SharePoint, and additional information can be tacked on to SharePoint user profiles.
Group Membership in AD vs Group Membership in SharePoint
In Azure AD, a user can be a member of multiple groups. Groups can include both Active Directory groups (which can be nested) and Office 365 (SharePoint) groups (which cannot be nested).
A SharePoint user can only be a member of SharePoint groups, since SharePoint does not keep track of membership of Active Directory groups. That said, a user may have access to content in SharePoint indirectly due to an Active Directory group having been granted access.
AD User Scope vs SharePoint User Scope
Unless you're working directly with the user profile service, when you work with SharePoint users programmatically, they need to be retrieved from a specific site in SharePoint. This is because each site collection has its own set of groups which cannot be used on other site collections within the SharePoint farm, so group membership is tracked only on a site-by-site basis.
Note that this means that a user's lookup ID number (which is different from their login name) may vary between site collections. This also means that a user's collection of groups will vary depending on the site from which the user object was retrieved.
An Azure AD user has no such silos.
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
I need to determine the sites and webs that a specified user can access in a SharePoint web application via the SharePoint API. Note the specified user is different from the current user that is calling the code. I initially was thinking of making use of the PortalSiteMapProvider, but it does not offer an option to change the user context in which it is built up. Can anyone offer any alternatives to this?
Thanks, MagicAndi
You could use the Webservices API:
Determining User's role in a SharePoint site/workspace using the webservices API
Not the most efficient solution to this problem, but you can iterate through all the site collections / webs in the web application and then call:
web.DoesUserHavePermissions(userID, SPBasePermissions.Open)
where "web" is a SPWeb object and userID is "DOMAIN\user.name" of the user you are checking access permissions for. Do it within a RWEP and make sure you dispose of your SPSite/SPWeb objects correctly.
One possible approach is to make use of impersonation to determine the sites and webs that a specific user (other than the current user) can access via the PortalSiteMapProvider. A method for impersonating another user in a SharePoint context is described here:
http://blackninjasoftware.com/2009/04/09/how-to-programmatically-impersonate-users-in-sharepoint/
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
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