I was experiëncing the same problem. Since I did find out what's causing it and since it so seems the solution isn't available yet on this forum (or anywhere else on the internet, for that matter), I'm kicking this topic back up, for those stumbling upon the same problem in the (near) future.
When the AD provider is freshly installed and you try to configure it whilst not setting a "Password" ("User Name" not even necessary), it doesn't create an "AD_AuthenticationPassword"-entry in the "PortalSettings"-table. When that entry is not around, the AD provider doesn't, for some reason, ever read and use the "AD_DefaultDomain" and "AD_SubNet" entries. This is strange, since it DOES change those fields to new values, each time the AD-providers' settings are changed in DNN.
Well anyways; now that we know the cause, the solution is easily guessable; to enter a user password in the "Password"-field, then update. It doesn't matter whether or not you enter a valid password for the configured domain. Heck; I'd even advise you to use a random, bad, password. That way, the hash stored in your database is useless to people with bad intentions, in case someone like that ever finds his/her way into your database. Well anyways; after the update, it generates the missing "AD_AuthenticationPassword"-entry, causing the "Default Domain" and "Auto-login IP Address"-fields to work as expected 
You may want to fix this in your next AD-provider version, Mike. It's obviously a bug 