Was not able to find a way to discover all the sites of an organization:
creating a site with user2
approving the app with an admin
using 'https://graph.microsoft.com/v1.0/sites?search=' does not show the new site.
Only once i add the admin to the site group I find the new site.
how can I find all the sites?
Do I need to get an access token for each user?
For example with this token I can access all the drives but can't find the sites.
There are a couple things going on related to what you're asking and I'll try to address each of them:
1) We don't have an officially supported way to discover all of the sites and site collections in a given tenant today. The "search=*" query may give you the results you're after but it is not guaranteed in all scenarios. We're looking at this scenario but do not have formal support in the product today.
2) Search results are security trimmed, when using delegated permissions the search API will only return sites that the logged in user has access to. This could explain why you needed to add the Admin first before it showed up.
3) To use search in scenarios where you do not want security trimmed results you will need to user Application permissions and have the Tenant Admin perform the application consent flow for the entire tenant. This is a fairly broad permission but is required for some scenarios.
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 have the app that uses OneDrive API (MS graph) to access OneDrive free accounts and OneDrive for business.
The app works fine.
In docs of the API i can see same API can be used also to access Sharepoint Online sites data.
How to do this? When i auth a user who has Sharepoint Online account with MS graph, there is only his drive (ondrive) but there is no his site listed.
How to get access to his sharepoint site too using same API?
I have found how to work with sites using the Graph API.
To get list of sites there is the call
GET /v1.0/sites/
Then use the SITEID to get list of drives (in fact, top level folders)
GET /v1.0/sites/SITEID/drives
Then to get contents of a drive user
GET /v1.0/sites/SITEID/drives/DRIVEID/root/children
And all next calls are same as for onedrive drive
However, there is the problem i still can not solve. How to create new top level folder (new drive on a site). There is no API call for this
I believe what you are looking for is the sites API. It lets you interact with a SharePoint site if you know the path or the id of the site. You can find the documentation for the api here:
https://dev.onedrive.com/resources/site.htm
There is no easy way to discover sites as of now. You can however search for a site. You can read more about it here:
https://dev.onedrive.com/sites/search.htm
This endpoint to get the list of sites is not working, so the last answer is not valid anymore.
https://graph.microsoft.com/v1.0/sites
I haven't found a way to do this, the discovery of sites, without admin consent. If the admin consent flow is not a problem you can try this workaround, use the endpoint of groups to ask for the groups that the user is member of, and you can use the groups to get the document libraries of the user.
To get the groups:
GET https://graph.microsoft.com/v1.0/me/memberOf
With the group id, you can use this endpoint:
GET https://graph.microsoft.com/v1.0/groups/{group-id}/drive
So if someone know how to do the discovery of sites for a user without admin consent, please share.
EDIT: I'm not sure why my answer was deleted, my answer basically has 2 things:
I gave notice that one answer here is not valid anymore.
I gave a possible other solution to the problem.
I am trying to find out if the currently logged on user has a certain security role. I've looked on Google (couldn't find an answer) and the SDk examples (they seemed way too complicated). So, if you know the name of the security role and the user ID, how do you check to see if the user has that role?
If you browse the folder structure of the CRM 2011 SDK (link: https://www.microsoft.com/en-us/download/details.aspx?id=24004) to this location you will find what you are looking for:
.\SDK\SampleCode\CS\BusinessDataModel\UsersAndRoles\DoesUserBelongToRole.cs
It provides a sample built as a C# Console application. The code will work in ASP.NET as long as the app pool user is authorized to access the CRM Organization that you are trying to connect to.
Hope this helps
You should be able to find lots of examples out there. However to get the current users roles in JavaScript you can use:-
Xrm.Page.context.getUserRoles()
That however will return a list of GUID's which you then need to compare with roles in the system. This part is a bit trickier however here is an article that shows pretty clearly how to do it
http://www.infinite-x.net/2010/11/16/retreiving-user-roles-in-crm-2011/
At a high level you need to do an OData query (against RoleSet) to return the role (or roles) that you are wanting to compare. Then you compare the GUID's of those roles against the GUID's returned by the getUserRoles() function and you're good to go!
We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.
-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO
-CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )
Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.
Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites
I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.
Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.
IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article
Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in
AD rights:
"Cms" <-Allowed to login to the cms system
Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article
So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?
What are my options ? What other solutions other than AD do I have ?
Thank you for any feedback, its much appreciated !
We have done something similar in my organization. Here is the overall flow:
User requests web page
User is redirect to login screen along with SAML request
User authenticates against Active Directory
User is passed back to request web page with SAML response
User group/rights information is retrieved from database
If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.
We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...
I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.
As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.
I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.
So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)
However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)
Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier.
Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.
I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.
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