The new concurrency Module is to be used on Top of the Session State Register (SSR) to make the concurrency tracking global and not local on a per Server basis.
Traditionally SBR checks/limits Concurrency on a per Server basis on the used Authentication-Method PLUS the Username. This is used in a check for being this account unique. As Realms are only a PART of the Username in a regular case you can not use this schema to contoll the amount of sessions per realm (except for Tunnels which is different and also local).
BUT in V7.2 the concurrency module enables you not only to use the Authentication-Method PLUS the Username but to do your concurrency checks on ANY other Radius Attribute instead. Depending on how you work with Realms this enables you to apply concurrency checks on a per realm basis.
First you must tell SBR on which (new) attribute limits have to be applied. Like in Radiu.ini
Apply-Login-Limits = yes
Login-Limit-Key = Called-Station-Id
To give an example you may use local directed realms that you identify in your Proxy.ini . On each Realm*.dir file you add an individual output filter to all Authentication AND Accounting methods.
In the Filter.ini for every Realm you set an individual Attribute Filter that deletes the Attribute you use for realm based checks and set's a uniques new Value identifiying the particular Realm like
Add Called-Station-Id Realm1
This will allow to keep controll for the Authentication Methods you use later on in the authentication where for example in a SQL Authentication method you use the %LoginLimit identifier to be used to controll the individual limit for a Realm.
It's only an example of how this might be implemented. I can not say if this is what exact you need.
It is mandatory for all kinds of session control/limits the AAA Server is getting proper Accounting information because that's the only way those knowledge about the ongoing session can be maintained.
But there is an issue. Actually, this case, the concurrency is applied in a proxy server. For example, a carrier limits concurrency on per ISP. The issue is that an unnecessary attribute, which contains a realm name, is forwarded to backend ISP, if an attribute is added for tracking the concurrency. I think it would ever be tolerated in all carriers. I tested your methodology; there is no configuration to delete added attributes when authentication and accounting requests is forwarded. If there is another methodology, Please let me know.
Concurrency controll will only work if you are the final AAA Server (probally after the end of a proxy cain) that does the final authentication. If you are a proxy inbeteen, SBR is not controlling any limits in terms of sessions/realms he just proxy forwards (and may add filterprocessing). He does not generate any Access-Rejects because he is not authenticating.
Even if you would consider it as "nice to have feature" as soon as you do MORE then PAP authentication it won't work anymore. For example EAP-TTLS (say you do Wi-Fi or fixed WiMAX). Everybody is encouraged to use EAP-Idents like "[email protected]" and the proxy server can not look into the inner protocol. With looking at the Access-Requests such a proxy receives he can not make any realm based desisions to spoof this.
The example I used is for tracking sessions at the AAA who is doing the final authentication at the end of a proxy chain.
Adding/modifying attributes here to the Access-Request messages will not pass them back.
I've used Called-Station-Id because this attribute is one of the fixed attributes you can see/browse for in the 7.2 session GUI. You may use any other homegrown Attribute as well.
My example is using directed Realms for selecting the authentication method and filter. Thus from SBR view an Proxy OUT filter would applied to these attributes to an Access-Request before it does the final (see it as a local proxy) authentication.
I had been assuming that the new Concurrency Module was taking over the SBR Service Level Manager.
SBR SLM can limit concurrent connections based on realms in a proxy point,
but It seems the Concurrency Module only control concurrent connections at the final authentication.Correct?