(RADIATOR) RewriteUsername - AuthBy LDAP
Hugh Irvine
hugh at open.com.au
Wed Aug 3 20:42:34 CDT 2005
Hello Scott -
You will need to add an AuthAttrDef to your configuration.
Something like this:
<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
AuthAttrDef Juniper-Local-User-Name, Juniper-Local-User-
Name, reply
</AuthBy>
# Log accounting to a detail file
AcctLogFileName %D/detail
</Realm>
It is not entirely clear to me from the debug how your LDAP attribute
is set up, so the above may need some tweaking.
It may need to be this:
AuthAttrDef radiusReplyItem, GENERIC, reply
If this is the case, the string should look like this (no ":")
Juniper-Local-User-Name = tier1
See section 6.36.16 in the Radiator 3.13 reference manual ("doc/
ref.html").
hope this helps
regards
Hugh
On 4 Aug 2005, at 10:05, Scott Ehnert wrote:
> 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.
>>
>>
>>
>
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