As far as I am aware (from years of working at ISP's), neither will a RADIUS server send nor most NAS devices ever check the status of any attribute post login (I don't even think they can, but it's been a long time since I've read the RFC's). Meaning, if you change the session timeout, it wont apply to any active sessions. The most that ever happens after authentication is radius accounting messages, which the NAS may send when a users session ends, or really whenever it wants (e.g. if it's resetting counters because they've exceeded the maximum storage size of the radius accounting attribute, or on some devices when you reset the interface counters it sends an accounting message with the old counter statistics before doing so).
The only way to guarantee the policy change is made is to disconnect the user and force them to re-authenticate. In our case, we had this issue come up when DSL users changed bandwidth plans, and we had to disconnect them after making a change to that attribute. Justin On May 23, 2008, at 9:47 PM, Tuc at T-B-O-H.NET wrote: > Hi, > > What it boils down to is that when you auth, you have the potential > for a "Session-Timeout" reply. Lets say its 120 minutes. You get > back that > you are authorized with that attribute. > > You send the accounting start record and off the user goes. 10 > minutes > into the session, the operators/a process/whatever decides to change > your Radius > entry so that the new Session-Timeout would be 5 minutes. How, if at > all, does > the NAS become aware of this? > > It doesn't seem that accounting records play into any of this. I > see where in 2866 you send a type 4, and get a type 5 back > (Accounting-Request > and Accounting-Response). The Accounting-Response seems like it only > says > "I've seen, I've recorded, thank you". If the ID was deleted, it > appears it > might not care. > > I'm just wondering except for constantly re-authorizing and getting > the Session-Timeout (Or worse, an Access-Reject) is there any way > for a NAS > to know that the Session-Timeout has expired, the ID is no longer > valid, etc. > > Thanks, Tuc >> >> Why don't you just ask your question, and if anyone can help you or >> point >> you in the right direction we will? I know you said it is not a >> Cisco >> product question, but there have been enough emails already that >> initially >> asking the question, but asking for direct replies instead of to >> the list >> because it wasn't a Cisco question, would probably have been more >> efficient. >> >> Thanks, >> >> Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS >> Senior Network Engineer >> Coleman Technologies, Inc. >> 954-298-1697 _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/