"double" realm problem

[mr typo]

where would be the best place to deny those users?
we do not have alot of practice with freeradius, so
any help would be appreciated,


kind regards
-euroreg

On Wed, Oct 7, 2009 at 3:03 PM, mr typo <euroregistrar at gmail.com> wrote:

> hey,
> yes we are talking about eduroam and  after reading your post, it seems
> like that it is the best
> to deny such users.
>
> thanks alot
>
> -euroreg
>
> On Wed, Oct 7, 2009 at 2:44 PM, Stefan Winter <stefan.winter at restena.lu>wrote:
>
>> Hi,
>>
>> > problem is, that we are a university, so they are "our" people.
>> > tousands of students and teachers. if we deny those users, our
>> > helpdesk will get more work.
>> > is there a way to remove the double entries or do i have to block those?
>>
>> Any chance we are talking about eduroam? In this case: doing something
>> locally to make it work for these users even with misconfigured devices
>> is *not* going to do any good, and you will have helpdesk trouble as
>> soon as your users roam.
>>
>> The rationale being straightforward: you "fix" your local realm
>> stripping, misconfigured clients are happy on your campus. Then they go
>> to other hotspots without your magic fixes, and roaming will break. At
>> some point they come back and whine, and you have to negotiate with the
>> remote side logs to figure their weird settings prevented them from
>> roaming. Then you still have to re-config the devices.
>>
>> Not to mention that it damages the eduroam brand, since these people
>> will believe "roaming doesn't work".
>>
>> Contrary to that, changing one setting once on those few(I guess - not
>> everyone on your campus uses Nokia cell phones, do they?) misconfigured
>> clients will fix the issue permanently and globally. I'm shepherding
>> about 10000 end-users myself on an eduroam IdP setup, and a HOWTO for
>> Symbian which highlights neuralgic parts seems to work for me (at least
>> I don't drown in user requests, and still have time to read and write
>> freeradius-users :-) ).
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> >
>> > -euroreg
>> >
>> > On Wed, Oct 7, 2009 at 1:50 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk
>> > <mailto:A.L.M.Buxey at lboro.ac.uk>> wrote:
>> >
>> >     Hi,
>> >
>> >     > we do have one realm configured domainname.com
>> >     <http://domainname.com> which works perfectly. every
>> >     > user who wants to authenticate with a different realm is proxied
>> >     to an
>> >     > outside radius. server. the setup works fine.
>> >     >
>> >     > we do have some mobile devices who send something like:
>> >     > username at company.com
>> >     <mailto:username at company.com>@wlan.mnc003.mc <http://wlan.mnc003.mc
>> >
>> >     > username at company.com <mailto:username at company.com>@Verisign...
>> >
>> >     as Stefan says - this looks suspiciously like Nokia Symbian clients.
>> >     if the client hasnt been configured correctly it will send the CN
>> >     of the certificate as the realm details...and other things - so
>> >     you get
>> >     that double realm issue... which might get to you via external
>> proxy..
>> >     or might not.
>> >
>> >     reject if you see more than one @ - or, if these are your people,
>> >     find them and fix their client. (in case of Nokia, its ensure that
>> the
>> >     realm is specified rather than left to default setting.
>> >
>> >     alan
>> >     -
>> >     List info/subscribe/unsubscribe? See
>> >     http://www.freeradius.org/list/users.html
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > -
>> > List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>>
>> --
>> Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
>> la Recherche
>> 6, rue Richard Coudenhove-Kalergi
>> L-1359 Luxembourg
>>
>> Tel: +352 424409 1
>> Fax: +352 422473
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20091007/d3d690f0/attachment.html>