Service Account replaced by IUSR ??

[Erwin@ODS]

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 !

 

[Joe Kaplan]

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.

 

[Erwin@ODS]

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.

Hi Joe,
(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

 

[Joe Kaplan]

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.

 

[Erwin@ODS]

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]

Well, that's some progress anyway.

I'm not sure if the console app would help or not. It is worth a shot. You
could also do a Windows service and communicate with it via remoting or
something.

I think I'd try to figure out why the timeout is occuring though. This
should be something you can do in process.

Joe K.