Alright,

So I have done a lot with DNN and Active Directory over the last few months (See DNN ADFIX http://www.getyourowntots.com/Projects/DNNProjects/DNNADFix/tabid/97/Default.aspx).

Anyway, I have gone farther with DNN and AD so that now I have the user's profile sync with all sorts of custom variables that I created in Active Directory.

It is pretty slick, but pretty dang static. 

I can see that in the future as we track more and more stuff with Active Directory we are going to want to use more and more custom attributes.  I don't want to have to recompile DNN everytime I want to add a new AD custom attribute to a profile. 

I have been thinking about this problem for a few weeks now and this is what I came up with.  Not sure about the feasibility of this, but maybe one of you will know.

Here is my thought:

Everytime DNN asks for a field out of a user's DNN profile I would have some sort of middle tier/provider that would intercept the request and query Active Directory for the value.  Then the middle tier/provider would return the value from Active Directory for use inside Dotnetnuke.

This method would eliminate the synchronizing of profile data between Active Directory and DNN. 

My thought is that using DNN's new User Profile Attributes you could create an attribute in DNN that matched an attribute in Active Directory, therefore whenever someone tries to access tha attribute from within DNN they will be simply passed along to Active Directory.

Does that sound reasonable? Doable? Could it be a Provider or would it have to be a core modification?

Brainstorming,

Stuart