Class attribute questions

2005-06-10 Thread Shawn K. O';Shea
Greetings,

I'm trying to look at the Class attribute during proxying. I want to
take data stored in the Class attribute and rewrite other attribute(s)
based on the contents. I have it working right now but have two
questions regarding it.

1) I'm currently using rlm_exec to call a simple perl script that
"decodes" the Class attribute value (from accessing %{Class}) from it's
hex octet form back to the ASCII inside. I just wanted to make sure that
I wasn't missing something, and that there isn't an easier way to get at
the ASCII inside the octet stream.

2) The rfc's allow for more than one Class attribute (at least in
Accounting-Request packets). How does FreeRADIUS treat references to
%{Class} when this happens? i.e. Is there a syntax to refer to each
instance of the Class attr or get a count of how many are in the packet?
(I'm not currently running into this, but want to keep that base covered
in case that situation arises).

Thanks,
-Shawn

~ 
Shawn O'Shea
Network Engineer
Airpath Wireless, Inc.
"Clearing the Way"
781-250-3500-office
781-250-3535-direct
781-250-3503-fax
[EMAIL PROTECTED]
http://www.airpath.com
~
 
CONFIDENTIALITY STATEMENT
This electronic message contains information from Airpath Wireless,
Inc., and may be confidential or privileged. The information is intended
to be for the use of the individual or entity named above. If you are
not the intended recipient, be aware that any disclosure, copying,
distribution or use of the contents of this message is prohibited. If
you have received this electronic message in error, please notify the
sender immediately by reply e-mail [EMAIL PROTECTED] or telephone at
(781) 250-3500. 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: Class attribute questions

2005-06-13 Thread Shawn K. O';Shea
> > I just wanted to make 
> > sure that I wasn't missing something, and that there isn't 
> an easier 
> > way to get at the ASCII inside the octet stream.
>   Edit the dictionary, and change "octets" to "string"?

I saw discussion in a previous thread (Handling of the 'Class'
attribute, this post in particular,
http://lists.freeradius.org/mailman/htdig/freeradius-users/2003-July/021
267.html) that implied this was frowned upon, at least when interacting
with other RADIUS servers (which is what I'm using FreeRADIUS for), but
also because the RFC recommends that it should be treated as
undistinguished octets. 

> > 2) The rfc's allow for more than one Class attribute (at least in 
> > Accounting-Request packets). How does FreeRADIUS treat 
> references to 
> > %{Class} when this happens? i.e. Is there a syntax to refer to each 
> > instance of the Class attr or get a count of how many are 
> in the packet?
>   The CVS snapshots allow this.  1.0.x doesn't.  See doc/variables.txt

I read through the current doc/variables.txt in CVS. Looks great. Is
this a 1.1.x kind of feature or will it find it's way into a later
1.0.x?

Thanks for the reply.
-Shawn

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: Multiple Authentication REALMS - I hope in Plain Text

2005-06-14 Thread Shawn K. O';Shea
>From what you've provided, I believe what is happening is that your
requests that you *want* to go to local LDAP are still being proxied to
your IAS server, and for some reason IAS isn't sending an Access-Reject
so you get that error about a "dead request". 

Realm "NULL" is a special realm that means "there is no realm as part of
the username as per any definitions of the realm module in
radiusd.conf". It appears from your debug output that you have the realm
for @ defined (suffix realm, anything after an @ symbol is the realm).
Since your new Called-Station-Id still has a user with no realm, it's
proxied to NULL as your debug shows:

rlm_realm: No '@' in User-Name = "unextest20", looking up realm NULL
rlm_realm: Found realm "NULL"
rlm_realm: Adding Stripped-User-Name = "unextest20"
rlm_realm: Proxying request from user unextest20 to realm NULL
rlm_realm: Adding Realm = "NULL"
rlm_realm: Preparing to proxy authentication request to realm "NULL"

