Ошибка при вызове api lsacallauthenticationpackage подсостояние getticket 0x6fb - Ремонт и установка крупной бытовой техники

Thank you. Here is the output for the commands from within the container. Look like there is a trust issue?

PS C:> whoami /all

USER INFORMATION

User Name SID
=================================== ============
user managercontaineradministrator S-1-5-93-2-1

GROUP INFORMATION

Group Name Type SID Attributes

==================================== ================ ============ =====================================================

Mandatory LabelHigh Mandatory Level Label S-1-16-12288

Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group

BUILTINUsers Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group

NT AUTHORITYSERVICE Well-known group S-1-5-6 Mandatory group, Enabled by default, Enabled group

CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group

NT AUTHORITYAuthenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group

NT AUTHORITYThis Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group

LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group

BUILTINAdministrators Alias S-1-5-32-544 Mandatory group, Enabled by default, Enabled group, G
roup owner
Unknown SID type S-1-5-93-0 Mandatory group, Enabled by default, Enabled group

NT AUTHORITYThis Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group

LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group

BUILTINAdministrators Alias S-1-5-32-544 Mandatory group, Enabled by default, Enabled group,
roup owner G
Unknown SID type S-1-5-93-0 Mandatory group, Enabled by default, Enabled group

PRIVILEGES INFORMATION

Privilege Name ======================== SeIncreaseQuotaPrivilege SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeSystemProfilePrivilege SeSystemtimePrivilege SeProfileSingleProcessPrivilege SeIncreaseBasePriorityPrivilege SeCreatePagefilePrivilege SeBackupPrivilege SeRestorePrivilege SeShutdownPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeChangeNotifyPrivilege SeRemoteShutdownPrivilege SeUndockPrivilege SeManageVolumePrivilege SeImpersonatePrivilege SeCreateGlobalPrivilege SeIncreaseWorkingSetPrivilege SeTimeZonePrivilege SeCreateSymbolicLinkPrivilege SeDelegateSessionUserImp Description State
================= ================================================================== ========
Adjust memory quotas for a process Disabled
Manage auditing and security log Disabled
Take ownership of files or other objects Disabled
Load and unload device drivers Disabled
Profile system performance Disabled
Change the system time Disabled
Profile single process Disabled
Increase scheduling priority Disabled
Create a pagefile Disabled
Back up files and directories Disabled
Restore files and directories Disabled
Shut down the system Disabled
Debug programs Enabled
Modify firmware environment values Disabled
Bypass traverse checking Enabled
Force shutdown from a remote system Disabled
Remove computer from docking station Disabled
Perform volume maintenance tasks Disabled
Impersonate a client after authentication Enabled
Create global objects Enabled
Increase a process working set Disabled
Change the time zone Disabled
Create symbolic links Disabled
ersonatePrivilege Obtain an impersonation token for another user in the same session Disabled

USER CLAIMS INFORMATION

User claims unknown.

Kerberos support for Dynamic Access Control on this device has been disabled.
PS C:> klist get ldap/contoso.com

Current LogonId is 0:0xe34097
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb

klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for th
is workstation trust relationship.

I am trying to and failing to authenticate my Kerberos credentials when doing ssh from a Windows 11 client joined to a Windows Server 2019 domain (let’s call it AD.LOCAL) to a Linux host joined to a domain managed by FreeIPA (let’s call it IPA.LOCAL).

I already have the trust relationship established as «Forest» trust, and to break down the issues I verified that if I change the client (to Linux), or the destination (to a host on the same domain) it works.

To demonstrate the problem, the command output is trimmed for brevity and the host and IPs anonymized.

❌ From Windows to IPA host:

PS C:Usersuser> ssh -v -K -l user@ad.local host02.ipa.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host02.ipa.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: GSS_S_FAILURE
debug1: Next authentication method: publickey
...

✅ From Windows to AD host:

PS C:Usersuser> ssh -v -K -l user@ad.local host01.ad.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host01.ad.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host01.ad.local ([192.168.0.62]:22).
...

