Re: 0.9.3 Solaris performance problem
I don't think prstat is reporting incorrectly. To verify, you could always use 'top'. Just be aware that top's statistics are not measured the same way as prstat. Just to make sure you have two procs in that box, run 'psrinfo -v' and see if you have two procs. Is there a chance you only have one proc on that machine? Another thought is to maybe use cputrack and cpustat to see what is going on. Robert On Wed, Oct 06, 2004 at 01:54:54AM +0100, Stungo, Jamie wrote: > No, hadn't tried that... thanks for the suggestion. Many calls to read() to get the > next username logging in. It may be that the high CPU load is due to the pattern > matching going on inbetween these calls. > > I'd like to understand why only one CPU shows at full load and the other idling. Is > it prstat reporting incorrectly? > > JS > > -Original Message- > From: Robert Banniza [mailto:[EMAIL PROTECTED] > Sent: Wed 10/6/2004 1:41 AM > To: [EMAIL PROTECTED] > Cc: > Subject: Re: 0.9.3 Solaris performance problem > Have you tried putting the process under truss (truss -fp ) to see > what kind of system calls are being made by radius? This may give you an > idea of what is going on. > > Robert > > On Wed, Oct 06, 2004 at 01:33:34AM +0100, Stungo, Jamie wrote: > > > > -Original Message- > > From: Kostas Kalevras [mailto:[EMAIL PROTECTED] > > Sent: Tue 10/5/2004 11:50 PM > > To: [EMAIL PROTECTED] > > Cc: > > Subject:Re: 0.9.3 Solaris performance problem > > On Tue, 5 Oct 2004, Stungo, Jamie wrote: > > > > > Hi all, > > > > > > We are experiencing some unexpected behaviour of freeradius on our Solaris 9 > > > platform. We use two V240 dual processor SPARC machines, LDAP back-end, flat > > > file accounting. I have heavily indexed the directory and it seems lightning > > > fast, slapd is running at 0.2% most of the time, yet radiusd chews 95+% of > > > CPU0 and I have to re-nice the process to get a workable shell! This is on > > > both machines. As I understand it we can't spread the load across both CPUs? > > > > >Freeradius is multithreaded, so the load sould be spread across both CPUs. >What > > >type is the CPU usage, kernel/user/io? > > > > > > CPU states: 0.0% idle, 14.6% user, 85.4% kernel, 0.0% iowait, 0.0% swap > > > > > > > > > > I don't believe that the problem is caused by the number of lookups as it was > > > running at fairly low loads (with 10k subs) until we recently added another > > > couple of thousand (who match in the users file instead of dropping through to > > > the LDAP). > > > > >I really don't understand this paragraph. What do you mean by subs? Couple > > >thousand of what? Match in the users file? > > > > Subs = subscribers/users. Approximately half the users would do two matches in the > > users file, the rest just one. > > > > > Our users file has about 130 DEFAULT matches (total) as follows: > > > > >That's plenty of DEFAULT entries. Remember that for each request the server > > >might try matching 130 entries. Make sure you have the best > > >matching entries first. Though i would not bet my money on that being the >root > > >cause. > > > > It's a good point, I have moved around some entries and I believe this has > > slightly improved things, however you're right and this is not the main problem. > > > > > > > > DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.1, > > > Auth-Type := Accept > > > Service-Type = Framed, > > > Framed-Protocol = PPP, > > > ERX-Virtual-Router-Name = PROVIDER1, > > > Tunnel-Type = L2TP, > > > Tunnel-Medium-Type = IP, > > > ERX-Tunnel-Password = xx, > > > Tunnel-Client-Endpoint = 172.X.X.X, > > > Tunnel-Server-Endpoint = 172.X.X.Y, > > > Tunnel-Assignment-Id = , > > > Tunnel-Client-Auth-Id = blahblah, > > > Tunnel-Server-Auth-Id = blehbleh > > > > > > DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.2, > > > Autz-Type := WholesaleLDAP, Auth-Type := Accept > > > Service-Type = Framed, > > > Framed-Protocol = PPP, > > > ERX-Virtual-Router-Name = PROVIDER
Re: 0.9.3 Solaris performance problem
Have you tried putting the process under truss (truss -fp ) to see
what kind of system calls are being made by radius? This may give you an
idea of what is going on.
Robert
On Wed, Oct 06, 2004 at 01:33:34AM +0100, Stungo, Jamie wrote:
>
> -Original Message-
> From: Kostas Kalevras [mailto:[EMAIL PROTECTED]
> Sent: Tue 10/5/2004 11:50 PM
> To: [EMAIL PROTECTED]
> Cc:
> Subject: Re: 0.9.3 Solaris performance problem
> On Tue, 5 Oct 2004, Stungo, Jamie wrote:
>
> > Hi all,
> >
> > We are experiencing some unexpected behaviour of freeradius on our Solaris 9
> > platform. We use two V240 dual processor SPARC machines, LDAP back-end, flat
> > file accounting. I have heavily indexed the directory and it seems lightning
> > fast, slapd is running at 0.2% most of the time, yet radiusd chews 95+% of
> > CPU0 and I have to re-nice the process to get a workable shell! This is on
> > both machines. As I understand it we can't spread the load across both CPUs?
>
> >Freeradius is multithreaded, so the load sould be spread across both CPUs. >What
> >type is the CPU usage, kernel/user/io?
>
>
> CPU states: 0.0% idle, 14.6% user, 85.4% kernel, 0.0% iowait, 0.0% swap
>
>
> >
> > I don't believe that the problem is caused by the number of lookups as it was
> > running at fairly low loads (with 10k subs) until we recently added another
> > couple of thousand (who match in the users file instead of dropping through to
> > the LDAP).
>
> >I really don't understand this paragraph. What do you mean by subs? Couple
> >thousand of what? Match in the users file?
>
> Subs = subscribers/users. Approximately half the users would do two matches in the
> users file, the rest just one.
>
> > Our users file has about 130 DEFAULT matches (total) as follows:
>
> >That's plenty of DEFAULT entries. Remember that for each request the server
> >might try matching 130 entries. Make sure you have the best
> >matching entries first. Though i would not bet my money on that being the >root
> >cause.
>
> It's a good point, I have moved around some entries and I believe this has slightly
> improved things, however you're right and this is not the main problem.
>
> >
> > DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.1,
> > Auth-Type := Accept
> > Service-Type = Framed,
> > Framed-Protocol = PPP,
> > ERX-Virtual-Router-Name = PROVIDER1,
> > Tunnel-Type = L2TP,
> > Tunnel-Medium-Type = IP,
> > ERX-Tunnel-Password = xx,
> > Tunnel-Client-Endpoint = 172.X.X.X,
> > Tunnel-Server-Endpoint = 172.X.X.Y,
> > Tunnel-Assignment-Id = ,
> > Tunnel-Client-Auth-Id = blahblah,
> > Tunnel-Server-Auth-Id = blehbleh
> >
> > DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.2,
> > Autz-Type := WholesaleLDAP, Auth-Type := Accept
> > Service-Type = Framed,
> > Framed-Protocol = PPP,
> > ERX-Virtual-Router-Name = PROVIDER1,
> > Tunnel-Type = L2TP,
> > Tunnel-Medium-Type = IP,
> > ERX-Tunnel-Password = xx,
> > Tunnel-Client-Endpoint = 172.X.X.X,
> > Tunnel-Server-Endpoint = 172.X.X.Y,
> > Tunnel-Assignment-Id = x,
> > Tunnel-Client-Auth-Id = blahblah,
> > Tunnel-Server-Auth-Id = blehbleh
> >
> > We get a lot of "Unresponsive child" and "Dropping conflicting packet" errors
> > in our radius log, as well as the max number of threads hitting its ceiling
> > (128). Suggestions for a reasonable figure for this for our hardware platform
> > would be helpful to know. It seems to hit its roof at around 250. I'm not sure
> > whether better performance would be gained from allowing it to peak or to keep
> > it low.
>
> >Could you post your authorize,authenticate,session and accounting sections? >Do you
> >check for double logins?
>
> We do check for double login checks by means of an LDAP lookup (WholesaleLDAP) on
> about half the users.
>
>
> authorize {
> #
> # The preprocess module takes care of sanitizing some bizarre
> # attributes in the request, and turning them into attributes
> # which are more standard.
> #
> # It takes care of processing the 'raddb/hints' and the
> # 'raddb/huntgroups' files.
> #
> # It also adds a Client-IP-Address attribute to the request.
> preprocess
>
> #
> # If you want to have a log of authentication requests,
> # un-comment the following line, and the 'detail auth_log'
> # section, above.
> auth_log
>
> #
> # The chap module will set 'Auth-Type := CHAP' if we are
> # handling a CHAP request and Auth-Type has not already be
Re: Radius groups per device
I ended up using the huntgroups file to do this (i.e.): Juniper-M-SeriesNAS-IP-Address == 10.1.1.20 User-Name = sally Then in my users file: DEFAULT Huntgroup-Name == "Juniper-M-Series" Auth-Type := LDAP, Fall-Through = No This gave me the ability to let "sally" auth on the the Juniper-M but login on everything else. Do a man on huntgroups and users file. Hope this helps... Robert On Fri, Sep 10, 2004 at 10:22:52AM -0500, Michael Gleissner wrote: > ver. freeradius-0.7.1 > > I have been researching for a week or two and have come up blank. > > I would like to create a group in /etc/group that the radius server will > recognize. This is for our VPN. The purpose being that if a user is in the > group they are allowed access to the VPN if not they can still use radius > auth for dial-up. We are using a Cisco 3000 VPN Concentrator. > > Thanks, > -Mike > * > Michael Gleissner *RHCE* > Network Specialist > (847) 925-6831 > William Rainey Harper College > 1200 W. Algonquin Rd. > Palatine, IL 60067 > * > > - > 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: Problem with FreeRADIUS 0.9.3 using LDAP Auth
Run 'radiusd -X -A' and report back where it seems to be hanging up.
Robert
On Tue, Aug 10, 2004 at 03:38:17PM -0600, Oscar Caballero Chavanel wrote:
> Hello,
>
> I started using and configuring FreeRADIUS 0.9.3 on SuSE Linux
> Enterprise Server 8.
>
> I need to authenticate RADIUS users to eDirectory server using LDAP.
> After some research, I found how to accomplish that, however, the
> performance is extremely slow. I am getting responses from LDAP after 10
> seconds of waiting... THe LDAP server is running OK and the performance
> using other software to query or authenticate is just fine.
>
> I guess that maybe I am doing something wrong with the configuration
> options.
>
> Maybe you guys, could give me a hand and take a look at the following
> lines:
>
> Extracted from the radiusd.conf file...
>
> ldap {
> server = "192.168.1.3"
> port = 389
> identity = "cn=admin,o=novell"
> password = novell
> basedn = "o=novell"
> # authtype = "MS-CHAP"
> filter = "(uid=%u)"
> start_tls = no
> # default_profile = "cn=radprofile,ou=dialup,o=My
> Org,c=UA"
> # profile_attribute = "radiusProfileDn"
> # access_group = "cn=clients,ou=dialup,o=My Org,c=UA"
> # access_attr = "dialupAccess"
> dictionary_mapping = ${raddbdir}/ldap.attrmap
> # ldap_cache_timeout = 120
> # ldap_cache_size = 0
> ldap_connections_number = 5
> # password_header = "{clear}"
> password_attribute = userPassword
> # groupname_attribute = cn
> # groupmembership_filter =
> "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))"
> timeout = 4
> timelimit = 3
> net_timeout = 1
> }
>
> I also changed my users configuration file, to use LDAP as the default
> (and unique) Auth-Type. Is there anything else I should configure or
> modify in the configuration files?
>
> Thanks so much for your help!
>
> Oscar Caballero
>
> -
> 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: Problem with Huntgroups
On Wed, Aug 04, 2004 at 02:41:09PM -0400, Alan DeKok wrote: > Robert Banniza <[EMAIL PROTECTED]> wrote: > > 1) In the users file, I have the following (pay attention to the > > Ldap-Group entry): > > > > DEFAULT Huntgroup-Name == "Cisco" > > Auth-Type := LDAP, > > Service-Type := 6, > > Ldap-Group == cisco, > > You are putting check items into the reply list. See "man 5 users". > > The above configurtion WILL NOT work, and WILL result in large > warning messages in the debug logs. I'm confused. Why does it state to use '==' in the rlm_ldap file in the doc directory? Thanks Robert > > Alan DeKok. > > - > 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: Using groups to allow certain engineers access to certain switches??
On Wed, Aug 04, 2004 at 02:14:41PM +0300, Kostas Kalevras wrote:
> On Tue, 3 Aug 2004, Robert Banniza wrote:
>
> > Guys,
> > I'm using Freeradius-0.9.3 with the rlm_ldap module (OpenLDAP backend)
> > and have most everything configured except this last little bit. I would
> > like to allow only certain users to have the ability to log in to only
> > certain switches. i.e. Cisco group will manage cisco devices and juniper
> > group can only manage juniper devices.
> >
> > I thought I could do this by placing:
> >
> > "Group = operator"
> >
> > in the huntgroups file under each individual huntgroup and then adding a
> >
> > "radiusReplyItem: Group := operator"
>
> The correct radius group attribute Ldap-Group. And you don't set group
> membership in this way. Please read the ldap documentation in the doc folder.
OK, I have looked at the rlm_ldap documentation and here is what I have.
I have restarted radiusd and everyone is still able to log into each
device successfully. I only want certain people with matching
radiusGroupName attributes to be able to log into the respective device
and anyone else to be rejected. What am I doing wrong here:
1) In the users file, I have the following (pay attention to the
Ldap-Group entry):
DEFAULT Huntgroup-Name == "Cisco"
Auth-Type := LDAP,
Service-Type := 6,
Ldap-Group == cisco,
Fall-Through = Yes
DEFAULT Huntgroup-Name == "Juniper-E-series"
Auth-Type := LDAP,
Ldap-Group == junipere,
Fall-Through = Yes
DEFAULT Huntgroup-Name == "Juniper-M-Series"
Auth-Type := LDAP,
Ldap-Group == juniperm,
Fall-Through = No
2) My LDAP schema has the following (pay attention to radiusGroupName):
dn: uid=homer, ou=people, dc=test, dc=net
objectclass: person
objectclass: radiusprofile
objectclass: uidObject
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: extensibleObject
cn: Homer Simpson
sn: Simpson
loginShell: /bin/bash
userpassword: {SSHA}vFGHHGJxzesR5Y/rodHeQbF9yiAAxbMP
uidnumber: 2001
gidnumber: 20
homeDirectory: /home/homer
uid: homer
shadowLastChange: 10877
shadowMin: 0
shadowMax: 99
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
radiusAuthType: LDAP
radiusReplyItem: Juniper-Local-User-Name := tier3
radiusReplyItem: ERX-Cli-Initial-Access-Level := "15"
radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15"
radiusReplyItem: ERX-CLI-Allow-All-VR-Access := 1
radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
radiusGroupName: cisco
radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
3) In my radiusd.conf file, I have groupname_attribute = radiusGroupName
and groupmembership_attribute = radiusGroupName.
>
> >
> > in my ldap schema. However, this has managed to seg fault the radiusd
> > process. Is this the correct way to go about adding tiered access to my
> > routers/switches? If not, I would appreciate any help out there.
> >
> > Robert
> >
> > -
> > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> >
>
> --
> Kostas Kalevras Network Operations Center
> [EMAIL PROTECTED] National Technical Universi
Re: Problem with Huntgroups
On Wed, Aug 04, 2004 at 10:52:28AM -0400, Alan DeKok wrote:
> "Geoffrey Cauchi" <[EMAIL PROTECTED]> wrote:
> > Did you have any reply re. this? We are facing a very similar problem and
> > it would be greatly appreciated if you could tell us how you solved the
> > problem.
>
> So far, I don't think he has.
>
> I've taken a quick look at the problem, but I'm not sure what's
> going wrong, so I'm not sure I can suggest any fix or work-around.
>
> Alan DeKok.
OK, I have looked at the rlm_ldap documentation and here is what I have.
I have restarted radiusd and everyone is still able to log into each
device successfully. I only want certain people with matching
radiusGroupName attributes to be able to log into the respective device
and anyone else to be rejected. What am I doing wrong here:
1) In the users file, I have the following (pay attention to the
Ldap-Group entry):
DEFAULT Huntgroup-Name == "Cisco"
Auth-Type := LDAP,
Service-Type := 6,
Ldap-Group == cisco,
Fall-Through = Yes
DEFAULT Huntgroup-Name == "Juniper-E-series"
Auth-Type := LDAP,
Ldap-Group == junipere,
Fall-Through = Yes
DEFAULT Huntgroup-Name == "Juniper-M-Series"
Auth-Type := LDAP,
Ldap-Group == juniperm,
Fall-Through = No
2) My LDAP schema has the following (pay attention to radiusGroupName):
dn: uid=homer, ou=people, dc=test, dc=net
objectclass: person
objectclass: radiusprofile
objectclass: uidObject
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: extensibleObject
cn: Homer Simpson
sn: Simpson
loginShell: /bin/bash
userpassword: {SSHA}vFGHHGJxzesR5Y/rodHeQbF9yiAAxbMP
uidnumber: 2001
gidnumber: 20
homeDirectory: /home/homer
uid: homer
shadowLastChange: 10877
shadowMin: 0
shadowMax: 99
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
radiusAuthType: LDAP
radiusReplyItem: Juniper-Local-User-Name := tier3
radiusReplyItem: ERX-Cli-Initial-Access-Level := "15"
radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15"
radiusReplyItem: ERX-CLI-Allow-All-VR-Access := 1
radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
radiusGroupName: cisco
radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
3) In my radiusd.conf file, I have groupname_attribute = radiusGroupName
and groupmembership_attribute = radiusGroupName.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using groups to allow certain engineers access to certain switches??
Guys, I'm using Freeradius-0.9.3 with the rlm_ldap module (OpenLDAP backend) and have most everything configured except this last little bit. I would like to allow only certain users to have the ability to log in to only certain switches. i.e. Cisco group will manage cisco devices and juniper group can only manage juniper devices. I thought I could do this by placing: "Group = operator" in the huntgroups file under each individual huntgroup and then adding a "radiusReplyItem: Group := operator" in my ldap schema. However, this has managed to seg fault the radiusd process. Is this the correct way to go about adding tiered access to my routers/switches? If not, I would appreciate any help out there. Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Setting Service-Type by device IP??
Is there a way to set the Service-Type by the device you are logging into? i.e. I want Service-Type := Administrative User for Cisco and Service-Type := Shell-User for Juniper devices. Can this be done according to the IP of each device? Thanks Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Juniper E-Series...which atributes to use?
On Wed, Jul 21, 2004 at 12:14:59PM +1000, Paul Hampson wrote: > On Tue, Jul 20, 2004 at 08:35:59AM -0500, Robert Banniza wrote: > > On Tue, Jul 20, 2004 at 11:00:18PM +1000, Paul Hampson wrote: > > > On Tue, Jul 20, 2004 at 06:35:32AM -0500, Robert Banniza wrote: > > > > This we have done. They mentioned that Unisphere-Init-CLI-Access-Level > > > > should work as well as ERX-Cli-Initial-Access-Level or > > > > Juniper-Initial-CLI-Access-Level. What I don't understand is how the > > > > Juniper is able to parse the three (as they are different names) and > > > > understand them. I do not have anything in ldap.attrmap that maps one to > > > > the other. > > > > > > It doesn't. The RADIUS server (FreeRADIUS, here) turns the names into > > > numbers using the dictionary files, and sends the numbered attributes > > > to the NAS. > > > > OK, that makes more sense. Here is what we are seeing in the logs when > > trying to use ERX-Cli-Initial-Access-Level: > > > DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): USER ATTRIBUTES: > > (homer) > > DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): service type > > attr: 6 > > DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): admin all VR > > access (vsa) attr: 1 > > DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): alternate admin > > auth level (vsa) attr: 15 > > DEBUG 07/19/2004 20:52:54 EDT radiusClient (): dropping [0009] > > attribute, un-supported data > > OK, it seems the initial admin level attribute's not getting through... > I'd suggest packet-sniffing the RADIUS packets, and (assuming your > sniffer can disassemble RADIUS packets) confirm that the packet on the > wire includes the VSA attribute Vendor 4874 (0x130a) Attribute 18 > (0x12). We can see that Vender 4874 Attribute 20 > (ERX-Alternate-Cli-Access-Level) is getting through fine. I think we have found the issue (I sent an email in earlier about this). It looks like setting Service-Type = Administrative-User is causing us to bypass the Initial-CLI-Access attrbiute. When I take the Service-Type = Administrative-User, everything works as suggested on the Juniper. However, having Service-Type = Administrative-User commented out breaks the Cisco AVPair stuff I need in order to gain Shell Level Access. > > > INFO 07/19/2004 20:52:54 EDT aaaUserAccess (): User: homer, access > > granted > [trim] > > Here is the ldap schema: > [trim] > > radiusReplyItem: Juniper-Local-User-Name := tier3 > > radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15" > > radiusReplyItem: ERX-Cli-Initial-Access-Level := "5" > > radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15" > > radiusReplyItem: ERX-CLI-Allow-All-VR-Access := 1 > > radiusprofileDN: uid=homer, ou=people, dc=test, dc=net > -- > Paul "TBBle" Hampson, on an alternate email client. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cisco-AVPair Question and Juniper...weird
Here's an odd one...Is there any way of getting around having to set Service-Type = Administrative-User in order to get the Cisco-AVPair := "shell:priv-lvl=15" to work correctly? The reason I ask is b/c when I set Service-Type = Administrative-User as the DEFAULT in the users file or through a radiusReplyItem: Service-Type := "Administrative-User" in OpenLDAP, the Juniper ERX radiusReplyItem: ERX-Cli-Initial-Access-Level := "5" attribute is ignored and all users log in with priv. level of 10. Hoeever, when I comment out the Service-Type = Administrative-User in the users file, the Juniper works correctly but am unable to log into the Cisco 29XX devices. Any help certainly appreciated. Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Juniper E-Series...which atributes to use?
On Tue, Jul 20, 2004 at 11:00:18PM +1000, Paul Hampson wrote:
> On Tue, Jul 20, 2004 at 06:35:32AM -0500, Robert Banniza wrote:
> > This we have done. They mentioned that Unisphere-Init-CLI-Access-Level
> > should work as well as ERX-Cli-Initial-Access-Level or
> > Juniper-Initial-CLI-Access-Level. What I don't understand is how the
> > Juniper is able to parse the three (as they are different names) and
> > understand them. I do not have anything in ldap.attrmap that maps one to
> > the other.
>
> It doesn't. The RADIUS server (FreeRADIUS, here) turns the names into
> numbers using the dictionary files, and sends the numbered attributes
> to the NAS.
OK, that makes more sense. Here is what we are seeing in the logs when
trying to use ERX-Cli-Initial-Access-Level:
INFO 07/19/2004 20:52:47 EDT security (): telnet connection 124 with
10.1.5.10 established
DEBUG 07/19/2004 20:52:48 EDT aaaServerGeneral ():
doInitiateUserSession: enter - profileHandle 0x0
DEBUG 07/19/2004 20:52:48 EDT aaaServerGeneral ():
doInitiateUserSession: setting application's profileHandle 0xc000cf
DEBUG 07/19/2004 20:52:51 EDT aaaServerGeneral ():
doInitiateUserSession: enter - profileHandle 0xc000cf
NOTICE 07/19/2004 20:52:51 EDT aaaServerGeneral (): setAddrProfile:
requested to set addr profile when one exists
DEBUG 07/19/2004 20:52:54 EDT aaaServerGeneral ():
doInitiateUserSession: enter - profileHandle 0xc000cf
NOTICE 07/19/2004 20:52:54 EDT aaaServerGeneral (): setAddrProfile:
requested to set addr profile when one exists
DEBUG 07/19/2004 20:52:54 EDT radiusClient (): buildAuthRequest:
building User Auth Request
DEBUG 07/19/2004 20:52:54 EDT radiusClient (): unknown interface type
(default)
DEBUG 07/19/2004 20:52:54 EDT radiusClient (): sendPacket: RADIUS Access
Request packet sent (default)
DEBUG 07/19/2004 20:52:54 EDT radiusClient (): processGoodAuthResponse
enter:
DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): USER ATTRIBUTES:
(homer)
DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): service type
attr: 6
DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): admin all VR
access (vsa) attr: 1
DEBUG 07/19/2004 20:52:54 EDT radiusAttributes (): alternate admin
auth level (vsa) attr: 15
DEBUG 07/19/2004 20:52:54 EDT radiusClient (): dropping [0009]
attribute, un-supported data
INFO 07/19/2004 20:52:54 EDT aaaUserAccess (): User: homer, access
granted
INFO 07/19/2004 20:52:54 EDT aaaUserAccess (): User: homer; terminating:
Unknown
INFO 07/19/2004 20:52:54 EDT security (): exec authorization succeeded:
no method list: model new, method (none), user hom
er, 10.1.5.10, vty3
INFO 07/19/2004 20:52:54 EDT security (): vty 3, telnet login, model
new, method radius, user homer, 10.1.5.10
INFO 07/19/2004 20:53:02 EDT security (): command authorization
succeeded: no method list: "enable 15" model new, method (
none), user homer, 10.1.5.10, vty3, level 10, virtual-router default
INFO 07/19/2004 20:53:07 EDT security (): command authorization
succeeded: no method list: "show users detail" model new,
method (none), user homer, 10.1.5.10, vty3, level 15, virtual-router
default
Here is the ldap schema:
dn: uid=homer, ou=people, dc=test, dc=net
objectclass: person
objectclass: radiusprofile
objectclass: uidObject
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: extensibleObject
cn: Homer Simpson
sn: Simpson
loginShell: /bin/bash
userpassword: {SSHA}vdyzFDGFDGsR5Y/rodfYWQgYvHaDxbMP
uidnumber: 2001
gidnumber: 20
homeDirectory: /home/homer
uid: homer
shadowLastChange: 10877
shadowMin: 0
shadowMax: 99
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
radiusAuthType: LDAP
radiusReplyItem: Juniper-Local-User-Name := tier3
radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
radiusReplyItem: ERX-Cli-Initial-Access-Level := "5"
radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15"
radiusReplyItem: ERX-CLI-Allow-All-VR-Access := 1
radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
>
> --
> Paul "TBBle" Hampson, on an alternate email client.
>
> -
> 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: Juniper E-Series...which atributes to use?
On Tue, Jul 20, 2004 at 12:49:55PM +1000, Paul Hampson wrote: > On Mon, Jul 19, 2004 at 08:05:28PM -0500, Robert Banniza wrote: > > I'm trying to set the Cli-Initial-Access-Level on a Juniper E-Series. > > However, the Juniper is not understanding: > > > radiusReplyItem: ERX-Cli-Initial-Access-Level := "5" > > > With that said, I have looked at > > http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-broadband/html/radius-attributes.html > > and they state that the attribute is Juniper-Initial-CLI-Access-Level > > which is not being picked up either. I therefore tried > > Unisphere-Init-CLI-Access-Level which was not found as well. No matter > > which of these attributes I try, the initial login is always set to a > > privilege level of 10. However, I also have: > > > radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15" > > > This attribute is found and works accordingly after logging in and > > issuing a 'enable 15'. > > > Anyone have any ideas as to what the attribute name should be called for > > the Initial CLI Access Level? I have been stumped on this for two weeks > > now and have googled and searched everything. > > Looking at that webpage, VSA 18 is the one you want. > "Juniper-Initial-CLI-Access-Level" > In FreeRADIUS's dictionary.ERX, that's > "ERX-Cli-Initial-Access-Level" > > So in short, that should work fine. >_< > > Raise it with your vendor? This we have done. They mentioned that Unisphere-Init-CLI-Access-Level should work as well as ERX-Cli-Initial-Access-Level or Juniper-Initial-CLI-Access-Level. What I don't understand is how the Juniper is able to parse the three (as they are different names) and understand them. I do not have anything in ldap.attrmap that maps one to the other. Robert > > -- > Paul "TBBle" Hampson, on an alternate email client. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Juniper E-Series...which atributes to use?
I'm trying to set the Cli-Initial-Access-Level on a Juniper E-Series. However, the Juniper is not understanding: radiusReplyItem: ERX-Cli-Initial-Access-Level := "5" With that said, I have looked at http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-broadband/html/radius-attributes.html and they state that the attribute is Juniper-Initial-CLI-Access-Level which is not being picked up either. I therefore tried Unisphere-Init-CLI-Access-Level which was not found as well. No matter which of these attributes I try, the initial login is always set to a privilege level of 10. However, I also have: radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15" This attribute is found and works accordingly after logging in and issuing a 'enable 15'. Anyone have any ideas as to what the attribute name should be called for the Initial CLI Access Level? I have been stumped on this for two weeks now and have googled and searched everything. Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius & Cisco-AVPair
Not sure if this is the same issue you are having but I had to set the Administrative-User line to get AVPair to work correctly with radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15". Here is what I have in my users file: DEFAULT Auth-Type := LDAP Service-Type = Administrative-User, Fall-Through = 1 Robert On Fri, Jul 16, 2004 at 05:12:27PM -0400, David Birnbaum wrote: > Howdy, > > I'm doing PPPoE to a Cisco 7206, trying to assign static IP addresses from > FreeRadius. So far, I've had no luck. I'm using FreeRadius 1.0.0-pre3, > and everything is dandy for authentication, but two problems: > > 1. Cisco doesn't seem to support Framed-Address for PPPoE (if anyone > knows different that would be great, because nobody at Cisco knows > how to do this. If you can tell me how, stop reading the rest of the > message and help me out!) > > 2. The advice from Cisco is try using Cisco-AVPair to assign a pool. > However, it doesn't seem to be getting parsed properly. > > Here's the entry in my radius file: > > msmiche Auth-Type := Local, Password == "X" > Cisco-AVPair = "ip:addr-pool=msmiche", > Service-Type = Framed-User, > Framed-Protocol = PPP, > Fall-Through = No > > But when I check the debug on the cisco, it complains that the format is > wrong, and it doesn't seem to pull from that pool. The pool has a single > IP address in it to assign: > > Jul 16 17:07:17: RADIUS: Initial Transmit Virtual-Access1 id 10 > 209.212.66.11:1645, Access-Request, len 77 > Jul 16 17:07:17: Attribute 4 6 D1D44262 > Jul 16 17:07:17: Attribute 5 6 0001 > Jul 16 17:07:17: Attribute 61 6 0005 > Jul 16 17:07:17: Attribute 1 9 6D736D69 > Jul 16 17:07:17: Attribute 2 18 C9E797B2 > Jul 16 17:07:17: Attribute 6 6 0002 > Jul 16 17:07:17: Attribute 7 6 0001 > Jul 16 17:07:17: RADIUS: Received from id 10 209.212.66.11:1645, > Access-Accept, len 60 > Jul 16 17:07:17: Attribute 26 28 000901166970 > Jul 16 17:07:17: Attribute 6 6 0002 > Jul 16 17:07:17: Attribute 7 6 0001 > Jul 16 17:07:17: Invalid attribute in radius buffer > Jul 16 17:07:17: Unable to dump packet further > > I would expect to see Attribute 9,1, or something like that, with some > additional text. > > Here's the cisco AAA stuff: > > aaa authentication ppp FRAMED if-needed group radius > aaa authorization network default none > > radius-server host X.X.X.X auth-port 1645 acct-port 1646 key 7 XXX > radius-server retransmit 2 > radius-server timeout 3 > radius-server attribute 6 on-for-login-auth > > Any suggestions much appreciated. I'm running 12.2(24a) right now on the > Cisco. > > David. > > - > 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: Juniper E-Series authentication setup and CLI access
Anyone have any ideas on this? I have Googled to no avail. Anyone else using Juniper ERX dixtionary to auth. and set CLI access levels? Any information would be appreciated. Robert On Thu, Jul 15, 2004 at 02:08:57PM -0500, Robert Banniza wrote: > Guys, > Per the original email (below), here is some more information (debug) > output. The symptons are that the radius users are all logging into the > Juniper with priv. level 10 (regardless of what the > ERX-Cli-Initial-Access-Level is set to). Here is what I'm seeing when I > run 'radiusd -X -A': > > rad_recv: Access-Request packet from host 64.202.129.18:40929, id=31, > length=89 > User-Password = "t3stm3" > User-Name = "homer" > Acct-Session-Id = "erx :0012583078" > Service-Type = Administrative-User > NAS-IP-Address = 10.1.5.17 > NAS-Identifier = "wilma.vr1-atl" > modcall: entering group authorize for request 0 > modcall[authorize]: module "preprocess" returns ok for request 0 > modcall[authorize]: module "chap" returns noop for request 0 > modcall[authorize]: module "eap" returns noop for request 0 > rlm_realm: No '@' in User-Name = "homer", looking up realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 0 > users: Matched DEFAULT at 152 > users: Matched DEFAULT at 216 > modcall[authorize]: module "files" returns ok for request 0 > modcall[authorize]: module "mschap" returns noop for request 0 > rlm_ldap: - authorize > rlm_ldap: performing user authorization for homer > radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' > radius_xlat: 'ou=people,dc=test,dc=net' > ldap_get_conn: Got Id: 0 > rlm_ldap: attempting LDAP reconnection > rlm_ldap: (re)connect to jag.test.net:389, authentication 0 > rlm_ldap: bind as / to jag.test.net:389 > rlm_ldap: waiting for bind result ... > rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter > (&(ObjectClass=posixAccount)(uid=homer)) > rlm_ldap: looking for check items in directory... > rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 > rlm_ldap: looking for reply items in directory... > rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item > Juniper-Local-User-Name := tier3 > rlm_ldap: extracted attribute Cisco-AVPair from generic item > Cisco-AVPair := "shell:priv-lvl=15" > rlm_ldap: extracted attribute ERX-Cli-Initial-Access-Level from generic > item ERX-Cli-Initial-Access-Level := "5" > rlm_ldap: extracted attribute ERX-Alternate-Cli-Access-Level from > generic item ERX-Alternate-Cli-Access-Level := "15" > rlm_ldap: extracted attribute ERX-Cli-Allow-All-VR-Access from generic > item ERX-CLI-Allow-All-VR-Access := 1 > rlm_ldap: user homer authorized to use remote access > ldap_release_conn: Release Id: 0 > modcall[authorize]: module "ldap" returns ok for request 0 > modcall: group authorize returns ok for request 0 > rad_check_password: Found Auth-Type LDAP > auth: type "LDAP" > modcall: entering group Auth-Type for request 0 > rlm_ldap: - authenticate > rlm_ldap: login attempt by "homer" with password "t3stm3" > rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net > rlm_ldap: (re)connect to jag.test.net:389, authentication 1 > rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/t3stm3 to > jag.test.net:389 > rlm_ldap: waiting for bind result ... > rlm_ldap: user homer authenticated succesfully > modcall[authenticate]: module "ldap" returns ok for request 0 > modcall: group Auth-Type returns ok for request 0 > Sending Access-Accept of id 31 to 64.202.129.18:40929 > Service-Type = Administrative-User > Juniper-Local-User-Name := "tier3" > Cisco-AVPair := "shell:priv-lvl=15" > ERX-Cli-Initial-Access-Level := "5" > ERX-Alternate-Cli-Access-Level := "15" > ERX-Cli-Allow-All-VR-Access := enable > Finished request 0 > Going to the next request > > The output from aaa debug mode off of the Juniper is as follows: > > INFO 07/15/2004 14:55:14 EDT security (): telnet connection 90 with > 10.1.1.162 established > INFO 07/15/2004 14:55:22 EDT security (): exec authorization succeeded: > no method list: model new, method (none), user h > omer, 10.1.1.162, vty3 > INFO 07/15/2004 14:55:22 EDT security (): vty 3, telnet login, model > new, method radius, user homer, 10.1.1.162 > > Is there something else I need to do? > &
Re: Juniper E-Series authentication setup and CLI access
I think this was done for Cisco enhanced Privilege levels so that we could use Shell Levels of 15 for users. On Thu, Jul 15, 2004 at 01:24:15PM -0600, Kenneth Grady wrote: > You don't want the "Service-Type = Administrative-User" for everyone > only for the few administrators. > > > On Thu, 2004-07-15 at 13:08, Robert Banniza wrote: > > Guys, > > Per the original email (below), here is some more information (debug) > > output. The symptons are that the radius users are all logging into the > > Juniper with priv. level 10 (regardless of what the > > ERX-Cli-Initial-Access-Level is set to). Here is what I'm seeing when I > > run 'radiusd -X -A': > > > > rad_recv: Access-Request packet from host 64.202.129.18:40929, id=31, > > length=89 > > User-Password = "t3stm3" > > User-Name = "homer" > > Acct-Session-Id = "erx :0012583078" > > Service-Type = Administrative-User > > NAS-IP-Address = 10.1.5.17 > > NAS-Identifier = "wilma.vr1-atl" > > modcall: entering group authorize for request 0 > > modcall[authorize]: module "preprocess" returns ok for request 0 > > modcall[authorize]: module "chap" returns noop for request 0 > > modcall[authorize]: module "eap" returns noop for request 0 > > rlm_realm: No '@' in User-Name = "homer", looking up realm NULL > > rlm_realm: No such realm "NULL" > > modcall[authorize]: module "suffix" returns noop for request 0 > > users: Matched DEFAULT at 152 > > users: Matched DEFAULT at 216 > > modcall[authorize]: module "files" returns ok for request 0 > > modcall[authorize]: module "mschap" returns noop for request 0 > > rlm_ldap: - authorize > > rlm_ldap: performing user authorization for homer > > radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' > > radius_xlat: 'ou=people,dc=test,dc=net' > > ldap_get_conn: Got Id: 0 > > rlm_ldap: attempting LDAP reconnection > > rlm_ldap: (re)connect to jag.test.net:389, authentication 0 > > rlm_ldap: bind as / to jag.test.net:389 > > rlm_ldap: waiting for bind result ... > > rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter > > (&(ObjectClass=posixAccount)(uid=homer)) > > rlm_ldap: looking for check items in directory... > > rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 > > rlm_ldap: looking for reply items in directory... > > rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item > > Juniper-Local-User-Name := tier3 > > rlm_ldap: extracted attribute Cisco-AVPair from generic item > > Cisco-AVPair := "shell:priv-lvl=15" > > rlm_ldap: extracted attribute ERX-Cli-Initial-Access-Level from generic > > item ERX-Cli-Initial-Access-Level := "5" > > rlm_ldap: extracted attribute ERX-Alternate-Cli-Access-Level from > > generic item ERX-Alternate-Cli-Access-Level := "15" > > rlm_ldap: extracted attribute ERX-Cli-Allow-All-VR-Access from generic > > item ERX-CLI-Allow-All-VR-Access := 1 > > rlm_ldap: user homer authorized to use remote access > > ldap_release_conn: Release Id: 0 > > modcall[authorize]: module "ldap" returns ok for request 0 > > modcall: group authorize returns ok for request 0 > > rad_check_password: Found Auth-Type LDAP > > auth: type "LDAP" > > modcall: entering group Auth-Type for request 0 > > rlm_ldap: - authenticate > > rlm_ldap: login attempt by "homer" with password "t3stm3" > > rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net > > rlm_ldap: (re)connect to jag.test.net:389, authentication 1 > > rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/t3stm3 to > > jag.test.net:389 > > rlm_ldap: waiting for bind result ... > > rlm_ldap: user homer authenticated succesfully > > modcall[authenticate]: module "ldap" returns ok for request 0 > > modcall: group Auth-Type returns ok for request 0 > > Sending Access-Accept of id 31 to 64.202.129.18:40929 > > Service-Type = Administrative-User > > Juniper-Local-User-Name := "tier3" > > Cisco-AVPair := "shell:priv-lvl=15" > > ERX-Cli-Initial-Access-Level := "5" > > ERX-Alternate-Cli-Access-Level := "15" > > ERX-Cli-Allow-All-VR-Access := enable > > Finished request 0 > > Going to the next request > > > > The outp
Re: Juniper E-Series authentication setup and CLI access
Guys, Per the original email (below), here is some more information (debug) output. The symptons are that the radius users are all logging into the Juniper with priv. level 10 (regardless of what the ERX-Cli-Initial-Access-Level is set to). Here is what I'm seeing when I run 'radiusd -X -A': rad_recv: Access-Request packet from host 64.202.129.18:40929, id=31, length=89 User-Password = "t3stm3" User-Name = "homer" Acct-Session-Id = "erx :0012583078" Service-Type = Administrative-User NAS-IP-Address = 10.1.5.17 NAS-Identifier = "wilma.vr1-atl" modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "eap" returns noop for request 0 rlm_realm: No '@' in User-Name = "homer", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched DEFAULT at 152 users: Matched DEFAULT at 216 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for homer radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' radius_xlat: 'ou=people,dc=test,dc=net' ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to jag.test.net:389, authentication 0 rlm_ldap: bind as / to jag.test.net:389 rlm_ldap: waiting for bind result ... rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter (&(ObjectClass=posixAccount)(uid=homer)) rlm_ldap: looking for check items in directory... rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 rlm_ldap: looking for reply items in directory... rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item Juniper-Local-User-Name := tier3 rlm_ldap: extracted attribute Cisco-AVPair from generic item Cisco-AVPair := "shell:priv-lvl=15" rlm_ldap: extracted attribute ERX-Cli-Initial-Access-Level from generic item ERX-Cli-Initial-Access-Level := "5" rlm_ldap: extracted attribute ERX-Alternate-Cli-Access-Level from generic item ERX-Alternate-Cli-Access-Level := "15" rlm_ldap: extracted attribute ERX-Cli-Allow-All-VR-Access from generic item ERX-CLI-Allow-All-VR-Access := 1 rlm_ldap: user homer authorized to use remote access ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "homer" with password "t3stm3" rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net rlm_ldap: (re)connect to jag.test.net:389, authentication 1 rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/t3stm3 to jag.test.net:389 rlm_ldap: waiting for bind result ... rlm_ldap: user homer authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: group Auth-Type returns ok for request 0 Sending Access-Accept of id 31 to 64.202.129.18:40929 Service-Type = Administrative-User Juniper-Local-User-Name := "tier3" Cisco-AVPair := "shell:priv-lvl=15" ERX-Cli-Initial-Access-Level := "5" ERX-Alternate-Cli-Access-Level := "15" ERX-Cli-Allow-All-VR-Access := enable Finished request 0 Going to the next request The output from aaa debug mode off of the Juniper is as follows: INFO 07/15/2004 14:55:14 EDT security (): telnet connection 90 with 10.1.1.162 established INFO 07/15/2004 14:55:22 EDT security (): exec authorization succeeded: no method list: model new, method (none), user h omer, 10.1.1.162, vty3 INFO 07/15/2004 14:55:22 EDT security (): vty 3, telnet login, model new, method radius, user homer, 10.1.1.162 Is there something else I need to do? Thanks Robert On Wed, Jul 14, 2004 at 10:11:33AM -0500, Robert Banniza wrote: > Guys, > I'm currently setting up Juniper E-Series devices to authenticate > against FreeRadius using rlm_ldap (OpenLDAP). I currently have: > > radiusReplyItem: ERX-Cli-Initial-Access-Level := "5" > radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15" > radiusReplyItem: ERX-Cli-Allow-All-VR-Access := 1 > > in my schema to allow for access levels, etc. The entire schema is: > > dn: uid=homer, ou=people, dc=test, dc=net > objectclass: person > objectclass: radiusprofile > objectclass: uidObject > objectClass: inetOrgPerson > objectClass:
Juniper E-Series authentication setup and CLI access
Guys,
I'm currently setting up Juniper E-Series devices to authenticate
against FreeRadius using rlm_ldap (OpenLDAP). I currently have:
radiusReplyItem: ERX-Cli-Initial-Access-Level := "5"
radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15"
radiusReplyItem: ERX-Cli-Allow-All-VR-Access := 1
in my schema to allow for access levels, etc. The entire schema is:
dn: uid=homer, ou=people, dc=test, dc=net
objectclass: person
objectclass: radiusprofile
objectclass: uidObject
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: extensibleObject
cn: Homer Simpson
sn: Simpson
loginShell: /bin/bash
userpassword: {SSHA}GyUvGheeeWsR5Y/rofdfYtbDDdQAxbMP
uidnumber: 2001
gidnumber: 20
homeDirectory: /home/homer
uid: homer
shadowLastChange: 10877
shadowMin: 0
shadowMax: 99
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
radiusAuthType: LDAP
radiusReplyItem: Juniper-Local-User-Name := tier1
radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
radiusReplyItem: ERX-Cli-Initial-Access-Level := "5"
radiusReplyItem: ERX-Alternate-Cli-Access-Level := "15"
radiusReplyItem: ERX-Cli-Allow-All-VR-Access := 1
radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
However, I noticed in the dictionary.erx the following:
# As a note on ERX broken-ness, If you don't send a Framed-IP-Address
# in the Access-Accept packet, the ERX disconnects the user, and
# sends an Accounting-Request packet with Acct-Status-Type = Stop
#
# It does NOT send a 'Start' packet, so this behaviour confuses the
# heck out of most admins, who do everything right, but have the ERX
# do stupid things.
#
#
Do I need to add anything else to my LDAP schema/config files in order
to get this to work? I'm not quite sure I understand what the caption
from the dictionary.erx file is telling me. Thanks for any help...
Robert
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Kenneth offered the magic bullet that fixed this. Now on to Juniper ERX auth. and ACL'ing down access to routers. Thanks for all the help guys! I really appreciate it! Robert On Mon, Jul 12, 2004 at 02:37:24PM -0600, Kenneth Grady wrote: > In your users file (line 153 or 217) try adding: > Service-Type = Administrative-User, > > On Mon, 2004-07-12 at 13:42, Robert Banniza wrote: > > Here is what we are seeing nowThe secret has been set and will allow > > us to login but we are not getting any privileged level: > > > > > > rad_recv: Access-Request packet from host 67.106.198.67:1645, id=15, > > length=75 > > NAS-IP-Address = 10.1.1.31 > > NAS-Port = 1 > > NAS-Port-Type = Virtual > > User-Name = "homer" > > Calling-Station-Id = "10.1.1.162" > > User-Password = "t3stm3" > > modcall: entering group authorize for request 0 > > modcall[authorize]: module "preprocess" returns ok for request 0 > > modcall[authorize]: module "chap" returns noop for request 0 > > modcall[authorize]: module "eap" returns noop for request 0 > > rlm_realm: No '@' in User-Name = "homer", looking up realm NULL > > rlm_realm: No such realm "NULL" > > modcall[authorize]: module "suffix" returns noop for request 0 > > users: Matched DEFAULT at 152 > > users: Matched DEFAULT at 216 > > modcall[authorize]: module "files" returns ok for request 0 > > modcall[authorize]: module "mschap" returns noop for request 0 > > rlm_ldap: - authorize > > rlm_ldap: performing user authorization for homer > > radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' > > radius_xlat: 'ou=people,dc=test,dc=net' > > ldap_get_conn: Got Id: 0 > > rlm_ldap: attempting LDAP reconnection > > rlm_ldap: (re)connect to jag.test.net:389, authentication 0 > > rlm_ldap: bind as / to jag.test.net:389 > > rlm_ldap: waiting for bind result ... > > rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter > > (&(ObjectClass=posixAccount)(uid=homer)) > > rlm_ldap: looking for check items in directory... > > rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 > > rlm_ldap: looking for reply items in directory... > > rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item > > Juniper-Local-User-Name := tier1 > > rlm_ldap: extracted attribute Cisco-AVPair from generic item > > Cisco-AVPair := "shell:priv-lvl=15" > > rlm_ldap: user homer authorized to use remote access > > ldap_release_conn: Release Id: 0 > > modcall[authorize]: module "ldap" returns ok for request 0 > > modcall: group authorize returns ok for request 0 > > rad_check_password: Found Auth-Type LDAP > > auth: type "LDAP" > > modcall: entering group Auth-Type for request 0 > > rlm_ldap: - authenticate > > rlm_ldap: login attempt by "homer" with password "t3stm3" > > rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net > > rlm_ldap: (re)connect to jag.test.net:389, authentication 1 > > rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/t3stm3 to > > jag.test.net:389 > > rlm_ldap: waiting for bind result ... > > rlm_ldap: user homer authenticated succesfully > > modcall[authenticate]: module "ldap" returns ok for request 0 > > modcall: group Auth-Type returns ok for request 0 > > Sending Access-Accept of id 15 to 67.106.198.67:1645 > > Juniper-Local-User-Name := "tier1" > > Cisco-AVPair := "shell:priv-lvl=15" > > Finished request 0 > > Going to the next request > > --- Walking the entire request list --- > > Waking up in 6 seconds... > > --- Walking the entire request list --- > > Cleaning up request 0 ID 15 with timestamp 40f2e98a > > Nothing to do. Sleeping until we see a request. > > > > > > > > > > > > On Mon, Jul 12, 2004 at 02:29:28PM -0400, Dustin Doris wrote: > > > You need to do what the debug message said and make sure your shared > > > secret is correct. Check clients.conf in your raddb directory. > > > > > > WARNING: Unprintable characters in the password. ? Double-check the > > > shared secret on the server and the NAS! > > > > > > > > > On Mon, 12 Jul 2004, Robert Banniza wrote: > > > > > > > Here is what radiusd -X -A provides: > > > > > > > &
Re: Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Here is what we are seeing nowThe secret has been set and will allow us to login but we are not getting any privileged level: rad_recv: Access-Request packet from host 67.106.198.67:1645, id=15, length=75 NAS-IP-Address = 10.1.1.31 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "homer" Calling-Station-Id = "10.1.1.162" User-Password = "t3stm3" modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "eap" returns noop for request 0 rlm_realm: No '@' in User-Name = "homer", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched DEFAULT at 152 users: Matched DEFAULT at 216 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for homer radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' radius_xlat: 'ou=people,dc=test,dc=net' ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to jag.test.net:389, authentication 0 rlm_ldap: bind as / to jag.test.net:389 rlm_ldap: waiting for bind result ... rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter (&(ObjectClass=posixAccount)(uid=homer)) rlm_ldap: looking for check items in directory... rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 rlm_ldap: looking for reply items in directory... rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item Juniper-Local-User-Name := tier1 rlm_ldap: extracted attribute Cisco-AVPair from generic item Cisco-AVPair := "shell:priv-lvl=15" rlm_ldap: user homer authorized to use remote access ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "homer" with password "t3stm3" rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net rlm_ldap: (re)connect to jag.test.net:389, authentication 1 rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/t3stm3 to jag.test.net:389 rlm_ldap: waiting for bind result ... rlm_ldap: user homer authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: group Auth-Type returns ok for request 0 Sending Access-Accept of id 15 to 67.106.198.67:1645 Juniper-Local-User-Name := "tier1" Cisco-AVPair := "shell:priv-lvl=15" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 15 with timestamp 40f2e98a Nothing to do. Sleeping until we see a request. On Mon, Jul 12, 2004 at 02:29:28PM -0400, Dustin Doris wrote: > You need to do what the debug message said and make sure your shared > secret is correct. Check clients.conf in your raddb directory. > > WARNING: Unprintable characters in the password. ? Double-check the > shared secret on the server and the NAS! > > > On Mon, 12 Jul 2004, Robert Banniza wrote: > > > Here is what radiusd -X -A provides: > > > > rad_recv: Access-Request packet from host 67.106.198.67:1645, id=10, > > length=75 > > NAS-IP-Address = 11.9.67.177 > > NAS-Port = 1 > > NAS-Port-Type = Virtual > > User-Name = "homer" > > Calling-Station-Id = "10.1.1.162" > > User-Password = "\334\303A_-VB/VJ N\017\230\217\317" > > modcall: entering group authorize for request 0 > > modcall[authorize]: module "preprocess" returns ok for request 0 > > modcall[authorize]: module "chap" returns noop for request 0 > > modcall[authorize]: module "eap" returns noop for request 0 > > rlm_realm: No '@' in User-Name = "homer", looking up realm NULL > > rlm_realm: No such realm "NULL" > > modcall[authorize]: module "suffix" returns noop for request 0 > > users: Matched DEFAULT at 152 > > users: Matched DEFAULT at 216 > > modcall[authorize]: module "files" returns ok for request 0 > > modcall[authorize]: module "mschap" returns noop for request 0 > > rlm_ldap: - authorize > > rlm_ldap: performin
Re: Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Here is what radiusd -X -A provides: rad_recv: Access-Request packet from host 67.106.198.67:1645, id=10, length=75 NAS-IP-Address = 11.9.67.177 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "homer" Calling-Station-Id = "10.1.1.162" User-Password = "\334\303A_-VB/VJ N\017\230\217\317" modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "eap" returns noop for request 0 rlm_realm: No '@' in User-Name = "homer", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched DEFAULT at 152 users: Matched DEFAULT at 216 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for homer radius_xlat: '(&(ObjectClass=posixAccount)(uid=homer))' radius_xlat: 'ou=people,dc=test,dc=net' ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to jag.test.net:389, authentication 0 rlm_ldap: bind as / to jag.test.net:389 rlm_ldap: waiting for bind result ... rlm_ldap: performing search in ou=people,dc=test,dc=net, with filter (&(ObjectClass=posixAccount)(uid=homer)) rlm_ldap: looking for check items in directory... rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 rlm_ldap: looking for reply items in directory... rlm_ldap: extracted attribute Juniper-Local-User-Name from generic item Juniper-Local-User-Name := tier1 rlm_ldap: extracted attribute Cisco-AVPair from generic item Cisco-AVPair := "shell:priv-lvl=15" rlm_ldap: user homer authorized to use remote access ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "homer" with password "ÜÃA_-VB/VJ N???Ï" rlm_ldap: user DN: uid=homer,ou=people,dc=test,dc=net rlm_ldap: (re)connect to jag.test.net:389, authentication 1 rlm_ldap: bind as uid=homer,ou=people,dc=test,dc=net/ÜÃA_-VB/VJ N???Ï to jag.test.net:389 rlm_ldap: waiting for bind result ... modcall[authenticate]: module "ldap" returns reject for request 0 modcall: group Auth-Type returns reject for request 0 auth: Failed to validate the user. WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS! Delaying request 0 for 1 seconds Finished request 0 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 10 to 67.106.198.67:1645 Juniper-Local-User-Name := "tier1" Cisco-AVPair := "shell:priv-lvl=15" Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 10 with timestamp 40f2cbda Nothing to do. Sleeping until we see a request. On Mon, Jul 12, 2004 at 12:46:46PM -0400, Dustin Doris wrote: > What about radiusd -x. Run Freeradius in debug mode. > > On Sun, 11 Jul 2004, Robert Banniza wrote: > > > Here is the debug output: > > > > 2d04h: AAA/MEMORY: create_user (0x20F7E20) user='' ruser='' port='tty1' > > +rem_addr='10.1.1.162' authen_type=ASCII service= > > LOGIN priv=1 > > 2d04h: AAA/AUTHEN/START (1821432037): port='tty1' list='' action=LOGIN > > +service=LOGIN > > 2d04h: AAA/AUTHEN/START (1821432037): using "default" list > > 2d04h: AAA/AUTHEN/START (1821432037): Method=radius (radius) > > 2d04h: AAA/AUTHEN (1821432037): status = GETUSER > > 2d04h: AAA/AUTHEN/CONT (1821432037): continue_login (user='(undef)') > > 2d04h: AAA/AUTHEN (1821432037): status = GETUSER > > 2d04h: AAA/AUTHEN (1821432037): Method=radius (radius) > > 2d04h: AAA/AUTHEN (1821432037): status = GETPASS > > 2d04h: AAA/AUTHEN/CONT (1821432037): continue_login (user='homer') > > 2d04h: AAA/AUTHEN (1821432037): status = GETPASS > > 2d04h: AAA/AUTHEN (1821432037): Method=radius (radius) > > 2d04h: AAA/AUTHEN (1821432037): status = PASS > > 2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): Port='tty1' list='' > > service=EXEC > > 2d04h: AAA/AUTHOR/EXEC: tty1 (3720401710) user='homer'
Re: Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Here is the debug output:
2d04h: AAA/MEMORY: create_user (0x20F7E20) user='' ruser='' port='tty1'
+rem_addr='10.1.1.162' authen_type=ASCII service=
LOGIN priv=1
2d04h: AAA/AUTHEN/START (1821432037): port='tty1' list='' action=LOGIN
+service=LOGIN
2d04h: AAA/AUTHEN/START (1821432037): using "default" list
2d04h: AAA/AUTHEN/START (1821432037): Method=radius (radius)
2d04h: AAA/AUTHEN (1821432037): status = GETUSER
2d04h: AAA/AUTHEN/CONT (1821432037): continue_login (user='(undef)')
2d04h: AAA/AUTHEN (1821432037): status = GETUSER
2d04h: AAA/AUTHEN (1821432037): Method=radius (radius)
2d04h: AAA/AUTHEN (1821432037): status = GETPASS
2d04h: AAA/AUTHEN/CONT (1821432037): continue_login (user='homer')
2d04h: AAA/AUTHEN (1821432037): status = GETPASS
2d04h: AAA/AUTHEN (1821432037): Method=radius (radius)
2d04h: AAA/AUTHEN (1821432037): status = PASS
2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): Port='tty1' list=''
service=EXEC
2d04h: AAA/AUTHOR/EXEC: tty1 (3720401710) user='homer'
2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): send AV service=shell
2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): send AV cmd*
2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): found list "default"
2d04h: tty1 AAA/AUTHOR/EXEC (3720401710): Method=radius (radius)
2d04h: AAA/AUTHOR (3720401710): Post authorization status = FAIL
2d04h: AAA/AUTHOR/EXEC: Authorization FAILED
2d04h: AAA/MEMORY: free_user (0x20F7E20) user='homer' ruser=''
port='tty1'
+rem_addr='10.1.1.162' authen_type=ASCII servi
ce=LOGIN priv=1
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
Soutlake#2#
2d04h: AAA: parse name=tty1 idb type=-1 tty=-1
2d04h: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1
+channel=0
2d04h: AAA/MEMORY: create_user (0x20F7C0C) user='' ruser='' port='tty1'
+rem_addr='10.1.1.162' authen_type=ASCII service=
LOGIN priv=1
2d04h: AAA/AUTHEN/START (2535633014): port='tty1' list='' action=LOGIN
+service=LOGIN
2d04h: AAA/AUTHEN/START (2535633014): using "default" list
2d04h: AAA/AUTHEN/START (2535633014): Method=radius (radius)
2d04h: AAA/AUTHEN (2535633014): status = GETUSER
2d04h: AAA/AUTHEN/CONT (2535633014): continue_login (user='(undef)')
2d04h: AAA/AUTHEN (2535633014): status = GETUSER
2d04h: AAA/AUTHEN (2535633014): Method=radius (radius)
2d04h: AAA/AUTHEN (2535633014): status = GETPASS
2d04h: AAA/AUTHEN/CONT (2535633014): continue_login (user='jessica')
2d04h: AAA/AUTHEN (2535633014): status = GETPASS
2d04h: AAA/AUTHEN (2535633014): Method=radius (radius)
2d04h: AAA/AUTHEN (2535633014): status = PASS
2d04h: tty1 AAA/AUTHOR/EXEC (1601631891): Port='tty1' list=''
service=EXEC
2d04h: AAA/AUTHOR/EXEC: tty1 (1601631891) user='jessica'
2d04h: tty1 AAA/AUTHOR/EXEC (1601631891): send AV service=shell
2d04h: tty1 AAA/AUTHOR/EXEC (1601631891): send AV cmd*
2d04h: tty1 AAA/AUTHOR/EXEC (1601631891): found list "default"
2d04h: tty1 AAA/AUTHOR/EXEC (1601631891): Method=radius (radius)
2d04h: AAA/AUTHOR (1601631891): Post authorization status = FAIL
2d04h: AAA/AUTHOR/EXEC: Authorization FAILED
2d04h: AAA/MEMORY: free_user (0x20F7C0C) user='jessica' ruser=''
port='tty1'
+rem_addr='10.1.1.162' authen_type=ASCII ser
vice=LOGIN priv=1
On Fri, Jul 09, 2004 at 12:42:05PM -0400, Dustin Doris wrote:
> What is the debug output? What happens when you try to login to the
> router? User denied?
>
> On Fri, 9 Jul 2004, Robert Banniza wrote:
>
> > Guys,
> > We are trying to allow users to authenticate to Cisco 26xx routers using
> > Freeradius with the rlm_ldap module (OpenLDAP). We would like some of
> > these users to be able to log in with enable privileges. The following
> > is what we have done to try this with no avail. The following is a
> > sample ldif entry:
> >
> > #
> > dn: uid=homer, ou=people, dc=test, dc=net
> > objectclass: person
> > objectclass: radiusprofile
> > objectclass: uidObject
> > objectClass: inetOrgPerson
> > objectClass: posixAccount
> > objectClass: extensibleObject
> > cn: Homer Simpson
> > sn: Simpson
> > loginShell: /bin/bash
> > userpassword: {SSHA}fghkjfghkhgkfhgrofZyn2u9yiAAxbMP
> > uidnumber: 2001
> > gidnumber: 20
> > homeDirectory: /home/homer
> > uid: homer
> > shadowLastChange: 10877
> > shadowMin: 0
> > shadowMax: 99
> > shadowWarning: 7
> > shadowInactive: -1
> > shadowExpire: -1
> > shadowFlag: 0
> > radiusAuthType: LDAP
> > radiusReplyItem: Juniper-
Re: Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Here is what we are seeing when a user tries to login:
% Authorization failed.
Connection to host lost.
On Fri, Jul 09, 2004 at 12:42:05PM -0400, Dustin Doris wrote:
> What is the debug output? What happens when you try to login to the
> router? User denied?
>
> On Fri, 9 Jul 2004, Robert Banniza wrote:
>
> > Guys,
> > We are trying to allow users to authenticate to Cisco 26xx routers using
> > Freeradius with the rlm_ldap module (OpenLDAP). We would like some of
> > these users to be able to log in with enable privileges. The following
> > is what we have done to try this with no avail. The following is a
> > sample ldif entry:
> >
> > #
> > dn: uid=homer, ou=people, dc=test, dc=net
> > objectclass: person
> > objectclass: radiusprofile
> > objectclass: uidObject
> > objectClass: inetOrgPerson
> > objectClass: posixAccount
> > objectClass: extensibleObject
> > cn: Homer Simpson
> > sn: Simpson
> > loginShell: /bin/bash
> > userpassword: {SSHA}fghkjfghkhgkfhgrofZyn2u9yiAAxbMP
> > uidnumber: 2001
> > gidnumber: 20
> > homeDirectory: /home/homer
> > uid: homer
> > shadowLastChange: 10877
> > shadowMin: 0
> > shadowMax: 99
> > shadowWarning: 7
> > shadowInactive: -1
> > shadowExpire: -1
> > shadowFlag: 0
> > radiusAuthType: LDAP
> > radiusReplyItem: Juniper-Local-User-Name := tier1
> > radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
> > radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
> > #
> >
> > The following is what we have on the router:
> >
> > #
> > aaa new-model
> > aaa authentication login default group radius enable
> > aaa authorization exec default group radius
> >
> > enable secret password
> >
> > radius-server host 67.106.198.70 auth-port 1812 acct-port 1813
> > radius-server retransmit 3
> > radius-server key testing123
> > #
> >
> > What else are we missing? Any help would be appreciated.
> >
> > Robert
> >
> > -
> > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> >
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Authenticating to Cisco 29xx using OpenLDAP and FreeRadius
Guys,
We are trying to allow users to authenticate to Cisco 26xx routers using
Freeradius with the rlm_ldap module (OpenLDAP). We would like some of
these users to be able to log in with enable privileges. The following
is what we have done to try this with no avail. The following is a
sample ldif entry:
#
dn: uid=homer, ou=people, dc=test, dc=net
objectclass: person
objectclass: radiusprofile
objectclass: uidObject
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: extensibleObject
cn: Homer Simpson
sn: Simpson
loginShell: /bin/bash
userpassword: {SSHA}fghkjfghkhgkfhgrofZyn2u9yiAAxbMP
uidnumber: 2001
gidnumber: 20
homeDirectory: /home/homer
uid: homer
shadowLastChange: 10877
shadowMin: 0
shadowMax: 99
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
radiusAuthType: LDAP
radiusReplyItem: Juniper-Local-User-Name := tier1
radiusReplyItem: Cisco-AVPair := "shell:priv-lvl=15"
radiusprofileDN: uid=homer, ou=people, dc=test, dc=net
#
The following is what we have on the router:
#
aaa new-model
aaa authentication login default group radius enable
aaa authorization exec default group radius
enable secret password
radius-server host 67.106.198.70 auth-port 1812 acct-port 1813
radius-server retransmit 3
radius-server key testing123
#
What else are we missing? Any help would be appreciated.
Robert
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Juniper Attributes and OpenLDAP
On Fri, Mar 19, 2004 at 06:35:17PM +0200, Kostas Kalevras wrote: > On Fri, 19 Mar 2004, Robert Banniza wrote: > > > In looking at the dictionary.juniper file, I notice there are 5 > > attributes in this file: > > > > ATTRIBUTE Juniper-Local-User-Name 1 string > > Juniper > > ATTRIBUTE Juniper-Allow-Commands 2 string > > Juniper > > ATTRIBUTE Juniper-Deny-Commands 3 string > > Juniper > > ATTRIBUTE Juniper-Allow-Configuration 4 string > > Juniper > > ATTRIBUTE Juniper-Deny-Configuration 5 string > > Juniper > > > > With that said, I'm using OpenLDAP to authenticate and would also like > > to use LDAP to control who has access to which commands within JUNOS. > > Therefore, can I place these attributes in my OpenLDAP ldif and have > > radius read themIn doing this, don't these attributes need to be > > defined within the RADIUS-LDAPv3.schema or some other schema? Is anyone > > doing this currently to show me where I need to go next? I have searched > > the web and there is little info on Juniper/Freeradius. > > You can either define a few new ldap attributes for the corresponding Juniper > RADIUS attributes and add them to your ldap schema. > Or you can use the generic attributes provided in the current schema: > > radiusReplyItem: Juniper-Local-User-Name := > > and so on I'm not sure I'm following you...Let's say I want to add the Juniper-Allow-Commands and Juniper-Deny-Commands to my user's profile within OpenLDAP. Wouldn't I have to define these attributes within some LDAP schema whether it be in the RADIUS-LDAPv3.schema or some other schema in order for OpenLDAP to know how to interpret the attribute? I guess the knowledge gap I'm having is to determine how/where to make Freeradius understand these attributes within OpenLDAP the same way Freeradius knows about these attributes through the dictionary.juniper file. Along those same lines, in which file do I put "radiusReplyItem: Juniper-Local-User-Name := "? Thanks Robert > > > > > Thanks > > > > Robert > > > > - > > 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Juniper Attributes and OpenLDAP
In looking at the dictionary.juniper file, I notice there are 5 attributes in this file: ATTRIBUTE Juniper-Local-User-Name 1 string Juniper ATTRIBUTE Juniper-Allow-Commands 2 string Juniper ATTRIBUTE Juniper-Deny-Commands 3 string Juniper ATTRIBUTE Juniper-Allow-Configuration 4 string Juniper ATTRIBUTE Juniper-Deny-Configuration 5 string Juniper With that said, I'm using OpenLDAP to authenticate and would also like to use LDAP to control who has access to which commands within JUNOS. Therefore, can I place these attributes in my OpenLDAP ldif and have radius read themIn doing this, don't these attributes need to be defined within the RADIUS-LDAPv3.schema or some other schema? Is anyone doing this currently to show me where I need to go next? I have searched the web and there is little info on Juniper/Freeradius. Thanks Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Juniper and authentication with Freeradius/OpenLDAP
Guys, I've been looking at the Juniper/Radius doc (http://www.qorbit.net/documents/junos-radius-authentication.pdf) that details auth'ing off of Steel Belted Radius. However, I'd like to use Freeradius to do exactly what this doc is stating but don't have any info. to go by. Is anyone using FreeRadius to auth. on Juniper? Also, what needs to be done to perform tier1, tier2, etc. groupings and what a person has access to running on the CLI? Also, can these attributes be placed in LDAP? Thanks Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP authentication...can't find uid with current filter?
On Tue, Mar 16, 2004 at 01:17:19PM -0500, Dustin Doris wrote:
> Take a look at ldap search filters
>
> http://www.ietf.org/rfc/rfc2254.txt
>
> On Tue, 16 Mar 2004, Robert Banniza wrote:
>
> > Having a problem testing my LDAP authentication. In running 'radiusd -X
> > -A', I'm trying to debug why uid 'brad' and his password are not being
> > found. Here is my ldap filter from radiusd.conf:
> >
> > ldap {
> > server = "somehost.somedomain.net"
> > identity = "cn=Manager,dc=somedomain,dc=net"
> > password = somepass
> > basedn = "ou=people,dc=somedomain,dc=net"
> > filter = "((posixAccount)(uid=%u))"
>
> *** Should be "(&(ObjectClass=posixAccount)(uid=%u))"
Thank you very much...That worked!!
Robert
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP authentication...can't find uid with current filter?
Having a problem testing my LDAP authentication. In running 'radiusd -X
-A', I'm trying to debug why uid 'brad' and his password are not being
found. Here is my ldap filter from radiusd.conf:
ldap {
server = "somehost.somedomain.net"
identity = "cn=Manager,dc=somedomain,dc=net"
password = somepass
basedn = "ou=people,dc=somedomain,dc=net"
filter = "((posixAccount)(uid=%u))"
...
...
}
Here is what I'm seeing from the radiusd debug output:
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config: including file: /usr/local/freeradius/etc/raddb/proxy.conf
Config: including file: /usr/local/freeradius/etc/raddb/clients.conf
Config: including file: /usr/local/freeradius/etc/raddb/snmp.conf
Config: including file: /usr/local/freeradius/etc/raddb/sql.conf
main: prefix = "/usr/local/freeradius"
main: localstatedir = "/usr/local/freeradius/var"
main: logdir = "/usr/local/freeradius/var/log/radius"
main: libdir = "/usr/local/freeradius/lib"
main: radacctdir = "/usr/local/freeradius/var/log/radius/radacct"
main: hostname_lookups = no
main: max_request_time = 30
main: cleanup_delay = 5
main: max_requests = 1024
main: delete_blocked_requests = 0
main: port = 0
main: allow_core_dumps = no
main: log_stripped_names = no
main: log_file = "/usr/local/freeradius/var/log/radius/radius.log"
main: log_auth = no
main: log_auth_badpass = no
main: log_auth_goodpass = no
main: pidfile = "/usr/local/freeradius/var/run/radiusd/radiusd.pid"
main: user = "(null)"
main: group = "(null)"
main: usercollide = no
main: lower_user = "no"
main: lower_pass = "no"
main: nospace_user = "no"
main: nospace_pass = "no"
main: checkrad = "/usr/local/freeradius/sbin/checkrad"
main: proxy_requests = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
proxy: wake_all_if_all_dead = no
security: max_attributes = 200
security: reject_delay = 1
security: status_server = no
main: debug_level = 0
read_config_files: reading dictionary
read_config_files: reading naslist
Using deprecated naslist file. Support for this will go away soon.
read_config_files: reading clients
Using deprecated clients file. Support for this will go away soon.
read_config_files: reading realms
Using deprecated realms file. Support for this will go away soon.
radiusd: entering modules setup
Module: Library search path is /usr/local/freeradius/lib
Module: Loaded expr
Module: Instantiated expr (expr)
Module: Loaded PAP
pap: encryption_scheme = "crypt"
Module: Instantiated pap (pap)
Module: Loaded CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = no
mschap: require_strong = no
mschap: passwd = "(null)"
mschap: authtype = "MS-CHAP"
Module: Instantiated mschap (mschap)
Module: Loaded System
unix: cache = no
unix: passwd = "(null)"
unix: shadow = "(null)"
unix: group = "(null)"
unix: radwtmp = "/usr/local/freeradius/var/log/radius/radwtmp"
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded LDAP
ldap: server = "somehost.somedomain.net"
ldap: port = 389
ldap: net_timeout = 1
ldap: timeout = 4
ldap: timelimit = 3
ldap: identity = "cn=Manager,dc=somedomain,dc=net"
ldap: start_tls = no
ldap: password = "somepasswd"
ldap: basedn = "ou=people,dc=somedomain,dc=net"
ldap: filter = "((posixAccount)(uid=%u))"
ldap: default_profile = "(null)"
ldap: profile_attribute = "(null)"
ldap: password_header = "(null)"
ldap: password_attribute = "(null)"
ldap: access_attr = "dialupAccess"
ldap: groupname_attribute = "cn"
ldap: groupmembership_filter =
"(|(&(objectClass=GroupOfNames)(member=%{Ldap-Us
erDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))"
ldap: groupmembership_attribute = "(null)"
ldap: dictionary_mapping =
"/usr/local/freeradius/etc/raddb/ldap.attrmap"
ldap: ldap_debug = 0
ldap: ldap_connections_number = 5
ldap: compare_check_items = no
ldap: access_attr_used_for_allow = yes
conns: 0
rlm_ldap: reading ldap<->radius mappings from file
/usr/local/freeradius/etc/rad db/ldap.attrmap
rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$
rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$
rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type
rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use
rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id
rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS
Calling-Station-Id
rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password
rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password
rlm_ldap: LDAP acctFlags mapped to RADIUS SMB-Account-CTRL-TEXT
rlm_ldap: LDAP radiusExpiration mapped to RADIUS Expiration
rlm_ldap: LDAP radiusServiceType mapped to RAD
rlm_ldap on Solaris not compiling
Guys, I'm trying to compile freeradius with LDAP support on Solaris 9 and the compile is erroring out. I've googled and read the thread http://lists.cistron.nl/pipermail/freeradius-users/2003-February/016497.html and I still can get this thing to compile. Here is what I'm using as the configure line: ./configure --prefix=/usr/local/freeradius --with-rlm-ldap-lib-dir=/usr/local/openldap/lib --with-rlm-ldap-include-dir=/usr/local/openldap/include Here is the error I'm getting from the rlm_ldap compile: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I../../include -DHAVE_LDAP_START_TLS -c rlm_ldap.c -o rlm_ldap.o rlm_ldap.c: In function `ldap_instantiate': rlm_ldap.c:381: error: `LDAP_OPT_X_TLS_HARD' undeclared (first use in this funct ion) rlm_ldap.c:381: error: (Each undeclared identifier is reported only once rlm_ldap.c:381: error: for each function it appears in.) rlm_ldap.c: In function `ldap_connect': rlm_ldap.c:1467: error: `LDAP_OPT_NETWORK_TIMEOUT' undeclared (first use in this function) rlm_ldap.c:1467: error: `LDAP_OPT_SUCCESS' undeclared (first use in this functio n) rlm_ldap.c:1473: error: `LDAP_OPT_DEBUG_LEVEL' undeclared (first use in this fun ction) rlm_ldap.c:1483: error: `LDAP_OPT_X_TLS' undeclared (first use in this function) rlm_ldap.c:1491: warning: implicit declaration of function `ldap_start_tls_s' make: *** [rlm_ldap.o] Error 1 Any ideas? I've tried a myriad of thing including passing LDFLAGS and putting -llber at the RLM_LIBS line in the Makefile. Any help would certainly be appreciated as I've burned three days on this. Robert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
