Add support for Kerberos/Active Directory/"windows" authentication

[EdiDD]

How to use windows authentication? Will assigning linux host to windows domain be enough for container to work with domain user authentication ? What can i do to achieve this ? I have windows server 2012 as active directory domain controller and debian 9 for docker.

[jovton]

docker run \
 --volume=/var/lib/sss/pipes/:/var/lib/sss/pipes/:rw  \
 --volume=/etc/sssd/:/etc/sssd/:ro  \
 --volume=/etc/krb5.conf:/etc/krb5.conf:ro \
 --volume=/etc/ipa/ca.crt:/etc/ipa/ca.crt:ro  \
 --volume=/etc/nsswitch.conf:/etc/nsswitch.conf:ro \
 --volume=/etc/pam.d/:/etc/pam.d/:ro \
 -h myubuntuhost.my.ad.domain ... etc, etc.

OMG! I think it works! The mapping of the volumes made a difference to me. Before that I couldn't do this:

CREATE LOGIN [DOMAIN\user] FROM WINDOWS;

It would tell me...

Windows NT user or group "DOMAIN\user" not found. Check the name again

But now, it works. Hmmm.

@lubo i think it need to be joined to the domain in order to create the service principles with setspn and ktpass and so on.

[jovton]

UPDATE: I still have domain trust issues though:

[turboaaa]

@jovton Switch to Azure Active Directory - Integrated authentication, and tell the client to accept the certificate.

[jovton]

@turboaaa what is the output of cat /var/opt/mssql/log/errorlog, assuming that is the configured logs location?

[turboaaa]

@jovton I don't have this configured in my environment at the moment, ended up just using a Red Hat VM for this. Working on other projects.

During the install on Red Hat I did run into some keytab issues, and had to make sure the kvno numbers matched up with the service account I was using. I have not gone back to the containers to apply the lessons learned.

[lubo]

@jovton What is a SPN and why should you care? makes me believe you don't need a computer account for that. Yes, in the example, the server is connected to a domain, but all the magic AFAIK happens on the domain account and nothing directly indicates that it has to be a computer account. But maybe I'm getting it wrong.

[jovton]

@turboaaa thanks for the hint. but i'm afraid Azure Active Directory - Integrated doesn't work either.

it could be that something is not right with either my AD domain controller setup and/or DNS (win server 2019 running in vm), or a problem in my krb5 / sssd conf files, or the self-signed certificate used in my mssql.conf created via openssl, or a combination of all those things. right now it's hard to tell and will take some deeper longer hours of investigation.

Re: SPN, you may be right. i have very little knowledge about these things and I'm still learning.

[turboaaa]

Under options, check the "Trust server certificate" under Connection Properties.

[jovton]

Under options, check the "Trust server certificate" under Connection Properties.

Thanks. I tried that, but still no luck I'm afraid. Same error (both Windows auth and Azure AD).

[turboaaa]

@jovton Went back over my notes, I never played around with certificates on my installation. Which is why I told my data analyst to force trusting it (not good practice, but the risk in this environment is very low.) I just wanted mssql to run on something that didn't need rebooting every week.

Can you build clean without importing a certificate?

[jovton]

This is from /var/opt/mssql/log/errorlog:

SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. The Local Security Authority cannot be contacted   [CLIENT: 192.168.200.1]

The certificate I was talking about is the one configured with the tlscert and tlskey variables in the mssql.conf file, so I think this is not related to the domain trust issues, and I'm not using connection encryption. I also haven't specified or used any certificates in the krb5 or sssd conf files. I used "realm" to join the domain and it said it was successful.

I also tried to "sync" the krb5.keytab and mssql.keytab files using ktutil, rkt / wkt, so they have the same entries. It doesn't appear to have helped.

I'm pretty new to docker and docker builds, I may not know what I'm doing so please bare with me 😸.

[turboaaa]

Did you use SPN or MSA? I had problems with SPN and ended up using MSA. https://michaelwiki.geekgalaxy.com/index.php/MSSQL_RHEL_7.7

[jovton]

Did you use SPN or MSA? I had problems with SPN and ended up using MSA. https://michaelwiki.geekgalaxy.com/index.php/MSSQL_RHEL_7.7

I use SPN. I haven't tried MSA yet, not sure how to proceed with that. I'll try the steps in the article/post. :)

It is very likely an SPN / keytab file issue, I will try to re-create them and double check the access to the keytab file for the container user. For now I'll wait to see if anyone else here has more luck before I comment any more, or until I myself have a breakthrough.

