2

I have an IIS application running on Server A. It needs the ability to write to a folder on a UNC share, currently on Server B. I would like to keep the share on Server B, but this environment does not have a Windows Active Directory domain -- up until this point, we have worked around this issue by running any given service (DB, for example) under an account whose username and password would be replicated on any other servers the service needed access to. Up until this point, we did not know the IIS application needed "domain-style" access to any other resources it didn't already have alternate methods of authenticating to.

The IIS application has the setting Identity: ApplicationPoolIdentity, which by my understanding causes it to run under the SID IIS AppPool\AppPoolName

So then, after some initial research and findings, I've come up with the following possibilities, ordered from least- to most-elegant. My comments in italics.

  1. Move the share onto Server A.
    Not really what I want to do -- would require a bunch of reconfiguration of existing services, inconsistent with other infrastructure.

  2. Move the folder in question onto a new share on Server B with anonymous-write access.
    This would at least keep all my shares on the same server, but security by obscurity is really not my style.

  3. Reconfigure the IIS application to run under an explicit username and password, to be replicated on Server B to grant access to the file share.
    This at least I think would accomplish what I want it to, but changing the identity seems risky and potentially prone to unforseeable consequenses for the application.

  4. Give the application pool identity on Server A a stored credential for a username and password that will allow access to the share on Server B.
    No idea if this would actually work, or if you can even give stored credentials to SIDs that aren't full user accounts in the first place. Just an idea, but I like it since it doesn't impact the existing configuration of the IIS application.

  5. Use ACLs on the share to grant access to the "Machine Account" of Server A.
    This seems like the holy grail as it's the recommended method ("application pool identities also use the machine account to access network resources"), but of course these machines are not bound to a Windows domain, which appears to be a prerequisite for using a Machine Account.

Ideally I'd like to find a hack or kludge that would accomplish item #5 or some other way of granting access solely by reconfiguring Server B, again without an AD domain. In any case I'd also like to know what the more experienced Windows Server admins would do in this situation (aside from just setting up a goddamn Active Directory domain).

NReilingh
  • 472
  • 3
  • 9
  • 24

1 Answers1

1

Your only option without a Windows domain is indeed to change the Application Pool Identity to an account that has access. If there's nothing special going on with the existing identity, you should just have to create a basic user account (it does not need a profile) and assign it as the identity.

At runtime it will be given the IIS_IUSRS group and have the same access it would as the default app pool identity.

NReilingh
  • 472
  • 3
  • 9
  • 24