I've created a custom SharePoint application which extends some of the OOTB functionality of SharePoint. Now I want to license the application and provide trial periods etc. So I want to store the licensing information in the file system/registry and check the validity of the license across the application. But even after I elevate to the application pool identity (who is just a domain user and not a system administrator as advised here http://technet.microsoft.com/en-us/library/cc678863%28office.12%29.aspx) I'm getting access denied for accessing my file.
What is the common practice to read/write/create files in the file system from SharePoint application?
Have you checked thet security logs to see which user is being denied access. I am pretty sure it will be the user who is logged into sharepoint rather than the app pool identity that is trying to access the file. The app poolidentity is usually only used in this way if the web site is using anonymous authentication.
Are you using SharePoint 2010 or 2007? What kind of Authentication? NTLM, Forms or Claims based?
If application is running under NTLM, then as Ben suggested, application will run under NTLM account and you should be able to access the resource.
If running under forms the application will run as anonymous user (local account), which will fail to access the shared resource.
I would suggest using ProcMon, it will capture the underlying access denied error and what user is being used to access that.
I guess there is no other solution apart from storing it in a custom database or a custom folder which is configured with full access for the application pool account.
Related
I have viewed and tried dozens of "answers" on StackOverflow, but none work.
I have a pretty simple aspx page with C# code behind.
The web site is on a Windows 2008R2 server.
The web site looks like (actual names changed):
MyServer - set for Anonymous Authentication
Application Pools
ASP.NET v4.0 Classic - .Net 4.0, Classic pipeline, App Pool Identity
MySiteAppPool - .Net 2.0, Integrated, runs under a Domain-wide Service identity (call it "mycompany\domservice")
Sites
MyMainSite - Windows Authentication, uses "MySiteAppPool"
"AutoPrint" - my web app, Windows Authentication, uses "ASP.Net v4.0 Classic" app pool, ASP.NET Impersonation enabled
My "AutoPrint" web app has a start page "AutoPrint.aspx" and code behind ("AutoPrint.aspx.cs", plus several classes).
The server and main site are not alterable, as there are several other applications under this site.
The user currently invokes this app with :
http://MyServer/AutoPrint
Everything I have tried is returning the "mycompany\domservice" result:
Request.LogonUserIdentity.Name.ToString() - returns "mycompany\domservice"
System.Environment.UserName.ToString() - returns "domservice"
System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString() - returns "mycompany\domservice"
What am I missing here? Why is this so hard?
Further clarifications:
"mycompany\domservice" - the "domservice" account is just an ActiveDirectory account in the "mycompany" domain that has permissions to read/write directories needed by the site and other applications. When installing the Site and additional web apps, we use that account as the "connect as" user.
What I am trying to do is to get the ActiveDirectory name of the Windows user account of the person who opened their browser and accessed this app. If user "JJONES" logs into Windows and launches the app with "http://myserver/autoprint", I want to get either "JJONES" or "mycompany\JJONES" as the user name.
If you use anonymous authentication, then the browser does not send any credentials (user id/password) to the server. Therefore if you want the client user id on the server, you have to use non-anonymous authentication, e.g,. Windows or Forms. You can use non-anonymous authentication and then allow or deny access to your web site to specific users or groups of users, or all users.
Thank you for all the helpful comments/suggestions.
The problem turned out to be a combination of factors. The App Pool I was using was using App Pool Identity (which has limited rights), so I had to use a specific account (the domain service account) in the "Connect as..." for the physical path credentials in order to access certain files.
Changing to use an App Pool that used an account with sufficient privileges (the domain service account) allowed me to leave the "Connect as..." using Pass-through authentication when converting to application.
Voila - I now get the user credentials using pretty much any of the proposed methods. After way too many hours of beating my head against the keyboard...
Have you looked at using HttpContext.User property ? This will give the current logged on user. After which point you may need to perform some nifty LDAP queries to get the username from AD.
See https://msdn.microsoft.com/en-us/library/system.web.httpcontext.user(v=vs.110).aspx
You may want to see the below link on how to search AD on the link "How can I search Active Directory by username using C#?"
Hope this helps you.
I have sections of my asp.net 4 MVC application that access Active Directory to check for Group Membership. When I a run the site from my computer, it works fine since I am a domain admin. When I run the site from a test computer under a standard user, I get a DirectoryServicesCOM error when trying to access AD. Obviously it's a permissions issue.
My question is, where and what within IIS do I tell to access AD as a specific account?
What are you using to access AD? I'm assuming System.DirectoryServices
What account is you app pool running as & what version of IIS? Assuming IIS7 or greater, you're probably using AppPoolIdentity which means you're accessing AD as anonymous user. Change the identity to NetworkService & it should use the machine account of your web server.
If you need privileges to do activities, then you'll need to use a specific account. If you're using AccountManagement Objects, then specify the credentials in a context class. If you're using classes in Protocols, then you do it using the connection. MSDN & Google have plenty of examples.
You should understand the security implications of the approach you use, as with all things security related.
I have a few newbie web service/Windows rights questions since I've typically been a LINUX/embedded dev in the past.
What directories does a web service executing on a server have access to by default?
I ask because I tried to write to C:\ and got an access violation. I kind of assumed I would in this case, but I assume there are some areas of the file system the web service can write to and read from by default, right? Or is it just the current working directory?
*How can I give a web service permissions to look at a new directory it didn't have default access to?*
This is C# - ASMX - .NET 3.5 - IIS
The WebService doesn't really have any associated access controls associated with it (in a sense). It is however tied to the access control of the user account which is being used to run the application. By default this is usually some built in user account with limited permissions.
IIS uses a number of built-in Windows accounts, as well as accounts
that are specific to IIS. For security reasons, you should be aware of
the different accounts and their default user privileges. It can be a
security risk to change the identity of a worker process so that it
runs as an account with a high level of access, such as the
LocalSystem user account.
See a list of possible user accounts here: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3648346f-e4f5-474b-86c7-5a86e85fa1ff.mspx?mfr=true
If you have Anonymous Authentication enabled you can usually check the settings on that to see which account is being used to run the web service. (Depending on which version of IIS you are using, clicking Edit should let you view the default user account)
After finding the account, usually you will have to explicitly grant it the permissions on the folders (read and write) that you want to give it access to. The default user account usually has pretty limited access (and for good reason). You can grant permissions on the Security tab of the properties of any of the folders on a Windows file system (Properties->Security)
If you're using Windows Authentication, then you should have the same access rights as the authenticated user using the application as long as the resources are local to the IIS server.
I have a requirement where I need to be able to access a list which sits in Central Administration from an Application Page which sits on my Web Front End (WFE). The issue I have is that the Application Pool User for my WFE does not have access to the SharePoint_AdminContent database so I get access denied, they both have their own App Pools
In the logs it shows the following:
Reverting to process identity
Current user before SqlConnection.Open: Name:
SharePointDemo\SPContentPool SID:
S-1-5-20 ImpersonationLevel: None
Current user after SqlConnection.Open: Name:
SharePointDemo\SPContentPool: S-1-5-20
ImpersonationLevel: None
Insufficient SQL database permissions for user 'SPContentPool'
in database
'SharePoint_AdminContent_53169fb3-137c-44b2-b90e-961b656e4275' on SQL Server instance 'SPNSQL'.
Additional error information from SQL
Server is included below. The EXECUTE
permission was denied on the object
'proc_EnumLists', database
'SharePoint_AdminContent_53169fb3-137c-44b2-b90e-961b656e4275',
schema 'dbo'.
I have tried to runwithelevatedprivileges as well as trying Daniel Larsons method (http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1919.entry) which uses the SharePoint\System user token but it only seems to elevate as high as the Application Pool.
I am hoping there is an easy way to impersonate the Application Pool of the Admin Web Application but have been unable to find a way to do so yet... Or change the process identity to one which has access
Any thoughts, ideas or solutions are thankfully received!
Phill
You should try to use the List web service to access the list items. And set the credentials before connecting to the web service.
The problem is that the CA Application Pool and the WFE Application pool most likely run under different accounts, which is best practice though annoying when you are a developer. There is no amount of Elevating Privileges you can do using SPSecurity.RunWithElevatedPrivileges to get around this.
Providing your security policy allows this, you can give the application pool that runs your WFE Web Application the same credentials as the Central Administration Application Pool.
This can be done using the Service Accounts screen at:
http:///_admin/FarmCredentialManagement.aspx
If you go down the web service route, you may want to role your own web service to prevent too much 'chatting' over HTTP.
Have you tried regular windows impersonation? You should probably be able to impersonate the service account and get access to the list that way.
I get an UnauthorizedAccessException everytime I try to access (just read) a file on a network share "\\server\folder1\folder2\file.pdf."
I am impersonating the domain\aspnet user which has read & write access to the above mentioned folders. The file is not read-only.
I tried finding the permissions via System.Security.Permissions.FileIOPermission. It just says NoAccess to all files.
I'm not sure what else I can do.
I am using Visual Studio 2008, ASP.net 2.0 on Framework 3.5, WinXP, IIS 5.1.
ASP.NET user will not work with network path. So you need to have a windows account that
will have all the rights and then you need to imposernate things in web.config like following.
<identity impersonate="true" userName="domainname\windowuseraccount" password="password"/>
I'll assume you have set up the impersonation properly. You have turned off anonymous access, set the authentication mode to Windows and set impersonation to true, etc.
Even with all that done properly and the correct account impersonating you will still not be able to access the file. The account being impersonated is using what are called network credentials. These are only valid on the machine on which the impersonation is taking place. When you attempt to access a file on the computer itself the access is performed with the user's credentials but for a file on a share the access is done as a non-authenticated user and so no access is allowed.
In order to allow you to use the user's credentials for remote work, i.e. accessing a share, integrated security for a remote database, etc. you need to use delegation rather than impersonation. This is a somewhat complicated topic involving your Active Directory set-up and your IIS configuration. Have a look at this article, it should give you a good place to start.
Make sure that the domain user has Security rights and Share rights. That is, on the shared folder, add the domain user under the "Sharing" tab in the properties, as wells as under the "Security" tab.
What IIS version are you using? If it is version 6, you can place the web app in it's own application pool, then set the identity of that application pool to be a domain user account. Then, grant that domain user account access to the network share.
FYI you can place the following in an aspx file to verify what identify your pages are running as:
<%# Page Language="C#" %>
<% Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name); %>
To access a network share the above user will need to be a domain account setup by a network administrator.