Hi Kees, what is the output of net ads enctypes list <account of service principal> And when you load the keytab on the webserver with ktutil, what is the output of ktutil rkt /etc/keytab/apache.keytab l -e If you kinit to testuser directly on the webserver, what is the ouput of klist -e ? After that, if you do a kvno http/webserver01.samdom.lan at SAMDOM.LAN what is the output of klist -e then? Also, the content of krb5.conf on the webserver would be useful... Best wishes, Christian Am 09.05.2022 um 21:51 schrieb Kees van Vloten:> Hi Christian > > Op 09-05-2022 om 21:37 schreef Christian via samba: >> Hi Kees, >> >> Are CNAMEs involved? > > No, the webserver is reached though an A record (the vhost is configured > on the A-record). > The non-domain client is DHCP and has no DNS entry (I do not have DDNS > configured). > > Does that answer the question? > >> >> 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 >>> >>> >>> >>> >> >>
Hi Christian, I will collect the requested info tomorrow since it is pretty late here. For now just a quick remark: authentication via the webserver does work if I present a krb5-ticket in the authentication, it is just when the fallback to user-id/password is involved that it fails with GSS Error in message below. That makes me believe that krb5.conf, keytab etc. are all fine and it is also why I am lost. But anyway, I supply the extra info tomorrow. - Kees Op 10-05-2022 om 00:39 schreef Christian via samba:> Hi Kees, > > what is the output of > > net ads enctypes list <account of service principal> > > And when you load the keytab on the webserver with ktutil, what is the > output of > > ktutil > rkt /etc/keytab/apache.keytab > l -e > > If you kinit to testuser directly on the webserver, what is the ouput > of klist -e ? > > After that, if you do a > > kvno http/webserver01.samdom.lan at SAMDOM.LAN > > what is the output of > > klist -e > > then? Also, the content of krb5.conf on the webserver would be useful... > > Best wishes, > > Christian > > Am 09.05.2022 um 21:51 schrieb Kees van Vloten: >> Hi Christian >> >> Op 09-05-2022 om 21:37 schreef Christian via samba: >>> Hi Kees, >>> >>> Are CNAMEs involved? >> >> No, the webserver is reached though an A record (the vhost is >> configured on the A-record). >> The non-domain client is DHCP and has no DNS entry (I do not have >> DDNS configured). >> >> Does that answer the question? >> >>> >>> 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 >>>> >>>> >>>> >>>> >>> >>> > >
Hi Christian, Thanks very much for your advice, issue solved :-) I have put details below for reference. And there is one question left why did login work all the time when presenting Apache with a kerberos ticket. Is a valid keytab (+ enctypes on the DC) not required in that situation? - Kees Op 10-05-2022 om 00:39 schreef Christian via samba:> Hi Kees, > > what is the output of > > net ads enctypes list <account of service principal>This was returning: "no msDS-SupportedEncryptionTypes attribute found" because the account was created on the DC but the machine is not a domain-member and hence never set that value. I set it manually to 28, which is what the DC-controller uses on its account. This being empty was causing the apache error below.> > And when you load the keytab on the webserver with ktutil, what is the > output of > > ktutil > rkt /etc/keytab/apache.keytab > l -e >After setting 28 with "net ads enctypes set" the next error occurred: GSS ERROR gss_accept_sec_context(): [Unspecified GSS failure.? Minor code may provide more information (Request ticket server http/webserver01.samdom.lan at SAMDOM.LAN kvno 2 found in keytab but not with enctype aes256-cts)] It turns out Samba exports the keytab when enctypes is not set like this: ktutil:? rkt /etc/keytab/apache.keytab ktutil:? l -e slot KVNO Principal ---- ---- --------------------------------------------------------------------- ?? 1??? 2 http/webserver01.samdom.lan at SAMDOM.LAN (arcfour-hmac) After setting the enctype value en re-exporting the keytab I have a working setup (it contains 3 entries representing the value of 28 for enctype), I can now log in with user-id/password.> If you kinit to testuser directly on the webserver, what is the ouput > of klist -e ? > > After that, if you do a > > kvno http/webserver01.samdom.lan at SAMDOM.LAN > > what is the output of > > klist -e > > then? Also, the content of krb5.conf on the webserver would be useful... > > Best wishes, > > Christian > > Am 09.05.2022 um 21:51 schrieb Kees van Vloten: >> Hi Christian >> >> Op 09-05-2022 om 21:37 schreef Christian via samba: >>> Hi Kees, >>> >>> Are CNAMEs involved? >> >> No, the webserver is reached though an A record (the vhost is >> configured on the A-record). >> The non-domain client is DHCP and has no DNS entry (I do not have >> DDNS configured). >> >> Does that answer the question? >> >>> >>> 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 >>>> >>>> >>>> >>>> >>> >>> > >