There are still two items on the todo list:
- DNN User account passwords. Since AD uses a one way hash for password and you cannot, nor would you want, to retrieve the users actual password, we need to figure out how to best handle passwords in the DNN database versus AD. Some installation may wish to have DNN change the AD passwords to keep them “in-sync“, however in many corporate environments, this is not a valid option.
This leaves us with a couple of options. - Tam's WA modifications enter the string “password“ as the password for all accounts. This was done since the DB does not allow nulls for password and you cannot read the AD password. Obviously when using a “mixed-mode“ authentication scheme, this is less than desirable.
- Upon user account creation, a random password is generated and created for the user in DNN. If the user ever needs to access their portal using forms authentication, they may use the “send passwrod reminder“ option to get the password. They may change this to whatever they wish. Negatvie aspects include this password possibly being different than the users AD password. There is no synch mechanism to AD.
- How to handle Windows Authentication Failures. What I mean is there are a couple schools of thought so far. If the automatic Windows authentication fails, we allow anonymous access. User then clicks login link and enters username and password. Two thoughts on the next steps are:
- Attempt to authenticate against AD using the form entered credentials. If access token granted, set the security principal and log user into portal as the ad user. If fail AD forms authentication, then attempt to match against DNN Users table as the normal DNN functionality works.
- Windows authentication is automatic or does not happen at all. Form credentials are only matched to DNN Users Table.
Still working on the best scenario but I believe we are going to approach this a bit carefully. More to come....
No comments:
Post a Comment