I *believe* the behaviour you truly want is something more like this:

 DEFAULT Called-Station-Id == "",Proxy-To-Realm := "msias"
Fall-Through = Yes

 DEFAULTCalled-Station-Id == "",Proxy-To-Realm := "msias"
Fall-Through = Yes

 DEFAULTCalled-Station-Id == "",Proxy-To-Realm := "localldap"
Fall-Through = Yes

And in proxy.conf:
realm msias  {
type= radius
authhost= radiusserver.some.domain:1645
accthost= radiusserver.some.domain:1646
Secret  = radiussecret
  }

realm localldap {
   type = radius
   authhost = LOCAL
   accthost = LOCAL
  }

Also, I'd just make sure what line in your users file is being matched.
Your debug output says a DEFAULT entry at line 90.

Check your IAS event log to see if it's getting proxied requests. I
usually run radiusd with -Xxx for extra debuging when a request gets
proxied, you should see something like this:

Fri Jun 10 15:02:47 2005 : Debug:  proxy: creating 0d02a8c0:1812
Fri Jun 10 15:02:47 2005 : Debug:  proxy: allocating 0d02a8c0:1812 0
Sending Access-Request of id 0 to a.b.c.d:1812

And a list of attributes.

Hope this helps.

-Shawn
~ 
Shawn O'Shea
Network Engineer
Airpath Wireless, Inc.
"Clearing the Way"
781-250-3500-office
781-250-3535-direct
781-250-3503-fax
[EMAIL PROTECTED]
http://www.airpath.com
~
 
CONFIDENTIALITY STATEMENT
This electronic message contains information from Airpath Wireless,
Inc., and may be confidential or privileged. The information is intended
to be for the use of the individual or entity named above. If you are
not the intended recipient, be aware that any disclosure, copying,
distribution or use of the contents of this message is prohibited. If
you have received this electronic message in error, please notify the
sender immediately by reply e-mail [EMAIL PROTECTED] or telephone at
(781) 250-3500. 
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Shepherd, Dave
> Sent: Tuesday, June 14, 2005 9:49 AM
> To: freeradius-users@lists.freeradius.org
> Subject: Multiple Authentication REALMS - I hope in Plain Text
> 
> Hi,
> 
>   It's been a long time, as the freeRADIUS software I've 
> being using for the last 3 years hasn't needed looking at 
> since installation. 
> 
>   So a big thank you to the development team J
> 
>   However, as with most things it's so good I've now got to 
> redesign and re-implement to encompass more of our 
> infrastructure, and I'm having problems.
> 
>   I have a number of settings in the _users_ file that are 
> based on the _Called_Station_ID_ then proxy the requests to a 
> specified REALM.
> 
>   i.e.
> 
>  DEFAULT Called-Station-Id == "",
> Proxy-To-Realm := "NULL"
> Fall-Through = Yes
> 
>  DEFAULTCalled-Station-Id == "",
> Proxy-To-Realm := "NULL"
> Fall-Through = Yes
> 
>  DEFAULTCalled-Station-Id == "",
> Proxy-To-Realm := "SPECIAL"
> Fall-Through = Yes
> 
> Now, the NULL realm is defined in the proxy.conf file as:
> 
> realm NULL {
> type= radius
> authhost= radiusserver.some.domain:1645
> accthost= radiusserver.some.domain:1646
> Secret  = radiussecret
>   }
> 
> This works and actually points to a MS IAS server going 
> against an NT4 Domain.
> 
> Now I need to authenticate a different set of users (who dial 
> a different number) against an LDAP repository, so as you can 
> see from my _users_ file I direct them at the "SPECIAL" 
> realm, which I have set as follows in proxy.conf:
> 
> realm SPECIAL {
> type= radius
> authhost= LOCAL
> accthost= LOCAL
> }
> 
> My plan was for this to then use the local radius server, 
> which has an _ldap_ module configure, which from what I can