Re: vlan ldap radiusd
Op 15 jul 2011, om 23:25 heeft Alexander Clouter het volgende geschreven: > Serge van Namen wrote: >> >> I accomplished to strip the username, it authenticates successfully against >> LDAP. >> But eventually it fails on EAP I think, because the username isn't the >> original from the request. >> >> [snipped] >> users: Matched entry DEFAULT at line 7 >> modcall[authorize]: module "files" returns ok for request 3 >> > What does this do? > > You must not change User-Name at all...I suspect somewhere in your > configuration you are doing so to try to fix another problem. If you > want the User-Name to be realmless then use Stripped-User-Name or use > unlang to populate something like Tmp-String-0. DEFAULT Suffix == "@realm", Strip-User-Name = Yes, Auth-Type = "LdapY", Autz-Type = "LdapY" Tunnel-Medium-Type = IEEE-802, Tunnel-Type = VLAN, Tunnel-Private-Group-ID = 1 > >> rlm_ldap: - authorize >> rlm_ldap: performing user authorization for userA >> radius_xlat: '(uid=userA)' >> radius_xlat: 'ou=y,ou=people,dc=example,dc=com' >> > What are you xlat'ing? Can we see your configuration? Are you using > ldap xlat to set User-Name? If so, don't! I didn't configure any xlat'ing afaik, maybe default behavior from what I configured above? > > Cheers > > -- > Alexander Clouter > .sigmonster says: fortune: not found > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
Serge van Namen wrote: > > I accomplished to strip the username, it authenticates successfully against > LDAP. > But eventually it fails on EAP I think, because the username isn't the > original from the request. > > [snipped] >users: Matched entry DEFAULT at line 7 > modcall[authorize]: module "files" returns ok for request 3 > What does this do? You must not change User-Name at all...I suspect somewhere in your configuration you are doing so to try to fix another problem. If you want the User-Name to be realmless then use Stripped-User-Name or use unlang to populate something like Tmp-String-0. > rlm_ldap: - authorize > rlm_ldap: performing user authorization for userA > radius_xlat: '(uid=userA)' > radius_xlat: 'ou=y,ou=people,dc=example,dc=com' > What are you xlat'ing? Can we see your configuration? Are you using ldap xlat to set User-Name? If so, don't! Cheers -- Alexander Clouter .sigmonster says: fortune: not found - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
Op 15 jul 2011, om 14:34 heeft Alexander Clouter het volgende geschreven:
> Serge van Namen wrote:
>>
>>> 'un-registered' (user bootstrapped) workstations go into VLAN
>>> 'users-unmanaged' whilst our equipment goes into 'users-staff'.
>>> Hope that makes sense...? :)
>>
>> Do you mean: unauthorized, user be put in default (jailed) vlan?
>>
> I work for a university so we have a lot of equipment that we do not
> maintain but is owned by the students/staff that needs to connect. So,
> we have three main workstation VLANs:
> * unauthorised
> * users-unmanaged
> * users-staff
>
> Unknown MAC addresses go into 'unauthorised' which is a sandpit network
> which does nothing more than redirect the web browser to our
> 'unauthorised workstation' webpage[1]. There they are permitted to get
> to a few websites (microsoft.com, etc) and to the instructions/tools
> they need to configure their computer for 802.1X.
>
> When they are 802.1Xing, they get put into 'users-unmanaged' which gives
> them all the access they could want, and that I am willing to give them.
> One day, when I find the time, I will have a 'pre-registration' VLAN (or
> more likely dual-purpose 'unauthorised') for unrecognised MAC addresses
> that have gotten past 'unauthorised' by doing 802.1X with some user
> credentials.
>
> 'users-staff' is currently MAC-auth workstations that we maintain, the
> helpdesk would not love me if I forced them to configure each
> workstation for 802.1X (we are condemned with Novell and not AD...but
> apparently not for much longer). :)
>
> One day, to get into 'users-staff', you will need to do EAP-TLS, but for
> now it is just MAC-auth.
>
> There is no different level of access betwork 'users-staff' and
> 'users-unmanaged' here, we just wanted to keep equipment that we
> maintain and equipment we do not in different subnets. Mainly to keep
> the subnet's small :)
Clean solution. :)
I accomplished to strip the username, it authenticates successfully against
LDAP.
But eventually it fails on EAP I think, because the username isn't the original
from the request.
rlm_realm: Looking up realm "Y" for User-Name = "userA@Y"
rlm_realm: Found realm "Y"
rlm_realm: Adding Stripped-User-Name = "userA"
rlm_realm: Proxying request from user userA to realm Y
rlm_realm: Adding Realm = "Y"
rlm_realm: Authentication realm is LOCAL.
modcall[authorize]: module "suffix" returns noop for request 3
users: Matched entry DEFAULT at line 7
modcall[authorize]: module "files" returns ok for request 3
rlm_pap: WARNING! No "known good" password found for the user. Authentication
may fail because of this.
modcall[authorize]: module "pap" returns noop for request 3
modcall: leaving group authorize (returns updated) for request 3
Found Autz-Type LdapY
Processing the authorize section of radiusd.conf
modcall: entering group LdapYfor request 3
rlm_ldap: - authorize
rlm_ldap: performing user authorization for userA
radius_xlat: '(uid=userA)'
radius_xlat: 'ou=y,ou=people,dc=example,dc=com'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in ou=y,ou=people,dc=example,dc=com, with filter
(uid=userA)
rlm_ldap: Added password {SSHA}X in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding userPassword as User-Password == "{SSHA}X"
rlm_ldap: looking for reply items in directory...
rlm_ldap: user userA authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module "Y" returns ok for request 3
modcall: leaving group LdapY (returns ok) for request 3
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 3
rlm_eap: Identity does not match User-Name, setting from EAP Identity.
rlm_eap: Failed in handler
modcall[authenticate]: module "eap" returns invalid for request 3
modcall: leaving group authenticate (returns invalid) for request 3
auth: Failed to validate the user.
Login incorrect: [userA] (from client radius port 16797697 cli 0017-f3f2-4572)
Delaying request 3 for 1 seconds
Finished request 3
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 22 to 1.2.3.4 port 1024
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 3 ID 22 with timestamp 4e203537
Nothing to do. Sleeping until we see a request.
Do I need to add the Suffix again to the reply?
Yours,
Serge
>
> Cheers
>
> [1]
> http://www.soas.ac.uk/itsupport/personal-equipment/unauthorised-workstation.html
>
> --
> Alexander Clouter
> .sigmonster says: Where do you think you're going today?
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.
Re: vlan ldap radiusd
Serge van Namen wrote: > >> 'un-registered' (user bootstrapped) workstations go into VLAN >> 'users-unmanaged' whilst our equipment goes into 'users-staff'. >> Hope that makes sense...? :) > > Do you mean: unauthorized, user be put in default (jailed) vlan? > I work for a university so we have a lot of equipment that we do not maintain but is owned by the students/staff that needs to connect. So, we have three main workstation VLANs: * unauthorised * users-unmanaged * users-staff Unknown MAC addresses go into 'unauthorised' which is a sandpit network which does nothing more than redirect the web browser to our 'unauthorised workstation' webpage[1]. There they are permitted to get to a few websites (microsoft.com, etc) and to the instructions/tools they need to configure their computer for 802.1X. When they are 802.1Xing, they get put into 'users-unmanaged' which gives them all the access they could want, and that I am willing to give them. One day, when I find the time, I will have a 'pre-registration' VLAN (or more likely dual-purpose 'unauthorised') for unrecognised MAC addresses that have gotten past 'unauthorised' by doing 802.1X with some user credentials. 'users-staff' is currently MAC-auth workstations that we maintain, the helpdesk would not love me if I forced them to configure each workstation for 802.1X (we are condemned with Novell and not AD...but apparently not for much longer). :) One day, to get into 'users-staff', you will need to do EAP-TLS, but for now it is just MAC-auth. There is no different level of access betwork 'users-staff' and 'users-unmanaged' here, we just wanted to keep equipment that we maintain and equipment we do not in different subnets. Mainly to keep the subnet's small :) Cheers [1] http://www.soas.ac.uk/itsupport/personal-equipment/unauthorised-workstation.html -- Alexander Clouter .sigmonster says: Where do you think you're going today? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
Op 15 jul 2011, om 11:26 heeft Alexander Clouter het volgende geschreven: > Serge van Namen wrote: >> >> In our situation the user is bound to a VLAN, so on every workstation >> in the building the user authenticates and the switchport becomes a >> member of the correct VLAN. >> > I *strongly* recommend not mixing host and user authentication, it's > just too much of a brain . What happens on a computer you > can SSH, terminal services into...user or host authentication? Host authentication is already dealt with on a higher level. Unknown hosts already cannot join the network, ever. :) > Sure you > can generalise, but you might as well just ignore the problem > altogether. Another example, user A walks in and authenticates > themselves to the network and goes into VLAN x, that user then goes to > lunch and evil user B starts to use the machine... Isn't that a problem of user awareness? That is possible in every situation if the user doesn't lock their screen. Or am I confused now? > > Obviously we all have our own policies and needs, but I recommend you > push the 'user authentication' (authorisation too) into a higher level > such as the application/server and not try to do it at the network > layer. That is already dealt with, this Proof of Concept is just a network security extension, not a whole new implementation. > > This does not mean you cannot use user authentication to bootstrap host > authentication. Exactly, the purpose is just for bootstrapping and to create 'flexible-workplaces' > For example our mindset here at work is that the user > is stating "I am responsible for this MAC address during this > session"...they might also be authorised to register that workstation > into a particular VLAN to ... > create some workstation credentials. Don't quit understand this part. :) > 'un-registered' (user bootstrapped) workstations go into VLAN > 'users-unmanaged' whilst our equipment goes into 'users-staff'. > Hope that makes sense...? :) Do you mean: unauthorized, user be put in default (jailed) vlan? > >> Correct me if I'm wrong but then we have to administer a separate >> database for hosts ( and in our case users ) Now we have 2 auth-types >> en autz-type's. >> >> 1 connects with cn=x,dc=example,dc=com (VLANid x) >> 1 connects with cn=y,dc=example,dc=com (VLANid y) >> >> Depending on the realm the user indicates when logging in >> (user@realm), autheticates and puts the "Tunnel-Private-Group-Id" in >> the reply with the correct VLAN id. >> > Well, you could just have users members of network groups instead (do > *not* repurpose an existing group). I would suggest, if you have the > time, create an enrollment page. Unknown MAC addresses (even with a > valid *user* 802.1X session) are redirected to a webpage to register the > machine into a network (typically only one, maybe your helpdesk members > would be permitted to register the equipment into a number of groups). > This does not mean that you use MAC-auth for that machine, but the > enrollment session could generate workstation credentials (EAP-TLS) to > use or you could still enforce that user 802.1X credentials (not > necessarily the original registraters one) need to be used to gain > access. We don't want to manage complex device lists, we just don't want unwanted hardware in our network. MAC address / device management is not in the scope of the Proof of Concept. :) Just: User A: VLAN X User B: VLAN Y User C: VLAN X etc. > > This means you can permit users to register up to five devices for > example. > >> The problem: When using 'Login Window' based 802.1x. >> So when user puts in it's user/pass at the login window, it does it's 802.1x >> magic. >> >> But with user@realm, LDAP doesnt understands this ofcourse, so the >> @realm needs to be stripped when authenicating to LDAP. >> >> So: >> >> user@realm ---> radius reads the realm, strips the @realm so LDAP >> understands, makes it's auth/autz-type. >> >> I hope you catch my drift. :) >> > This is covered in the FreeRADIUS documentation (and numerous 'eduroam' > examples, it looks like you are aiming for this type of thing). > 'suffix' is what you want in your authorize section, you then pass to > the ldap module 'Stripped-User-Name'. Thanks! One of the things I was looking for. > > Cheers > > -- > Alexander Clouter > .sigmonster says: Massachusetts has the best politicians money can buy. > Yours, Serge > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
Serge van Namen wrote: > > In our situation the user is bound to a VLAN, so on every workstation > in the building the user authenticates and the switchport becomes a > member of the correct VLAN. > I *strongly* recommend not mixing host and user authentication, it's just too much of a brain . What happens on a computer you can SSH, terminal services into...user or host authentication? Sure you can generalise, but you might as well just ignore the problem altogether. Another example, user A walks in and authenticates themselves to the network and goes into VLAN x, that user then goes to lunch and evil user B starts to use the machine... Obviously we all have our own policies and needs, but I recommend you push the 'user authentication' (authorisation too) into a higher level such as the application/server and not try to do it at the network layer. This does not mean you cannot use user authentication to bootstrap host authentication. For example our mindset here at work is that the user is stating "I am responsible for this MAC address during this session"...they might also be authorised to register that workstation into a particular VLAN to create some workstation credentials. 'un-registered' (user bootstrapped) workstations go into VLAN 'users-unmanaged' whilst our equipment goes into 'users-staff'. Hope that makes sense...? :) > Correct me if I'm wrong but then we have to administer a separate > database for hosts ( and in our case users ) Now we have 2 auth-types > en autz-type's. > > 1 connects with cn=x,dc=example,dc=com (VLANid x) > 1 connects with cn=y,dc=example,dc=com (VLANid y) > > Depending on the realm the user indicates when logging in > (user@realm), autheticates and puts the "Tunnel-Private-Group-Id" in > the reply with the correct VLAN id. > Well, you could just have users members of network groups instead (do *not* repurpose an existing group). I would suggest, if you have the time, create an enrollment page. Unknown MAC addresses (even with a valid *user* 802.1X session) are redirected to a webpage to register the machine into a network (typically only one, maybe your helpdesk members would be permitted to register the equipment into a number of groups). This does not mean that you use MAC-auth for that machine, but the enrollment session could generate workstation credentials (EAP-TLS) to use or you could still enforce that user 802.1X credentials (not necessarily the original registraters one) need to be used to gain access. This means you can permit users to register up to five devices for example. > The problem: When using 'Login Window' based 802.1x. > So when user puts in it's user/pass at the login window, it does it's 802.1x > magic. > > But with user@realm, LDAP doesnt understands this ofcourse, so the > @realm needs to be stripped when authenicating to LDAP. > > So: > > user@realm ---> radius reads the realm, strips the @realm so LDAP > understands, makes it's auth/autz-type. > > I hope you catch my drift. :) > This is covered in the FreeRADIUS documentation (and numerous 'eduroam' examples, it looks like you are aiming for this type of thing). 'suffix' is what you want in your authorize section, you then pass to the ldap module 'Stripped-User-Name'. Cheers -- Alexander Clouter .sigmonster says: Massachusetts has the best politicians money can buy. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
Op 14 jul 2011, om 21:30 heeft Alexander Clouter het volgende geschreven:
> Serge van Namen wrote:
>>
>> I'm working on a proof-of-concept for 802.1x and dynamic vlan's on
>> switches.
>>
>> All this works perfectly with user@realm, but now I want to read the
>> vlan ID from a ldap attribute and then send the radius request with
>> that value in "Tunnel-Private-Group-ID".
>>
> Reading an attribute for this is argubly silly in the context of LDAP.
> Better to test for a group membership otherwise you might aswell shovel
> everything in a relational database like SQL.
In our situation the user is bound to a VLAN, so on every workstation in the
building the user authenticates and the switchport
becomes a member of the correct VLAN.
Correct me if I'm wrong but then we have to administer a separate database for
hosts ( and in our case users )
Now we have 2 auth-types en autz-type's.
1 connects with cn=x,dc=example,dc=com (VLANid x)
1 connects with cn=y,dc=example,dc=com (VLANid y)
Depending on the realm the user indicates when logging in (user@realm),
autheticates and puts the "Tunnel-Private-Group-Id" in the reply with the
correct VLAN id.
The problem: When using 'Login Window' based 802.1x.
So when user puts in it's user/pass at the login window, it does it's 802.1x
magic.
But with user@realm, LDAP doesnt understands this ofcourse, so the @realm needs
to be stripped when authenicating to LDAP.
So:
user@realm ---> radius reads the realm, strips the @realm so LDAP understands,
makes it's auth/autz-type.
I hope you catch my drift. :)
>
> For us we create host LDAP objects, and then those objects are members
> of a LDAP group which has details regarding the VLAN in it (and
> subnetting, etc etc).
>
> I am slowly cobbling bits together on my website[1]. My post-auth looks
> like:
>
> post-auth {
>
>
># defaults
>update reply {
>Tunnel-Type := VLAN
>Tunnel-Medium-Type := IEEE-802
>Tunnel-Private-Group-Id := "unauthorised"
>
>Termination-Action := RADIUS-Request
>Session-Timeout := 300
>
>Acct-Interim-Interval := 3600
>}
>
>if ((EAP-Message) && !(Ldap-UserDn)) {
>cache_ldap-userdn
>}
>
>lanwarden_vlan
>if (!(control:Tunnel-Private-Group-Id) ||
> control:Tunnel-Private-Group-Id == "") {
>if (Realm == "DEFAULT") {
>update reply {
>Tunnel-Private-Group-Id := "eduroam"
>}
>}
># to be removed once we register personal workstations
>elsif (Realm == "%{config:local.MY.realm}") {
>update reply {
>Tunnel-Private-Group-Id :=
> "users-unmanaged"
>}
>}
>}
>else {
>update reply {
>Tunnel-Private-Group-Id :=
> "%{control:Tunnel-Private-Group-Id}"
>}
>}
>if (reply:Tunnel-Private-Group-Id != "unauthorised") {
>update reply {
># Cisco only support a max of 65535
>Session-Timeout := 64800
>}
>}
>
>
> }
>
>
> 'cache_ldap-userdn' you can find in the archives and the reasoning for
> it, meanwhile lanwarden_vlan lurks in policy.conf and looks like:
>
> lanwarden_vlan {
>if ((control:Ldap-UserDn)) {
>if ("%{md5:%{client:secret}%{Calling-Station-Id}%l}" =~
> /[0-7]$/) {
>update control {
>Tunnel-Private-Group-Id :=
> "%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>}
>if (control:Tunnel-Private-Group-Id == "") {
>update control {
>Tunnel-Private-Group-Id :=
> "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>}
>}
>}
>else {
>update control {
>Tunnel-Private-Group-Id :=
> "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>}
>if (control:Tunnel-
Re: vlan ldap radiusd
Serge van Namen wrote:
>
> I'm working on a proof-of-concept for 802.1x and dynamic vlan's on
> switches.
>
> All this works perfectly with user@realm, but now I want to read the
> vlan ID from a ldap attribute and then send the radius request with
> that value in "Tunnel-Private-Group-ID".
>
Reading an attribute for this is argubly silly in the context of LDAP.
Better to test for a group membership otherwise you might aswell shovel
everything in a relational database like SQL.
For us we create host LDAP objects, and then those objects are members
of a LDAP group which has details regarding the VLAN in it (and
subnetting, etc etc).
I am slowly cobbling bits together on my website[1]. My post-auth looks
like:
post-auth {
# defaults
update reply {
Tunnel-Type := VLAN
Tunnel-Medium-Type := IEEE-802
Tunnel-Private-Group-Id := "unauthorised"
Termination-Action := RADIUS-Request
Session-Timeout := 300
Acct-Interim-Interval := 3600
}
if ((EAP-Message) && !(Ldap-UserDn)) {
cache_ldap-userdn
}
lanwarden_vlan
if (!(control:Tunnel-Private-Group-Id) ||
control:Tunnel-Private-Group-Id == "") {
if (Realm == "DEFAULT") {
update reply {
Tunnel-Private-Group-Id := "eduroam"
}
}
# to be removed once we register personal workstations
elsif (Realm == "%{config:local.MY.realm}") {
update reply {
Tunnel-Private-Group-Id :=
"users-unmanaged"
}
}
}
else {
update reply {
Tunnel-Private-Group-Id :=
"%{control:Tunnel-Private-Group-Id}"
}
}
if (reply:Tunnel-Private-Group-Id != "unauthorised") {
update reply {
# Cisco only support a max of 65535
Session-Timeout := 64800
}
}
}
'cache_ldap-userdn' you can find in the archives and the reasoning for
it, meanwhile lanwarden_vlan lurks in policy.conf and looks like:
lanwarden_vlan {
if ((control:Ldap-UserDn)) {
if ("%{md5:%{client:secret}%{Calling-Station-Id}%l}" =~
/[0-7]$/) {
update control {
Tunnel-Private-Group-Id :=
"%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
}
if (control:Tunnel-Private-Group-Id == "") {
update control {
Tunnel-Private-Group-Id :=
"%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
}
}
}
else {
update control {
Tunnel-Private-Group-Id :=
"%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
}
if (control:Tunnel-Private-Group-Id == "") {
update control {
Tunnel-Private-Group-Id :=
"%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
}
}
}
}
}
It looks horrible as xlat does *not* support failover. :(
Cheers
[1] http://www.digriz.org.uk/lanwarden
--
Alexander Clouter
.sigmonster says: You are so boring that when I see you my feet go to sleep.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: vlan ldap radiusd
On 14/07/11 13:09, Serge van Namen wrote:
Hi,
I'm working on a proof-of-concept for 802.1x and dynamic vlan's on switches.
All this works perfectly with user@realm, but now I want to read the vlan ID from a ldap
attribute and then send the radius request with that value in
"Tunnel-Private-Group-ID".
Can anyone give me a bump in the right direction?
Read this:
http://wiki.freeradius.org/Rlm_ldap
Pay particular attention to "reply items". You can also use "ldap xlat"
in the inner-tunnel post-auth section e.g.
post-auth {
update reply {
Tunnel-Private-Group-Id := "%{ldap:///url}";
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
vlan ldap radiusd
Hi, I'm working on a proof-of-concept for 802.1x and dynamic vlan's on switches. All this works perfectly with user@realm, but now I want to read the vlan ID from a ldap attribute and then send the radius request with that value in "Tunnel-Private-Group-ID". Can anyone give me a bump in the right direction? Yours, Serge - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
