This weekend we had a customer whose AuthAnvil server went into a fault condition after they accidentally changed the password of the AuthAnvil database user without considering the impact of that decision. I thought it might make sense to share with the community why it’s a BAD idea to be playing with the “AADBUser” account if you do not know what you are doing with it.
Let’s start with some background. Back in the old AuthAnvil v1 (way back in 2004) days during initial threat modeling it was determined that to help reduce the attack surface of AuthAnvil on Windows Server 2003 the use of least privilege would be ideal. So we created a restricted user in Windows with only enough privileges to access the SQL Server (using Mixed Mode auth) and the application directories, which were controlled through strong ACLs. We would ask the administrator installing AuthAnvil to provide the username and password they wished to create, defaulting to the name of “AADBUser”. It was a great architectural decision that took security in mind to apply least privilege; it was a poor practical decision because most administrators don’t have the discipline to document change management properly and store passwords in a safe manner. (We hadn’t released the AuthAnvil Password Server yet ) The result was that during upgrades where the installer would require a password to make any changes, the process would come to a grinding halt when the administrator “forgot” the password and had no clue what to do. At one point, we contributed more than 70% of our new cases created during an upgrade cycle to be on this one single condition… the administrator had no clue what AADBUser was or what the password was.
Seeing so many cases being created on what should have been a simple password entry field, we decided to go back to the drawing board. By the time AuthAnvil v3 was released the installer would read into your password policy of your domain (or on the system if it was not domain joined) and generate a random password to meet those complexity rules and then store this value in the Data Protection API (DPAPI) store where Microsoft themselves store passwords. This allowed us to protect the credential and get access to the password in a safe manner and still manage the account within our software. So we automatically create the account, set a strong password and mark the password to never expire so you don’t have to do anything with it. Meanwhile, we get the benefit of using least privilege with a restricted account you don’t have to manage.
Now, later this month when AuthAnvil Two Factor Auth v5 is released there will be a slight change to this. To account for the updated fault tolerance and clustering capabilities of AuthAnvil we have moved to using SQL auth for our interaction with SQL Server no matter if it's on-premise, or in the cloud. This allows us the ability to use SQL Azure Database which is already highly redundant and fault tolerant in Microsoft’s Cloud Services, for those customers who wish to use it. And we have moved the protection of the restricted account out of DPAPI and into a custom config section in the application with is encrypted to our standards to permit the control and access while using things like Network Load Balancing (NLB) in clustered environments.
It also has one other positive side affect. We are starting to move away from administrators breaking their AuthAnvil environment because someone accidentally does something like disable the restricted account, or change it’s password… without knowing the impact. Like what happened this weekend with one of our customers.
We can always learn from the experience of our customers. It is clear the more we can do to balance security and usability in a way that benefits both sides of the equation… the more we all win. If you have ever wondered what that section in the installer is doing when it says “Creating restricted user… please wait”… now you know. We are reducing the attack surface of your AuthAnvil environment by creating an account with the least amount of privileges to allow it to communicate with the resources it needs. Tampering with that account will cause the AuthAnvil system to collapse on itself and fail securely, not allowing you to do anything until the account is updated. If you are unsure how to repair that if you do accidentally do that, contact Customer Service at www.scorpionsoft.com/help. We have guidance and a simple tool in the Tools directory of the application that can do this for you.