[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd-{ldap,meta} && authentication

Turbo Fredriksson wrote:

Quoting "Pierangelo Masarati" <ando@sys-net.it>:



But for now, I'll stick with back-meta. I can now do simple binds, but not
GSSAPI.


I suggest you stay with back-ldap if you don't need back meta, and boost
up the logs to see what happens with your authz-regexp. Also, a knowledge
of your authz-policy and authzFrom/authzTo design would be helpful.


I've read some about this both on the list and in the man pages, but 'decided'
that I didn't want/need it... The reason for this is that I don't want to
have ANY passwords or anything in a config file on disk. That was the MAIN
(almost the ONLY) reason why I ended up with LDAPv3 (Kerberos V + LDAP).


I understand your point, and I think that's a wise option; to this purpose,
I (we) may need some help and feedback in setting up such a configuration,
to make sure we keep (or make) everything working in that case as well.

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 because
they are used for authorization regardless being related to SASL or to any other
(e.g. internal) authorization mechanism. For backward compatibility, configuration
directives still work with the old name (in the future, a warning to encourage
reconfiguration might be issued), and the "saslAuthz{To|From}" remains as alternate
name for the authorization policy attributes.

Also, I've been thinking about how I could use 'saslAuth{To,From}' in
my setup. It seems more directed to 'authentication on behalf of someone
else' which I'm not trying to do...

My sasl-regexp's are in the thread, but here it is again non the less:

----- s n i p -----
# Regexp for SASL authentication:
sasl-regexp
       uid=(.*),cn=swe.net,cn=gssapi,cn=auth
       ldap:///c=SE??sub?(krb5PrincipalName=$1@SWE.NET)
# Regexp  for SSL cert authentication:
sasl-regexp
       email=(.*),cn=(.*),ou=(.*),o=(.*),c=(.*)
       ldap:///ou=$3,o=$4,c=$5??sub?(&(cn=$2)(|(mail=$1)(mailAlternateAddress=$1)))
----- s n i p -----


Quoting "Pierangelo Masarati" <ando@sys-net.it>:



I would really appreciate if you (or anybody else) could give it
a try and help check/improve the support for other SASL mechs;
it is very unlikely that I'll have a working GSSAPI set up in a
reasonable time with my current resources, and this could limit
the availability of this feature in the next release.



Fair enough. I'll give it a go 'later', but first I must understand
how the CURRENT system works and how I can circumvent any problems
I find...


OK.



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?


This works fine on the master (or slapd with local DB) since that is trying
to AUTH with it while the proxy is trying to SEARCH with it (_before_ it
tries to AUTH I presume)...


During SASL bind, and in general during authz, the LOCAL server performs internal searches, and sets an appropriate flag on the operation that turns SEARCH and READ accesses into AUTH; there is no security concern here, because the operation occurs as if the rootdn were performing it (it's internal). The proxy, of course, needs a regular protocol-based operation to obtain the same info. Here's where the administrative identity of "idassert" comes into play. Of course, you'll need to give that identity the appropriate access to the data that's required for authentication, with the appropriate access level. The code, as it is released now, is likely not working as you intend, because these operations between the proxy and the remote server are performed before bind takes place, and thus anonymously. In this sense, the only breach into security as you intend it the "idassertion" is making, is that there is just one identity the remote server needs to trust from the proxy. In this sense, the remote server needs to be proxy-aware, and appropriate access must be provided to the administrative identity.

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 :)


Another idea (the 'official' one if I read this thread and the man pages
correctly) is to use a special DN/pw combo that have READ/SEARCH access
to this (krb5PrincipalName) attribute. But that will still require a
password in slapd.conf. No biggie perhaps, since ACI/ACLs can be written
to _limit_ (really limit! :) what it can do/read. But still. I don't like
the idea....


That's the idea of the idassert stuff... And you don't necessarily need a password in the proxy's slapd.conf, since the proxy can use SASL to bind with the administrative identity; I haven't tested it with GSSAPI, but I presume in the end it should work... maybe after some tweaking :)

Ciao, p.




   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497