(RADIATOR) RewriteUsername - AuthBy LDAP
Scott Ehnert
scott.ehnert at gmail.com
Wed Aug 3 19:05:49 CDT 2005
Hello Hugh,
I have made some strides since yesterday. I have assigned a VSA
within the LDAP user, and RADIUS is properly asking for this attribute
and I am seeing it be returned. The attribute I have defined in this
case is 'Juniper-Local-User-Name' My question now is, how do I take
the value that is being returned for 'Juniper-Local-User-Name' and
send it along as an attribute in the Access-Accept? The goal is to be
able to authenticate using LDAP, with various levels of access being
defined within the LDAP user attributes. So one user will have
'tier1' access and another user will have 'tier2' tier1 and tier2
will be defined on the router as an access class, not as a user.
radius.cfg snippet:
<Realm lab.somenet.net>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy LDAP2>
NoDefault
Host localhost
AuthDN cn=admin, dc=somenet, dc=net
AuthPassword <scrubbed>
BaseDN dc=somenet, dc=net
Version 3
UsernameAttr cn
PasswordAttr passwd
Debug 255
ServerChecksPassword
</AuthBy>
# Log accounting to a detail file
AcctLogFileName %D/detail
</Realm>
This is the output when I have no AddToReply in my radius.cfg and try
to ssh to my router:
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got uid: radius26
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got cn: radius26
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got objectClass: account
posixAccount top shadowAccount radiusprofile
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got shadowLastChange: 12985
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got shadowMax: 99999
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got shadowWarning: 7
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got loginShell: /bin/bash
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got uidNumber: 1014
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got gidNumber: 1014
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got homeDirectory: /home/radius26
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got radiusReplyItem:
Juniper-Local-User-Name:= tier1
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got gecos: ,,,
Wed Aug 3 16:47:51 2005: DEBUG: LDAP got userPassword:
{SMD5}gDLElR8Pv1v6YhPA2hr09xQdGzc=
Wed Aug 3 16:47:51 2005: DEBUG: Radius::AuthLDAP2 looks for match with radius26
Wed Aug 3 16:47:51 2005: DEBUG: Radius::AuthLDAP2 ACCEPT:
Wed Aug 3 16:47:51 2005: DEBUG: Access accepted for radius26
Wed Aug 3 16:47:51 2005: DEBUG: Packet dump:
*** Sending to 10.255.255.243 port 4306 ....
Packet length = 20
02 80 00 14 a5 52 01 e4 d0 6b 81 66 59 38 d5 1c
be b2 0c f2
Code: Access-Accept
Identifier: 128
Authentic: <4>D<194>I f<221><11>|R<231><197><30>Y><172>
Attributes:
You can see that the radiusReplyItem value of
Juniper-Local-User-Name=tier1 is being returned, but it is not being
included in the Attributes field of the Access-Accept packet.
With no Attribute of Juniper-Local-User-Name being included, the
router assumes you want to login as radius26, rather than placing user
radius26 into class 'tier1', and allowing access accordingly.
ssh radius26 at cr1.lab.somenet.net
radius26 at cr1.lab.somenet.net's password:
--- JUNOS 6.3R2.2 built 2004-08-06 01:43:25 UTC
This account is currently not available.
Connection to cr1.lab.somenet.net closed.
Now, when I place the AddToReply function in the radius.cfg:
<Realm lab.somenet.net>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy LDAP2>
NoDefault
Host localhost
AuthDN cn=admin, dc=somenet, dc=net
AuthPassword <scrubbed>
BaseDN dc=somenet, dc=net
Version 3
UsernameAttr cn
PasswordAttr passwd
Debug 255
ServerChecksPassword
AddToReply Juniper-Local-User-Name=tier1
</AuthBy>
# Log accounting to a detail file
AcctLogFileName %D/detail
</Realm>
Now it sends the attribute, and access is granted:
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got uid: radius26
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got cn: radius26
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got objectClass: account
posixAccount top shadowAccount radiusprofile
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got shadowLastChange: 12985
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got shadowMax: 99999
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got shadowWarning: 7
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got loginShell: /bin/bash
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got uidNumber: 1014
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got gidNumber: 1014
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got homeDirectory: /home/radius26
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got radiusReplyItem:
Juniper-Local-User-Name:= tier1
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got gecos: ,,,
Wed Aug 3 16:54:35 2005: DEBUG: LDAP got userPassword:
{SMD5}gDLElR8Pv1v6YhPA2hr09xQdGzc=
Wed Aug 3 16:54:35 2005: DEBUG: Radius::AuthLDAP2 looks for match with radius26
Wed Aug 3 16:54:35 2005: DEBUG: Radius::AuthLDAP2 ACCEPT:
Wed Aug 3 16:54:35 2005: DEBUG: Access accepted for radius26
Wed Aug 3 16:54:35 2005: DEBUG: Packet dump:
*** Sending to 10.255.255.243 port 1699 ....
Packet length = 33
02 0e 00 21 cc 09 be 93 cd 1f c9 f0 b8 f7 7a 59
d2 35 9d 28 1a 0d 00 00 0a 4c 01 07 74 69 65 72
31
Code: Access-Accept
Identifier: 14
Authentic: <127><215>{<17>_<208><240>2<18><29>0<31><8><188><208><28>
Attributes:
Juniper-Local-User-Name = "tier1"
ssh radius26 at cr1.lab.somenet.net
radius26 at cr1.lab.somenet.net's password:
--- JUNOS 6.3R2.2 built 2004-08-06 01:43:25 UTC
radius26 at cr1.lab1>
In summary, my question is: how do I force the radius server to pack
that returned value of radiusReplyItem into the Attributes field of
the Access-Accept packet?
Thank you and regards,
-=Scott
On 8/2/05, Hugh Irvine <hugh at open.com.au> wrote:
>
> Hello Scott -
>
> Understood.
>
> You should check with the vendors concerned to determine how best to
> do the radius authentication.
>
> I will be happy to help if you can send me any relevant URL's.
>
> regards
>
> Hugh
>
>
> On 3 Aug 2005, at 12:51, Scott Ehnert wrote:
>
> > Thanks for the clarification and patience. Unfortunately (or
> > fortunately depending on your perspective), I am using several types
> > of gear, none of which are Cisco. Radius is the only option supported
> > by all the various platforms for authentication.
> >
> > Regards,
> >
> > -=Scott
> >
> > On 8/2/05, Hugh Irvine <hugh at open.com.au> wrote:
> >
> >>
> >> Hello Scott -
> >>
> >> Even for configuration access, radius is used in the same way as
> >> described in my previous mail.
> >>
> >> BTW - if this is for Cisco equipement, Radiator now supports full
> >> TACACS+ operation for authentication, authorisation and accounting.
> >>
> >> There is an example in "goodies/tacacsplusserver.cfg".
> >>
> >> regards
> >>
> >> Hugh
> >>
> >>
> >> On 3 Aug 2005, at 12:22, Scott Ehnert wrote:
> >>
> >>
> >>> Hello Hugh,
> >>>
> >>> Thank you for the quick reply. I believe I may have made a
> >>> mistake by
> >>> using the term NAS. What I am trying to do is establish radius
> >>> authentication for configuration access to routers and switches
> >>> in my
> >>> network. This is opposed to authenticating PPP dialup users for
> >>> instance. In this case, I believe my query makes more sense?
> >>>
> >>> Regards,
> >>>
> >>> -=Scott
> >>>
> >>> On 8/2/05, Hugh Irvine <hugh at open.com.au> wrote:
> >>>
> >>>
> >>>>
> >>>> Hello Scott -
> >>>>
> >>>> When you enable radius authentication on a network device (NAS)
> >>>> it is
> >>>> generally to avoid having to define anything on the NAS at all.
> >>>>
> >>>> What is uaually done is to return suitable radius reply
> >>>> attributes in
> >>>> the access accept that are appropriate for the particular user
> >>>> (rewritten usernames are not returned to the NAS except in very
> >>>> particular circumstances).
> >>>>
> >>>> So in your case you would use AddToReply in your AuthBy clause for
> >>>> common reply attributes, together with any relevant reply
> >>>> attributes
> >>>> defined on a per-user basis. You can use multiple AuthBy clauses if
> >>>> required.
> >>>>
> >>>>
> >>>> <Realm box.somenet.net>
> >>>> RewriteUsername s/^([^@]+).*/$1/
> >>>> <AuthBy LDAP2>
> >>>> NoDefault
> >>>> Host localhost
> >>>> AuthDN cn=admin, dc=somenet, dc=net
> >>>> AuthPassword <scrubbed>
> >>>> BaseDN dc=somenet, dc=net
> >>>> Version 3
> >>>> UsernameAttr cn
> >>>> PasswordAttr passwd
> >>>> ServerChecksPassword
> >>>> Debug 255
> >>>> AddToReply ......
> >>>> </AuthBy>
> >>>> # Log accounting to a detail file
> >>>> AcctLogFileName %D/detail
> >>>> </Realm>
> >>>>
> >>>>
> >>>> hope this helps
> >>>>
> >>>> regards
> >>>>
> >>>> Hugh
> >>>>
> >>>>
> >>>> On 3 Aug 2005, at 10:40, Scott Ehnert wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> Warning: novice radius user...
> >>>>>
> >>>>> What I am trying to accomplish is this:
> >>>>>
> >>>>> Any given user tries to connect to a network device by connecting
> >>>>> with
> >>>>> their username, i.e. 'ssh someuser at box.somenet.net'. The Radius
> >>>>> server authenticates on user 'someuser', maps that to a pre-
> >>>>> defined
> >>>>> access class, then rewrites 'someuser' to user 'full-access'
> >>>>> after the
> >>>>> LDAP authentication has been completed. User 'full-access'
> >>>>> will be
> >>>>> defined as a user on the NAS, this way I don't have to define
> >>>>> individual users on each individual device, I can instead define a
> >>>>> class with appropriate privileges.
> >>>>>
> >>>>> What happens now if I use the RewriteUsername function is that it
> >>>>> does
> >>>>> the rewrite before the LDAP authorization occurs, returning an
> >>>>> Access-Reject as there is no username.
> >>>>>
> >>>>> Is this something that can be accomplished as I have described
> >>>>> it? Is
> >>>>> there a different/better way?
> >>>>>
> >>>>> ----Archive info----
> >>>>> I found one reference in the archive that may be appropriate...
> >>>>>
> >>>>> http://www.open.com.au/archives/radiator/2004-06/msg00170.html
> >>>>> You may need to remove the first User-Name before adding the
> >>>>> second
> >>>>> one (whether this works on the Cisco remains to be seen).
> >>>>>
> >>>>> StripFromReply User-Name
> >>>>> AddToReply User-Name = .....
> >>>>>
> >>>>> ----end Archive info----
> >>>>>
> >>>>> my basic info follows. I have the first rewrite to strip the
> >>>>> Realm,
> >>>>> the second rewrite is currently for testing and is not intended
> >>>>> to be
> >>>>> the final syntax.
> >>>>>
> >>>>> config file snippet:
> >>>>>
> >>>>> <Realm box.somenet.net>
> >>>>> RewriteUsername s/^([^@]+).*/$1/
> >>>>> <AuthBy LDAP2>
> >>>>> NoDefault
> >>>>> Host localhost
> >>>>> AuthDN cn=admin, dc=somenet, dc=net
> >>>>> AuthPassword <scrubbed>
> >>>>> BaseDN dc=somenet, dc=net
> >>>>> Version 3
> >>>>> UsernameAttr cn
> >>>>> PasswordAttr passwd
> >>>>> ServerChecksPassword
> >>>>> Debug 255
> >>>>> RewriteUsername s/^.*/radius2/
> >>>>> </AuthBy>
> >>>>> # Log accounting to a detail file
> >>>>> AcctLogFileName %D/detail
> >>>>> </Realm>
> >>>>>
> >>>>> radiusd output snippet:
> >>>>>
> >>>>> Tue Aug 2 17:10:55 2005: DEBUG: No entries for radius2 found in
> >>>>> LDAP database
> >>>>> Tue Aug 2 17:10:55 2005: DEBUG: Radius::AuthLDAP2 looks for match
> >>>>> with radius2
> >>>>> Tue Aug 2 17:10:55 2005: INFO: Access rejected for radius2: No
> >>>>> such user
> >>>>> Tue Aug 2 17:10:55 2005: DEBUG: Packet dump:
> >>>>> *** Sending to 10.255.255.243 port 4491 ....
> >>>>>
> >>>>> Packet length = 36
> >>>>> 03 d8 00 24 b4 04 34 15 54 42 24 21 81 5e 69 53
> >>>>> ba f9 db 11 12 10 52 65 71 75 65 73 74 20 44 65
> >>>>> 6e 69 65 64
> >>>>> Code: Access-Reject
> >>>>> Identifier: 216
> >>>>> Authentic: Z<255><18><244><1><240>)<16><188><27>
> >>>>> $<148><165><5><168>s
> >>>>> Attributes:
> >>>>> Reply-Message = "Request Denied"
> >>>>>
> >>>>>
> >>>>> Thanks for any help,
> >>>>>
> >>>>> -=Scott
> >>>>>
> >>>>> --
> >>>>> Archive at http://www.open.com.au/archives/radiator/
> >>>>> Announcements on radiator-announce at open.com.au
> >>>>> To unsubscribe, email 'majordomo at open.com.au' with
> >>>>> 'unsubscribe radiator' in the body of the message.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> NB:
> >>>>
> >>>> Have you read the reference manual ("doc/ref.html")?
> >>>> Have you searched the mailing list archive (www.open.com.au/
> >>>> archives/
> >>>> radiator)?
> >>>> Have you had a quick look on Google (www.google.com)?
> >>>> Have you included a copy of your configuration file (no secrets),
> >>>> together with a trace 4 debug showing what is happening?
> >>>>
> >>>> --
> >>>> Radiator: the most portable, flexible and configurable RADIUS
> >>>> server
> >>>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> >>>> -
> >>>> Nets: internetwork inventory and management - graphical,
> >>>> extensible,
> >>>> flexible with hardware, software, platform and database
> >>>> independence.
> >>>> -
> >>>> CATool: Private Certificate Authority for Unix and Unix-like
> >>>> systems.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> NB:
> >>
> >> Have you read the reference manual ("doc/ref.html")?
> >> Have you searched the mailing list archive (www.open.com.au/archives/
> >> radiator)?
> >> Have you had a quick look on Google (www.google.com)?
> >> Have you included a copy of your configuration file (no secrets),
> >> together with a trace 4 debug showing what is happening?
> >>
> >> --
> >> Radiator: the most portable, flexible and configurable RADIUS server
> >> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> >> -
> >> Nets: internetwork inventory and management - graphical, extensible,
> >> flexible with hardware, software, platform and database independence.
> >> -
> >> CATool: Private Certificate Authority for Unix and Unix-like systems.
> >>
> >>
> >>
> >
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
>
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list