Re: LDAP Profiles

2005-03-30 Thread Kostas Kalevras
On Tue, 29 Mar 2005, Jarred Cleem wrote:
Thanks Dustin Doris for your reply.  I seem to be missing something
because I can not get it to work like you mentioned.  Let me provide
some data and config info in hopes that you might be able to help
further.  What I am hoping for is that it will send the profile info and
the info for the user.
For example, I am hoping to see the return attributes for jcleem/dial to
be:
radiusClientIPAddress: 172.18.5.1
radiusFramedIPNetmask: 255.255.255.0
radiusFramedProtocol: PPP
radiusFramedRouting: None
radiusServiceType: Framed-User
radiusFramedCompression: Van-Jacobson-TCP-IP
But I only get (does not include radiusClientIPAddress):
The radiusClientIPAddress attribute is a check and not a reply item. It is 
normally not included in raddb/ldap.attrmap and i don't think you wanted to use 
that in the first place. What you need to use is the radiusFramedIPAddress 
attribute:
radiusFramedIPAddress: 172.18.5.1

--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED]   National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: LDAP Profiles

2005-03-30 Thread Dustin Doris

 On Tue, 29 Mar 2005, Jarred Cleem wrote:

  Thanks Dustin Doris for your reply.  I seem to be missing something
  because I can not get it to work like you mentioned.  Let me provide
  some data and config info in hopes that you might be able to help
  further.  What I am hoping for is that it will send the profile info and
  the info for the user.
 
  For example, I am hoping to see the return attributes for jcleem/dial to
  be:
  radiusClientIPAddress: 172.18.5.1
  radiusFramedIPNetmask: 255.255.255.0
  radiusFramedProtocol: PPP
  radiusFramedRouting: None
  radiusServiceType: Framed-User
  radiusFramedCompression: Van-Jacobson-TCP-IP
 
  But I only get (does not include radiusClientIPAddress):

 The radiusClientIPAddress attribute is a check and not a reply item. It
 is normally not included in raddb/ldap.attrmap and i don't think you
 wanted to use that in the first place. What you need to use is the
 radiusFramedIPAddress attribute: radiusFramedIPAddress: 172.18.5.1

 --

Kostas is correct, but if you really need to use Client-IP-Address for
some reason, then add it to ldap.attrmap as a reply item.

replyItem   Client-IP-Address   radiusClientIPAddress

-Dusty

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


Re: LDAP Profiles

2005-03-30 Thread Alan DeKok
Dustin Doris [EMAIL PROTECTED] wrote:
 Kostas is correct, but if you really need to use Client-IP-Address for
 some reason, then add it to ldap.attrmap as a reply item.

  Where it will do *nothing*.  Absolutely and totally *nothing*.

  It's not a real RADIUS attribute, so it will never go into a packet.

  Alan DeKok.

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


Re: LDAP Profiles

2005-03-30 Thread Dustin Doris

 Dustin Doris [EMAIL PROTECTED] wrote:
  Kostas is correct, but if you really need to use Client-IP-Address for
  some reason, then add it to ldap.attrmap as a reply item.

   Where it will do *nothing*.  Absolutely and totally *nothing*.

   It's not a real RADIUS attribute, so it will never go into a packet.

   Alan DeKok.


Good point.  Not enought coffee this morning, I guess.

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


Re: LDAP Profiles vs. No-profiles

2005-03-29 Thread Kostas Kalevras
On Mon, 28 Mar 2005, Jarred Cleem wrote:
I am setting up a test environment and I am having some problems.  Any help 
would be great.  I have the servers build very similarly to what is document 
at 
http://www.freeradius.org/radiusd/doc/ldap_howto.txt.  I have created a few 
profiles like dialup, dsl, and isdn.  I have the server working in the test 
environment and it seems to function very well.  My question is how do I use 
profiles and still be able to pass specific attributes to the radius server 
that are dependent on the user.  For example, if the user has been assigned a 
static IP address.  Below is an example of an of the users file from the old 
Radius server that we are migrating off of.
default profile: An ldap entry holding radius attributes. Defined in the 
ldap module configuration and used in all cases
regular profile: An ldap entry holding radius attributes. Defined in the user 
entry as an attribute pointing to the dn of that entry. Used when authorizing 
that specific user.

