I'm using the Cassia library to get terminal service information on Server 2008R2. Further more, this is being called from a ASMX web service. I'm having problems with an Access Denied error:
System.ComponentModel.Win32Exception: Access is Denied
I'm assuming this just means that my Application Pool needs to be added to a certain user group, but I'm not sure which one (had to do this before to read performance counters). Anyone know which?
Update: As I said in a comment under this post, adding the app pool to the admin group allowed the right access. However after a while (maybe a week or a few days), the access was auto deleted. Not sure if it was automatically done by some pre-included service or by another administrative user. However I don't really think this is the best way for this anyway. There's got to be a lower level group that would have access to terminal services. Any ideas?
Related
We have two WFE servers and Application server for the SharePoint. User profile service is configured and we want use it. But User Profile Synchronization Service stays on starting state and after a while stops, then it makes the forefront identity manager services disabled too.
I just checked the farm user account access and also configure the service again and again to fix this issue.
The stuck on starting issue can be a real pain to deal with. Spencer Harbar wrote an article a few years ago that I, unfortunately, have to refer to from time to time. It's very comprehensive and there are several things that could cause the problem but it usually comes down to incorrect permissions on either a windows service, a SharePoint service, a DB, or issues in forefront. Bookmark this one... it will be your friend :)
http://www.harbar.net/articles/sp2010ups2.aspx
Make sure that the farm account is added to the local administrator group during starting and provisioning User Profile Sync Service service.
For more details check
User Profile Synchronization Service Stuck on Starting
User Profile Synchronization Service Starting then Stopped in SharePoint
We have an app in the Google Apps Marketplace (the new one, i.e. using OAuth2) which needs to get a list of users in the domain.
We're currently using the Provisioning API for this (which we know is deprecated, but there seems to be no better option). Lately however, we're starting to get "You are not authorized to access this API" 403's, for some domains.
Does anyone know why we're suddendly getting 403's, a bug perhaps? There seem to be some other bugs as well, for example the scope https://apps-apis.google.com/a/feeds/user/#readonly doesn't work, but https://apps-apis.google.com/a/feeds/user/ does.
Does anyone know when it will be possible to start using the new Admin SDK Directory API to get a list of users? This isn't possible now because even when an administrator installs the app, it would only work if they go to their domain security settings and manually check "Enable API Access", see the related question here: How can I access user info on a domain without the domain administrator enabling API access?
You can start using Admin SDK Directory API. The question you linked to was regarding the case where an admin explicitly disables API access. When they install and an app, we re-enable that setting and let them know.
Not sure about the 403s but that is an older API that is replaced by the Admin SDK.
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
After not getting much help on the last question, I decided to blow away the VM and re-create it as I already lost a week on this issue. And of course still issues, btu a little different.
I am using WSS on a 2008 server. I removed from the SharePoint admin the blocked asmx page types. I am using the administrator account with password and the domain, which is the IP of the VM machine. Normally I would never recommend using the admin account, but since I am just running a test to connect to SharePoint web services, so be it.
When accessing this site via a webbrowser, no issues whatsoever.
When accessing the web services from the browser using the admin credentials, no problem.
Then when trying to access the web service via Visual Studio I get the windows security dialog;
Followed by a discovery credential for the list;
Followed by another Discovery Credential for access to the error.aspx page, but as you can see, I can see the list of services for lists.asmx;
Followed by yet another Discovery Credential asking for permission to the $metadata and this just continues continually -it will NEVER authenticate via visual studio 2010;
And then, of course, when the code is ran, what do we get - ACCESS DENIED.
Call made; code not listed makes connection.
Make call to service:
And receive the error.
And IIS for SharePoint is set top Windows Authentication and Impersonate. All defaults.
It has now been going on 5 days; does anyone at all have any clue as to what is causing this? I have used this code and technique for years with Windows Server 2003 and WSS 2.0 and / or MOSS 2007 connecting from remote machines and NEVER, I mean NEVER had issues like this.
I would really appreciate any help.
I have published my site and an exception is thrown but no error files are generated in the App_Data folder. I am wondering whether its write access to the folder.
The documentation says the ASP.Net process needs write access but not sure what is meant by that. Can someone tell me which user needs rights to this folder?
Thanks
UPDATE: I have found that the ASP.Net process on Win 2003 is the user NETWORK SERVICE. Is that correct?
On Windows Server 2003 (IIS6+) and higher it is NETWORK SERVICE. On IIS 5 and below it is the ASPNET user account that needs the required access.
It's whatever user is the identity of the application pool your app is running in. Typically this will be Network Service, but it could be a different account if your hosting administrator has set it up that way.