Tamás Becz wrote:
Now with a new solution I also need to query a central ldap database for authorization info: I need to get a given attribute off of user records and present them to the NAS. I was pointing my finger at Filter-Id, but purely because the NAS docs points at it, it could really be anything.
You probably don't want to use Filter-ID. It has a pre-defined meaning. Using it for another purpose is bad.
If I omit the proxy part, then it's just a straightforward ldap config with adding the attribute as a reply Item mapped to Filter-ID in the ldap.attrmap with +=, getting rid of reading the userPassword so that no one tries to auth against the password there and enable ldap in the authorize section.
OK.
However, when I then proxy the request these extra Filter-Ids are lost: they are neither proxied (which is just as well, I really don't know what would the homeserver do about it) nor are they sent in my reply. I've found traces of something like this being discussed that this is because there is a separate data structure, but that is over a decade old, and I'm a bit confused on how this supposed to work.
What you're *not* saying is that you're putting the Filter-ID into the reply list. That gets replaced by the reply from the home server. If you want the attributes kept... put them in another list.
Is there a way to keep does attributes (or to get them after proxying, either in post-proxy or post-auth maybe?) by using rlm_ldap?
No. Put the attributes into the "control" list. That's what it's for. Then, copy them to the reply in post-auth. Alan DeKok.