Refer to the roll-up below for continuity.
Looking at ADSIProvider.VB and Configuration.vb, I find that the ADSI_lastname and ADSI_firstname references are in Configuration.vb and appear to be pointed to the appropriate places as I listed below. I don't really understand .NET well enough to say that it is pulling from the right places and since things are not ending up in the right places, I suspect there is a problem somewhere else. Perhaps Private Function GetSimplyUser is being invoked.
All of which points me to something I pointed out in another post elsewhere. When I configure my domain, I don't see any OK's in GC, LDAP, or Root Domain. Since I am using the same entry I used in 3.? (where I did get OK's) I have been assuming there is a problem here somewhere. Since nothing works in terms of a domain/username/password combo, I've just been thinking of it as a bug. Perhaps it isnt?
To roll-up the relevent posts, I quote myself:
"In my case it seems to pull the first name from sAMAccountName. The last name is the domain, there is no display name and the email address is the SAMAccountName with the @domain.com concatenated. I would think that SN would be used for last name; givenName for the first name; displayName for the display name and mail for the eMail. For smart card use it would also be useful to have distinguishedName in the DB as well."
"I should go further to say that I am dumping every fieldin AD and don't see a lastname or firstname. From my experience, those fields don't exist."
"msdn2.microsoft.com/en-us/library/ms675090.aspx lists all the attributes and I don't see it there either. It is possible that these are from a structure defined outside of ADSIProvider.vb I guess. I'm not yet familiar enough with .NET to figure that out. Looking through the data structure I wonder where the distinguishedName is being written?"