Hi All,

Following from previous threads the old attribute mapping scheme in rlm_ldap 
has been removed in the 3.0 branch. Existing mapping files should be converted 
to the new configuration file format.

#
        #  Mapping of RADIUS dictionary attributes to LDAP directory attributes.
        #
        #  WARNING: Although this format is almost identical to the unlang 
        #  update section format, it does *NOT* mean that you can use other
        #  unlang constructs in module configuration files.
        #
        #  Configuration items are in the format:
        #       <radius attribute> <op> <ldap attribute>
        # 
        #  Where:
        #       <radius attribute>:     The destination RADIUS attribute
        #                       with any valid list and request qualifiers.
        #       <op>:           Is any assignment attribute (=, :=, +=, -=).
        #       <ldap attribute>:       The attribute in the associated 
        #                       with user or profile objects in the LDAP 
        #                       directory. If the attribute name is wrapped in 
        #                       double quotes it will be xlat expanded.
        # 
        #  Request and list qualifiers may also be placed after the section
        #  name to set defaults for unqualified RADIUS attributes.
        update reply {
#               control:NT-Password     := ntPassword
#               Reply-Message           := radiusReplyMessage
#               Tunnel-Type             := radiusTunnelType
#               Tunnel-Medium-Type      := radiusTunnelMediumType
#               Tunnel-Private-Group-ID := radiusTunnelPrivategroupId
        }

Unlike normal update sections, the list after update can also contain request 
qualifiers, and the pairs can contain both request and list qualifiers that 
override the default.

The righthand operand may also be xlat expanded (if double quoted), though as 
with any expansion you'll incurr a small performance penalty. I don't really 
see any use cases for this, but it's consistent with normal update section 
behaviour.

Hopefully we'll be able to expand the enhanced update section format to the 
main server config before 3.0 is released.

I was also thinking about possibly adding group and profile update sections. 
Currently the main update section applies to all profiles processed. But wanted 
to see if people would find them useful first. Would you find that useful?

Testing/feedback appreciated.

-Arran



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to