Re: LDAP attribute mapping
>
> or...
>
> update [] {
> ...
> }
>
> update reply {
> config:Auth-Type = Reject
> Reply-Message = "Go away"
> }
That one gets my vote.
update {
}
defaults to request.
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
Phil Mayers wrote:
> +1
>
> Personally I'd rather the latter format everywhere, even unlang:
>
> update {
> request:foo = 1
> }
Yeah. That shouldn't be hard. Maybe I can look at it in 2 weeks,
after IETF.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
On Tue, Oct 30, 2012 at 07:02:02PM +, Phil Mayers wrote:
> +1
>
> Personally I'd rather the latter format everywhere, even unlang:
>
> update {
> request:foo = 1
> }
Agreed - having that option would make things much tidier when
several things in different lists are being updated at once.
update {
config:Auth-Type = Reject
reply:Reply-Message = "Go away"
}
On the other hand, the current form is nicer when updating a few
attributes all in one list, so maybe both...? :)
or...
update [] {
...
}
update reply {
config:Auth-Type = Reject
Reply-Message = "Go away"
}
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
+1
Personally I'd rather the latter format everywhere, even unlang:
update {
request:foo = 1
}
John Dennis wrote:
>
>What I'd like to see is the individual modules converging on common
>behavior so there is a consistent model.
>
>I suspect a number of the modules were written independently and
>contributed, their diverse heritage makes for some awkwardness when
>viewing the totality of FreeRADIUS.
>
>If rlm_rest and rlm_cache have attribute models that are elegant and
>well thought out then let's move everything to that model. On the other
>
>hand if ulang is conceptually cleaner then lets move rlm_rest and
>rlm_cache to a ulang solution. Pick one idea and make everything follow
>
>those rules. Consistency is a virtue and should be a goal of 3.0 IMHO,
>it will make using FreeRADIUS easier. A major version upgrade is one of
>
>the very few opportunities available to clean up.
--
Sent from my mobile device, please excuse brevity and typos.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
> >> If rlm_rest and rlm_cache have attribute models that are elegant and well >> thought out then let's move everything to that model. On the other hand if >> ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a >> ulang solution. Pick one idea and make everything follow those rules. > > With 2.0 there was an effort to maintain configuration compatibility, which > limited standardisation efforts. Maintaining config compatiblity with 3.0 we > don't have that constraint. * Were not maintaining config compatibility with 3.0 so we don't have that constraint. Just talking with Alan, apparently whole subsections can be referenced. This is especially useful for things like TLS, where you're using the same certs in multiple places, and you can define a global TLS section and then reference it from the various module configuration. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
On 30 Oct 2012, at 13:00, John Dennis wrote: > On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote: >> Quick poll. >> >> For 3.0 the ldap module will be moving away from using the >> ldap.attrmap file and instead use a config based mapping. >> >> There are a few ways we are considering for organising the mapping. >> >> We can use something like the existing unlang: >> >> Or something like rlm_rest and rlm_cache: >> >> It really depends on whether people are actually using the full >> ldap.attrmap, or whether they're just pulling out one or two >> attributes. Each approach is as efficient as the other performance >> wise, so it comes down to which one people prefer. >> >> Any thoughts? > > What I'd like to see is the individual modules converging on common behavior > so there is a consistent model. This is what's happening. We now have a common API for connections which means that managing connection pools is done in a consistant and easy to understand way. TLS configuration is also being standardised as much as possible, though there will probably be some minor differences where libraries only expose a subset of OpenSSL configuration parameters. > I suspect a number of the modules were written independently and contributed, > their diverse heritage makes for some awkwardness when viewing the totality > of FreeRADIUS. Yes. > If rlm_rest and rlm_cache have attribute models that are elegant and well > thought out then let's move everything to that model. On the other hand if > ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a > ulang solution. Pick one idea and make everything follow those rules. With 2.0 there was an effort to maintain configuration compatibility, which limited standardisation efforts. Maintaining config compatiblity with 3.0 we don't have that constraint. That said, discuss whether using exactly the same syntax is useful. People may get more confused and try to use other unlang statements within module configs. > Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using > FreeRADIUS easier. A major version upgrade is one of the very few > opportunities available to clean up. Yes. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote: Quick poll. For 3.0 the ldap module will be moving away from using the ldap.attrmap file and instead use a config based mapping. There are a few ways we are considering for organising the mapping. We can use something like the existing unlang: Or something like rlm_rest and rlm_cache: It really depends on whether people are actually using the full ldap.attrmap, or whether they're just pulling out one or two attributes. Each approach is as efficient as the other performance wise, so it comes down to which one people prefer. Any thoughts? What I'd like to see is the individual modules converging on common behavior so there is a consistent model. I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS. If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules. Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of the very few opportunities available to clean up. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP attribute mapping
I pull out only the attributes I need and change ldap.attrmap to match my
schema. Personally, I can live with either config method.
Arran Cudbard-Bell wrote:
>Quick poll.
>
>For 3.0 the ldap module will be moving away from using the ldap.attrmap file
>and instead use a config based mapping.
>
>There are a few ways we are considering for organising the mapping.
>
>We can use something like the existing unlang:
>
>update control {
> Cleartext-Password := userpassword
>}
>
>update reply {
> User-Name = radiusUserName
>}
>
>update outer.reply {
> Reply-Message = radiusReplyMessage
>}
>
>Or something like rlm_rest and rlm_cache:
>
>update {
> control:Cleartext-Password := userpassword
> reply:User-Name = radiusUserName
> reply.outer:User-Name = radiusUserName
>}
>
>It really depends on whether people are actually using the full ldap.attrmap,
>or whether they're just pulling out one or two attributes. Each approach is as
>efficient as the other performance wise, so it comes down to which one people
>prefer.
>
>Any thoughts?
>
>-Arran
>
>
>
>
>
>
>-
>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP attribute mapping
Quick poll.
For 3.0 the ldap module will be moving away from using the ldap.attrmap file
and instead use a config based mapping.
There are a few ways we are considering for organising the mapping.
We can use something like the existing unlang:
update control {
Cleartext-Password := userpassword
}
update reply {
User-Name = radiusUserName
}
update outer.reply {
Reply-Message = radiusReplyMessage
}
Or something like rlm_rest and rlm_cache:
update {
control:Cleartext-Password := userpassword
reply:User-Name = radiusUserName
reply.outer:User-Name = radiusUserName
}
It really depends on whether people are actually using the full ldap.attrmap,
or whether they're just pulling out one or two attributes. Each approach is as
efficient as the other performance wise, so it comes down to which one people
prefer.
Any thoughts?
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
