Re: [squid-users] Single Forest Multiple Domains kebreos setup (squid_kerb_ldap)
Hi Bilal,
GIGO . wrote:
Problem:
Single FOrest Multiple domains where as Root A is empty with no users. Domain B C have no trust configured between each other. The internet users belong to Domain B Domain C. We want to enable users from both domains to authenticate via Kerberos and authrorized through LDAP.
If you serve multiple Kerberos realms add a HTTP/f...@realm service principal per realm to the
HTTP.keytab file and use the -s GSS_C_NO_NAME option with squid_kerb_auth..
i think this is the only change required in squid configuration to authenticate and authorize from multiple domains?
I never tried this with non-hierarchical or non-Windows domains, but I
would give it a go:
As there is at least a one-way trust from A to B/C, you don't need
multiple service principals for the proxy. What you would do is create a
single service principal in domain A.
When users from domains B and C are accessing the proxy, they should be
able to discover (or be told in krb5.conf) that the service principal is
in domain A and will acquire a service ticket from that domain. The
proxy will then be able to verify these tickets.
I would use -s HTTP/f...@a.com. You don't need to set GSS_C_NO_NAME.
Please confirm that am i to create SPN as below for this setup to work.
I don't have experience with msktutil. I created the SPN and keytab file
for a computer account on the Windows DC:
ktpass.exe -princ HTTP/f...@a -mapuser accountna...@a -crypto
rc4-hmac-nt -ptype KRB5_NT_SRV_HST +rndpass -out krb5.keytab
PLease guide me on the changes that would be required in the krb5.conf file ?
If the domain structure is reflected in DNS (i.e. with SRV records) and
the proxy is able to query the forest DNS you shouldn't need anything in
the krb5.conf of the proxy. Try dig _kerberos._tcp.b.com on the proxy.
For simplicity I would add the default realm:
[libdefaults]
default_realm = A.COM
Eventually and you will have to add a [capaths] section to define the
trust relationship:
[capaths]
B.COM = {
A.COM = .
}
C.COM = {
A.COM = .
}
This is only for the proxy and applies to a Windows2003 forest. The
clients might need different settings.
Regards,
Fabian
Re: [squid-users] Problems setting up Kerberos authentication
Hi all, Fabian Hugelshofer wrote: Markus Moeller wrote: Continuation needed means that the GSSAPI exchange has not finished and the server needs more data from the client. Can you see in wireshark if the token length is the one squid_kerb_auth says it is squid_kerb_auth: Got 'YRYI...' from squid (length: 3607) Update: I could find the reason for the error message. Even though it was a hierarchical domain structure, the proxy server performed a transit domain path verification. One domain of the path was not in the transited domains list. Not sure whether this is a Microsoft or Heimdal issue. As a workaround I manually spefified the list of transit domains in the [capatsh] section of krb5.conf. This made it work. For details see my posts on the Heimdal mailing list: https://list.sics.se/sympa/arc/heimdal-discuss/2010-03/msg00096.html Regards, Fabian
Re: [squid-users] Re: Problems setting up Kerberos authentication
Markus Moeller wrote: It looks like a configuration error. Also I recall Heimdal had some issues with Cross realms. But you say all clients are on Windows only the server uses squid with Heindal, so the problem might be on the Windows side. Do the three AD domains trust each other ? Yes, all clients use Windows. Domain trust between all the involved domains is ok.
Re: [squid-users] Problems setting up Kerberos authentication
Markus Moeller wrote:
Can you download kerbtray from microsoft and list the tickets you have
on XP on a working and failing machine. Can you alos capture with
wireshark the traffic on port 88 ?
Using kerbtray did not show a difference. Capturing the traffic on port
88 shows that in both cases the client walks through the domain
hierarchy and at the end gets a ticket for the proxy service.
Comparing the tickets that are sent in the HTTP request with Wireshark
did not show any difference at all. For what I can see there
I used debug_options ALL,1 29,9. Both cases start with:
2010/03/04 13:39:49| authenticateValidateUser: Validating Auth_user
request '(nil)'.
2010/03/04 13:39:49| authenticateValidateUser: Auth_user_request was NULL!
2010/03/04 13:39:49| authenticateAuthenticate: broken auth or no
proxy_auth header. Requesting auth header.
2010/03/04 13:39:49| authenticateFixHeader: headertype:38 authuser:(nil)
2010/03/04 13:39:49| authenticateNegotiateFixErrorHeader: Sending
type:38 header: 'Negotiate'
2010/03/04 13:39:50| authenticateAuthenticate: header Negotiate YII...
2010/03/04 13:39:50| authenticateAuthenticate: This is a new checklist
test on FD:71
2010/03/04 13:39:50| authenticateAuthenticate: no connection
authentication type
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '1'.
2010/03/04 13:39:50| authenticateDecodeAuth: header = 'Negotiate YII...
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128'.
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128' now
at '1'.
2010/03/04 13:39:50| authenticateDecodeNegotiateAuth: Negotiate
authentication
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: auth state
negotiate none. Negotiate YII...
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: Locking
auth_user from the connection.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '2'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateStart: auth_user_request '0x8552f98'
2010/03/04 13:39:50| authenticateNegotiateStart: auth state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: 'YII...
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '3'.
2010/03/04 13:39:50| squid_kerb_auth: Got 'YR YII... ' from squid
(length: 3607).
Then for the non-working case:
2010/03/04 13:39:50| squid_kerb_auth: continuation needed
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Helper:
'0x82d5d40' {TT oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=}
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Need to challenge
the client with a server blob 'oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo='
The only difference that I can see is that in the non-working case the
ticket length is 3607 and in the working case 2643.
## With a user from non-working domain B1.B.EXAMPLE.COM
# kinit us...@b1.b.example.com
us...@b1.b.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
2010/03/04 15:26:51| squid_kerb_auth_test: gss_init_sec_context()
failed: An unsupported mechanism was requested. unknown mech-code 0
for mech unknown
Token: NULL
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@b1.b.example.com's Password:
kinit: krb5_get_init_creds: Server
(HTTP/proxy.d1.d.example@b1.b.example.com) unknown
This is correct it should not work as there is no
HTTP/proxy.d1.d.example@b1.b.example.com principal. You need to use
another call to get a TGT for HTTP/proxy.d1.d.example.com like:
kinit us...@b1.b.example.com
kgetcred HTTP/proxy.d1.d.example@a.example.com
klist
At the moment I don't have kgetcred available. I will try this later.
Thanks for the hint.
Using a user from the domain that is not working on a computer of the
domain that is, did not help. Is definitely somehow domain-related. The
tickets
Re: [squid-users] Problems setting up Kerberos authentication
Markus Moeller wrote:
Continuation needed means that the GSSAPI exchange has not finished and
the server needs more data from the client. Can you see in wireshark if
the token length is the one squid_kerb_auth says it is
squid_kerb_auth: Got 'YRYI...' from squid (length: 3607)
I could confirm that the data that the client sends in the HTTP request
is the same that is received by squid_kerb_auth. YR is added by squid
(the space in the log of my last post got lost).
Further, I discovered that authentication is working for users from
certain domains, but not for those at whose location the proxy is
standing at. I describe the AD domain setup in more details:
The computer account that is associated with the service principal in
the keytab file is from domain A.EXAMPLE.COM. Users, for who access is
not working, are from domain B1.B.EXAMPLE.COM. Access is working for
users from C.EXAMPLE.COM and a few others. The users from these other
domains have been tested by starting IE as a user from that domain on a
computer in domain C.EXAMPLE.COM. I forgot to mention that all the
clients are Windows XP with IE7.
The FQDN of the proxy is not in the Windows domain hierarchy. It is
proxy.d1.d.example.com.
I compiled squid_kerb_auth_test from Squid 3.1. On the proxy:
## With a user from non-working domain B1.B.EXAMPLE.COM
# kinit us...@b1.b.example.com
us...@b1.b.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
2010/03/04 15:26:51| squid_kerb_auth_test: gss_init_sec_context()
failed: An unsupported mechanism was requested. unknown mech-code 0 for
mech unknown
Token: NULL
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@b1.b.example.com's Password:
kinit: krb5_get_init_creds: Server
(HTTP/proxy.d1.d.example@b1.b.example.com) unknown
## With a user from the domain of the proxy (A.EXAMPLE.COM)
# kinit us...@a.example.com
us...@a.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
Token: YIIF...
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@a.example.com's Password:
Tomorrow I will try with a user from another domain that is working and
that is outside A.EXAMPLE.COM. The content of my krb5.conf is:
[libdefaults]
default_realm = A.EXAMPLE.COM
[realms]
A.EXAMPLE.COM = {
kdc = 10.0.0.1
kdc = 10.0.0.2
}
B1.b.EXAMPLE.COM = {
kdc = 10.1.0.1
kdc = 10.1.0.2
}
[domain_realm]
.example.com = A.EXAMPLE.COM
example.com = A.EXAMPLE.COM
.d1.d.example.com = A.EXAMPLE.COM
d1.d.example.com = A.EXAMPLE.COM
Fabian
[squid-users] Problems setting up Kerberos authentication
Hi all, I am trying to set up Kerberos authentication with Squid 2.7.stable7 on Linux. I use Heimdal 1.3.1. I already had success doing so on two proxies, but in a third environment, authentication fails. In squid.conf I have the following entries: auth_param negotiate program /opt/squid/libexec/squid_kerb_auth -d -s HTTP/proxy.example@example.com acl REQUIRE_AUTH proxy_auth REQUIRED http_access allow src_localhost http_access deny !REQUIRE_AUTH http_access allow all Environmental variables KRB5_CONFIG and KRB5_KTNAME are set. By using kinit on the proxy it is possible to obtain a user ticket (auth with a password) and obtaining the service principal ticket (HTTP/proxy.example@example.com, auth with the keytab file) works fine, too. When a client tries to use the proxy, the conversation is as following: * User requests website * Proxy responds with 407 and sets header Proxy-Authenticate: Negotiate * User sends another request for the website and sends the ticket. From Wireshark: OID: 1.3.6.1.5.5.2 (SPNEGO) negTokenInit MechTypes: 1.2.840.48018.1.2.2 (MS KRB5), 1.2.840.113554.1.2.2 (KRB5), 1.3.6.1.4.1.311.2.2.10 (NTLMSSP) krb5_blob: Kerberos AP-REQ Realm: EXAMPLE.COM Server Name (type 2, service and instance): HTTP/proxy.domain.com * squid_kerb_auth reports: squid_kerb_auth: Got 'YRYI...' from squid (length: 3607) squid_kerb_auth: parseNegTokenInit failed with rc=102 squid_kerb_auth: continuation needed. * Proxy replies with 407: GSS-API:SPNEGO:negTokenTarg negResult: accept-incomplete supportedMech: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP) * Client gets an authentication pop-up where he can enter a username and password, but this does not work. This is probably related to the suggested NTLMSSP. * User requests URL again, this time with an NTLM authenticator GSS-API:SNPEGO:negTokenTarg NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_NEGOTIATE * squid_kerb_auth reports: squid_kerb_auth: Got 'KKoS...' from squid (length: 67) squid_kerb_auth: parseNegTokenInit failed with rc=300 squid_kerb_auth: Invalid GSS-SPNEGO query [KKoS...]. NA Invalid GSS-SPNEGO query. * Server replies to client with Proxy-Authenticate: Negotiate Invalid Does anyone have an idea what is going wrong, i.e. why the authentication helper replies with continuation needed and what I should try to debug? Best regards, Fabian
