Hi Mike,

I went ahead and unregisterred my account from the parent and every child portal. Then I ensured every trace of my user account in the aspnet_Users and aspnet_Membership tables was deleted. When I reactivated the authentication module I was immediately logged into the first child site I reenabled. However, I can no longer log into any other site associated with this installation of DNN. Every attempt gives me the following errors;

1. A User Already Exists for the Username Specified. Please register again Using A Different Name. (There's no user by this name in this site's User Account database)
2. Login Failed, remember that Passwords are case sensitive.

As a test I unregisterred from that site and reactivated authentication on the parent. My account was created, but I could not create a new account in the previous site I just unregisterred from.  I have 4 more sites that I have not upgraded yet; they are ALL still comfortably parked at version 4.4.1.  Each of my sites have at least 20 children, so I would be a willing candidate for testing now that there's adequate visibility on the issue.

And since the core is watching these threads PLEASE NOTE: EVERYONE begins with the same letter when you use AD Authentication (e.g. DOMAINNAME). A more practical solution would be a concantenation of LASTNAME, FIRSTNAME MI and give us the option to choose the displayed fields in the User Accounts module. I have Thousands of accounts that start with my DomainName and the REAL BAD thing is, it's NOT ordered! This is very annoying.

Same here, I had about 4000 of those buggers all in the same letter of the user list.  I couldn't search for them by partial name either for some reason, I had to type out the entire DOMAIN\username format to find it using the search (took too long to page through them all).

Anyways, I wanted to mention that for future design it might be a good idea to remove the domain from the username entirely, make it a seperate entry in the user table (or special AD table).

Hi, just want to share my experience with the fix. In my current environment, we have a single portal with about 400 users. Prior to upgrading to 4.5.1, AD single sign-on was working properly in 4.5.0. After upgrading to 4.5.1, single sign-on no longer worked and users were required to login manually.

Based on what mikeh suggested, I checked my Users table and found that many of the usernames were in domain\username format. My own username though was in DOMAIN\username format. So I tested with my own username by changing to domain\username format. Then I tried to access the admin\Security\WindowsSignin.aspx page. I wasn't able to sign in automatically. Then I changed my username to the DOMAIN\username format and voila, I was able to sign in automatically.

I performed further testing with other accounts that were affected and these users are now able to auto-login after changing their username to DOMAIN\username. I then wrote a simple sql update statement to update all users with domain\username to DOMAIN\username. The statement is as below,
update users set username=case when charindex('\',username)<>0 then upper(substring(username,0,charindex('\',username)))+ '\' + substring(username,charindex('\',username)+1,len(username)) else username end)

 I hope anyone will be able to find this useful in applying the fix.

Thanks and regards.

(