user profile: The attributes contained in the user entry. These attributes take 
precedence to the attributes defined in the above profiles. So in general you 
can use default/regular profiles to define default attributes used in most cases 
and then define any user specific attributes inside each user's entry.

# Entry for Customer 1 dedicated dsl
Customer1 Auth-Type = Local, Password = xx
   Service-Type = Framed-User,
   Framed-Protocol = PPP,
   Framed-IP-Address = 192.168.1.69,
   Framed-IP-Netmask = 255.255.255.252,
   Framed-Routing = Broadcast-Listen,
   Framed-Filter-Id = std.ppp,
   Framed-MTU = 1500,
   Framed-Compression = Van-Jacobsen-TCP-IP
# Entry for customer 2 dedicated dsl
Customer2 Auth-Type = Local, Password = xxx
   Service-Type = Framed-User,
   Framed-Protocol = PPP,
   Framed-IP-Address = 192.168.1.65,
   Framed-IP-Netmask = 255.255.255.252,
   Framed-Routing = Broadcast-Listen,
   Framed-Filter-Id = std.ppp,
   Framed-MTU = 1500,
   Framed-Compression = Van-Jacobsen-TCP-IP
# Entry for customer 3 dedicated dsl
Customer3 Auth-Type = Local, Password = xx
   Service-Type = Framed-User,
   Framed-Protocol = PPP,
   Framed-IP-Address = 192.168.1.177,
   Framed-IP-Netmask = 255.255.255.248,
   Framed-Routing = Broadcast-Listen,
   Framed-Filter-Id = std.ppp,
   Framed-MTU = 1500,
   Framed-Compression = Van-Jacobsen-TCP-IP
DEFAULT Auth-Type = System
   Fall-Through = Yes
DEFAULT Service-Type = Framed-User
   Framed-IP-Address = 255.255.255.254,
   Framed-MTU = 576,
   Service-Type = Framed-User,
   Fall-Through = Yes
#
# Default for PPP: dynamic IP address, PPP mode, VJ-compression.
# NOTE: we do not use Hint = PPP, since PPP might also be auto-detected
#   by the terminal server in which case there may not be a P suffix.
#   The terminal server sends Framed-Protocol = PPP for auto PPP.
#
DEFAULT Framed-Protocol = PPP
   Framed-Protocol = PPP,
   Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.
#
DEFAULT Hint = CSLIP
   Framed-Protocol = SLIP,
   Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for SLIP: dynamic IP address, SLIP mode.
#
DEFAULT Hint = SLIP
   Framed-Protocol = SLIP
--
Jarred F. Cleem
IS Manager
Multiband
2000 44th Street SW
Fargo, ND 58103
(W) 701-281-5376 (F)701-492-5376
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED]   National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf

Re: LDAP Profiles

2005-03-29 Thread Dustin Doris

 Not sure how to ask my next question so I will try my best.  We have
 some users who receive static IP addresses and other special attributes
 that are unique to only that user.  Then we have some who receive the
 same attributes and attribute values as the next person.  The big
 difference is those users who receive a static IP verses a dynamic IP
 out of the DHCP pool.  It is my understanding that after LDAP has
 verified the user it tells RADIUS all the group info.  RADIUS then goes
 through the RADIUS Groups info and tries to find the first match.  Once
 the match is found RADIUS then returns to the NAS the attributes for the
 profile not the actual user attributes.  How do I setup the servers so
 that sometimes it returns the profile info (in the case of DHCP type
 customers) and sometimes returns specific attributes (in the case of
 static IP customers)?



You can send back any reply values you want for the individual users by
putting those entries into their ldap entry.

eg:

uid=somestaticuser,ou=radius,dc=yourdomain,dc=com
objectclass: radiusprofile
radiusgroupname: dial
radiusgroupname: isdn
radiusframedipaddress: 1.1.1.1
radiusframedipnetmask: 255.255.255.252

That will send back the reply attributes of framedipaddress and
framedipnetmask for only that user.

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


LDAP Profiles vs. No-profiles

