Jevos, Peter wrote: > Fall-through attribute doesn’t work in this case, cause it is “falling” > all the time ( even though it matches the condition )
You're not getting what I'm saying. The "users" file does *not* run during the "authenticate" phase. So it makes no sense to ask about modifying the "users" file contents to change the "authenticate" process flow. > However, let’s think about this classic case: You have one router, with > more profiles to connect ( different pools, dns, and so on ) > > Every profile should have its authentication against different AD group A group does not supply authentication information. Again, proper terminology is *critical* to designing a good solution. When you use the wrong terminology, it means you're not clear on how things work, and any solution you design will be based on incorrect assumptions. The solution here is to define which situations require which authentication methods. Usually, this is as easy as looking at the packet. Look for differences in the packet between what you want as authentication method "A" versus authentication method "B". Then, write logic to say "when the packet looks like X, choose A. When it looks like Y, choose B". This is *much* simpler and saner than "everyone try A, if it fails, try B, if that fails, try C, ..." Think of it this way: If you're driving to Disneyland, you look up the destination on a map, and drive there. You don't drive to Chicago, realize you're in the wrong place, and ask the locals for directions to Disneyland. > So it is not possible to solve it through USERS file ? As I've said, no. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