[jovton]

OKAY, some success!!!

i tried doing all things except not in a docker container, but via the stand-alone mssql-server installation, and then Windows/AD integrated authentication works beautifully. The problem is the date/time. When simply running the default SQL Server container image provided by Microsoft, the date command in the container reports UTC, while the host (joined to the AD domain) is on a different timezone, which will cause the untrusted domain issues. Now, to figure out if there some way to permanently set the correct date / time / timezone in the container so it it always the same as the host's...

[turboaaa]

Does this not work? -e TZ=America/New_York

Or mounting the local timezone file into the container?

[jovton]

Does this not work? -e TZ=America/New_York

@turboaaa I tried that, but doesn't appear to work. Trying to figure out if the tzdata package is installed in the container, and if not how to do that.

[jovton]

it appears MS has updated their images to account for the tzdata package dependency, so that is sorted.

but what i did wrong was that i wanted to read the host timezone into a variable and use it in the subsequent docker run command, but i used single quotes ( ' ) instead of double ( " ) to enclose the environment variable parameter values (for -e), so it did not pass the correct timezone into the container. the following was my setup and it works perfectly...

export TZ=$(cat /etc/timezone); docker run \
-e "TZ=$TZ" \
-e "SET_CONTAINER_TIMEZONE=true" \
-e "CONTAINER_TIMEZONE=$TZ" \
-e "ACCEPT_EULA=Y" \
-e "MSSQL_SA_PASSWORD=mysupersecretpassword" \
-e "MSSQL_PID=Developer" \
-p 1433:1433 \
-v /var/opt/mssql:/var/opt/mssql \
-v /var/lib/sss/pipes/:/var/lib/sss/pipes/:rw  \
-v /etc/sssd/:/etc/sssd/:ro  \
-v /etc/krb5.conf:/etc/krb5.conf:ro \
-v /etc/ipa/ca.crt:/etc/ipa/ca.crt:ro  \
-v /etc/nsswitch.conf:/etc/nsswitch.conf:ro \
-v /etc/pam.d/:/etc/pam.d/:ro \
-v /etc/timezone:/etc/timezone:ro \
-v /etc/localtime:/etc/localtime:ro \
-h ubuntu.mannetjie.net \
--user mssql --name "sql1" --restart unless-stopped \
-d mcr.microsoft.com/mssql/server:2019-latest

this assumes of course that the AD join was a success, keytab file setup was correct and mssql.conf reflects these things.

[gaborgsomogyi]

@jovton Do I understand correctly you've successfully set up kerberos on a docker based SQL server? I'm interested in how exactly it's done because I've to do the same. If you can share more details I would appreciate.

[turboaaa]

@jovton Do I understand correctly you've successfully set up kerberos on a docker based SQL server? I'm interested in how exactly it's done because I've to do the same. If you can share more details I would appreciate.

He mounted additional resources from the host that are generally locked down. Please note this method does not work on most kubernetes clusters, or container hosts you do not control.

A fully contained solution has yet to be created. I have been able to move a number of items into the container, i.e. Pam and kerberose cache, but some of the other resources are kernel locked.

[jovton]

@gaborgsomogyi turboaaa is right. My setup worked because the container uses some of the host's resources (krb5.conf, sssd pipes/sockets etc.) by attaching data volumes: Mount a host directory as data volume. In my case is was the (docker) host that was already "joined" to the AD domain, and not the container. In certain scenarios like a fully contained environment it may not be possible for the host to share locked-down resources with the containers, such as those mentioned by turboaaa, i.e. kubernetes cluster. this is the next challenge and milestone :)

UPDATE: After seeing this https://docs.pagure.org/SSSD.sssd/design_pages/sockets_for_domains.html it's all beginning to make sense now, It seems that the domains you can authenticate against entirely depends on how the host is set up. Looks like a work in progress.

[gaborgsomogyi]

@jovton After couple of days struggle I can't really make a successful server setup without docker and linux :) I'm using pure widows on AWS but no success to see that SQL server would use kerberos: https://gist.github.com/gaborgsomogyi/e27c761e05d451ed794591e38a903402 Actually auth_scheme is always SQL :/

[jovton]

@jovton After couple of days struggle I can't really make a successful server setup without docker and linux :) I'm using pure widows on AWS but no success to see that SQL server would use kerberos: https://gist.github.com/gaborgsomogyi/e27c761e05d451ed794591e38a903402 Actually auth_scheme is always SQL :/

Hi @gaborgsomogyi. Unfortunately I'm not familiar with how things work on AWS, and I have only tried AD auth on Ubuntu 18.04 LTS in a Hyper-V VM on a local NAT network. I'm am busy writing up some posts on my experiences.

In the mean time, I spotted this bit of information here: Use Active Directory authentication with SQL Server on Linux

Well, well... was this info there before and I just missed it? Does that mean SQL Server can completely bypass the SSSD mechanisms and we don't have to mount-bind to /var/lib/sss/pipes in our containers? Perhaps you're right @lubo, all this "AD joining" might be for naught 😁...

[turboaaa]

@jovton LDAP auth would solve almost all issues! Kerberose is really only needed for seamless SSO.

Great find.

[simongarisch]

There are a few of us at my workplace bumping into this issue. Would be great to have a solution.

[rclarke2050]

@twright-msft Hi Travis. whats the current situation with resolving this now. Could we possibly have a recap, and summary. ;-) much appreciated, as we're going to be using Docker SQL Linux 2019 for CICD.

