It's because it always checks against the AD for the password. If you change the password in your DNN profile it isn't written back to the AD.

Ahhh okay, I know what's happening. When you launch the site as you normally do the site uses the WindowsSignin.ascx which automatically checks against the AD and logs you in (it doesn't care what password is stored in DNN). When you click on the Login button after having logged in and out as the Host user DNN uses the regular Signin.ascx. The code checks the database to see if the account exists (which yours does obviously). If it exists then it doesn't ever check back against the AD and uses whatever password that's stored in the DNN database. I understand why the code was written that way because it speeds up logins but it causes issues if you're running a site in mixed-mode which you have to if your site has non-domain users visiting from over the internet. That was one of the things that I changed when I updated the DNNUpdate Fix for 4.3.7 and 4.4.0 because roles weren't being synchronized if DNN was running in mixed-mode. It now checks if Authentication and Synchronizing are turned on then checks the Username for the Domain\Username format and if true then uses the WindowsAuthentication procedures (which will check the password against the AD instead of the DNN database).