Your SQL Linux has been joined to domain and you can connect to the SQL Server instance using Windows Authentication.
The connection itself is fine, but when you run some high privilege T-SQL statements like 'Create Login' , 'sp_addsrvrolemember' , you may run into the issue 'Error 15404 ‘Could not obtain information about Windows NT group/user '%ls', error code 0x80090304''
You will find following messages in PALLOG
11/22/2019 13:56:26.448761588 Debug [security.kerberos] <0000040947/0x00000200> Processing SSPI operation 0x0000000F
11/22/2019 13:56:26.449366379 Error [security.ldap] <0000040947/0x00000200> Initializing credentials for use in new cache failed: Keytab contains no suitable keys for red4$@SQLREPRO.EDU
11/22/2019 13:56:26.449613575 Debug [security.kerberos] <0000040947/0x00000200> Import name [ADMINISTRATOR@SQLREPRO.EDU] returned [ADMINISTRATOR@SQLREPRO.EDU]
11/22/2019 13:56:26.449633375 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]
11/22/2019 13:56:26.449753473 Debug [security.kerberos] <0000040947/0x00000200> Import name [RED4$] returned [RED4$]
11/22/2019 13:56:26.449905471 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]
11/22/2019 13:56:26.450014469 Error [security.kerberos] <0000040947/0x00000200> GSS MAJOR: 851968 GSS MINOR: 39756033 Error acquiring credentials in AcquireCredCaseInsensitive
11/22/2019 13:56:26.450029069 Error [security.kerberos] <0000040947/0x00000200> Unspecified GSS failure. Minor code may provide more information
11/22/2019 13:56:26.450039869 Error [security.kerberos] <0000040947/0x00000200> No key table entry found for red4$@SQLREPRO.EDU
11/22/2019 13:56:26.450053069 Debug [security.kerberos] <0000040947/0x00000200> SSPI operation 0x0000000F returned status: KerberosStream.cpp:2021 Operation unsuccessful
11/22/2019 13:56:26.450119868 Debug [security.kerberos.libos] <0000040961/0x0000020c> GetSecContextByUserABI() return value: 0x80090304
11/22/2019 13:56:26.488617991 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000
11/22/2019 13:56:26.488748289 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000
11/22/2019 13:56:26.489370580 Debug [security.kerberos.libos] <0000040961/0x0000020c> LookupAccountSid() return value: 0x00000001
Why?
When you run queries like 'create login', it will cause permissions to be checked. The first time you do it, it invalidates current permission. When you do it again, the permission check will be rechecked. When doing the permission check, SQL Server has to go through the mssql.keytab to pick up the machine entry key or MSA key. If SQL Server does not find the entries or find invalid entries, it raises error in question.
Here are three common scenarios that will cause the issue.
1.The machine account entries are not added. (mssql.keytab is configured by machine account)
If you skip the step 'Option 1: Using UPN to configure the keytab' in article https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication?view=sql..., you will run into this issue.
For example, here is a screenshot of valid mssql.keytab. If you don't have the entries highlighted, error 15404 happens.
2.Credentials of the MSA are not added. (mssql.keytab is configured by Managed Service Account)
This is similar to the scenario 1.
For example, here is a screenshot of valid mssql.keytab. If you don't have the entries highlighted, error 15404 happens
3.The machine account entries are expired. (mssql.keytab is configured by machine account)
To my knowledge, updating the machine account password cause the KVNO increase, and the machine account entries stall.
If someone in the SQL Server Linux runs following command: adcli update --computer-password-lifetime=0.
It will update the machine account password and caused the KNVO increase.
Please note, Windows domain controller does not control the machine account password update. It’s the client decision to update the password or not.
Even you have the 'Domain member: Maximum machine account password age' policy enabled, domain controller does not force clients to update machine account password.
Solution
===
1.For scenario 1 &2, just add then entries back.
2.For scenario 3, you need to recreate the mssql.keytab.
The ‘adcli update’ commands update machine account password, and refresh the /etc/krb5.keytab. You need to following the step ‘Option 1: Using UPN to configure the keytab’ , but with some changes.
The original steps is :
Now, you need to ‘Delete all the entries by their slot number that are not the UPN’, and delete all stalled UNP entries. Only UPN with latest KVNO are left.
For example, here is a screenshot of /etc/krb5.keytab.
You need delete all the entries, keep the entries highlighted.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.