Advanced Many Thanks Travis for all the hard work people put into this. respect!

[vin-yu]

We're working on some tooling for AD for SQL Server on Linux containers which will simplify this experience. However the first version will require that the container host is able to join the AD domain/realm-joined.

[rclarke2050]

is there any feasable way to by-pass the joining to AD and still have windows authentication working on DDL Statements? for example:

CREATE USER [domain\ntaccount] WITH DEFAULT_SCHEMA = [domain\ntaccount];

According to what i understand, IPs could be different in containers, and each dev would be spinning up/down their containers, so i believe the pain of joining to AD would not suffice in a container world. Or; am i missing something?

could you give us a rough ballpark timeframe of when the second version (no join required) will be available?

[turboaaa]

@rclarke2050

is there any feasable way to by-pass the joining to AD and still have windows authentication working on DDL Statements?

Keep in mind that they are using kerberos for AD authentication. Kerberos is protected by the Linux kernel, which containers should not have direct access to. Would love to see an LDAP option as there are use cases where seamless sign in is not a necessity.

According to what i understand, IPs could be different in containers, and each dev would be spinning up/down their containers, so i believe the pain of joining to AD would not suffice in a container world. Or; am i missing something?

It's not the containers that join the domain, it's the host for the containers. To AD the kerberos traffic is coming from the host and not the container. If you are running a kubernetes cluster on VMs you control, this isn't a logistical problem (though binding to protected host resources opens up security implications). If you wanted to deploy this on serverless cloud resources, you wouldn't be able to join the host to the domain.

[PrometheusRising1]

Since BDC on Openshift now supports Windows Auth, has there been any progress on this?

[vicrem]

Hi everyone,

I think I managed to get a working solution where we dont need a domain joined container or host to use Windows Authentication.

The solution is far from automated-> You'll need to create a keytab, TLS cert and configure mssql.conf outside the build, or at least that's how I did it..

Anyway.. My setup:

Docker Swarm with 3 nodes (none of them are domain joined or have krb5/sssd/third-party-tools installed) Virtual IP (keepalive) to access the Swarm Traefik as docker proxy (wildcard pointing to Virtual IP) NFSv4 to bind mount docker volumes Active Directory

This how I did it:

Thx to @jovton I managed to use his hack to get SSSD up & running inside the container. I did not mount any files/dirs from the host, instead I create necessary directories during build and execute SSSD from "run_script" during boot. Krb5-user is also configured to receive valid tickets.

Result:

[sssd[be[VICREM]]] [simple_bind_send] (0x0100): Executing simple bind as: CN=ldap-bind-user,OU=users,DC=vicrem,DC=se [sssd[be[VICREM]]] [fo_set_port_status] (0x0100): Marking port 3269 of server 'ldap.vicrem.se' as 'working' [sssd[be[VICREM]]] [set_server_common_status] (0x0100): Marking server 'ldap.vicrem.se' as 'working' [sssd[be[VICREM]]] [sysdb_idmap_store_mapping] (0x0100): Adding new ID mapping [S-1-5-21-1483676591-1150964932-725778543][S-1-5-21-1482316591-1422945922-725876543][297]

My AD user can login using Windows Auth :)

Repo: https://github.com/vicrem/mssql.git

//Victor

[jovton]

@vicrem wow! Thanks Victor. I will have to give this a try.

[vicrem]

@jovton tell me if there something you need help with :)

[vicrem]

Authentication and authorization is now working

[vicrem]

I have a new setup where I create the keytab during build. Can someone return with feedback? Recommendation is to try it with a test AD.

