Mike, et. al:
While I certainly appreciate all efforts to make the AD provider a great way to connect, I have researched this module very deeply and have found a number of issues and concerns.
For the last two weeks and a little over a hundred hours with this provider, I found that it is nearly impossible to connect to an external ldap provider. For instance, I have a DNN instance that I want to connect to a separate AD/LDAP source outside the domain that DNN is installed. (the DNN server is in a DMZ, and the AD server goes through a special port to our AD server which contains the private AD server.)
Willing jumping into the code (that's where the 100+ hours came from), I quickly was overwhelmed with the amount of calls to the Configuration class.. both with the AD and the ADSI configuration classes. If one is to step through the code, one will notice that there are nearly 50 calls to the configuration object's GetConfig() method. When it pulls from the cache, the cache is, nearly every time, set to nothing. (Recursion anyone? -- the call to GetConfig creates a call to itself to set the cache.)
Under the new world of Windows Server 2008, logins may have to contain the suffix @mydomain.com in order to login....wait… let me back up a moment...
Our goal is not to have internal domain users login necessarily... nor single sign-on (SSO) We want our users to login using their email address. @ signs and .com (or any .xxx (top level domain) doesn't seem to work. Why Myfirstname.lastname works I have no idea. But make note that the sAMAccount (pre-Windows 2000) login is a random hash now and I don't know why Microsoft decided to do it that way.
So, we want our users to be authenticated against AD via LDAP://dc=mydomain, dc=com. The GC:// nor LDAP://rootDSE because the DNN server is not a part of the domain it's attempting to authenticate against.
After many hours of attempting to fix the "target" LDAP:// vs GC issue, I gave up in the interest of time.
So, with that said, may I recommend that the AD Provider be rewritten (seriously). I know the AD provider has gone under a number of changes over the years, so I understand (I'm not trolling, I promise); but seriously, the code is very difficult to follow, (I'm a seasoned developer and I had to make a map of all the calls and I still got lost... the Configuration class is reported as ambiguous by VS2005.
Here's my recommendation (if you don't mind), I think it will help the overall project.
--Start from scratch to avoid
--Refactor the Configuration class and give it a new name that doesn't clash with the ADSI.Configuration class.
--Pass in the PortalProperties and the Configuration class where it makes sense– cuts down on literally about 50 calls to getconfig() and GetPoralSettings().
--add a private property _config to hold the configuration where needed to avoid the dreaded GetConfig() Maybe make the Config a static class (it seems like that was the original intent of the class by looking at the older code.. but not sure).
--step through the code, and you'll see what I'm talking about.
--Allow root domain to be: LDAP://x.x.x.x/dc=mydomain, dc=com
----when ldpa:// is used in root domain, avoid running to gc:// or ldap://rootDSE
--See what's up with the cache-- never really worked for me and I ended up with recursion.(that's when I gave up.)
--please consider starting from the ground up... (if you haven't already. :-)
Also, (some good news) the Windows200 on IIS/7 seems to work fine. (Oh, that reminds me.. the check pipeline method is called every page call!)
MOST IMPORTANTLY, LOGON_USER (or whatever it is) will never be set because our users are external and will never be logged into the network. The popup box to login cannot be displayed.
Why am I writing this? Because, I'm seeing an increased need for external logins to be authenticated via AD. The source for AD/user info may not be in the same domain as the DNN server (in most cases for security reasons). I did get the AD server to authenticate using the Secure (not delegate) mode and it worked very well -- I just couldn't get around the Configuration, GetConfig(), ADSI.Configuration, issues.
I'm very passionate about this project, however, it needs some help. Hopefully the community can help.
If you would like to discuss this further, just let me know... (if you want, register at www.landango.com and we can discuss.)
Thanks Mike!