SQL Server Container Linux - Login failed for user 'sa'

7/13/2018

I am trying to follow the tutorial here:

https://docs.microsoft.com/en-us/sql/linux/tutorial-sql-server-containers-kubernetes?view=sql-server-linux-2017

As directed in the tutorial, I create a kubernetes cluster and deploy a the linux sql server container.

I create the secret, as in the link above, and can use **kubectl get secret ** to decrypt and verify the contents, as directed in the link here: https://kubernetes.io/docs/concepts/configuration/secret/

I use a persistent volume, along with a persistent volume claim, and deploy the sqldeployment.yaml, as in the link above.

I attach to the container using kubectl attach -i -t and I can see the log stream.

When I try to log in, it says

**SQL Management Studio:** 
Login failed for user 'sa'. (Microsoft SQL Server, Error: 18456)

**kubectl attach output stream**
Error: 18456, Severity: 14, State: 8.
Login failed for user 'sa'. Reason: Password did not match that for the login provided.

I have tried all manner of passwords, including the one on the microsoft tutorial link, above.

Question: - How do I set up a linux container, with the correct password, so that I can log in to the SQL Server, as directed in the Microsoft tutorial above? - Any pointers on what I might be doing wrong?

-- Banoona
containers
docker
kubernetes
linux
sql-server

2 Answers

8/4/2018

The answer is that I was using a Kubernetes persistent volume to store the database files. I had probably stored the wrong password by initialising it once into the master database, the data for which is stored in the persistent volume.

Upon altering the password stored in the Kubernetes secret and redeploying the sql server service numerous times, I was confused that the password did not get reset, and I remained unable to login. Once I had removed the persistent volume and persistent volume claim, I was able to reset the password and reinitialise it properly because the master database had been effectively reinstalled.

It appears that once the password has been initialised at startup, it gets stored in the master database on the persistent volume. Therefore, changing the Kubernetes secret - wbich stores the value of the password for the purposes of ONCE-OFF initialisation - has no effect.

The above scenario is easy to understand, but can be very confusing.

The solution was to delete the persistent volume (pv) and peristent volume claim (pvc), which effectively deleted the data files, including those of the master database, where the password is configured on the server.

-- Banoona
Source: StackOverflow

8/4/2018

Your password must meet the password policy. I copy this from the official Microsoft website.

Password complexity policies are designed to deter brute force attacks by increasing the number of possible passwords. When password complexity policy is enforced, new passwords must meet the following guidelines:

The password does not contain the account name of the user.

The password is at least eight characters long.

The password contains characters from three of the following four categories:

Latin uppercase letters (A through Z)

Latin lowercase letters (a through z)

Base 10 digits (0 through 9)

Non-alphanumeric characters such as: exclamation point (!), dollar sign ($), number sign (#), or percent (%).

-- dhani
Source: StackOverflow