hello
Firstly I apologise for this being quite a long post as I've included
some wire sniffed traffic hoping it may help with any diagnosis you
might be able to offer.
I have been using without issue, basic authentication for web
browsers using Active Directory as the authentication source.
The Active Directory host was recently patched with a number of
updates. Two in particular seem relevant, KB926122 (Active Directory
Remote Code Execution vulnerability - Security Bulletin, MS07-039)
and KB935966 (DNS RPC Remote Code Execution). The first of these
overcomes a vulnerability that allows elevated privileges from a
particularly crafted LDAP request.
So in the squid (2.5.stable9, also tested and verified the same in
2.6.5) config I have these (obfsucated here - the domain name is
replaced by A,B,C,D) settings:
auth_param basic program /usr/lib/squid/ldap_auth -b
"dc=A,dc=B,dc=C,dc=D" -f (cn=%s) -H "ldap://AD_HOST/"; -D cn=user-to-
bind-as,cn=Users
,dc=A,dc=B,dc=C,dc=D -w"binding password"
and
external_acl_type Active_Directory_Groups %LOGIN /usr/lib/squid/
squid_ldap_group -b "dc=A,dc=tB,dc=C,dc=D" -f (&(cn
=%u)(memberOf=%g)) -H "ldap://AD_HOST/"; -S -D cn=user-to-bind-
as,cn=Users,dc=A,dc=B,dc=C,dc=D -w"binding password"
acl authenticated_user proxy_auth REQUIRED
acl wwwAccess external Active_Directory_Groups
cn=wwwGroupAccess,cn=Users,dc=A,dc=B,dc=C,dc=D
Using, for example, "http_access allow authenticated_user
wwwAccess" it all worked perfectly.
Then the above patches were applied to the AD_HOST. I cannot find
any useful information regarding exactly the changes that were made
from Microsoft.
Now, upon sending the 407 proxy auth code to the browser and
receiving the credentials nothing happens for about 3 minutes at
which point the auth succeeds and the page loads. in cache.log
warnings are posted about running out of basic authenticators and
recommend increasing the number of children. This hasn't work at all
as the real world load cannot be met by just changing that parameter.
Leaving out the group check and merely asking for an authenticated
user - "http_access allow autneticaed_user" - also doe snot work.
Sniffing the wire between the squid server and the Active Directory
host, shows a simple bind using the DN of the user-to-bind-as which
succeeds.
Then the request about the username from the browser is sent:
LDAPMessage searchRequest(2) "dc=A,dc=B,dc=C,dc=D" wholeSubtree
messageID: 2
protocolOp: searchRequest (3)
searchRequest
baseObject: dc=A,dc=B,dc=C,dc=D
scope: wholeSubtree (2)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: True
Filter: (cn=rolf)
equalityMatch
attributeDesc: cn
assertionValue: rolf
attributes: 1 item
Item: 1.1
The response to which is odd:
LDAPMessage searchResEntry(2) "CN=rolf,OU=container for this
username,DC=A,DC=B,DC=C,DC=D" [1 result]
messageID: 2
protocolOp: searchResEntry (4)
searchResEntry
objectName: CN=rolf,OU=container for this
username,DC=A,DC=B,DC=C,DC=D
attributes: 0 items
[Response To: 7]
[Time: 0.000598000 seconds]
Lightweight-Directory-Access-Protocol
LDAPMessage searchResDone(2) Unknown result(9) (Referral:
ldap://A.B.C.D/CN=Configuration,DC=A,DC=B,DC=C,DC=D) [1 result]
messageID: 2
protocolOp: searchResDone (5)
searchResDone
resultCode: Unknown (9)
errorMessage: Referral:\nldap://A.B.C.D/
CN=Configuration,DC=A,DC=B,DC=C,DC=D
[Response To: 7]
[Time: 0.000598000 seconds]
Then nothing is heard from the Active Directory Host for 189 seconds
and then it responds with a bind request for the user specified from
the browser:
LDAPMessage bindRequest(6) simple
messageID: 6
protocolOp: bindRequest (0)
bindRequest
version: 2
name: CN=rolf,OU=container for this
username,DC=A,DC=B,DC=C,DC=D
authentication: simple (0)
simple: 326B2B35552E4B2E
then squid sends an unbind request:
LDAPMessage unbindRequest(7)
messageID: 7
protocolOp: unbindRequest (2)
unbindRequest
Then it starts all over again and binds as before, then sends the
user and group search request:
LDAPMessage searchRequest(2) "dc=A,dc=B,dc=C,dc=D" wholeSubtree
messageID: 2
protocolOp: searchRequest (3)
searchRequest
baseObject: dc=A,dc=B,dc=C,dc=D
scope: wholeSubtree (2)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: True
Filter: (&(cn=rolf)
(memberOf=cn=wwwGroupAccess,cn=Users,dc=A,dc=B,dc=C,dc=D))
and: (&(cn=rolf)
(memberOf=cn=wwwGroupAccess,cn=Users,dc=A,dc=B,dc=C,dc=D))
Filter: (cn=rolf)
equalityMatch
attributeDesc: cn
assertionValue: rolf
Filter:
(memberOf=cn=wwwGroupAccess,cn=Users,dc=A,dc=B,dc=C,dc=D)
equalityMatch
attributeDesc: memberOf
assertionValue:
cn=wwwGroupAccess,cn=Users,dc=A,dc=B,dc=C,dc=D
attributes: 1 item
Item: 1.1
To which the response is:
LDAPMessage searchResEntry(2) "CN=rolf,OU=container for this
username,DC=A,DC=B,DC=C,DC=D" [1 result]
messageID: 2
protocolOp: searchResEntry (4)
searchResEntry
objectName: CN=rolf,OU=container for this
username,DC=A,DC=B,DC=C,DC=D
attributes: 0 items
[Response To: 24]
[Time: 0.000687000 seconds]
Lightweight-Directory-Access-Protocol
LDAPMessage searchResDone(2) Unknown result(9) (Referral:
ldap://A.B.C.D/CN=Configuration,DC=A,DC=B,DC=C,DC=D) [1 result]
messageID: 2
protocolOp: searchResDone (5)
searchResDone
resultCode: Unknown (9)
errorMessage: Referral:\nldap://A.B.C.D/
CN=Configuration,DC=A,DC=B,DC=C,DC=D
[Response To: 24]
[Time: 0.000687000 seconds]
At which time the authentication succeeds and the page loads.
So we've had to turn off proxy authentication until we can workaround
or solve this issue.
I would be most grateful for any ideas or help.
thank you
rolf.
