[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapd-{ldap,meta} && authentication
Quoting Pierangelo Masarati <ando@sys-net.it>:
> >You talk about 'authz-regexp'. Is that the same thing as 'sasl-regexp', or
> >is there such a thing that I've missed in the man pages (or isn't there)?
>
> Sorry, I forgot to mention that recently some of the "sasl-*" options
> were renamed "authz-*" and the "saslAuthz{To|From}" attribute dropped
> the "sasl" prefix
This is in HEAD I assume... ?
> >>The proxy needs to bind to the remote server with a trusted
> >>identity that can read the credentials, and this administrative
> >>bind can be done via SASL as well.
> >
> >Ah, there it is again...
> >
> >Running both the proxy and the master with '-d -1', I draw the conclution
> >that anonymous read access to the 'krb5PrincipalName' (which is used in
> >the sasl-regexp to find the DN) isn't allowed. I only have AUTH access to
> >it, not READ.
> >
> Can you provide this log?
Instead of removing 'semi-sensitive' information, I could send them to you
privatly (which you can chare within your core development 'community' if
you like - don't mind THAT much, I just don't want to publicise the FQDN's
TO public :) if you like/need it.
This is, however, some snippets that I think matter:
SLAVE:
----- s n i p -----
do_sasl_bind: dn () mech GSSAPI
conn=0 op=3 BIND dn="" method=163
==> sasl_bind: dn="" mech=<continuing> datalen=65
SASL Canonicalize [conn=0]: authcid="turbo"
slap_sasl_getdn: id=turbo [len=5]
slap_sasl_getdn: u:id converted to uid=turbo,cn=REALM,cn=GSSAPI,cn=auth
>>> dnNormalize: <uid=turbo,cn=REALM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=turbo,cn=REALM,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=turbo,cn=REALM,cn=GSSAPI,cn=auth,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=turbo,cn=realm,cn=gssapi,cn=auth,272)=0
<<< dnNormalize: <uid=turbo,cn=realm,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name uid=turbo,cn=realm,cn=gssapi,cn=auth to a DN
slap_sasl_regexp: converting SASL name uid=turbo,cn=realm,cn=gssapi,cn=auth
slap_sasl_regexp: converted SASL name to ldap:///c=SE??sub?(krb5PrincipalName=turbo@REALM)
slap_parseURI: parsing ldap:///c=SE??sub?(krb5PrincipalName=turbo@REALM)
ldap_url_parse_ext(ldap:///c=SE??sub?(krb5PrincipalName=turbo@REALM))
str2filter "(krb5PrincipalName=turbo@REALM)"
put_filter: "(krb5PrincipalName=turbo@REALM)"
put_filter: simple
put_simple_filter: "krb5PrincipalName=turbo@REALM"
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0x405ef2dc ptr=0x405ef2dc end=0x405ef300 len=36
0000: a3 22 04 11 6b 72 62 35 50 72 69 6e 63 69 70 61 ."..krb5Principa
0010: 6c 4e 61 6d 65 04 0d 74 75 72 62 6f 40 xx xx xx lName..turbo@xxx
end get_filter 0
>>> dnNormalize: <c=SE>
=> ldap_bv2dn(c=SE,0)
<= ldap_bv2dn(c=SE,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(c=se,272)=0
<<< dnNormalize: <c=se>
slap_sasl2dn: performing internal search (base=c=se, scope=2)
query template of incoming query = (krb5PrincipalName=)
QUERY NOT ANSWERABLE
QUERY NOT CACHEABLE
ldap_create
ldap_url_parse_ext(ldap://master.domain.tld/)
=>ldap_back_getconn: conn 0x81c6768 inserted
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP master.domain.tld:389
ldap_new_socket: 13
ldap_prepare_socket: 13
ldap_connect_to_host: Trying _MASTER_IP_ADDRESS_:389
[...]
[rw] searchBase: "c=se" -> "c=se"
[rw] searchBase: "(krb5PrincipalName=turbo@REALM)" -> "(krb5PrincipalName=turbo@REALM)"
ldap_search_ext
put_filter: "(krb5PrincipalName=turbo@REALM)"
put_filter: simple
put_simple_filter: "krb5PrincipalName=turbo@REALM"
ldap_send_initial_request
ldap_send_server_request
[...]
ldap_msgfree
send_ldap_result: conn=0 op=0 p=3
send_ldap_result: err=0 matched="" text=""
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=0]: slapAuthcDN="uid=turbo,cn=realm,cn=gssapi,cn=auth"
SASL proxy authorize [conn=0]: authcid="turbo@REALM" authzid="turbo@REALM"
conn=0 op=3 BIND authcid="turbo@REALM"
SASL Authorize [conn=0]: proxy authorization allowed
send_ldap_sasl: err=0 len=-1
send_ldap_response: msgid=4 tag=97 err=0
[...]
connection_input: conn=0 deferring operation: binding
<== slap_sasl_bind: rc=0
conn=0 op=3 BIND dn="uid=turbo,cn=realm,cn=gssapi,cn=auth" mech=GSSAPI ssf=56
do_bind: SASL/GSSAPI bind: dn="uid=turbo,cn=realm,cn=gssapi,cn=auth" ssf=56
do_extended
[...]
----- s n i p -----
MASTER:
----- s n i p -----
conn=0 op=1 SRCH base="c=se" scope=2 deref=0 filter="(krb5PrincipalName=turbo@REALM)"
==> limits_get: conn=0 op=1 dn="[anonymous]"
[...]
=> access_allowed: search access to "uid=turbo,ou=People,o=Swe.Net AB,c=SE" "krb5PrincipalName" requested
[...]
=> acl_mask: access to entry "uid=turbo,ou=People,o=Swe.Net AB,c=SE", attr "krb5PrincipalName" requested
=> acl_mask: to value by "", (=n)
[...]
=> access_allowed: search access denied by =x
----- s n i p -----
> >I've been thinking about a ACI/ACL that can circumvent this (SEARCH access
> >from the proxy for example) but none is something that I want or will work
> >in the long run.
> >
> Not for anonymous, for sure :)
This morning I did it like this (it's just a workaround - I don't like it
just 'for the sake of it' :). It's the closest thing I can think of that doesn't
open up the whole database for an attacker. It CAN I guess, but I can't think
of a _real_ way to exploit it yet...
Created a proxy user - 'uid=proxy,...' - which only have SEARCH access to the
'authentication attributes' (userPassword, krb5PrincipalName, mail and
mailAlternateAddress) that are used one way or the other.