Very odd. Did everything work okay in DNN 4.5.3 (the 01.00.00 provider is essentially the same code just separated from the core)? This isn't on a multi-portal AD install is it? There are issues with automatic logins but I haven't seen them with manual logins.

Under the Standard option no it doesn't check the AD and I may have misspoken earlier. I'll have to check my code but, now that I'm more awake than I was earlier, I do believe I changed the code to validate against the AD everytime and if the password was different to update it in DNN.

I am experiencing the same issue. Most accounts are created automatically, but there are several that do not. I have disabled anonymous access on the server and directed traffic through the /logon/windows/default.aspx page.

Also, I am using a multi portal install and it seems that if the user id is created on one portal, sometimes it doesnt get created for the others. I can go into the PortalUsers TABLE and manually add a record that associates the UserId with the PortalId; but this is much too time consuming.

I wonder if it has something to do with the AD account? Maybe DNN is looking for a property in the LDAP record that is NULL and the ADSI provider fails to call the create user method. I have thought about building a custom provider that accepts a connection string parameter and field mappings to use an external User Store. Then you can call "server.variables("LOGON_USER")" or some other method to get the current user and pass the ID to the user store to get user properties.

I downloaded the beta and installed it to a development site to test. So far, so good, but there was no previous AD provider on the development server.

To replace the 01.00.00 provider on the production server, do I just uninstall the old one and install the new one? Or is there additional steps I should take?

BTW - Thanks a bunch for all the contributions you have made! You have really made my life easier!