✅ From Linux to IPA host:

$ ssh -v -K -l user@ad.local host02.ipa.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host02.ipa.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host02.ipa.local ([192.168.0.181]:22).
...

✅ From Linux to AD host:

$ ssh -v -K -l user@ad.local host01.ad.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host01.ad.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host01.ad.local ([192.168.0.62]:22).
...

My tickets after running the above commands:

Windows ticket:

PS C:Usersuser> klist

Current LogonId is 0:0xe934d3

Cached Tickets: (2)

#0>     Client: user @ AD.LOCAL
        Server: krbtgt/AD.LOCAL @ AD.LOCAL
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 6/17/2022 14:55:54 (local)
        End Time:   6/18/2022 0:55:54 (local)
        Renew Time: 6/24/2022 14:55:54 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc02.ad.local

#1>     Client: user @ AD.LOCAL
        Server: host/host01.ad.local @ AD.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 6/17/2022 14:55:54 (local)
        End Time:   6/18/2022 0:55:54 (local)
        Renew Time: 6/24/2022 14:55:54 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc02.ad.local

Linux ticket:

$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user@AD.LOCAL

Valid starting       Expires              Service principal
06/17/2022 14:31:40  06/18/2022 00:30:36  host/host02.ipa.local@
        renew until 06/18/2022 14:30:34
        Ticket server: host/host02.ipa.local@IPA.LOCAL
06/17/2022 14:31:39  06/18/2022 00:30:36  krbtgt/IPA.LOCAL@AD.LOCAL
        renew until 06/18/2022 14:30:34
06/17/2022 14:31:09  06/18/2022 00:30:36  host/host01.ad.local@
        renew until 06/18/2022 14:30:34
        Ticket server: host/host01.ad.local@AD.LOCAL
06/17/2022 14:30:36  06/18/2022 00:30:36  krbtgt/AD.LOCAL@AD.LOCAL
        renew until 06/18/2022 14:30:34

And for completeness, I have nothing of interest in /etc/krb5.conf on the Linux box, I intentionally commented out pretty much everything.

$ grep -v # /etc/krb5.conf

[libdefaults]
    default_ccache_name = KEYRING:persistent:%{uid}

OS versions

Windows client:

PS C:Usersuser> cmd /c ver

Microsoft Windows [Version 10.0.22000.675]

Linux client:

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: Rocky
Description:    Rocky Linux release 8.6 (Green Obsidian)
Release:        8.6
Codename:       GreenObsidian

Update to answer questions in a comment:

Windows client:

$ klist get host/host02.ipa.local

Current LogonId is 0:0xe934d3
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb

klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.

Note: The trust is configured as «External» type.

Linux client does not have sssd installed at all.

$ rpm -qa sss* | grep . ; echo $?
1

But for completeness:

$ env SSSD_KRB5_LOCATOR_DISABLE=1 kvno host/host02.ipa.local
kvno: Configuration file does not specify default realm while parsing principal name host/host02.ipa.local

Now, this makes me think that the Linux client tools simply behave differently in respect to resolving hostname credentials. E.g., the following command, when told that the wanted credential is a hostname, it succeeds and it goes gets a krbtgt for IPA.LOCAL from AD.LOCAL, then goes to the IPA.LOCAL servers to get the ticket:

$ env SSSD_KRB5_LOCATOR_DISABLE=1 kvno -S host host02.ipa.local
host/host02.ipa.local@: kvno = 1
$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user@AD.LOCAL

Valid starting       Expires              Service principal
06/20/2022 11:57:32  06/20/2022 21:56:38  host/host02.ipa.local@
        renew until 06/21/2022 11:56:34
        Ticket server: host/host02.ipa.local@IPA.LOCAL
06/20/2022 11:57:32  06/20/2022 21:56:38  krbtgt/IPA.LOCAL@AD.LOCAL
        renew until 06/21/2022 11:56:34
