Re: ACL/ACI && SASL

[Turbo Fredriksson <turbo@bayour.com>]

>>>>> "Quanah" == Quanah Gibson-Mount <quanah@stanford.edu> writes:

    Quanah> Hi Turbo, We've been running 2.1 in production since April
    Quanah> of this year, and it has proven to be very stable.  We use
    Quanah> Kerberos V5 extensively, and make use of krb5PrincipalName
    Quanah> to do the mappings you are talking about, which indeed
    Quanah> allows us to have more flexible ACL's.

Could you give me some ACL/ACI examples on how you have set it up?

    Quanah> I will note that for the servers, you will want to compile
    Quanah> them against Heimdal K5 and NOT MIT Kerberos V5 if you are
    Quanah> using threads, as your servers will not be stable
    Quanah> otherwise. ;) For clients, it doesn't really matter too
    Quanah> much.

There's no WAY i'm switching to KTH kerberos! Not for 'sentimental' or
or other 'strange' :) reasons. I'm not going to rebuild my WHOLE site,
with lots of users, usage etc, etc. It will take WAY to much time, effort
and most of all MONEY to switch.

It's just not a viable option if you think of it...

    Quanah> --On Thursday, June 26, 2003 2:20 PM +0200 Turbo
    Quanah> Fredriksson
    Quanah> <turbo@bayour.com> wrote:

    >> I'm trying to convert my OpenLDAP 2.0 server to use ACI so that
    >> I can get 'dynamic' updates of access control.
    >> 
    >> Writing the basic file ACL, I got into a snag when it comes to
    >> SASL authentication.
    >> 
    >> This is what the ACL file looks like:
    >> 
    >> ----- s n i p ----- # No read access as default. Some things is
    >> readable only from # localhost and my own domain!
    >> defaultaccess none
    >> 
    >> # We need to do SASL auth, so the Root DSE must be readable to
    >> anyone access to dn="" by domain=.*\.domain\.tld read by
    >> domain=localhost read
    >> 
    >> # Some things should/must be readable to anyone access to
    >> attr=uid,cn,accountStatus,uidNumber,gidNumber,gecos,homeDirectory,loginSh
    >> ell,entry by aci write by domain=.*\.domain\.tld read by
    >> domain=localhost read
    >> 
    >> # Some things should only be visible if authenticated access to
    >> attr=sn,givenName,krb5PrincipalName by aci write by users read
    >> 
    >> # Some things should be writable (implies read access) to the
    >> user access to
    >> attr=cn,sn,givenName,homePostalAddress,mobile,homePhone,labeledURI,mailFo
    >> rwardingAddress,street,physicalDeliveryOfficeName,mailMessageStore,o,l,st
    >> ,telephoneNumber,postalCode,title by self write by aci write
    >> 
    >> # We must be able to authenticate, so userPassword must be
    >> redable to # anyone access to attr=userPassword by anonymous
    >> auth by aci write
    >> 
    >> access to * by aci write by dn="uid=turbo.+\+realm=DOMAIN.TLD"
    >> write by * none ----- s n i p -----
    >> 
    >> Much of this can probably be removed when I get ACI's to
    >> work...
    >> 
    >> 
    >> Now, with this I can retreive all that I want anonymously, I
    >> get the desired attributes when doing a simple bind.
    >> 
    >> Authenticating (via SASL) as my self, I get the whole object.
    >> 
    >> 
    >> Removing the 'SASL ACL' from "access to *" (which is the main
    >> intention), I _DON'T_ get the desired attributes (which is/was
    >> expected).
    >> 
    >> Now, what I'm trying to do is write a very portable ACL file
    >> which I can use (without /much/ change) on all my OpenLDAP
    >> servers (and future installations). Hence, I don't want to
    >> hardcode any access by 'turbo@DOMAIN.TLD' etc!
    >> 
    >> 
    >> In my production server I use ACL's like this, which work as
    >> expected. The ACL is 'cleaned' to remove crud:
    >> 
    >> ----- s n i p ----- access to dn="uid=(.*),ou=.*" attr=mailHost
    >> by dn="uid=$1.\+realm=DOMAIN.TLD" read by self read ----- s n i
    >> p -----
    >> 
    >> The problem with THIS is that in my development system(s)
    >> (which will eventually migrate to my production servers), I use
    >> multiple backends, with different layouts. For example, one
    >> such backend/db is using 'cn' as user reference:
    >> 
    >> cn=Turbo Fredriksson,ou=People,o=Turbo Fredriksson
    >> 
    >> This object does not contain the 'uid' attribute, so I can't
    >> use the above ACL (not portable anyway), nor can I replace
    >> 'uid' with 'cn' (since my principal is 'turbo', not 'Turbo
    >> Fredriksson').
    >> 
    >> 
    >> Since I'm using (MIT) Kerberos V, I have the krb5PrincipalName
    >> which I'd like to use for the ACL (and later in the ACI's).
    >> This attribute is the 'only' thing that say how/where to get
    >> the password.
    >> 
    >> 
    >> The question now is how to retreive this value, and/or convert
    >> my SASL 'id' (turbo@DOMAIN.TLD) to a DN. Remember, this is a
    >> 2.0 server so I can't use the 'sasl-regexp' things.  If noone
    >> can think of a solution, then I guess I HAVE to start migrating
    >> to 2.1 (maybe this is the better solution anyway since 2.1 is
    >> getting 'stable' :).



    Quanah> -- Quanah Gibson-Mount Senior Systems Administrator
    Quanah> ITSS/TSS/Computing Systems Stanford University GnuPG
    Quanah> Public Key: http://www.stanford.edu/~quanah/pgp.html