[mrlioncub]

I would like to see the configuration of the SQL server for authentication from Kerberos (keytab file).

[vicrem]

@mrlioncub have a look in here -> https://github.com/vicrem/mssql.git

The only configuration I have for SQL is found in initialization.sh (line 148-155) the rest is made by krb and sssd

[jblesener]

MS also has some documentation on the process here: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-containers-ad-auth-adutil-tutorial?view=sql-server-ver15

[hopoffbaby]

Hi All,

Myself and some of my colleagues have been trying to get AD auth for mssql working inside docker for about 3 days now. We seem frustratingly close but cannot quite get it.

Firstly, following the MS documentation to install MSSQL directly onto Linux and connect it to AD works fine in our environment. I followed these instructions:

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication?view=sql-server-ver15

Our goal is to ultimately get this working in Kubernetes. Before complicating things with K8S though we tried to get it working in Docker. This is where the fun begins!

We can get it to connect to AD and we can add users. However the users must be added using the long domain name. For example BARF1.COM/user1. The problem is when using SSMS or sqlcmd -E you can only use the short name BARF1/user1. This then gives the error (bearing in mind this works find directly installed on a host):

2021-02-19 14:42:57.19 Logon       Error: 17806, Severity: 20, State: 14.
2021-02-19 14:42:57.19 Logon       SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. The Local Security Authority cannot be contacted   [CLIENT: 172.26.63.14]
2021-02-19 14:42:57.22 Logon       Error: 18452, Severity: 14, State: 1.
2021-02-19 14:42:57.22 Logon       Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. [CLIENT: 172.26.63.14]

The steps we followed to get to this point were:

# create mssql user manually

setspn -A MSSQLSvc/k8ssql1.barf1.com:1433 mssql
setspn -A MSSQLSvc/k8ssql1.barf1:1433 mssql
setspn -A MSSQLSvc/k8ssql1:1433 mssql

setspn -A MSSQLSvc/hpc-d-hpc-k8-n3.barf1.com:1433 mssql
setspn -A MSSQLSvc/hpc-d-hpc-k8-n3.barf1:1433 mssql
setspn -A MSSQLSvc/hpc-d-hpc-k8-n3:1433 mssql

kinit mssql@BARF1.COM
kvno mssql@BARF1.COM
kvno MSSQLSvc/k8ssql1.barf1.com:1433@BARF1.COM

ktpass /princ MSSQLSvc/k8ssql1.barf1.com:1433@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'
ktpass /princ MSSQLSvc/k8ssql1.barf1.com:1433@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

ktpass /princ MSSQLSvc/hpc-d-hpc-k8-n3.barf1.com:1433@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'
ktpass /princ MSSQLSvc/hpc-d-hpc-k8-n3.barf1.com:1433@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

ktpass /princ MSSQLSvc/k8ssql1:1433@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'
ktpass /princ MSSQLSvc/k8ssql1:1433@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

ktpass /princ MSSQLSvc/hpc-d-hpc-k8-n3:1433@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'
ktpass /princ MSSQLSvc/hpc-d-hpc-k8-n3:1433@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

ktpass /princ mssql@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass PASSWORD'
ktpass /princ mssql@BARF1.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

ktpass /princ mssql@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'
ktpass /princ mssql@BARF1 /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser BARF1\mssql /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno 2 /pass 'PASSWORD'

This resulted in a keytab as follows

[root@hpc-d-hpc-k8-n3 ~]# klist -k mssql.keytab Keytab name: FILE:mssql.keytabKVNO Principal
---- --------------------------------------------------------------------------
   2 MSSQLSvc/k8ssql1.barf1.com:1433@BARF1
   2 MSSQLSvc/k8ssql1.barf1.com:1433@BARF1.COM
   2 MSSQLSvc/hpc-d-hpc-k8-n3.barf1.com:1433@BARF1
   2 MSSQLSvc/hpc-d-hpc-k8-n3.barf1.com:1433@BARF1.COM
   2 MSSQLSvc/k8ssql1:1433@BARF1
   2 MSSQLSvc/k8ssql1:1433@BARF1.COM
   2 MSSQLSvc/hpc-d-hpc-k8-n3:1433@BARF1
   2 MSSQLSvc/hpc-d-hpc-k8-n3:1433@BARF1.COM
   2 mssql@BARF1.COM
   2 mssql@BARF1.COM
   2 mssql@BARF1
   2 mssql@BARF1

We then map this into the container @ /var/opt/mssql/secrets/mssql.keytab, along with the krb5.conf to /etc/krb5.conf and /var/opt/mssql/krb5.conf

