Bug 1222605

Summary:	KDC has no support for encryption type
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Axel Schwarzer <SchwarzerA>
Component:	Network	Assignee:	Samuel Cabrero <scabrero>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	chcao, samba-maintainers, SchwarzerA
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Axel Schwarzer 2024-04-10 09:00:39 UTC

Yesterday morning I performed my weekly update with "zypper dup -l" and everything went fine. After the necessary reboot I still got a Kerberos TGT like before:

---[ 8< ]---
Ticket cache: FILE:/tmp/krb5cc_<uid>
Default principal: <usr>@<DOMAIN>.DE

Valid starting       Expires              Service principal
config: pa_type(krbtgt/<DOMAIN>@<DOMAIN>.DE) = 2
	AD types: 
10.04.2024 10:19:48  10.04.2024 20:19:48  krbtgt/<DOMAIN>.DE@<DOMAIN>.DE
	renew until 11.04.2024 10:19:48, Flags: RIA
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 , AD types: 
---[ 8< ]---

but FireFox could not use it on all URLs like before. Two SSOs still work (with IIS in background) but the other websites delivered by different Apaches still require me to logon via browser popup. In one of the logs (apache2, 2.4.51-150400.6.14.1 on Tumbleweed current) errors appear:

---[ 8< ]---
[Wed Apr 10 07:05:54.191519 2024] [auth_gssapi:info] [pid 23771:tid 140480260077312] [client 192.168.x.y:44258] NO AUTH DATA Client did not send any authentication headers
[Wed Apr 10 07:05:54.191608 2024] [auth_gssapi:error] [pid 23771:tid 140480260077312] [client 192.168.x.y:44258] The main request is tasked to establish the security context, can't proceed!
[Wed Apr 10 07:11:23.158296 2024] [auth_gssapi:info] [pid 23771:tid 140479521879808] [client 192.168.z.w:51094] NO AUTH DATA Client did not send any authentication headers, referer: https://kb-it.<domain>.de/doku.php?id=sf:systeme:containerisierung:pgsql_migration
[Wed Apr 10 07:11:23.158381 2024] [auth_gssapi:error] [pid 23771:tid 140479521879808] [client 192.168.z.w:51094] The main request is tasked to establish the security context, can't proceed!, referer: https://kb-it.<domain>.de/doku.php?id=sf:systeme:containerisierung:pgsql_migration
---[ 8< ]---

And an Apache on Debian simply answers with HTTP 401. An attempt to trace FireFox gave me these hints: 

---[ 8< ]---
[Parent 126907: Main Thread]: D/negotiateauth   service = intranet.<domain>.de
[Parent 126907: Main Thread]: D/negotiateauth   using negotiate-gss
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::nsAuthGSSAPI()
[Parent 126907: Main Thread]: D/negotiateauth Attempting to load user specified library [libgssapi_krb5.so.2]
[Parent 126907: Main Thread]: D/negotiateauth Attempting to load gss functions
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::Init()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth entering nsAuthGSSAPI::GetNextToken()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth gss_init_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information
KDC has no support for encryption type

[Parent 126907: BgIOThreadPool #1]: D/negotiateauth   leaving nsAuthGSSAPI::GetNextToken [rv=80004005]
[Parent 126907: Main Thread]: D/negotiateauth   service = kb-it.<domain>.de
[Parent 126907: Main Thread]: D/negotiateauth   using negotiate-gss
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::nsAuthGSSAPI()
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::Init()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth entering nsAuthGSSAPI::GetNextToken()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth gss_init_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information
KDC has no support for encryption type

[Parent 126907: BgIOThreadPool #1]: D/negotiateauth   leaving nsAuthGSSAPI::GetNextToken [rv=80004005]
[Parent 126907: Main Thread]: D/negotiateauth   service = kb-chgv.<domain>.de
[Parent 126907: Main Thread]: D/negotiateauth   using negotiate-gss
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::nsAuthGSSAPI()
[Parent 126907: Main Thread]: D/negotiateauth entering nsAuthGSSAPI::Init()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate]
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth entering nsAuthGSSAPI::GetNextToken()
[Parent 126907: BgIOThreadPool #1]: D/negotiateauth gss_init_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information
KDC has no support for encryption type
---[ 8< ]---


Other browsers (on Windows, Edge/Chrome/FireFox) are not affected. No changes were made to our AD and DCs.

Comment 1 Chenzi Cao 2024-07-16 15:24:12 UTC

Hi Samuel, would you please help to take a look at this issue? I'm not sure whether it is correct to assign it to you, please feel free to reassign whenever necessary, thanks!

Comment 2 Samuel Cabrero 2024-07-17 11:56:16 UTC

This is probably related to crypto-policies:

> * jue feb 29 2024 Pedro Monreal <pmonreal@suse.com>
> - Add crypto-policies support [bsc#1211301]
>   * Update krb5.conf in vendor-files.tar.bz2

> $ ls -l /etc/krb5.conf.d/crypto-policies
> lrwxrwxrwx 1 root root 40 jul  1 09:51 /etc/krb5.conf.d/crypto-policies -> ../crypto-policies/back-ends/krb5.config
> $ cat /etc/krb5.conf.d/crypto-policies
> [libdefaults]
> permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac

The default value for permitted_enctypes includes "arcfour-hmac-md5". You might need to adjust your config.

Comment 3 Samuel Cabrero 2024-07-18 08:27:03 UTC

Axel confirmed by mail that everything works again.