06/20/2022 11:56:38  06/20/2022 21:56:38  krbtgt/AD.LOCAL@AD.LOCAL
        renew until 06/21/2022 11:56:34

P.S. Updated the description as we upgraded the trust from «External» type to «Forest» type. Still the same problem.

SQL Server connectivity, Kerberos authentication and SQL Server SPN (SQL Server Service Principal Name )

Most of you would already be aware of Kerberos authentication in SQL Server (http://technet.microsoft.com/en-us/library/cc280744%28v=sql.105%29.aspx) It is mandate for delegation and highly secured method for client server authentication.

Connection failures caused by Kerberos authentication issues drives majority of questions in MSDN and other SQL Server forums. Some of the common errors you would get when Kerberos authentication fails include.

{

Cannot generate SSPI context

Login failed for user ‘(null)’
Login failed for user ”
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Linked server connections failing

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed

Note: For the last two errors error code translates to

Error -2146893039 (0x80090311): No authority could be contacted for authentication
Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted

So it is pretty much clear that if you get last two errors then it means secure session could not be established with you domain controller. So you can use nltest /SC_QUERY:YourDomainName to check the domain connection status.

You will also see below event from netlogon session in system event log when your SQL Server connection fails with last two errors in the above list

Log Name: System
Source: NETLOGON
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: client.Contoso.com
Description: This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

}

Before we jump into troubleshooting Connection failures caused by Kerberos authentication let see how to force SQL Server to use Named pipes protocol when you get above errors and workaround the problem till you fix the Kerberos authentication with TCP/IP. To force SQL Server to use NP protocol you can use any one of the below methods.

1. Prefix the SQL Server instance name with np: Ex: If your server name is MssqlwikiInstance1 , modify the connection string to np: MssqlwikiInstance1

2. Change the order of client protocols and bring Named pipes before the TCP/IP protocol (SQL Server configuration manager -> SQL Server native client configuration -> Client protocols -> Order – >Bring Named pipes above TCP/IP)

clip_image002[4]

Note: You have to do the change both in 32-Bit and 64-Bit SQL Server native client configuration in your client systems.

3. Create a named pipe Alias

When you get Kerberos authentications errors or if you notice SQL Server is failing back to NTLM authentication you can follow below steps to troubleshoot Kerberos failures.

1. How to check If SQL Server is suing Kerberos authentication?

SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid

For the Kerberos authentication to work in SQL Server, SPN (Service principal name) has to be registered for SQL Server service. SPN is automatically registered by SQL Server using the startup account of SQL Server when SQL Server starts and deregistered when SQL Server is stopped. Kerberos authentication would fail when the SPN is not registered (or) when there is duplicate SPN’s registered in Active directory (or) client system is not able to get the Kerberos ticket (or) DNS is not configured properly.

2. How to Check if SPN’s are successfully registered in the active directory?

When SPN’s is registered in active directory during the startup of SQL Server by startup account of SQL Server, a message similar to one below is logged in SQL Server error log.

2013-12-05 22:21:47.030 Server The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/node2.mssqlwiki.com ] for the SQL Server service.

2013-12-05 22:21:47.030 Server The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/node2.mssqlwiki.com:1433 ] for the SQL Server service.

When SQL Server could not register SPN’s during the startup below error message is logged in SQL Server error log?

Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/node2.mssqlwiki.com ] for the SQL Server service. Windows return code: 0xffffffff, state: 53. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/node2.mssqlwiki.com:1433 ] for the SQL Server service. Windows return code: 0xffffffff, state: 53. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

3. I see SQL Server could not register SPN error message in SQL Server errorlog. How do I make SQL Server register SPN’s automatically?

If your Domain controller is windows2008R2 or lower grant Read servicePrincipalName and Write servicePrincipalName privilege for startup account of SQL Server using ADSIEDIT.msc tool

