I currently have my report server set up so that a user's AD groups determines which reports they can run. The user can be access the reports through either Report Manager or a custom site that I've created.
To reduce clutter, I would like to make it so that the user won't be able to see any reports or folders to which they do not have access. I can't find a setting in Report Manager or a way to do this using the ReportService in my web app. Is it possible to do this?
Report Manager does work that way. If they are seeing folders or reports, they have access and you may want to double check your authorization settings.
With regard to your custom application, you'll probably want to make sure you are passing in the logged in users credentials to the report server. If your custom application runs under a security context that has full access on the report server, then users will be able to access reports they shouldn't be able to access.
Related
I've been tasked with figuring out a way to make a certain set of Azure users authenticate to a Web Application by accepting/denying a warning message that should be presented before the users are directed to the application itself. The users that should not go through this process are in-network users.. they should be able to input the URL and be presented with a sign-in page and from there they will have access into the application. This has already been configured via Azure AD but the previous issue for out of network users is what i'm having issues with.
My current thoughts on this is to create an a simple authorization page created by an azure function that out of network users will be directed to because the IP addresses will be placed in a conditional access rule to do so. From the simple page the user will be directed to the application or logged out if they choose cancel.
This is just a thought but definitely open to suggestions. Thoughts?
For those who may have been interested in an answer for this question I have figured it out. In order to do this I had to create a "Terms Of Use" within Azure Active Directory. This Terms of use consisted of a pdf file containing the information my user needed to view before accept/deny could be clicked. On the "Terms Of Use" was created I then created a custom conditional access policy which included users needing to accept the "Terms Of Use" before being able to access our Portal or Applications. Hope this helps
I am trying to use power bi embedded service rest apis with a pro account, I have gone through the rest api reference guide -
https://learn.microsoft.com/en-us/rest/api/power-bi
The issue is that am unable to share a report with a particular set of users with the api, now i know that we can with rest api create appspaces/groups, and add users to group, but thats at the group level. I want to basically give permission at the report level. It is very easily possible from the app.powerbi.com portal by going into the share option. But there is no api that i can find to share a report to a user in an appspace.
We are stuck in our POC because of this as report level security is basic and a must have requirement for any kind of custom usage.
Currently Power BI REST API doesn't allow you to do that. As you said, you can only manage users on workspace level. If you need such dynamic report level management, you can try to achieve this by removing the rights of your users on the workspace and embed the reports in some application, implementin "app own data" scenario. This way you will be able to manage user's access in your application, while the reports will be always accessed with your "master account".
Our environment is Sharepoint 2010, with a web application created (and site collection on top), using claims based authentication. The first site is using port 881. It is using integrated windows authentication. Another web application is created, extending the first application, using port 882. This site is using Forms Based Authentication, the membership provider is System.Web.Security.ActiveDirectoryMembershipProvider, named admembers. I have turned off Client Integration on both sites.
When I login to the 881 site, on my corporate network, logged into the machine with the same domain account that sharepoint uses, I can open an Office file saved in a document library, and it subsequently opens in the appropriate Office application, without asking me login again. But, If I login to Sharepoint from a computer that is not on our network, or login to the computer with an account that is not a domain account, I get prompted again to login when openning an Office document. If I choose the option to save, it does not prompt, but if I choose open in the dialog window, I am forced to enter my domain credentials again.
When I login to the 882 site, which uses FBA, I experience the same problem. If I open an Office document, the appropriate Office application opens, and asks me for my credentials, by showing me a dialog window with the sign in page loaded. If I choose to save the file, then I am not prompted to login, and the file saves to a local folder.
I can't expect my users that are off site to login again everytime they open an Office document, like Work, Excel, Powerpoint, etc. I have tried numerous fixes, including disabling client integration, changing the browser handling mode (strict/permissive), changing internet explorer settings (for integrated windows authentication), changing the integrated windows authentication site to use basic authentication, even hacking the page using jquery to call the sharepoint javascript function that execute the "download a copy" function. None of them work: when choosing to "open" the Office document in the browser, the user has to login again, or just close the dialog window without logging in (as long as client integration for the zone is turned off).
I'm looking to get this accomplished using windows authentication or forms based authentication.
Help!
I found this answer in a similar post which seemed to fix the problem for me when I tested it. The gist of it is you need to deny the HTTP Verbs OPTIONS and PROPFIND in IIS. Having said this, I'm not an IIS guru and am not exactly sure what this means or what else it might affect. Can anyone else shed some light on this?
A bit of background, I'm using SharePoint 2010, on an FBA site.
You have the standard three use cases:
Employee intranet access
Employee remote access
Partner remote access
Employee intranet access
This normally always works out of the box, and it looks like it is working for you.
Employee remote access
The only way that i have seen this work (and i have tried many ways) is to get TMG or ISA. Basically ISA is setup in FORMS auth with SSL, it captures the auth details, and then passes them to the sharepoint server. (and other servers if you have them eg OWA for sharepoint mail web parts)
If you select the "Is private computer" option on the ISA login screen, then Office documents share the auth cookie and don't prompt for another login. I had so many problems, but as soon as i installed TMG, they all went away. I would not recommend any other approach now.
The added bonus of this method, is that remote employees are treated as the same account as the intranet user. The way you are setup with a seperate web application, means that they will be different accounts, so things like [checkout/modifiedby/createdby/personalisation] will be different accounts (though they look the same)
Partner remote access
This may never ever work on some clients (especially Vista), as IE needs to share the authentication with Office
If this is sharepoint 2010, try this.
Get-SPSecurityTokenServiceConfig
Look at your UseSessionCookies value in the output. If True, apply the powershell below.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $false
$sts.Update()
If UseSessionCookies is true, you will have to login to any docs u want to download...
We have a SharePoint application where we want the user to be able to modify the web.config by activating a feature. The application is extended, so we have an AD based web application and another that uses Forms Based authentication (FBA), with the FBA application being the "main" user application.
We use the SPWebConfigModification class (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx) to write to the web.config for settings we need for the activated feature.
This works great on the AD based side of things. However, when we try and run this on the FBA based web app, we get an error because the site collection administrator for the FBA site, does not have any access to modify the web.config on the server. Given that they are a FBA user, we can not give them rights on the server either.
Has anyone run into this? Does anyone have any work arounds. I assume I could try and have the application to update the web.conifg run via the command line, but I would really like it be done by the user when they activate the feature. I could also try and loosen security rights on the web.config, but that is a bad path to start down.
Thanks!
John
An alternative would be to write a component which does it.
This could be trigged by activating a feature, or updating a webpart.
This would mean you don't need to loosen security, or do it via the command line.
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.