Version 3 ldap Generic

[Cody Ritts]

Hello,

I am upgrading from FR 1.1 to 3.0.4.

I am struggling to understand the the syntax for upgrading my $GENERIC$ 
statement.  I have only found 3 threads discussing, which I did non 
fully understand, and am not sure they covered my problem.

In my old ldap.attrmap I have the following lines:

> replyItem	Framed-IP-Address		dslIPAddress
> replyItem	Idle-Timeout			dslIdleTimeout
> replyItem	$GENERIC$			dslACLin
> replyItem	$GENERIC$			dslACLout
> replyItem	$GENERIC$			dslINSPECTin
> replyItem	$GENERIC$			dslINSPECTout
> replyItem	$GENERIC$			dslStatus


The example ldap contents of dslACLin and dslACLout are:
>   dslACLin: cisco-avpair += "ip:inacl=OUTBOUND"
>   dslACLout: cisco-avpair += "ip:outacl=FIREWALL"


So, in my mods-enabled/ldap, when I added:
>   valuepair_attribute = "dslACLin"

In my radtest reply, I do get a:
>    Cisco-AVPair = "ip:inacl=OUTBOUND"

But based on one of the other threads and the way that it is configured, 
I will assume that "valuepair_attribute =" is only good once?

Good news for me however, down at the bottom of update{}
I see the following.

> #  These are provided for backwards compatibility.
> #  Where only a list is specified as the RADIUS attribute,
> #  the value of the LDAP attribute is parsed as a valuepair
> #  in the same format as the 'valuepair_attribute' (above).
> #	control: += 'radiusCheckAttributes'
> #       reply:   += 'radiusReplyAttributes'


so I add:
>   reply:  += 'dslACLout'

Then radiusd -X gets:
>> /usr/local/etc/raddb/mods-enabled/ldap[85]: Invalid source for list '+='

so I try :=, and = with the same.  To be honest, I dont know what the 
source list is.  After reading man unlang I see that there is "update 
<list>"  but then again, it says right above the block that this is not 
a unlang update format so, I am still lost.

So I try this:

> reply:Cisco-AVPair  += 'dslACLout'

And the server will start, but it does not parse out the avpair, this is 
the radius reply:
>   Cisco-AVPair = "cisco-avpair += \"ip:outacl=FIREWALL\""

So I dont know what I am doing wrong there, but I also bear in mind that 
this is just a "compatibility" feature, so when that gets dropped I will 
still be in the same spot.

That makes me wonder about how I should have done that in the first 
place.  I suppose I used GENERIC because it was in the same file as the 
other attributes, I tried it and it worked.  Is there a "more correct" 
way of doing that for long term support?  Like creating dictionary 
entries for those attributes then map them?

Also, as an interim solution until I can update my schema and management 
applications, if I add dslACLout to the dictionary, and map it, then is 
it possible to use unlang and regex in post-auth/"update reply" to parse 
"cisco-avpair +=" out of dslACLout and then add it back in as cisco-avpair?

Thanks in advance any help,

Cody