Hi Mike.

Thanks for the feedback.

The main reason we've stuck with a module approach rather than a provider is that feedback from users was, as far as single signon goes, that  they just want to present one login option to users.

If we used the provider approach, then the  AD login becomes a tab on the standard login control and it's harder to separate out landing pages for DNN and AD users. And we can't disable the DNN login tab because there are times a system admin needs to login as a DNN host rather than as their AD identity. It's just more flexible.

We work very closely with DNN and they have no plans to bake AD into the core any more than Facebook, SAML or  ADFS authentication. (at least none I'm aware of). In fact, with vNext, you are going to see the platform trim right down.

We are pretty close to v3 (and no - I'm not committing to a release date  :)   ) and our approach has been to streamline the code, switch to client side frameworks and move to C# - we're actively preparing for vNext. This foundation is being used for other providers we have in beta for ADFS and Salesforce.

If you want to update AD, use our Profile Update module - http://store.dnnsoftware.com/home/product-details/active-directory-profile-updater-v2.

I'd appreciate some feedback from you. How do you think we can support the open-source community more? We're a commercial company and make a living and employ people off the corporate services we provide around implementing DNN for companies - especially intranets and secure communities. We'd love to be able to support the open-source provider more - but that goes against some of the commercial terms imposed on us. We have one customer who insists we don't make the source available to maintain the security of the product. And the reality is, the people who use AD are almost always companies and are implementing DNN so they can profit - so they should not have a problem paying.  That said, we'll almost always give a licence to not-for profits - they just need to ask.

Cheers

Ian