Hi Team, I fail to get logged in by apache2 on a webpage from a non-domain machine (i.e. I get the browser basic auth dialog and pass my credentials). The apache server is not joined to the DC either but it does have a computer-account and a keytab on the webserver. All machines involved run on Debian 11, the DC runs Louis' Samba 4.15.7, all machines are on the same subnet. Authentication on the same webpage does work when I am trying this from a domain-joined Windows machine, i.e. when I present a krb5-ticket. Apache's error log says: [Mon May 09 20:43:10.717747 2022] [auth_gssapi:error] [pid 92032] [client 192.168.1.100:40992] GSS ERROR gss_init_sec_context(): [Unspecified GSS failure.? Minor code may provide more information (KDC has no support for encryption type)], referer: https://internal.samdom.lan/home.html I am using mod_auth_gssapi with this config: <Directory /var/www/pages> ??? AuthName "Login" ??? AuthType GSSAPI ??? GssapiSSLonly On ??? GssapiLocalName On ??? GssapiUseSessions On ??? Session On ??? SessionCookieName gssapi_session path=/private;httponly;secure; ??? GssapiSessionKey file:/var/lib/apache2/secrets/session.key ??? GssapiCredStore keytab:/etc/keytab/apache.keytab ??? GssapiDelegCcacheDir /run/apache2/krb5 ??? GssapiBasicAuth On ??? GssapiAllowedMech krb5 ??? Require valid-user ??? AllowOverride None ??? Order allow,deny ??? Allow from all </Directory> ls -l /etc/keytab/apache.keytab -rw-r----- 1 root www-data 94 May? 3 18:55 /etc/keytab/apache.keytab When I look on the DC, it seems the authentication process is fine and I am authenticated: [2022/05/09 20:55:22.312671,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: AS-REQ testuser at SAMDOM.LAN from ipv4:192.168.8.8:42579 for krbtgt/SAMDOM.LAN at SAMDOM.LAN [2022/05/09 20:55:22.333446,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Client sent patypes: encrypted-timestamp, 150, 149 [2022/05/09 20:55:22.333529,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Looking for PKINIT pa-data -- testuser at SAMDOM.LAN [2022/05/09 20:55:22.333564,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Looking for ENC-TS pa-data -- testuser at SAMDOM.LAN [2022/05/09 20:55:22.333696,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: ENC-TS Pre-authentication succeeded -- testuser at SAMDOM.LAN using aes256-cts-hmac-sha1-96 [2022/05/09 20:55:22.333765,? 3] ../../auth/auth_log.c:647(log_authentication_event_human_readable) ? Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[testuser at SAMDOM.LAN] at [Mon, 09 May 2022 20:55:22.333741 CEST] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:192.168.8.8:42579] became [DINTELMOND]\[testuser] [S-1-5-21-1366037735-1163107043-795354949-1197]. local host [NULL] [2022/05/09 20:55:22.359384,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: AS-REQ authtime: 2022-05-09T20:55:22 starttime: unset endtime: 2022-05-10T06:55:22 renew till: unset [2022/05/09 20:55:22.359463,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 [2022/05/09 20:55:22.359500,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Requested flags: renewable-ok, proxiable, forwardable [2022/05/09 20:55:22.564106,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: TGS-REQ testuser at SAMDOM.LAN from ipv4:192.168.1.10:58486 for http/webserver01.samdom.lan at SAMDOM.LAN [canonicalize, proxiable, forwardable] [2022/05/09 20:55:22.569549,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Server (http/webserver01.samdom.lan at SAMDOM.LAN) has no support for etypes [2022/05/09 20:55:22.569670,? 3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) ? Kerberos: Failed building TGS-REP to ipv4:192.168.8.8:58486 [2022/05/09 20:55:22.570030,? 3] ../../source4/samba/service_stream.c:67(stream_terminate_connection) ? stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' I guess there must be an issue in the apache2 gssapi configuration, but what is it? - Kees
Hi Kees, Are CNAMEs involved? Best, Christian Am 09.05.2022 um 21:31 schrieb Kees van Vloten via samba:> Hi Team, > > > I fail to get logged in by apache2 on a webpage from a non-domain > machine (i.e. I get the browser basic auth dialog and pass my > credentials). > The apache server is not joined to the DC either but it does have a > computer-account and a keytab on the webserver. > > All machines involved run on Debian 11, the DC runs Louis' Samba > 4.15.7, all machines are on the same subnet. > > Authentication on the same webpage does work when I am trying this > from a domain-joined Windows machine, i.e. when I present a krb5-ticket. > > Apache's error log says: > > [Mon May 09 20:43:10.717747 2022] [auth_gssapi:error] [pid 92032] > [client 192.168.1.100:40992] GSS ERROR gss_init_sec_context(): > [Unspecified GSS failure.? Minor code may provide more information > (KDC has no support for encryption type)], referer: > https://internal.samdom.lan/home.html > > I am using mod_auth_gssapi with this config: > > <Directory /var/www/pages> > ??? AuthName "Login" > ??? AuthType GSSAPI > ??? GssapiSSLonly On > ??? GssapiLocalName On > ??? GssapiUseSessions On > ??? Session On > ??? SessionCookieName gssapi_session path=/private;httponly;secure; > ??? GssapiSessionKey file:/var/lib/apache2/secrets/session.key > ??? GssapiCredStore keytab:/etc/keytab/apache.keytab > ??? GssapiDelegCcacheDir /run/apache2/krb5 > ??? GssapiBasicAuth On > ??? GssapiAllowedMech krb5 > ??? Require valid-user > ??? AllowOverride None > ??? Order allow,deny > ??? Allow from all > </Directory> > > ls -l /etc/keytab/apache.keytab > -rw-r----- 1 root www-data 94 May? 3 18:55 /etc/keytab/apache.keytab > > > When I look on the DC, it seems the authentication process is fine and > I am authenticated: > > [2022/05/09 20:55:22.312671,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: AS-REQ testuser at SAMDOM.LAN from ipv4:192.168.8.8:42579 for > krbtgt/SAMDOM.LAN at SAMDOM.LAN > [2022/05/09 20:55:22.333446,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Client sent patypes: encrypted-timestamp, 150, 149 > [2022/05/09 20:55:22.333529,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Looking for PKINIT pa-data -- testuser at SAMDOM.LAN > [2022/05/09 20:55:22.333564,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Looking for ENC-TS pa-data -- testuser at SAMDOM.LAN > [2022/05/09 20:55:22.333696,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: ENC-TS Pre-authentication succeeded -- testuser at SAMDOM.LAN > using aes256-cts-hmac-sha1-96 > [2022/05/09 20:55:22.333765,? 3] > ../../auth/auth_log.c:647(log_authentication_event_human_readable) > ? Auth: [Kerberos KDC,ENC-TS Pre-authentication] user > [(null)]\[testuser at SAMDOM.LAN] at [Mon, 09 May 2022 20:55:22.333741 > CEST] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation > [(null)] remote host [ipv4:192.168.8.8:42579] became > [DINTELMOND]\[testuser] > [S-1-5-21-1366037735-1163107043-795354949-1197]. local host [NULL] > [2022/05/09 20:55:22.359384,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: AS-REQ authtime: 2022-05-09T20:55:22 starttime: unset > endtime: 2022-05-10T06:55:22 renew till: unset > [2022/05/09 20:55:22.359463,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, using > aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 > [2022/05/09 20:55:22.359500,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Requested flags: renewable-ok, proxiable, forwardable > [2022/05/09 20:55:22.564106,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: TGS-REQ testuser at SAMDOM.LAN from ipv4:192.168.1.10:58486 > for http/webserver01.samdom.lan at SAMDOM.LAN [canonicalize, proxiable, > forwardable] > [2022/05/09 20:55:22.569549,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Server (http/webserver01.samdom.lan at SAMDOM.LAN) has no > support for etypes > [2022/05/09 20:55:22.569670,? 3] > ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) > ? Kerberos: Failed building TGS-REP to ipv4:192.168.8.8:58486 > [2022/05/09 20:55:22.570030,? 3] > ../../source4/samba/service_stream.c:67(stream_terminate_connection) > ? stream_terminate_connection: Terminating connection - > 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - > NT_STATUS_CONNECTION_DISCONNECTED' > > > I guess there must be an issue in the apache2 gssapi configuration, > but what is it? > > > - Kees > > > >
Andrew Bartlett
2022-May-20 22:51 UTC
[Samba] Security notes on Apache2 GSSAPI (basic) authentication
On Mon, 2022-05-09 at 21:31 +0200, Kees van Vloten via samba wrote:> Hi Team, > > > I fail to get logged in by apache2 on a webpage from a non-domain > machine (i.e. I get the browser basic auth dialog and pass my credentials). > The apache server is not joined to the DC either but it does have a > computer-account and a keytab on the webserver.Well done sorting this out, but I also need to pass on a warning: The username as seen by the likes of mod_auth_kerb can be misleading. Bug 14556 (CVE-2020-25717) that we released in Nov 2021 was all about a user on the domain being able to pretend to be other usernames. The usernames that are possible are (in any case variation): samAccountName, samAccountName-without-trailing-$ (eg a ticket for 'root' against an AD user of root$) and the UPN. So lock down who can modify accounts in your AD, including machineAccountQuota, and match back the account to AD against samAccountName (eg with an LDAP search) if any of this scares you. I tried to get MIT and Heimdal Kerberos to require and parse the PAC to thwart this, but nothing has been released as far as I'm aware, and it is optional at best. In your situation, for the basic auth side, please ensure that canonicalisation is on in your krb5.conf, as that will help a little, but you can't detect - without reading the PAC - if a Kerberos-enabled attacker is doing it to you. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba