MembershipProvider, ADAM and userProxy

[Guest]

Hello,
I finally got my POC to work. I have some users in ADAM and I can browse
and validate using the Membership provider... Cool!!!!

Except that if I have a user of userProxy class in ADAM, my provider
does not see it. After doing much reseach (googling is the new term) I think
I understand why. The AD Membership provider looks for user class, not
userProxy class. That make sense.... still how can I see/manage my users.

Unless someone has a miracle cure for this, I'll have to write my own
member ship provider for ADAM.

All comments are welcome.

-Martin

 

[Steven Cheng[MSFT]]

Hello Martin,

It seems you've got the basic stuff of AD membership provider working (the
issue you posted in the previous thread).

As for the new problem you mentioned, I'd like to confirm the class
(userProxy and user) here, is it the OU in AD? Based on my local test, it
is possible that different AD objects like users are stored in different
OU. What's the current AD connectionstring you used?

If the problem here is that the users are under different OU which can not
be covered by a single connectionstring(such as authenticate users in
different domains), you can consider define multiple membership providers
in code and programmtically determine which one to use (all use all of them
on by one). Here is a MSDN tech article discusing on authenticate users in
multiple trusted domains through the AD membership provider:

#How To: Use Forms Authentication with Active Directory in Multiple Domains
in ASP.NET 2.0
http://msdn.microsoft.com/library/en-us/dnpag2/html/paght000021.asp?frame=tr
ue

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Joe Kaplan]

I haven't looked at the code in the provider to know if there is something
easy you could just override to make this work, but one thing that did occur
to me is that you could just rename the userProxy class to user and change
user to something else in ADAM. It would be confusing, but it would
probably work.

Joe K.

 

[Guest]

Hi Steven,
The problem is that the AD membership provider only the 'user' class.
ADAM manages, on top of the user class, a userProxy class. This userProxy
class is not recognized by the AD membership provider... hence I have a
problem.

Thank you for your help Steven

-Martin

 

[Guest]

Thank you Joe,
That helps to know that I am rigth... sometimes.

I like your solution but in our solution we want to use both user and
userProxy. I have already started working on an ADAM membership provider...
If you have any pointers I'd be more than happy to listen.

Thank you

-Martin

 

[Joe Kaplan]

Ah, I see. That is a bit of a PITA. It sounds like you are building an
extranet scenario or something (some users in AD, some in ADAM, integrated
in ADAM via bind proxies and simple bind).

I wish I could help more with this, but I don't know what you need to do.
However, I do know the providers are designed to be inherited from, so
perhaps you can do that and just modify the piece you need via an override.

You might also consider using reflector and the file disassembler plugin to
reverse engineer the existing one so you can easily recompile a small mod.
Might save you some time (if overriding isn't an option).

Best of luck!

Joe K.

 

[Steven Cheng[MSFT]]

Hi Martin,

Yes, you're right. After lookup the diassembly code of the
ActiveDirectoryMembershipProvider, I found the following code fragement
which hard code the DirectorySearcher's filter as (objectClass = user):

===============================
private MembershipUser FindUser(DirectoryEntry containerEntry, string
filter, SearchScope searchScope, bool retrieveSAMAccountName, out
DirectoryEntry userEntry, out bool resetBadPasswordAnswerAttributes, out
string sAMAccountName)
{
MembershipUser user1 = null;
DirectorySearcher searcher1 = new DirectorySearcher(containerEntry);
searcher1.SearchScope = searchScope;
searcher1.Filter = "(&(objectCategory=person)(objectClass=user)" +
filter + ")";

...............................

}
================================

So I agree with you that building a custom provider would be a reasonable
solution. Also, you can even make it more flexible(add more configurable
options) so that it can fit more scenarios.

For building custom membership providers, here are some good reference
maybe helpful to you:


#Source Code for the Built-in ASP.NET 2.0 Providers Now Available for
Download
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx

#Provider Toolkit
http://msdn.microsoft.com/asp.net/downloads/providers/default.aspx


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thank you Steven,
Your help is appreciated.

-Martin

 

[Guest]

Thank you Joe,
I have already started to work on the provider, pretty simple in fact.


-Martin

 

[gely]

Guys,

Although I am a bit late getting to this party, I am driving the same
road.

Question: Where is the source for the ActiveDirectoryMembershipProvider
class? The link for the "Source Code for the Built-in ASP.NET 2.0
Providers" (so gractiously supplied by Steven Cheng) includes code for
the SQLMembershipProvider class, but I can't find the one for AD.

Am I missing something?
Am I looking in the wrong place?
.. or am I just asking for something that isn't yet available?

- Thanks,
gely -

 

[Joe Kaplan]

I don't think they published that one and I don't know why. However,
remember that you can always reverse engineer anything in the framework back
into source in your language of choice using reflector and can get real
files with the file disassembler plugin.

Joe K.

 

[gely]

Joe et all,

As suggested, I used reflector to create a custom membership provider -
with no changes to the original logic. It took more than a little
effort (seems like I had to disassemble and include almost half of the
original classes), but I finally got it to build and handle calls.

Using it in place of the ActiveDirectoryMembershipProvider in the
web.config file allowed for the authentication of ADAM users.

I then modified the filter for the DirectorySearcher to be:

searcher1.Filter =
"(&(objectCategory=person)(|(objectClass=user)(objectClass=userProxy))"
+ filter + ")";

I can still authenticate ADAM users, but the result for the AD users is
the same (unsuccessful login attempt) - and there is no trace of an
attempted authentication in the domain logs.

Do you think this could be a result of a needed property that the user
class has that the userproxy class does not?

Not sure how to proceed. Any suggestions would be helpful.

- Thanks -

 

[gely]

Ok: A bit more testing, and I find that, although I am calling my
assembly as the membership provider, I don't seem to be using it. Let
me explain:

If I rename or remove my assembly, or rename my custom membership class,
I receive an expected error from .NET.

If I change only the filter value, even to jibberish, .NET successfully
authenticates to ADAM.

This tells me that I am looking to my assembly for instantiation, but,
apparently, calling methods from elsewhere.

I created my custom provider by inheriting from the
ActiveDirectoryMembershipProvider and then overriding the FindUser
method. The rest of the code in my assembly is simply to support this
method. The new assembly lives in the bin directory of the .NET web
site.

Where'd I screw up? (Or is the better question "Where didn't I screw
up?"?)

- Thanks,
Geoff -

 

[Gary Murchison]

Gely,

I looking to do a similar sort of thing... did you get your questions
answered?

One thing I'm unclear on, you say :

"I created my custom provider by inheriting from the
ActiveDirectoryMembershipProvider and then overriding the FindUser
method."

....however the FindUser method of ActiveDirectoryMembership provider is
private and therefore can't be overridden by your custom provider. Am I
missing something?