|
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 squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
