DNN has many ways to configure the SQL database based on the security that is needed. To make it easier to evaluate which security model to use, I have listed the possible scenerios and how to setup each scenerio.
Scenerio #1 (dbowner access, dbo)
You can keep the databaseOwner in the web.config file set to dbo and set the permissions for the user you are going to access the site with to only have db_owner permissions. This assumes that the default schema for the user that is used in the connectionString is set to dbo (if not, this will not work).
Scenerio #2 (non db-owner access, dbo).
You can keep the databaseOwner in the web.config file set to dbo and set the permissions for the user you are going to access the site with to only having db_datareader, db_datawriter, db_securityadmin and db_ddladmin permissions. This assumes that the default schema for the user that is used in the connectionString is set to dbo (if not, this will not work).
Scenerio #3 (non db-owner, execute only access, dbo)
You setup 2 users one with db_datareader, db_datawriter, db_securityadmin and db_ddladmin permissions and the other with not additional access except belonging to the public group. You then use the the user that only belongs to the public group for the normal connectionStrings and you use the one with the additional parameters in the upgradeConnection parameter. This is better than the 1st 2 because the everyday user that runs the site only has execute permissions on all the sprocs and functions. See my blog here about this setup. This assumes that the default schema for the users that are used in the connectionString / upgradeConnectionString is set to dbo (if not, this will not work).
Scenerio #4 (db-owner, {custom databaseOwner})
If you set a user as the databaseOwner in the web.config then it has to have db_Owner permissions. Otherwise setting it as databaseOwner in the web.config is not correct. Joe Brinkman has a great video about this setup posted here. To get it to work though, instead of giving the user that is set as the dbowner (ex: DNNdbo) in the DNN web.config db_datareader, db_datawriter, db_securityadmin and db_ddladmin permissions you have to give the use dbowner permissions
Scenerio #5 (db-owner, lmited or execute access only, {custom databaseOwner})
This is the scenerio where there is problems, but it can be overcome using the upgradeConnectionString. If you do the steps to implement Scenerio #4 and then add another user (ex: DNNUser) you can then either give this user db_datareader, db_datawriter, db_securityadmin and db_ddladmin permissions or you can only let them be part of the public group so it only has execute permisions. When you create the login for the user make sure you set the default scheme (login / user mappings) to the same schema you created in Scenerio #4. You then set the upgradeConnectionString to use the user that is the owner of of the scheme you created (ex: DNNdbo), and you set the normal connectionsStrings to the limite access user (ex: DNNUser).
Summary
DNN does support none dbo_owner support (Scenerio #2 & #3). DNN does also support non dbo support (Scenerio #5), but if you set the databaseOwner to a user other than dbo that user has to have db_owner permissions. So that your site does not need to run under this user you have to use the upgradeConnectionsString and have an additional user that is setup with limited permissions (set to use the same default schema as the db_owner user).