[squid-users] unable to get squid kerberos group working.
L.P.H. van Belle
belle at bazuin.nl
Tue Feb 21 10:00:34 UTC 2017
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 at 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 at REALM \
-D REALM \
-S dc1.internal.domain.tld at REALM:dc2.internal.domain.tld at 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 at domain test-group at NULL
support_member.cc(91): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Default domain loop: group at domain test-group at NULL
support_member.cc(119): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Default group loop: group at domain test-group at NULL
support_member.cc(121): pid=3420 :2017/02/21 10:24:35| kerberos_ldap_group: DEBUG: Found group at domain test-group at 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 at 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 at 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 at domain test-group at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170221/c0b21593/attachment-0001.html>
More information about the squid-users
mailing list