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.
Related
This seems like a simple question but I'm struggling to find an answer anywhere. Help! ;-)
I'm trying to use Microsoft Graph to read SharePoint lists/libraries in a SharePoint site, however this is just for one site (for our department) amongst many on our SharePoint online. I've registered an Azure AD app (with secret etc...) and requested 'application' permissions for the Microsoft Graph ('Create, edit, and delete items and lists in all site collections') and its saying 'admin consent required' is 'yes' and its currently flagged as 'not granted for *****'.
My boss is now asking - with a worried tone ;-)
will this mean the app can basically read/write/delete on all sites in
the organisations SharePoint (not just our site) if our IT department
'consent'?
I said I don't know actually... I guess I'm not entirely clear on which permissions this is for, is it just to call the Microsoft Graph API or is it for this app to access SharePoint itself? I've searched for answers to this but I'm struggling to find anywhere that says anything about giving your app permissions in SharePoint, it all seems to be about getting permissions for the Microsoft Graph to access SharePoint.
I just want the app to have permissions to read/write lists/files in this one SharePoint site, not any others (we have loads of sites for other departments). I feel like we should be adding permissions for this app (its service principal?) somewhere on the SharePoint site we want to access, but what permissions do I need to setup and where so this app can only access this one site?
Azure AD app registration now allows for granular access to SharePoint site collection, there is a new option Sites.Selected under Azure AD App Registration - Request API Permissions - refer to https://developer.microsoft.com/en-us/graph/blogs/controlling-app-access-on-specific-sharepoint-site-collections/
Unfortunately, this feature is still missing. It is not possible to limit the permissions to only one SharePoint site. It's either access to all SharePoint sites in the organisation or none. Check out the user vote for more information: here. Microsoft is still working on providing a way to limit the access to specific resources.
I submitted an office 365 SharePoint add-in app for certification in the Office Store, and was told that one of the changes required is that I remove the 'Full Control' permission for the app, as it is not supported in the store. My app enables the user to create a new web site based on certain criteria. The add-in works correctly with 'Full Control' permission, but does not work with lower levels such as 'Manage'.
If the store does not allow me to use 'Full Control', what permissions or options can I use in order to still be able to create sites on behalf of the user?
Is there a different way to go about having the add-in app create sites in an existing site collection? The trigger can be user initiated, or event based.
I would love to get any ideas or solutions for this - Thanks!
The only option I can think of is to create a web service that is external to SharePoint and create the site in the service.
Here are a couple of resources that may help you:
Walkthrough: Building a Custom Web API for use with SharePoint Online
PnP Webcast - Calling external APIs securely from SharePoint Framework
With the release of Office 365 can someone tell me the support available for custom visual sandboxed web parts created using Visual Studio 2010 SharePoint Power Tools that fetches an Office 365 active directory attribute values for a particular user? E.g. If my company already has existing users in a local Active Directory environment when I subscribe to Microsoft Office 365, there are tools for synchronizing those users to Office 365 directory. Let say I have synchronized my local Active Directory to Office 365 Directory, now is it possible to programmatically or OOTB way to read Office 365 directory attribute’s value for any Office 365 Directory user? I have a custom attributes added to my local Active Directory one of the attribute is “CC Number” and I want to get the value associated with this attribute for some XYZ user.
We have an Office 365 SharePoint application to which we would like to add either (or both) a custom sandboxed web part and a OOTB web part that only reads a data from an Office 365 Directory for respective Office 365 directory user.
Is this type of functionality supported with the first/current release of Office 365?
it's a really common scenario that organizations will move parts of their systems into the Microsoft Cloud by using Office365. In order to get rid of the additional AD management overhead you have to build a federation on AD level.
You need a SecureTokenService which does the authentication for your users. Microsofts implementation of STS is ADFS (ActiveDirectory Foundation Services) which could easily be plugged into an existing AD structure. Your AD has to be 2008 I think.
There is a good ebook from Dominick Baier and some other security guys available. It's called "Guide to claim based identity", you can read it online on http://msdn.microsoft.com/en-us/library/ff423674.aspx or there is anywhere a download it think... can't remember sry.
In MOSS 2007, I want to search/get Computer Names from Active Directory in SharePoint just like search users.
Assuming you want to retrieve these names programmatically:
As far as I know there is no SharePoint API to retrieve computer names from the AD.
Though there are methods on SPUtility to retrieve Users and Groups from the AD.
To query computer names you have to implement you own Ldap query:
Use the .Net types System.DirectoryServices.DirectoryEntry / System.DirectoryServices.DirecorySearcher to query against the AD.
If you were using .Net 3.5 you could use the types System.DirectoryServices.AccountManagement.ComputerPrincipal and System.DirectoryServices.AccountManagement.PrincipalSearcher to do so.
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