[1] tells: "When you configure <processModel> 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? Let me understand. If the process (or user) from account LocalAccount on host with name MyDevComp accesses a remote server with name RemoteServer in workgroup, then it accesses with identity MyDevComp\LocalAccount but identified as RemoteServer\LocalAccount? or how to understand that LocalAccount should exist on RemoteServer in order for accessing identity to be identified successfully or failed? Why should the local account exist on accessed server (resource) machine in order for the client to be successfully identified (and under which ID)? and not lost any identity [1] states: "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)? Why is the identity "mutilated"? And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server? [1] http://msdn.microsoft.com/en-us/library/aa291350.aspx ASP.NET Delegation

On Fri, 17 Sep 2010 04:26:59 +0000, vgv8 wrote: [1] tells: * "When you configure <processModel> 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? Because that's the way the Windows security model works. Let me understand. If the process (or user)?from *account?LocalAccount* on host with name MyDevComp accesses a remote server with name RemoteServer in workgroup, then it accesses with identity*MyDevComp\LocalAccount* but identified as *RemoteServer\LocalAccount*? The local account will be identified on the remote server as LocalAccount, the remote server will then check its local account database for a matching account and password. If it finds one, access will be allowed, if it doesn't, it won't be. or how to understand that LocalAccount should exist on RemoteServer in order for accessing identity to be identified successfully or failed? In a workgroup, there's no shared accounts database so there's no other way for this to work. Why should? the local account exist on accessed server (resource) machine in order for the client to be successfully identified (and under which ID)? and not lost any identity As above. [1] states: * "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)? Why is the identity?"mutilated"? It isn't mutilated at all, it is a special account and therefore is treated differently than standard user accounts. And what is identity used?when the process?from workgroup Windows under identity ?((NT AUTHORITY\NETWORK SERVICE) accesses? a remote server? Outside of a domain, the network service account is not really usable for access to remote resources and processes. You can ask why this is so, and complain that this account is "mutilated" all you like, that's simply the way the Windows security model was designed and works. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca

Because that's the way the Windows security model works. I could not understand what is the security paradigm and point in in identifying the remote identity through local one. Should it be understood that in workgroup the computer of client cannot be identified and why? In a workgroup, there's no shared accounts database so there's no other way for this to work But there are well-known identities of accounts present in any (workgroup and somained) Windows: - local Administrators (except DC) - system accounts ("NT Authorities\" Why cannot they be used to eliminate the need of creating dummy local accounts just for accessing? Outside of a domain, the network service account is not really usable for access to remote resources and processes. You can ask why this is so, and complain that this account is "mutilated" all you like, that's simply the way the Windows security model was designed and works I am not complaining. I am trying to understand You do not explain how security model works either. There is no point to explain by obscure, already known to me. general phrases and to reply to me by my own re-phrased statements. If you can add and expalin, then add and explain, refer to docs. For ex., what are the rules and when one account is substituted by another and what makes "NT AUTHORITY" accounts different that they cannot be used as "shared" accounts Why (what happens under the hood) that the remote local account is identified if the local duplicate exists and its identity is lost when there is no local duplicate. I can see neither the rationale for this nor the underlying mechanisms.

On Fri, 17 Sep 2010 16:48:51 +0000, vgv8 wrote: You do not explain how security model works either. There is no point to?explain by obscure general phrases?just to te Well, there's no point, then I guess I'm done. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca

You do not explain how security model works either. There is no point to?explain by obscure general phrases Well, there's no point, then I guess I'm done. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Thanks, I am sorry for deviating your time having asked quite obvious, if not banal things. I forked subquestion to this discussion: Does access to server requires client (process) to login to server machine?