Re: AD Login failure when using ActiveDirectoryMembershipProvider
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 22 Feb 2007 22:38:38 -0600
You are correct. The DirectoryEntry code just uses the current security
context. The provider uses DirectoryEntry as well, but they have code that
actually reverts back to the process identity before doing the directory
access.
AD can tell you what happened when the logon failed, but the problem with it
is usually that you don't have any access to the domain controllers if you
are a developer unless this is a test lab, so it makes it much harder. A
network sniffer is very helpful, although they are so low level that it can
take a fair bit of practice to figure out what you are looking at.
The way I figured this out was by using .NET Reflector to reverse compile
the assembly for the provider and looking at the source code. :)
I agree that Windows security can be painful. At least the newsgroups don't
suck when you have questions. :) I've been putting off learning about the
AD membership provider for a while as I haven't needed it in my own work so
far and we never got to it in our book, so the education is useful for me.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Craig Wagner" <MSDNNospam207@xxxxxxxxxxxxx> wrote in message
news:8D6F5F3B-548B-4FBE-A985-7EF9112AED5B@xxxxxxxxxxxxxxxx
That would explain it.
This is one reason I always have trouble with security-related items. If
I've got an app that's misbehaving when it makes database queries I can
always fire up Profiler and see what the heck it's doing when it connects
to
the SQL Server.
Is there any sort of similar tool so that I can monitor what identity my
app
is exposing when it makes resource requests?
It would also explain why the following, running in the same
configuration,
works just fine (and was adding to my confusion):
DirectoryEntry entry =
new DirectoryEntry( "myconnectstring", null, null,
AuthenticationTypes.Secure );
There probably is no 'magic' going on behind the scenes that is disabling
the impersonation.
"Joe Kaplan" wrote:
.
- References:
- Re: AD Login failure when using ActiveDirectoryMembershipProvider
- From: Dominick Baier
- Re: AD Login failure when using ActiveDirectoryMembershipProvider
- From: Joe Kaplan
- Re: AD Login failure when using ActiveDirectoryMembershipProvider
- Prev by Date: Re: 2 membership databases
- Next by Date: Re: Getting GROUPS from Active Directory by inputing an AD username
- Previous by thread: Re: AD Login failure when using ActiveDirectoryMembershipProvider
- Next by thread: Re: AD Login failure when using ActiveDirectoryMembershipProvider
- Index(es):
Relevant Pages
|
|