Hello Arran, ________________________________________ Von: freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org [freeradius-users-bounces+tobias.hachmer=stadt-frankfurt.de@lists.freeradius.org]" im Auftrag von "Arran Cudbard-Bell [a.cudbardb@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@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