2005-03-28 Thread Jarred Cleem
I am setting up a test environment and I am having some problems.  Any help 
would be great.  I have the servers build very similarly to what is document at 
http://www.freeradius.org/radiusd/doc/ldap_howto.txt.  I have created a few 
profiles like dialup, dsl, and isdn.  I have the server working in the test 
environment and it seems to function very well.  My question is how do I use 
profiles and still be able to pass specific attributes to the radius server 
that are dependent on the user.  For example, if the user has been assigned a 
static IP address.  Below is an example of an of the users file from the old 
Radius server that we are migrating off of.

# Entry for Customer 1 dedicated dsl
Customer1 Auth-Type = Local, Password = xx
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 192.168.1.69,
Framed-IP-Netmask = 255.255.255.252,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = std.ppp,
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP

# Entry for customer 2 dedicated dsl
Customer2 Auth-Type = Local, Password = xxx
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 192.168.1.65,
Framed-IP-Netmask = 255.255.255.252,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = std.ppp,
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP

# Entry for customer 3 dedicated dsl
Customer3 Auth-Type = Local, Password = xx
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 192.168.1.177,
Framed-IP-Netmask = 255.255.255.248,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = std.ppp,
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP

DEFAULT Auth-Type = System
Fall-Through = Yes

DEFAULT Service-Type = Framed-User
Framed-IP-Address = 255.255.255.254,
Framed-MTU = 576,
Service-Type = Framed-User,
Fall-Through = Yes

#
# Default for PPP: dynamic IP address, PPP mode, VJ-compression.
# NOTE: we do not use Hint = PPP, since PPP might also be auto-detected
#   by the terminal server in which case there may not be a P suffix.
#   The terminal server sends Framed-Protocol = PPP for auto PPP.
#
DEFAULT Framed-Protocol = PPP
Framed-Protocol = PPP,
Framed-Compression = Van-Jacobson-TCP-IP

#
# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.
#
DEFAULT Hint = CSLIP
Framed-Protocol = SLIP,
Framed-Compression = Van-Jacobson-TCP-IP

#
# Default for SLIP: dynamic IP address, SLIP mode.
#
DEFAULT Hint = SLIP
Framed-Protocol = SLIP

--
Jarred F. Cleem
IS Manager
Multiband
2000 44th Street SW
Fargo, ND 58103
(W) 701-281-5376 (F)701-492-5376


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


LDAP Profiles

2005-03-25 Thread Jarred Cleem

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


LDAP Profiles

2005-03-24 Thread Jarred Cleem








Thanks for the reply Dustin!
I believe what you describe will work just fine. 



Not sure how to ask my next question
so I will try my best. We have some users who receive static IP addresses
and other special attributes that are unique to only that user. Then we
have some who receive the same attributes and attribute values as the next
person. The big difference is those users who receive a static IP verses
a dynamic IP out of the DHCP pool. It is my understanding that after LDAP
has verified the user it tells RADIUS all the group info. RADIUS then
goes through the RADIUS Groups info and tries to find the first match.
Once the match is found RADIUS then returns to the NAS the attributes for the
profile not the actual user attributes. How do I setup the servers so
that sometimes it returns the profile info (in the case of DHCP type customers)
and sometimes returns specific attributes (in the case of static IP customers)?




Thanks for your help in
advance.



--

Jarred F. Cleem

IS Manager

Multiband

2000 44th Street
  SW

Fargo, ND 58103

(W) 701-281-5376 (F)701-492-5376









Message: 6

Date: Mon, 7 Mar
2005 09:20:43 -0500 (EST)

From: Dustin
Doris [EMAIL PROTECTED]

To: freeradius-users@lists.freeradius.org

Subject: Re:
LDAP Profiles

Reply-To: freeradius-users@lists.freeradius.org



 On Sun, 6 Mar 2005,
Jarred Cleem wrote:



  Hello all;

 

  I am tying to put
together an openLDAP/FreeRadius implementation for a

  multitude of
services we provide. We are currently providing high speed

  cable modem
services, local dial-up, national dial-up, Motorola Canopy

  Wireless, DSL,
ISDN, extended Ethernet, Ethernet over power and a few

  other ISP type
services. Currently we have a different AAA platform for

  all of the different
services we provide. I am doing some research and

  setting up a test
lab to see if I can get everything to one AAA

  platform. I
think I am close but am looking for some additional help

  with the
