Disable account in Active Directory from .NET using DirectoryEntry

[Nathan Smith]

When I try to disable a user account thru forms authentication, I am getting
an System.UnauthorizedAccessException: General access denied error. If I
impersonate user it will prompt me to login and if I put in an administrator
password it will work but obviously that won't work for the public. I would
like to keep impersonate user set to false and no windows login screen to
come up. Any ideas? Is there a way to change the user it's using to disable
the account within .NET?

 

[Joe Kaplan \(MVP - ADSI\)]

Disabling a user is basically just flipping the correct bit in the
userAccountControl attribute in AD. However, I can't make any sense of what
your actual problem is here except that you are not using an account with
sufficient privileges to make this change.

Can you provide some more details and show some code?

Thanks,

Joe K.

 

[Nathan Smith]

I also think it's a privileges issue but I'm not sure which account I should
be looking at. Is it an issue with IUSR that is the anonymous user running
the website or an issue with the user I am trying to make the change too?
Like I said if I set impersonate user I am able to login from a prompt and
disable user.

 

[Nathan Smith]

How do I change the account I'm making the change with?

 

[Paul Clement]

¤ When I try to disable a user account thru forms authentication, I am getting
¤ an System.UnauthorizedAccessException: General access denied error. If I
¤ impersonate user it will prompt me to login and if I put in an administrator
¤ password it will work but obviously that won't work for the public. I would
¤ like to keep impersonate user set to false and no windows login screen to
¤ come up. Any ideas? Is there a way to change the user it's using to disable
¤ the account within .NET?

Without impersonation the default identity under which the application executes
is ASPNET (or Network Service under Windows Server 2003). So unless you want to
provide administrator capability to this user, which is not a good idea, there
isn't really another viable alternative.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Joe Kaplan \(MVP - ADSI\)]

There are two basic approaches:

- You can put in the userid and password in the DirectoryEntry object
itself, or
- You can change the security context of the current thread to be the
account you want. Note that this is the default behavior if you don't
supply credentials, so this probably what you are getting now.

The first is easiest, but may not be practical depending on your specifics.
The second approach may be the way you want to go, but there are a lot of
options and a lot of potentially icky details.

I'd start by reading this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;329986

Essentially, there are two possible accounts in question, the process
account or the impersonated account on the thread which may be different
than the process account. The way you go about changing them depends on
which version of Windows server you are using and your security settings in
IIS and ASP.NET. Can you give more details?

Joe K.

 

[Nathan Smith]

I am using windows 2003. In IIS I am allowing anonymous access using the
IUSR_Test2 user.

 

[Paul Clement]

The account impersonated depends upon the authentication mechanism you are using
for the web app. If you are using Anonymous (no) authentication then the
impersonated account is IUSR<machinename>. If you use Basic, the impersonated
account would be the user account authenticated via the login dialog. If
Integrated Windows authentication is used, then the account authenticated and
impersonated (transparently) would be that which is logged on to the client
Windows machine that is making the request.

As I previously mentioned, if impersonation is not enabled, then the ASPNET
account is the default under all authentication mechanisms (under Windows 2000).
The below link provides a bit more detail.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetap05.asp

There is also extended impersonation which uses the LogonUser API function call,
but this requires some additional security configuration to use and I don't
recommend it. Another link, I've posted below, will provide a more thorough
explanation of how security works under ASP.NET.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/authaspdotnet.asp

Hope this helps.
________________________________________
From: Nathan H. Smith [mailto:xxx]
Sent: Friday, January 14, 2005 1:27 PM
To: xxx
Subject:

What user does it impersonate? Does someone have to be physically logged into
the machine for it to work?
<<

Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Joe Kaplan \(MVP - ADSI\)]

And I assume you are not supplying credentials to your DirectoryEntry
objects? In that case, it boils down to 2 things:
- Leave anonymous checked, enable impersonation in web.config and change
the anonymous account in IIS to an appropriately privileged domain account,
or
- Change the Application Pool identity for the AppPool for this application
in IIS to an appropriately privileged domain account and ensure that
impersonation is disabled in web.config

Either will work.

BTW, a helpful technique in for figuring out the identity of the current
thread is to call
System.Security.Principal.WindowsIdentity.GetCurrent().Name. That will tell
you the account that S.DS will use to access AD (unless you supplied
specific credentials to the DirectoryEntry as otherwise noted above).

Cheers,

Joe K.

 

[Nathan Smith]

What if I'm able to supply the username and password to the DirectoryEntry by
retrieving those values for a web.config file? would that work?

 

[Joe Kaplan \(MVP - ADSI\)]

Honestly, that's why I use in my day to day work 90% of the time.

Just use the full constructor for your DirectoryEntry objects:
new DirectoryEntry("LDAP://whatever", "domain\user", "password",
AuthenticationTypes.Secure);

I find this approach to be much simpler than dealing with the security
context issues, as long as you can keep the credentials you supply secure
enough for your needs. Think about that part carefully though.

Joe K.