Wait!  Wait!  You were right - you're brilliant!
I just didn't wait long enough - DNN must cache this table or something because I changed several of the settings and tested it and still couldn't get into the pages.  But the next morning I could.  So I changed the rest - waited about an hour and they all work.

Now the quesitons are:
1) Are these pages now insecure from someone who knows how to manually create the appropriate URL

2) How do I fix the real problem - IE is this a permissions problem somehow?

3) Once fixed, what caused this and how do I keep it from happening again?

Thanks Sebastian,
I'm not aware of any updates applied between the time it worked and failed.
The only event I can find in the logs before I discovered I couldn't get into the Admin pages was the one below - which still happens any time someone tries to register.  I'm going to start a new thread on it.

Message: DotNetNuke.Services.Exceptions.ModuleLoadException: Mailbox name not allowed. The server response was: sorry, your mail was administratively denied. (#5.7.1) ---> System.Net.Mail.SmtpException: Mailbox name not allowed. The server response was: sorry, your mail was administratively denied. (#5.7.1) at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response) at System.Net.Mail.MailCommand.Send(SmtpConnection conn, Byte[] command, String from) at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, SmtpFailedRecipientException& exception) at System.Net.Mail.SmtpClient.Send(MailMessage message) at DotNetNuke.Services.Mail.Mail.SendEmail(String fromAddress, String senderAddress, String toAddress, String subject, String body) at DotNetNuke.Services.Mail.Mail.SendMail(UserInfo user, MessageType msgType, PortalSettings settings) at DotNetNuke.Entities.Modules.UserModuleBase.CompleteUserCreation(UserCreateStatus createStatus, UserInfo newUser, Boolean notify, Boolean register) at DotNetNuke.Modules.Admin.Users.ManageUsers.UserCreateCompleted(Object sender, UserCreatedEventArgs e) --- End of inner exception stack trace ---

Came across this after upgrading from DNN 5.6.3 to DNN 5.6.8. Updating the IsSecure value (telling it to NOT use SSL which isn't even configured for that site) and restarting the application (had to do this in IIS) took care of it.
SQL statement is: UPDATE Tabs SET IsSecure=0 WHERE IsSecure=1