connectivity between FreeRadius and openLDAP.

 

  I currently have
FreeRadius communicating with openLDAP and

  authenticating the
user. However, the LDAP server is giving the RADIUS

  server the wrong
profile after authentication. I am not sure if I

  completely and
correctly understand how this works. It looks as thought

  it is finds the
first ldap-group in my users file and returns the ldap

  path to the
profile. My problem is that if a user has more then one

  service, say
dial-up and DSL, it does not return the right profile. It

  returns the first
match in the users file.

 

  How do I get LDAP
and FreeRadius to return to the NAS the correct

  profile for the
type of service the user is trying to authenticate to?

 

  Below is my
configuration information.

 

  openLDAP 2.2.23

  freeRadius 1.0.2

  Fedora Core 3

 

  Current users file

  ---begin
users

  DEFAULT Ldap-Group
== disabled, Auth-Type := Reject


 Reply-Message = Account
disabled. Please call the helpdesk.

 

  DEFAULT Ldap-Group
== dial, User-Profile :=

 
uid=dial,ou=profiles,dc=multiband,dc=us


 Fall-Through = no

 

  DEFAULT Ldap-Group
== isdn, User-Profile :=

 
uid=isdn,ou=profiles,dc=multiband,dc=us


 Fall-Through = no

 

  DEFAULT Ldap-Group
== dsl-ip, User-Profile :=

 
uid=dsl-ip,ou=profiles,dc=multiband,dc=us


 Fall-Through = no

 

  DEFAULT Auth-Type
:= Reject


 Reply-Message = Please
call the helpdesk.

  ---end
users--



 With the above
configuration if a user is a member on more than one groups then

 the first one matched
will be the *only* one that will be used. And that *is*

 correct behaviour. What
i think you need is to also use incoming request

 attributes to
