We have a web application running on a windows server 2012 R2 server. This application worked on a previous server (we don’t have access to this anymore to look at the settings). The application has a section that allows a user to browse files on the network share using impersonation and this is the issue.
If the user logs onto the web server directly and accesses the service that user can browse the file share without any issues. Where the issue comes into play is if the user accesses the web app from there pc then IE reports an error. This error is misleading I think as it talks about ASP.NET but other areas show different results.
We know this is an issue with the impersonation because if in the website, Authentication, ASP.NET Impersonation to use a specific user rather than the authenticated user the file browsing works.
We have tried a lot of different things and have narrowed it down to being this impersonation issue.
When a user try’s through the application to access the network share and it fails I do not see it trying to access the file server. (We turned auditing on for the files and no fails from that server) What we do see is on the web server is the following errors:
Event code: 4011
Event message: An unhandled access exception has occurred.
Event time: 28/08/2015 15:16:23
Event time (UTC): 28/08/2015 14:16:23
Event ID: 0a67c0cd1bd7408080531d9e578a5d19
Event sequence: 8
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT/mims-1-130852449724574570
Trust level: Full
Application Virtual Path: /app
Application Path: C:\inetpub\wwwroot\app\
Machine name: WEBSERVER NAME
Process information:
Process ID: 2748
Process name: w3wp.exe
Account name: Application pool domain account (also same thing in any other account mode)
Request information:
Request URL: http://app/app/EasyShare.aspx?tab=1
Request path: /app/EasyShare.aspx
User host address: PC Address
User: USER ACCOUNT
Is authenticated: True
Authentication Type: Negotiate
Thread account name: Application pool domain account (also same thing in any other account mode)
Custom event details:
On the Web server I turned logon auditing on to see what was going on and can see the user is being impersonated:
Special privileges assigned to new logon.
Subject:
Security ID: Domain\user
Account Name: User
Account Domain: Domain
Logon ID: 0x3FD5AE23
Privileges: SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
SeSystemEnvironmentPrivilege
SeLoadDriverPrivilege
SeImpersonatePrivilege
Followed by:
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Impersonation Level: Impersonation
New Logon:
Security ID: Domain\User
Account Name: USER
Account Domain: DOMAIN
Logon ID: 0x3FD5AE23
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name: PC
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): NTLM V2
Key Length: 128
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The impersonation level field indicates the extent to which a process in the logon session can impersonate.
The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
But yet the user cannot access these file shares.
We have on the webserver in AD made sure it is trusted for delegation.
Now we are at a bit of a loss and everything we read keeps us going round in circles with no fix in sight, Hopefully one of you lovely chaps may be able to helpJ