Reposting my unanswered in technet.microsoft question?
MSDN "ASP.NET Delegation" article tells:
1) "When you configure to use a particular account as the process identity, ASP.NET attempts to delegate that account. If it is a local account that is identical (including password) to a local account on a remote machine, delegation is possible. If such an account does not exist on the remote machine, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON). In addition, delegation is also possible if the account is a domain account that has access to the remote machine, in which case it uses the domain network identity of that account."
The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?
If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created,
does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?
Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?
The same MSDN "ASP.NET Delegation" article tells:
"NetworkService account. It behaves the same as the System account. This account possesses the network credentials associated with the machine account (domainname\machinename) in the domain of which it is a member"
Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)?
as well as many other common pre-built accounts?
Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?
And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?
My related questions:
domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
how to check group membership of an “NT AUTHORITY\” account ?
Is client LocalSystem (SYSTEM) identified by target/server machine? and in which context?
Window workgroup LocalSystem vs. domain (AD) LocalSystem [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
interoperating with Windows domain computer from workrgroup Windows [closed]
the context of local user of AD-joined machine? Is it of domain machine account or of local machine account?
RunAs under domain account from non-AD Windows [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
how to share the same domain machine account with multi-boot workgroup Windows setup?
Q1: The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?
A1: Yes. See A3 below.
Q2: If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created, does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?
A2: Yes - all access by processes on System1 to resources on System2 must be authenticated - except in the rare cases when someone has configured one or more resources (and system policies) on System2 to allow anonymous (i.e. unauthenticated) access. Further, Server2 can only authenticate network requests that present credentials that System2 can verify - either from the local user accounts and passwords on System2, or by contacting a trusted domain controller (if System2 is joined to a domain). System2 doesn't know anything about user accounts or "user contexts" (those special 'accounts' like LocalSystem, Interactive, LocalService which are only ever represented by special hard-coded SIDs) that are only relevant on System1 - which includes any local user account defined on System1, and any of those special SIDs.
Q3: Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?
A3: The only exception (and it's not an exception, it's a designed-in use case) is when System1 authenticates using a username + password that are the same on System2. What you'll see in the network traffic is that System1's process (currently running e.g. as System1\UserX) will make a request over the network for a resource on System2 (e.g. file share, database object, web page). In that request from System1, is included "the credentials that System1 is trying to use to authenticate" (this is an abstract generalization to get away from describing things specific to any one authentication protocol - just bear with it). Under other circumstances, the account UserX doesn't exist on System2, or it has a different password, so that the authentication attempt fails on System2, and System1's request fails. That is, System2 assumes that UserX must be System2\UserX, and either the account doesn't exist or the password doesn't match.
Under the circumstance where there are matching local accounts, System2 "thinks" that System1 is logging on not with account "System1\UserX" but with "System2\UserX", and since the password matches, the authentication attempt succeeds.
Q4: Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)?
as well as many other common pre-built accounts?
Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?
A4: Remember, NETWORK SERVICE isn't a defined account (you won't find it listed in Local Users and Groups applet) but simply a SID - and if any process includes that SID in its token (depending on the circumstances of how the process with that token is created), then any resource that allows "Network Service" (which really means "any resource that allows the Network Service SID") to access the resource will allow it to pass. Otherwise, Network Service is just a user-friendly abstraction, and unfortunately user friendly usually makes things harder to get to the bottom of how it really works.
You might be able to assign permissions or Privileges to the Network Service SID before the system is joined to the domain, but requests to remote systems will respond very differently for a service running as Network Service depending on if the machine is joined to a domain or not. If joined to a domain, the remote request will usually (on modern Windows versions) attempt the remote authentication using the Domain Computer account for the local system. If not joined to a domain, there will be no credentials sent with the remote request, and the remote system will have to treat it as an anonymous (i.e. unauthenticated) request.
Q5: And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?
A5: As implied in A4, there is no identity that the remote server sees in this scenario.
Related
We have developed a web application to display sensitive information over our company's intranet. We had initially planned to implement sufficient security to allow remote access via the intranet to the application through a browser. But, due to an unforeseen requirements from our security team, we have decided not to allow remote access. We would still like a small number of users to be able to access the application, so here's the question. How can you host a web application in IIS visible only to users logged into the hosting machine? (The machine is both the host of the web app, and the only machine where the web app would be visible.)
I'm relatively new to IIS, so please speak as plainly as possible.
It seems like their must exist some setting in IIS to limit incoming and outgoing requests to the current machine.
It's possible to block all IP addresses with the following:
Which can be found in IIS 7 at this location:
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
[1] tells:
"When you configure to use a particular account as the process identity, ASP.NET attempts to delegate that account. If it is a local account that is identical (including password) to a local account on a remote machine, delegation is possible. If such an account does not exist on the remote machine, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON). In addition, delegation is also possible if the account is a domain account that has access to the remote machine, in which case it uses the domain network identity of that account."
[2] informs:
"The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used"
"The service presents the computer's credentials to remote servers
Also, the predefined "NT AUTHORITY\LOCAL SYSTEM" (or SYSTEM [3]) is present in any Windowses
and should have been usable for identification (even when client (process) accessed from workgroup Windows), shouldn't have?
Though, a row of answers, for ex., [3] tells the opposite:
'In Workgroups, the SID only has a meaning on the local workstation. When accessing another workstation, the SID is not transferred just the name. The 'Local System' can not access any other systems'
Is LocalSystem identified or not by remote/target machine?
and how?
as ComputerName\LocalSystem ?
or
as NT AUHORITY\LOCAL SYTEM ?
Update:
This question is completely inside the context of development environment in Windows workgroup...
though all answers deviated to Windows domain...
CITED:
[1]
ASP.NET Delegation
http://msdn.microsoft.com/en-us/library/aa291350.aspx
[2]
LocalSystem Account
http://msdn.microsoft.com/en-us/library/ms684190.aspx
[3]
sysadmin1138's answer to my question "Windows LocalSystem vs. System"
https://serverfault.com/questions/168752/windows-localsystem-vs-system
My related questions:
domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
how to check group membership of an “NT AUTHORITY\” account ?
Does access to server resources require client process to login to server machine?
Windows workgroup LocalSystem vs. domain (AD) LocalSystem [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
interoperating with Windows domain computer from workrgroup Windows [closed]
the context of local user of AD-joined machine? Is it of domain machine account or of local machine account?
RunAs under domain account from non-AD Windows [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
how to share the same domain machine account with multi-boot workgroup Windows setup?
There are two possibilities in your scenario, depending on the version of Windows on the local ("client") machine and on how well the service integrates with the Windows services APIs:
- remote machines will see requests from the "client" machine as NT AUTHORITY\ANONYMOUS
- remote machines will see requests from the "client" machine as DOMAIN\COMPUTER_ACCOUNT_NAME
A remote machine will only see requests from its own processes as coming from SYSTEM/LocalSystem.
If you want to find out through testing which account context you're seeing due to remote requests, enable Audit Logon Events (Success and Failure) in Audit Policy on the remote system. You can also find complementary (and sometimes helpful) information by using a protocol analyser like Microsoft Network Monitor, and capture the packet stream sent from "client" to remote machine and back.
Edit: also see my answer to the related/overlapping question here for related details.
System/LocalSystem and NETWORK SERVICE as well will all authenticate remotely as the computer account, DOMAIN\MACHINENAME$. There is a another built in account, the LOCAL SERVICE which will always authenticate remotely as ANONYMOUS LOGON (therefore failing most authorizations).
Trying to understand these concepts as SIDs and names has not much meaning. Authentication is an SSPI handshake at the end of which the authenticator will query the context token of the authenticatee and validate access (perform authorization), and the name of the authenticatee can also be queried from the security context. If the SSPI handhsake was remote (between two distinct LSAs) then the name QueryContextAttributes would return, in a successful authentication scenario, the remote machine name domain\machine$. If it was a loop-back handshake where only one LSA is involved, then the same call will return NETWORK SERVICE or System. There is also the posibility of the handshake authenticating 'ANONYMOUS LOGON', like the Workgroup case, use of a local account, or attempt to cross domain trust boundaries, but basically there are all failed authentication.
Here's the desired setup:
Service with wsHttpBinding is on IIS 6 on Machine 1 behind the firewall.
Client is front end website on IIS 6 on Machine 2 on a DMZ.
We are currently able to authenticate the client using Windows authentication, but with impersonation
<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />
since the website would use the "ASPNET" as username, which is not in the domain.
We now want to move away from this method, because of safety issue; we don't want to expose this kind of info on the DMZ.
Is there any way to get authenticated properly without using
the impersonate on the client
config?
If we changed so that we use
certificate authentication, would it
affect service operations that
require impersonations (needed
impersonations for file access on
the network for example)?
thanks.
This has been resolved now, and I think it'd be constructive to share the solutions.
In terms of my original question - whether it's able to do impersonation without setting it explicitly in the config or in the front end code. As mentioned by the above, the App Pool method does work, but only when both the client and server are on the same domain.
Since the web site client being situated in the DMZ has no access of the local network at all, meaning we are unable to impersonate any network user (this is a flaw in my original question, saying the impersonation works - it was actually not working).
So the only way to go was using certificate. Since this is internal communications, I have generated a test certificate on each of the server / client sides with the makecert. Using peer trust certificate authentications, I am able to get the communication working between the client and the server. This will ensure that no Windows / network user account information is presented in the DMZ zone.
I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.