AD(Active Directory) authentication for SQL Containers on Azure Kubernetes Service (AKS)
Published Sep 13 2021 06:36 AM 11.2K Views

In this blog today, let's configure AD (Active Directory) authentication for SQL Server containers running on Azure Kubernetes Service (AKS). Same steps can be followed for SQL Server containers deployed on other kubernetes environments as well.



  1. Create an Azure Vnet and add a virtual machine to the network as a domain controller.
  2. We will use another machine (in this case, an Ubuntu machine) that is added to the above-mentioned network and joined to the domain to create the required keytab file for SQL Server container.
  3. Then, create an Azure kubernetes service cluster with network plugin set to Azure CNI and connected to the Azure vnet created in the preceding steps.

Current Environment details & Setup:

In this environment:-

  1. I've created an Azure Vnet (aksvnet2) and a VM ( as the domain controller with domain named: CONTOSO.COM.
  2. I then created an Azure kubernetes service cluster (akscluster2) with the network type plugin set to Azure CNI, resulting in the cluster being part of the Azure Vnet(aksvnet2). To create an Azure kubernetes service using the Azure CNI plugin, refer to this document. Once the cluster is created you would see the network plugin showing as Azure CNI as shown below, please note that the cluster is not part of the domain but only connected to the network.
  3. I also added another Azure VM Ubuntu 20.04 machine ( to the network and joined it to the domain, this machine will be used to generate the keytabs.amvin87_0-1631537502525.png

Now, we log in to our Azure VM machine (, which was previously created and added to the domain. If you need assistance creating the VM and adding it to the domain refer to this article. We'll use this machine to generate the service keytab, which we'll then copy to the container required for AD authentication setup.


Preparing for the deployment:

Before we can create the keytab we must first plan the container hostname, add the dns host entry for the container hostname and specify the internal load balancer IP address for the DNS host entry. The following are the configuration details for this blog:

  1. The container hostname will be: sqlinst1-0 ( I am going to deploy SQL container as statefulset).
  2. For the internal load balancer we will use the IP address that is available on the network, in this case the IP address from the vnet that I will be using is:
  3. The DNS host entry that I added to the domain controller before deploying the SQL Server container is shown below:amvin87_2-1631537502497.png
  4. The AD account that I will use in the keytab is : "sqluser".

With the above information, we are now ready to create the keytab on the Ubuntu machine. I download & install the adutil client on the server and then run following commands:

  1. We first proceed to create the user "sqluser" with the command:
    adutil user create --name sqluser --distname CN=sqluser,CN=Users,DC=CONTOSO,DC=COM --password 'P@ssw0rd!'​
  2. I also enable the AES protocol for the sqluser, which is needed when you don't want to use older protocols like RC4.amvin87_3-1631537502500.png
  3. Run the following command to create the spns:
    adutil spn addauto -n sqluser -s MSSQLSvc -H -p 1433​​
  4. We are now ready to create the keytab using the commands listed below:
    adutil keytab createauto -k ~/container/mssql.keytab -p 1433 -H --password 'P@ssw0rd!' -s MSSQLSvc
    adutil keytab create -k ~/container/mssql.keytab -p sqluser --password 'P@ssw0rd!'

With this, the keytab is ready and here is how it looks, note for this example I used RC4 protocol but for production environment you should not use RC4.



Time to deploy SQL Server container:

With all of the preliminary work completed, we are now ready to deploy the SQL Server container. I've included all of the deployment files below, along with explanations of the various parameters used:

  1. First, we create the krb5.conf configmap that will be mounted on the container and contains the relevant realm details so that the container can communicate with the domain. In my case, the domain is CONTOSO.COM, but the details will vary depending on your environment. The file is saved as krb5conf.yaml, so when I deploy this configmap, I run the following command:
    kind: ConfigMap
    apiVersion: v1
      name: krb5-conf
      krb5.conf: |
        default_realm = CONTOSO.COM
        CONTOSO.COM = {
          kdc =
          admin_server =
          default_domain = CONTOSO.COM
        [domain_realm] = CONTOSO.COM = CONTOSO.COM​
     kubectl apply -f "path to file>/krb5conf.yaml"
  2. We then create the mssql.conf configmap and like the name suggests this has the mssql.conf details that needs to be mounted. The file is saved as mssql.yaml and the command I run to create the configmap is :
    kind: ConfigMap
    apiVersion: v1
      name: mssql
      mssql.conf: |
        accepteula = Y
        accepteulaml = Y
        captureminiandfull = true
        coredumptype = full
        lcid = 1033
        defaultdatadir = /var/opt/mssql/userdata
        defaultlogdir = /var/opt/mssql/userlog
        kerberoskeytabfile = /var/opt/mssql/secrets/mssql.keytab
        privilegedadaccount = sqluser​
    kubectl apply -f "<path to file>/mssql.yaml"

Please note:I am adding the network related configuration details like the keytab location on the container and the privilagedadaccount to be used for SQL Server.

  1. Lets create the secret to store SA password and the command I use is shown below, please ensure that you change this to the SA password that you want to use
     kubectl create secret generic mssql --from-literal=SA_PASSWORD="MyC0m9l&xP@ssw0rd"​
  2. Using the yaml file below, we can now deploy SQL Server containers:
    kind: StorageClass
         name: azure-disk
      storageaccounttype: Standard_LRS
      kind: Managed
    apiVersion: apps/v1
    kind: StatefulSet
     name: sqlinst1
      app: sqlinst1
     serviceName: "sqlinst1"
     replicas: 1
       app: sqlinst1
        app: sqlinst1
         fsGroup: 10001
        - name: sqlinst1
          - /bin/bash
          - -c
          - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
          - name: ACCEPT_EULA
            value: "Y" 
          - name: MSSQL_ENABLE_HADR
            value: "1"
          - name: SA_PASSWORD
                name: mssql
                key: SA_PASSWORD
          - name: mssql
            mountPath: "/var/opt/mssql"
          - name: tempdb
            mountPath: "/var/opt/mssql/tempdb"
          - name: data
            mountPath: "/var/opt/mssql/userdata"
          - name: log
            mountPath: "/var/opt/mssql/userlog"
          - name: mssql-config-volume
            mountPath: /var/opt/config
          - name: krb5-conf
            mountPath: /etc/krb5.conf
            subPath: krb5.conf
        - ip: ""
           - ""
           - ""
           - "contoso"
       dnsPolicy: "None"
           - ""
           - "com"
         - name: mssql-config-volume
            name: mssql
         - name: krb5-conf
            name: krb5-conf
      - metadata:
          name: mssql
            - ReadWriteOnce
              storage: 8Gi
      - metadata:
          name: tempdb
            - ReadWriteOnce
              storage: 8Gi
      - metadata:
          name: data
            - ReadWriteOnce
              storage: 8Gi
      - metadata:
          name: log
            - ReadWriteOnce
              storage: 8Gi
    apiVersion: v1
    kind: Service
      name: sqlinst1-0
      annotations: "true"
      type: LoadBalancer
      - name: sql
        protocol: TCP
        port: 1433
        targetPort: 1433
      selector: sqlinst1-0​

We are deploying the following Kubernetes objects in this yaml file:

  1. Creating a statefulset deployment called sqlinst1
  2. Deploying the Azure disk storage class for persistent data storage and deploying SQL Server container.
  3. After that, creating an internal load balancer service with static IP (so the IP remains the same even after restart) called sqlinst1-0 pointing to sqlinst1-0 container.amvin87_5-1631537502503.png

Because my kubernetes service host nodes are not joined to the domain, I must provide domain-related information to the containers during deployment, which is why you see me using parameters like hostAliases, dnsPolicy, and dnsConfig. The IP address that is used in hostAliases.ip refers to the domain controller's IP address, while hostname refers to the domain controller's hostname. This adds the necessary entries to the container's /etc/hosts file. Similarly the dnsConfig settings add the dnssearch and dns nameserver entries of the domain and the domain controller respectively in /etc/resolv.conf file of the container.


During the container deployment, I load the mssql.conf and krb5.conf configuration files as configmaps. With this in place, we can now copy the keytab file from the Ubuntu server to the local client from which we are running kubectl, and then copy it from the local client to the container and restart the SQL Server container. To copy the mssql.keytab file from the client to the container, use the following command:




kubectl cp "certificate\mssql.keytab" sqlinst1-0:/var/opt/mssql/secrets/mssql.keytab




Where certificate is the name of a folder in my current working directory.

Note: To troubleshoot AD authentication issues, you will also need logger.ini, which can be copied to the container in the same way you copied mssql.keytab. The command to copy the file is: 



kubectl cp "certificate\logger.ini" sqlinst1-0:/var/opt/mssql/logger.ini



The logger.ini file consists of the following details :




To restart the container post the copy you can run the command: kubectl delete pod sqlinst1-0. This will delete and recreate the SQL Server container.


AD authentication in action:

After restarting the SQL Server container, you can now connect to it using the FQDN name of the container, which is the DNS host entry that was added in this case: "" After connecting, open a query window and run the following command to add a domain user:




create login [contoso\amvin] from windows.




Log in with this AD user now, and the AD authentication should work as shown below:amvin87_7-1631537502523.png





I hope this helps, and please let me know if you have any further questions! Happy Monday !!


Version history
Last update:
‎Sep 30 2022 06:31 AM
Updated by: