Re: Re: Freeradius 3 & LDAP Generic Attributes
The ldap.attrmap syntax in FR2 was: checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem Basically the ldap attributes radiusCheckItem & radiusReplyItem contained FR attr/value pairs which were then added to the corresponding attribute list in FR (e.g. in LDAP radiusReplyItem could be "Primary-DNS-Server := 1.1.1.1"). They wouldn't necessarily need to be distinct check/reply attributes in the new rlm_ldap... it could work more like unlang where an LDAP attribute value could be "control:Disabled := true", and where if the list: portion is omitted it would default to reply. No matter how this happens, there's probably going to need to be a special case syntax made in the rlm_ldap attribute mapping... Best Regards, -Nick
On 12 Apr 2013, at 15:00, Nicholas Lemberger <nick.lemberger@lkfd.net> wrote:
The ldap.attrmap syntax in FR2 was: checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem
Basically the ldap attributes radiusCheckItem & radiusReplyItem contained FR attr/value pairs which were then added to the corresponding attribute list in FR (e.g. in LDAP radiusReplyItem could be "Primary-DNS-Server := 1.1.1.1").
They wouldn't necessarily need to be distinct check/reply attributes in the new rlm_ldap... it could work more like unlang where an LDAP attribute value could be "control:Disabled := true", and where if the list: portion is omitted it would default to reply. No matter how this happens, there's probably going to need to be a special case syntax made in the rlm_ldap attribute mapping...
I was thinking just adding a valuepair_attr = "blah" config item in the ldap config and then doing exactly what you suggested above. It's not much work, i'll take a look at it later today or tomorrow. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 12 Apr 2013, at 15:21, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 12 Apr 2013, at 15:00, Nicholas Lemberger <nick.lemberger@lkfd.net> wrote:
The ldap.attrmap syntax in FR2 was: checkItem $GENERIC$ radiusCheckItem replyItem $GENERIC$ radiusReplyItem
Basically the ldap attributes radiusCheckItem & radiusReplyItem contained FR attr/value pairs which were then added to the corresponding attribute list in FR (e.g. in LDAP radiusReplyItem could be "Primary-DNS-Server := 1.1.1.1").
They wouldn't necessarily need to be distinct check/reply attributes in the new rlm_ldap... it could work more like unlang where an LDAP attribute value could be "control:Disabled := true", and where if the list: portion is omitted it would default to reply. No matter how this happens, there's probably going to need to be a special case syntax made in the rlm_ldap attribute mapping...
I was thinking just adding a valuepair_attr = "blah" config item in the ldap config and then doing exactly what you suggested above.
It's not much work, i'll take a look at it later today or tomorrow.
Done, but somebody's new xlat parser is segfaulting so i'd wait until tomorrow for that to be fixed before testing. -Arran
participants (2)
-
Arran Cudbard-Bell -
Nicholas Lemberger