Launch the ADSI Edit -> Domain -> DC=DCNAME,DC=com -> CN=Users -> CN=SQLServer_ServiceAccount -> Properties -> security tab-> advanced ->Add self -> Edit ->in permissions ->Click properties -> grant ->Read servicePrincipalName and -> Write servicePrincipalName

If your domain controller is Windows2012 grant Validate write to service principal name for startup account of SQL Server using Active directory user and computers snap in

clip_image010[4]

4. From SQL Server error log I see SPN’s are registered successfully but still Kerberos authentication is failing. What is next?

Check if there are duplicate SPN’s registered in Ad using the LDIFDE tool. Below query will fetch all the SQL Server SPN’s from active directory and print in c:tempspnlist.txt.

Ldifde -f c:tempspnlist.txt -s YourDomainName -t 3268 -d «» -r «(serviceprincipalname= MSSQLSvc/*)»

Search for duplicate SPN in the output file (spnlist.txt). In our case SPN name is MSSQLSvc/node2.mssqlwiki.com:1433 .So if there are more than one entry in the output file for MSSQLSvc/node2.mssqlwiki.com:1433 then there is a duplicate SPN’s which has to be deleted.

5. How do I identify which SPN is duplicate?

In the output of the LDIFDE you will find the SAM accountName which registered the SPN, just above the ServicePrincipalName (Refer the sample below). If the SAM account is not the startup account of SQL Server then it as duplicate SPN.

{

sAMAccountName: NODE2$

sAMAccountType: 805306369

dNSHostName: NODE2.mssqlwiki.com

servicePrincipalName: MSSQLSvc/node2.mssqlwiki.com

servicePrincipalName: MSSQLSvc/node2.mssqlwiki.com:1433

}

6. There is a duplicate SPN in active directory how do I delete?

Use the setspn tool

Syntax: Setspn -D «MSSQLSvc/FQDN:port» «SAMAccount name which has duplicate SPN «

Setspn -D » MSSQLSvc/node2.mssqlwiki.com:1433″ «DOMAINAccountname»

7. SPN’s are registered properly, there is no duplicate SPN but still the Kerberos authentication is not working ?

Run the KLIST exe from the client and check if it is able to get the ticket

Example:

Klist get MSSQLSvc/node2.mssqlwiki.com:1433

If the client is able to get the ticket then you should see a output similar to one below

{

c:WindowsSystem32>Klist get MSSQLSvc/node2.mssqlwiki.com:1433

Current LogonId is 0:0x2de9f6

A ticket to MSSQLSvc/node2.mssqlwiki.com:1433 has been retrieved successfully.

Cached Tickets: (10)

clip_image012[4]

}

If the client is unable to get the ticket then you should see an error similar to one below.

{

c:WindowsSystem32>Klist get MSSQLSvc/node2.mssqlwiki.com:1433

Current LogonId is 0:0x2de9f6

Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb

klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server

does not have a computer account for this workstation trust relationship.

clip_image014[4]

}

If the client is unable to get the ticket check if it not able to retrieve the ticket only the ticket for SQL Server (or) not able to get any tickets. You can use below commands

Klist get Host/FQDN of DC where SQLServer is installed

Klist get Host/FQDN of SQLServer Machine name

If all the tickets are failing then most probably the issue should be with DNS/Network setting, you can troubleshoot further based on the error you receive from klist or collect Netmon traces to troubleshoot further.

8. If the client is able to get the ticket and still Kerberos authentication fails?

Ping the SQL Server name and IP address (with –a ) and identify if it is able to resolved to fully qualified name DNS name, If it is not able to resolve to FQDN of SQL Server then fix the DNS settings

9. How to Collect Netmon traces and identify Kerberos authentication failure?

Wait for my next blog

If you liked this post, do like us on Facebook at https://www.facebook.com/mssqlwiki and join our Facebook group

Thank you,

Karthick P.K |My Facebook Page |My Site| Blog space| Twitter

Disclaimer:

The views expressed on this website/blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights

Источник