Quantcast

unable to get squid kerberos group working.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unable to get squid kerberos group working.

L.P.H. van Belle

Hai,

 

I noticed a problem in the kerberos_ldap_group and im unable to get it working.

I reported the bug here also : https://github.com/squid-cache/squid/issues/17

 

Environment: Debian Jessie, Squid 3.5.24 debian rebuild from debian stretch.

kerberos_ldap_group: INFO: Starting version 1.3.1sq

 

first :  The kerberos group goes wrong with the SRV record detection.

A and PTR records are in place and tested.

 

And a check on the SRV records shows.

 

dig SRV _ldap._tcp.internal.domain.tld.

;; ANSWER SECTION:

_ldap._tcp.internal.domain.tld. 900 IN SRV 5 100 636 dc1.internal.domain.tld.

_ldap._tcp.internal.domain.tld. 900 IN SRV 5 100 636 dc2.internal.domain.tld.

_ldap._tcp.internal.domain.tld. 900 IN SRV 10 100 389 dc1.internal.domain.tld.

_ldap._tcp.internal.domain.tld. 900 IN SRV 10 100 389 dc2.internal.domain.tld.

;; AUTHORITY SECTION:

 

dig SRV _ldaps._tcp.internal.domain.tld.

;; ANSWER SECTION:

_ldaps._tcp.internal.domain.tld. 900 IN SRV 0 100 636 dc1.internal.domain.tld.

_ldaps._tcp.internal.domain.tld. 900 IN SRV 0 100 636 dc2.internal.domain.tld.

;; AUTHORITY SECTION:

 

 

but debug logs shows. ( cache.log )

support_resolv.cc(407): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Adding internal.domain.tld to list

support_resolv.cc(443): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Sorted ldap server names for domain INTERNAL.DOMAIN.TLD:

support_resolv.cc(445): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Host: dc1.internal.domain.tld Port: 636 Priority: 5 Weight: 100

support_resolv.cc(445): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Host: dc2.internal.domain.tld Port: 389 Priority: 5 Weight: 100

support_resolv.cc(445): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Host: dc1.internal.domain.tld Port: 636 Priority: 10 Weight: 100

support_resolv.cc(445): pid=15718 :2017/02/20 08:24:03| kerberos_ldap_group: DEBUG: Host: dc2.internal.domain.tld Port: 389 Priority: 10 Weight: 100

Wrong order in the debug output.

 

The hostnames and priority changes, and this changes randomly at every startup.

I dont know it this is the cause of my problem, thats why im asking here.

 

So Im trying to get my kerberos group checks working, but still no go and i just dont see what the problem is.

 

The Kerberos auth i use, which works fine.

 

auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \

    --kerberos /usr/lib/squid/negotiate_kerberos_auth -s HTTP/proxy2.internal.domain.tld@REALM \

    --ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego --domain=NTDOM

 

The kerberos_ldap_group line which im trying to get working.

external_acl_type memberof-test-group ipv4 %LOGIN  /usr/lib/squid/ext_kerberos_ldap_group_acl -d -i -m 4

     -g test-group \

    -N NTDOM@REALM \

    -D REALM \

    -S dc1.internal.domain.tld@REALM:dc2.internal.domain.tld@REALM

acl test-group external memberof-test-group

and im my config im having als test.

http_access deny test-group

 

I tried also with the –g test-group@ and –g test-group@@REALM

 

 

This is the debug part of the kerberos group auth when starting squid.

 

kerberos_ldap_group.cc(376): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: INFO: Got User: testuser Domain: REALM

support_member.cc(63): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: User domain loop: group@domain test-group@NULL

support_member.cc(91): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Default domain loop: group@domain test-group@NULL

support_member.cc(119): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Default group loop: group@domain test-group@NULL

support_member.cc(121): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Found group@domain test-group@NULL

support_ldap.cc(898): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setup Kerberos credential cache

support_krb5.cc(127): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Set credential cache to MEMORY:squid_ldap_3420

support_krb5.cc(138): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Get default keytab file name

support_krb5.cc(144): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Got default keytab file name /etc/squid/keytab.PROXY2-HTTP

support_krb5.cc(158): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Get principal name from keytab /etc/squid/keytab.PROXY2-HTTP

support_krb5.cc(169): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Keytab entry has realm name: REALM

support_krb5.cc(181): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Found principal name: HTTP/proxy2.internal.domain.tld@REALM

support_krb5.cc(196): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Got principal name HTTP/proxy2.internal.domain.tld@REALM

support_krb5.cc(260): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Stored credentials

support_ldap.cc(927): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Initialise ldap connection

support_ldap.cc(933): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Canonicalise ldap server name for domain REALM

support_resolv.cc(379): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.REALM record to dc1.internal.domain.tld

support_resolv.cc(379): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.REALM record to dc2.internal.domain.tld

support_resolv.cc(379): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.REALM record to dc2.internal.domain.tld

support_resolv.cc(379): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved SRV _ldap._tcp.REALM record to dc1.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 1 of REALM to dc1.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 2 of REALM to dc1.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 3 of REALM to dc1.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 4 of REALM to dc2.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 5 of REALM to dc2.internal.domain.tld

support_resolv.cc(207): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Resolved address 6 of REALM to dc2.internal.domain.tld

support_resolv.cc(407): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Adding REALM to list

support_resolv.cc(443): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Sorted ldap server names for domain REALM:

support_resolv.cc(445): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Host: dc2.internal.domain.tld Port: 389 Priority: 5 Weight: 100

support_resolv.cc(445): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Host: dc1.internal.domain.tld Port: 636 Priority: 5 Weight: 100

support_resolv.cc(445): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Host: dc2.internal.domain.tld Port: 389 Priority: 10 Weight: 100

support_resolv.cc(445): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Host: dc1.internal.domain.tld Port: 636 Priority: 10 Weight: 100

support_resolv.cc(445): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Host: REALM Port: -1 Priority: -2 Weight: -2

support_ldap.cc(942): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc2.internal.domain.tld:389

support_ldap.cc(953): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI

support_sasl.cc(276): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error

support_ldap.cc(957): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

support_ldap.cc(942): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc1.internal.domain.tld:636

support_ldap.cc(953): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI

support_sasl.cc(276): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error

support_ldap.cc(957): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

support_ldap.cc(942): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc2.internal.domain.tld:389

support_ldap.cc(953): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI

support_sasl.cc(276): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error

support_ldap.cc(957): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

support_ldap.cc(942): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setting up connection to ldap server dc1.internal.domain.tld:636

support_ldap.cc(953): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI

support_sasl.cc(276): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error

support_ldap.cc(957): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

support_ldap.cc(942): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Setting up connection to ldap server REALM:389

support_ldap.cc(953): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Bind to ldap server with SASL/GSSAPI

support_sasl.cc(276): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error

support_ldap.cc(957): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

support_ldap.cc(979): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Error during initialisation of ldap connection: Success

support_ldap.cc(1048): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Error during initialisation of ldap connection: Success

support_member.cc(132): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: INFO: User testuser is not member of group@domain test-group@NULL

kerberos_ldap_group.cc(411): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: ERR

 

 

I use samba4 AD DC’s

 

The ssl certs are tested and correct, ssl BUMP is running and works fine.

The ssl root-CA is also in place and also published to the pc's

 

So im a bit lots now where to look or what im doing wrong here.

Anyone any tips?

 

 

Greetz,

 

Louis


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Loading...