>Here's the complete debug (excluding the server start-up messages). There's >rather a lot of it which is why I tried to post the bits relevant to what I'm >trying (rather unsuccessfully :-) ) to understand. > >rad_recv: Access-Request packet from host 10.127.240.217 port 1645, id=36, >length=148 .. >[ldap_staff] search failed >rlm_ldap: ldap_release_conn: Release Id: 0 >++[ldap_staff] returns notfound >++? if (ok) >? Evaluating (ok) -> FALSE >++? if (ok) -> FALSE >++- entering else else {...} .. >+++[ldap_student] returns ok >+++? if (ok) >? Evaluating (ok) -> TRUE >+++? if (ok) -> TRUE >+++- entering if (ok) {...}
That is the unlang construction - in default virtual server. >++++[control] returns ok I assume this is where you set temp attribute. >+++- if (ok) returns ok >+++ ... skipping else for request 0: Preceding "if" was taken >++- else else returns ok And then it goes on ... >Sending Access-Challenge of id 36 to 10.127.240.217 port 1645 .. >rad_recv: Access-Request packet from host 10.127.240.217 port 1645, id=37, >length=159 etc. And many requests later you ask about it: >++? if (control:Tmp-String-0 == "ldap-student") > (Attribute control:Tmp-String-0 was not found) .. and it's not there. Of course it's not, since it wasn't set during processing of that Access-Request but much earlier in the exchange. I would suggest that you move unlang statements to inner-tunnel virtual server. You can do update reply and set Reply-Message in authorize there (forget about temp attribute and changeing it in post-auth). Just enable use_tunneled_reply in peap section of eap.conf and Reply-Message will be passed on from inner tunnel into the final reply. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html