NateDawg

 

The way I think it works it that when a user logs in for the first time they are authenticated against AD, then
the username and password they typed in get put into the database. So, it matches what’s in AD, but it was
supplied by the user.

hmmm - It will be interesting to see what Tam says.   I think if you first don't create the user in DNN then Tams module just gets the username and puts it in the database on first logging in.  It doesn't (shouldn't) use the password when authenticating users from then on, therefore there should be no point in getting it.  The exception might be when wanting to implement 'mixed' authentication where a username and password is required.. I'm not sure how that woud work...

NateDawg

“I bet if you change the password in the database, you'd still be able to log into DNN using Windows Auth.”
Correct, and it will overwrite the password in the database when you log in, with the one in AD.

I don't think it does... Well I hope not..  Why would it need to?  It doesn't need to check the password when using Integrated Auth so why update the password?  I've never manually created our users in DNN and the passwords are definitely not in the database... - Well, according to what was returned using the 'Email password facility I discussed earlier..  

Nathan, could you do a test for me as I'm keen to get to the bottom of this.. Could you log into your portal using an account that doesn't already exist in DNN, using Tams module in Windows Auth mode (therefore the account will be created automatically).   Then use that email password function and see what it returns?

Cheers,
Andrew