We have over 1000 users already in our DNN portal and have been using a different method of automatically logging our users in but wanted to start looking at potentially using the AD provider (because of linked documents, etc).  The problem is our users do not have the domain prepended (ie., MyDomain\MyUser; ours is just MyUser).  So now, on our staging site if I access it it creates a new login for my using "MyDomain\Me" and I still have another login as "Me".  Obviously this is bad since I have literally hundreds of records on the intranet linked to my userid from "Me". 

Now I realize that I could solve this simply by running a SQL command to go through and add "MyDomain\" to the beginning of all logins on the portal except for our host and admin accounts, but I'm not exactly in love with that idea.

Thoughts?

That makes sense and I can understand the possible repercussions.  As a suggestion it could be a feature that an end user could turn on or off, and you could allow "wildcard" stripping (like anything that begins with someDomain* or regex stripping, etc).  Maybe even only strip the domain if the user is coming from a certain range of IP addresses?

As I started thinking about the problem we were facing here at work and possible solutions I actually came up with a solution to our problem that wouldn't require switching authentication providers.  The SW.AutoLogon module has a Windows/AD mode (which we've been using) but our problem was linking to secured tabs/files via newsletters/emails.  Then it occurred to me (and it was a complete DUH! moment) that we should create our own login page, drop the Account Login module on there (just in case) and an instance of the SW.AutoLogon module; any attempts to access protected content without a login would redirect to that page, the SW.AutoLogon would pick it up, log them in, and redirect back to the requested page.  Same theory would of course apply with the core DNN AD Provider.

Anyway, since we were already using the SW.AutoLogon and only missing that minor piece it was easy to put that on there and fix it.  The SW.AutoLogon module can handle domain stripping (along with the wildcarding I mentioned above) so it worked out good for us.

Additionally we perform an import every week from our HR software to pull in new users and changes for old users (including department transfers, terminations, etc; import contains all sorts of employee data that other custom modules feed from).  Our import module handles all the security roles (because our AD roles are completely different from our DNN roles and we want to keep it that way), etc., so it makes for a great combination. 

I dunno, we may still want to switch for the auto creation of users just in case somebody tries to access the intranet before HR imports them (which has happened on several occasions).  I think I'll email you direct to talk about the domain stripping.  BTW, the source download doesn't appear to actually have source in it. :)

*EDIT* The source is in the source package, as a SourceFiles.resources.  I just wasn't expecting to find it packaged that way and overlooked that file.  Oops!