differentiate services (which you aren't right now). Something

 like:



 DEFAULT NAS-Port-Type
== ISDN, Ldap-Group == isdn, User-Profile :=


uid=isdn,ou=profiles,dc=multiband,dc=us

  Fall-Through
= no



 DEFAULT NAS-Port-Type
== Virtual, Ldap-Group == dsp-ip, User-Profile :=


uid=dsl-ip,ou=profiles,dc=multiband,dc=us





Sometimes you can also know
the service based on the nas-ip-address, so

its easy to use with
huntgroups.



eg:



huntgroups file



dial nas-ip-address ==
1.1.1.1

dial nas-ip-address ==
1.1.1.2

dial nas-ip-address ==
1.1.1.3, nas-port-type == async

isdn nas-ip-address ==
1.1.1.3, nas-port-type == isdn

adsl nas-ip-address ==
1.1.1.4



What I did there was make 3
nas-ip-addresses in the dial huntgroup. One

of them does both dial and
isdn, so I added the additional check-item to

it. One nas-ip is
adsl.



Then in the users file.



DEAULT Huntgroup-Name ==
dial, Ldap-Group == dial, User-Profile :=

uid=dial...



DEFAULT Huntgroup-Name ==
isdn, Ldap-Group == isdn, User-Profile :=

uid=isdn...



etc...



DEFAULT Auth-Type := Reject



What you are doing there is
first checking the huntgroup. If you come

from a dial huntgroup, then
we will look to see if you have the ldap-group

dial which would

Re: LDAP Profiles

2005-03-07 Thread Dustin Doris
 On Sun, 6 Mar 2005, Jarred Cleem wrote:

  Hello all;
 
  I am tying to put together an openLDAP/FreeRadius implementation for a
  multitude of services we provide.  We are currently providing high speed
  cable modem services, local dial-up, national dial-up, Motorola Canopy
  Wireless, DSL, ISDN, extended Ethernet, Ethernet over power and a few
  other ISP type services.  Currently we have a different AAA platform for
  all of the different services we provide.  I am doing some research and
  setting up a test lab to see if I can get everything to one AAA
  platform.  I think I am close but am looking for some additional help
  with the connectivity between FreeRadius and openLDAP.
 
  I currently have FreeRadius communicating with openLDAP and
  authenticating the user.  However, the LDAP server is giving the RADIUS
  server the wrong profile after authentication.  I am not sure if I
  completely and correctly understand how this works.  It looks as thought
  it is finds the first ldap-group in my users file and returns the ldap
  path to the profile.  My problem is that if a user has more then one
  service, say dial-up and DSL, it does not return the right profile.  It
  returns the first match in the users file.
 
  How do I get LDAP and FreeRadius to return to the NAS the correct
  profile for the type of service the user is trying to authenticate to?
 
  Below is my configuration information.
 
  openLDAP 2.2.23
  freeRadius 1.0.2
  Fedora Core 3
 
  Current users file
  ---begin users
  DEFAULT Ldap-Group == disabled, Auth-Type := Reject
 Reply-Message = Account disabled.  Please call the helpdesk.
 
  DEFAULT Ldap-Group == dial, User-Profile :=
  uid=dial,ou=profiles,dc=multiband,dc=us
 Fall-Through = no
 
  DEFAULT Ldap-Group == isdn, User-Profile :=
  uid=isdn,ou=profiles,dc=multiband,dc=us
 Fall-Through = no
 
  DEFAULT Ldap-Group == dsl-ip, User-Profile :=
  uid=dsl-ip,ou=profiles,dc=multiband,dc=us
 Fall-Through = no
 
  DEFAULT Auth-Type := Reject
 Reply-Message = Please call the helpdesk.
  ---end users--

 With the above configuration if a user is a member on more than one groups 
 then
 the first one matched will be the *only* one that will be used. And that *is*
 correct behaviour. What i think you need is to also use incoming request
 attributes to differentiate services (which you aren't right now). Something
 like:

 DEFAULT   NAS-Port-Type == ISDN, Ldap-Group == isdn, User-Profile :=
 uid=isdn,ou=profiles,dc=multiband,dc=us
   Fall-Through = no

 DEFAULT   NAS-Port-Type == Virtual, Ldap-Group == dsp-ip, User-Profile :=
 uid=dsl-ip,ou=profiles,dc=multiband,dc=us


Sometimes you can also know the service based on the nas-ip-address, so
its easy to use with huntgroups.

eg:

huntgroups file

dial  nas-ip-address == 1.1.1.1
dial  nas-ip-address == 1.1.1.2
dial  nas-ip-address == 1.1.1.3, nas-port-type == async
isdn  nas-ip-address == 1.1.1.3, nas-port-type == isdn
adsl  nas-ip-address == 1.1.1.4

What I did there was make 3 nas-ip-addresses in the dial huntgroup.  One
of them does both dial and isdn, so I added the additional check-item to
it.  One nas-ip is adsl.

Then in the users file.

DEAULT Huntgroup-Name == dial, Ldap-Group == dial, User-Profile :=
uid=dial...

DEFAULT Huntgroup-Name == isdn, Ldap-Group == isdn, User-Profile :=
uid=isdn...

etc...

DEFAULT Auth-Type := Reject

What you are doing there is first checking the huntgroup.  If you come
from a dial huntgroup, then we will look to see if you have the ldap-group
dial which would signal that you get access to dial.  If not, we move on
and will eventually hit the reject line.  If you do have dial, we
authenticate you and return the dial profile.

Same thing for isdn.  If you are coming from an isdn huntgroup, then we
check to see if you have the isdn group, if so we authenticate you,
otherwise we move on.

The documentation is getting old, but there is an explanation of that in
doc/ldap_howto.txt or at http://doris.cc/radius.

I will be rewriting that in the next few months with more specific
radius/ldap stuff, I'll get rid of the OS specific stuff, and add some new
things like configurable_failover.  I was hoping to have it done now, but
my radius rebuild project got demoted due to marketing trying to push out
new products yesterday.

Hope that helps.

-Dusty Doris

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


LDAP Profiles

2005-03-06 Thread Jarred Cleem
Hello all;

I am tying to put together an openLDAP/FreeRadius implementation for a
multitude of services we provide.  We are currently providing high speed
cable modem services, local dial-up, national dial-up, Motorola Canopy
Wireless, DSL, ISDN, extended Ethernet, Ethernet over power and a few
other ISP type services.  Currently we have a different AAA platform for
all of the different services we provide.  I am doing some research and
setting up a test lab to see if I can get everything to one AAA
platform.  I think I am close but am looking for some additional help
with the connectivity between FreeRadius and openLDAP.

I currently have FreeRadius communicating with openLDAP and
authenticating the user.  However, the LDAP server is giving the RADIUS
server the wrong profile after authentication.  I am not sure if I
completely and correctly understand how this works.  It looks as thought
it is finds the first ldap-group in my users file and returns the ldap
path to the profile.  My problem is that if a user has more then one
service, say dial-up and DSL, it does not return the right profile.  It
returns the first match in the users file.  

How do I get LDAP and FreeRadius to return to the NAS the correct
profile for the type of service the user is trying to authenticate to?

Below is my configuration information.

openLDAP 2.2.23
freeRadius 1.0.2
Fedora Core 3

Current users file
---begin users
DEFAULT Ldap-Group == disabled, Auth-Type := Reject
Reply-Message = Account disabled.  Please call the helpdesk.

DEFAULT Ldap-Group == dial, User-Profile :=
uid=dial,ou=profiles,dc=multiband,dc=us
Fall-Through = no

DEFAULT Ldap-Group == isdn, User-Profile :=
uid=isdn,ou=profiles,dc=multiband,dc=us
Fall-Through = no

DEFAULT Ldap-Group == dsl-ip, User-Profile :=
uid=dsl-ip,ou=profiles,dc=multiband,dc=us
Fall-Through = no

DEFAULT Auth-Type := Reject
Reply-Message = Please call the helpdesk.
---end users--

Thanks for any help.

--
Jarred F. Cleem


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


Re: LDAP Profiles

2005-03-06 Thread Kostas Kalevras
On Sun, 6 Mar 2005, Jarred Cleem wrote:
Hello all;
I am tying to put together an openLDAP/FreeRadius implementation for a
multitude of services we provide.  We are currently providing high speed
cable modem services, local dial-up, national dial-up, Motorola Canopy
Wireless, DSL, ISDN, extended Ethernet, Ethernet over power and a few
other ISP type services.  Currently we have a different AAA platform for
all of the different services we provide.  I am doing some research and
setting up a test lab to see if I can get everything to one AAA
platform.  I think I am close but am looking for some additional help
with the connectivity between FreeRadius and openLDAP.
I currently have FreeRadius communicating with openLDAP and
authenticating the user.  However, the LDAP server is giving the RADIUS
server the wrong profile after authentication.  I am not sure if I
completely and correctly understand how this works.  It looks as thought
it is finds the first ldap-group in my users file and returns the ldap
path to the profile.  My problem is that if a user has more then one
service, say dial-up and DSL, it does not return the right profile.  It
returns the first match in the users file.
How do I get LDAP and FreeRadius to return to the NAS the correct
profile for the type of service the user is trying to authenticate to?
Below is my configuration information.
openLDAP 2.2.23
freeRadius 1.0.2
Fedora Core 3
Current users file
---begin users
DEFAULT Ldap-Group == disabled, Auth-Type := Reject
   Reply-Message = Account disabled.  Please call the helpdesk.
DEFAULT Ldap-Group == dial, User-Profile :=
uid=dial,ou=profiles,dc=multiband,dc=us
   Fall-Through = no
DEFAULT Ldap-Group == isdn, User-Profile :=
uid=isdn,ou=profiles,dc=multiband,dc=us
   Fall-Through = no
DEFAULT Ldap-Group == dsl-ip, User-Profile :=
uid=dsl-ip,ou=profiles,dc=multiband,dc=us
   Fall-Through = no
DEFAULT Auth-Type := Reject
   Reply-Message = Please call the helpdesk.
---end users--
With the above configuration if a user is a member on more than one groups then 
the first one matched will be the *only* one that will be used. And that *is* 
correct behaviour. What i think you need is to also use incoming request 
attributes to differentiate services (which you aren't right now). Something 
like:

DEFAULT NAS-Port-Type == ISDN, Ldap-Group == isdn, User-Profile :=
uid=isdn,ou=profiles,dc=multiband,dc=us
Fall-Through = no
DEFAULT NAS-Port-Type == Virtual, Ldap-Group == dsp-ip, User-Profile :=
uid=dsl-ip,ou=profiles,dc=multiband,dc=us
Hope you get the idea.
Thanks for any help.
--
Jarred F. Cleem
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED]   National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html