"Erwin@ODS" <erwin@onedaysolutions.com> wrote in message
news:%23GzsZGasHHA.3736@TK2MSFTNGP02.phx.gbl...
> Hi,
> Could anyone help me with this.
> I am testing a .Net 2 application that creates a user in AD. It also has
> to create a shared folder on a remote server.
> I'm testing this on a Windows SBS 2003 machine, taking the same server as
> "remote" server, by using the UNC path when creating the directory.
>
> Now, in order to avoid impersonation I did the following :
> - create a service account, register it in AD using the setspn.exe tool
> described in article
> http://msdn2.microsoft.com/en-us/library/ms998358.aspx.
> - giving the service account administrator rights (only for testing
> purposes, this will be graded down in production)
> - checking the "trust account for delegation" option in the account
> - create a separate application pool in IIS 6 only for this application.
> - setting the identity for this AppPool to the newly created user
>
> So far, everything works fine, and I succeed in creating the user in AD.
> But the application breaks down when I want to create the folder, for the
> reason that the app doesn't have access rights to the folder.
> It will only work when I use impersonation :
> - either to the specially created service account
> - or to the web user, if he has administrator rights.
>
> But the whole idea of creating a service account was to avoid
> impersonation !
>
> I decided to audit the parent directory in which the user directories
> should be created. And this is what I got as event (I snipped some lines
> for briefness) :
>
> Event Type: Failure Audit
> Event Source: Security
> Event Category: Logon/Logoff
> Event ID: 529
> User: NT AUTHORITY\SYSTEM
> Computer: MYSERVER
> Description:
> Logon Failure:
> Reason: Unknown user name or bad password
> User Name: IUSR_MYSERVER
> Domain: IQS
> Logon Type: 8
> Logon Process: Advapi Authentication Package: Negotiate
> Workstation Name: MYSERVER
> Caller User Name: adtester
>
> What boggles my mind is that the user is still IUSR_MYSERVER in stead of
> the specially created service account "adtester" !
>
> Do you have any idea what's going on here or am I missing something ?
>
> Thanks !

> (First off, I'm a *big* fan of your book about AD !)
> Well, to get to the matter at hand, I'm quite sure that anonymous access
> is disabled. In fact, I did a check with the
> System.Security.Principal.WindowsIdentity.GetCurrent() and sure enough the
> application runs under the service account.
> The only thing that is a bit different is that I'm running the application
> with a different port number (192.168.1.2:8080), but that should not
> affect the security, should it ?
> As for the "trust account for delegation" option is concerned, I thought
> you had to enable this, based on this text fragment in the article I
> referred to :
> "By using impersonation, ASP.NET applications can execute code or access
> resources with the identity of the authenticated user or a fixed Windows
> identity. Standard impersonate-level impersonation tokens that are usually
> created when you enable impersonation allow you to access local resources
> only. To be able to access remote network resources, you require a
> delegate-level token. To generate a delegate-level token when you
> impersonate, you need to use Kerberos authentication and your process
> account needs to be marked as trusted for delegation in Active Directory.
> "
>
> But now that I read it again, I see your point. Anyway, it doesn't work
> either with or without this option checked, so I'll uncheck it. I like
> clean settings.
>
> Erwin

"Erwin@ODS" <erwin@onedaysolutions.com> wrote in message
news:OFk52McsHHA.2004@TK2MSFTNGP03.phx.gbl...
> Joe Kaplan wrote:
>> Hm, I can't think of a reason why the IUSR account would get used here
>> then. If you are definitely not impersonating (which it looks like you
>> are not) and don't have anonymous checked anyway, then the remote access
>> to the file share should use the process account.
>>
>> There must be something else going on that is creating the issue, but I
>> don't know what it is.
>>
>> Can you show the code you are using for accessing the file share? That
>> might be helpful.
>>
>> Joe K.
>>
> I told you before, you must have a magic radience.
> Suddenly, without impersonation, the service account DOES authenticate !
> I'm not sure what happened, I didn't change anything but now it works.
> Perhaps there is a delay somewhere.
> Well, when I said "it works" that's a bit too optimistic : the
> authentication seems to be allright, but now the application times out.
> I'm thinking of creating a console application to create the shared
> directories. It could then be started by the web application. Any thoughts
> on that ?
> Erwin

Joe Kaplan wrote:
> It looks like the IIS anonymous user is being impersonated for some reason
> here. That should be the only reason why that user would get used at all.
> Can you see any reason how that might have happened? Is anonymous enabled
> in the application at all?
>
> Out of curiosity, why are you enabling for delegation if you don't plan to
> delegate? Based on what I read below, it sounds like you just want to use
> the fixed process account for accessing remote resources, so delegation
> should not matter. As such, you should also able to avoid impersonation as
> well since you would generally only impersonate if you need to delegate or
> access local resources with the security context of the authenticated user.
>
> Joe K.
>

Joe Kaplan wrote:
> Hm, I can't think of a reason why the IUSR account would get used here then.
> If you are definitely not impersonating (which it looks like you are not)
> and don't have anonymous checked anyway, then the remote access to the file
> share should use the process account.
>
> There must be something else going on that is creating the issue, but I
> don't know what it is.
>
> Can you show the code you are using for accessing the file share? That
> might be helpful.
>
> Joe K.
>