AW: [v3] LDAP access_attribute

[Hachmer, Tobias]

Hello Arran,
________________________________________
Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de at lists.freeradius.org [freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de at lists.freeradius.org]" im Auftrag von "Arran Cudbard-Bell [a.cudbardb at freeradius.org]
Gesendet: Dienstag, 26. November 2013 18:19
An: FreeRadius users mailing list
Betreff: Re: [v3] LDAP access_attribute

On 26 Nov 2013, at 10:55, Hachmer, Tobias <Tobias.Hachmer at stadt-frankfurt.de> wrote:
>> what are the considerations to change the behavior regarding “access_attribute” in ldap from the “access_attr” in v2?
>> From a ldap perspective is it easier to administer user objects in ldap when you can see directly if a user has access or not.
> Hmm the comment in mods-available/ldap is misleading. I'll fix it.
> If you set access_positive 'yes' and the string value of the attribute is 'false', the user will still be locked out.

Yeah, from mods-available/ldap I understood that (access_positive = yes) only the existence of the attribute controls whether the user is locked out or not irrespective of the attributes value.

> The idea behind the new logic is to support:
> userAccountEnabled (access_positive = yes)
> userAccountDisabled (access_positive = no)

Please don't misunderstand me. The new logic "access_positive" is quite good. This is not my point I am talking about.

> But I sort of take your point (though I think it's a matter of personal preference).
> The code will now check for:
> userAccountDisabled (access_positive = no) with value 'false' (case insensitive)
> In which case the user will be allowed to log in.
> So in both cases an attribute with value 'false' negates whatever the normal result would of been.

Yeah, my point is that the attribute's (e.g. userAccountDisabled) value (e.g. a simple boolean TRUE/ FALSE) should control whether the user is locked out or not, not the existence on its own.
The code changes you have made respect this?

userAccountEnabled (access_positive = yes)
 - if the value is TRUE (or anything but FALSE) the user is accepted
 - if the value is FALSE the user is rejected

userAccountDisabled (access_positive = no)
  - if the value is TRUE (or anything but FALSE) the user is rejected
  - if the value is FALSE the user is accepted

Thanks for the changed explanation but I think this is not bulletproof enough.

                # If this is undefined, anyone is authorised.
                # If it is defined, the contents of this attribute
                # determine whether or not the user is authorised
#                access_attribute = "dialupAccess"

This is very clear as it says the __contents__ of this attribute determine ...

                # Control whether or not "access_attribute" is used to
                # determine authorization. If set to "yes", then
                # "access_attribute" existing means "allow access".
                # "access_attribute" not existing means "deny access"
                #
                # If set to "no", then
                # "access_attribute" existing means "deny access".
                # "access_attribute" not existing means "allow access"
                #
                # In either case if the attribute is present but has
                # a value of 'false', the result is negated.
#                access_positive = yes

Here the words "existing" and "present" are a bit confusing. From my point of view the explanation would be much clearer and better to understand if you give examples with contents, like e.g. :
                # Control whether or not "access_attribute" is used to
                # determine authorization. If set to "yes", then
                # "dialupAccess" set to "TRUE" or anything but "FALSE" means "allow access".
                # "dialupAccess" set to "FALSE" means "deny access"
                #
                # If set to "no", then
                # "dialupAccess" set to "FALSE" means "allow access".
                # "dialupAccess" set to "TRUE" or anything but "FALSE" means "deny access"
                #
                # In either case if the attribute is present but has
                # a value of 'false', the result is negated.
#                access_positive = yes

Kind regards,
Tobias Hachmer