The krb5.conf file looks as follows:

[logging]
default = FILE:/tmp/krb5.log

[libdefaults]
 default_realm = BARF1.COM
 clockskew = 5000
 rdns = false
 udp_preference_limit = 0
 forwardable = True
 dns_lookup_realm = True
 dns_canonicalize_hostname = True

[realms]
 BARF1.COM = {
    kdc =<ad server>
    admin_server = <ad server>
    default_domain = BARF1.COM
 }

[domain_realm]
 barf1.com = BARF1.COM
 .barf1.com = BARF1.COM
 barf1 = BARF1.COM
 .barf1 = BARF1.COM

and finally we have the mssql.conf file mapped to /var/opt/mssql/mssql.conf, which looks like:

[network]
privilegedadaccount = mssql
kerberoskeytabfile = /var/opt/mssql/secrets/mssql.keytab
disablesssd = true
enablekdcfromkrb5conf = true

It is so frustrating because

1. This works directly on a Linux host, but not in a container
2. I can add users but using BARF1.COM instead of BARF1
3. sqlcmd and SSMS forces the user to log in with BARF1

Any help would be GREATLY appreciated. We have looked far and deep over the interwebz and this thread is the most promising thing I have found.

I have tried @jovton suggestion of mapping in sssd content from the host machine with no success, and I have also tried the docker-compose from @vicrem but also no luck. I see errors about LDAP bind issues and failure to create keytabs. I also tried the manual create option too.

I'm about ready to give up on this and just call it impossible. The documentation from Microsoft, while on the surface looks detailed, just does not work for me at all! @vin-yu Any updates on the docs?

Fingers crossed one of the gurus here can help :)

Thanks, hopoffbaby

[vicrem]

Hi @hopoffbaby, have a look on re_expression in SSSD, it might help you.

[takbgit]

Hi @hopoffbaby, we have been hitting the exact same issues as you and follow the exact same procedures.

We just got it to work by adding -u 0 to the podman container create command to force sql server to run as root.

So this looks more like a bug with running sql server as non-root.

I believe that SQL Server 2017 ran as root. Guessing that MS haven't quite got the rootless working right in 2019 yet.

[hopoffbaby]

@takbgit

I'm not sure about podman and rootless, but I did manage to get this solved with a support ticket to Microsoft.

The issue in the end for me was permissions on the mapped in krb5 and keytab files etc, and the most surprising was having to add COM to the search path in resolv.conf.

After that I was able to add the users with the short domain name and integrated Auth from ssms and sqlcmd worked as expected.

Cheers

[amvin87-zz]

There is a new documentation to configure AD Auth for containers and you can all do it from Linux machines using adutil, please follow the link documented here: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-containers-ad-auth-adutil-tutorial?view=sql-server-ver15

[hopoffbaby]

@amvin87 this is the guide I followed. It might be worth adding the info about adding COM into resolv.conf as this is what fixed the problem for me and was what was advised by Microsoft premier support

[amvin87-zz]

thank you for the feedback. I will edit this document or will work on creating a troubleshooting document that will have this documented and other steps to follow when configuring AD auth for SQL containers.

[DukaJ]

Hello everyone,

I can see that this topic is still active, I would like to ask. My case is pretty simple: I have .NET Core application which authenticate users through Windows AD. Everything worked smoothly until I wanted to dockerize my solution and place it inside Linux/Windows container.

My question is: Is it possible to connect to Windows AD through Linux or Windows containers? If it is, how? (Is the only way using gMSA?)

I've tried many things but I feel like I'm in endless loop.

Thank you in advance!

[amvin87-zz]

Hi @DukaJ here the question was specific to SQL Server running on Linux containers to support AD auth, for a .net application running on container supporting AD auth, I am not aware of the answer.

[hopoffbaby]

@DukaJ

I'd like to know that too. Although not sure it's related to this topic. From what I understand you need to use gMSA. I have several iis website that need as Auth too

[DukaJ]

@amvin87, @hopoffbaby Thank you guys, I'll look up somewhere else!

[akazakov]

yes, you can use AD enabled servers on docker / k8s without gMSA (including SQL server on linux). You just need to setup the keytabs and spns for your service correctly.

[amvin87-zz]

You can refer to this documentation https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-containers-ad-auth-adutil-tutorial?view=sql-server-ver15 and this video for a demo https://www.youtube.com/watch?v=A0mn9928N48 to configure AD auth for SQL on Linux containers.