It pulls the email from the Active Directory user object so if there isn't one specified there it won't fill the email address. At some point Tam (the original coder) was automatically creating the email if one didn't exist or he planned to and never did and I didn't notice that wasn't happening until very recently. So yes it is supposed to work like that but it doesn't work.

That said, I have run into instances where the AD provider won't pull all the information it that it should which is one of the reasons I'm looking at a complete rewrite of the code take advantage of extensions made to the System.DirectoryServices class in .NET 2.0. However I haven't run into situations such as you were having when fields weren't pulled in.

Mike,

I've installed the Beta on a 4.8.1 ddn portal. After following the instructions in the 01.00.02 I encountered errors when testing the settings.

Accessing Global Catalog fails, Checking the Root Domain is ok but the accessing LDAP fails as does the Find all domains in network.

The error message that gets displayed is as follows: Could not access LDAP to obtain domains info. Logon failure: unknown user name or bad password.

I've spoken with our Systems Admins and they assured me that the user account I was using definately has Permission to read access to the Active Directory.

We also tried using several Domain Admin accounts with the same results.

I thought it may have had something to do with needing to use the identity impersonation. I modified the web.config file but then I couldn't access the site at all.

Any thoughts?

Adrian

Adrian,

First, let's take DNN out of the equation make sure the server can contact the AD. Take a look at Softerra's LDAP Browser (http://www.ldapbrowser.com/download.htm). If you can connect and get domain user information through there then we know the problem is in the AD provider connecting to the AD.

Second, if the connection does work through LDAP Browser. We need to try impersonation. I cover this in the documentation but basically the user account you use for impersonation needs to have the same rights as NETWORK SERVICE does on the DNN install. That part is covered in the documentation. Now here's where I think I may have made an omission in the documentation and need to test to verify. I think that same account also needs to have the same rights to <SystemDrive>:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\<DnnInstall> directory. That should take care of the errors you're seeing when you use impersonation.