(RADIATOR) full user name -> rewritten to realm only -> want full user name again in LDAP lookup & hooks.
Hugh Irvine
hugh at open.com.au
Thu Nov 10 21:41:28 CST 2005
Hello Matt -
This looks OK - does it work properly for you?
If so its fine.
regards
Hugh
On 11 Nov 2005, at 14:32, Lohier, Matthew wrote:
>
>
> Hugh,
>
> I've got an LDAP directory such as this one:
> ou=Channel directory,dc=TT,dc=org
> cn=REALM1,ou=Channel directory,dc=TT,dc=org
> pdsn=101.101.101.101,cn=REALM1,ou=Channel
> directory,dc=TT,dc=org
> pdsn=101.101.101.102,cn=REALM1,ou=Channel
> directory,dc=TT,dc=org
> cn=REALM2,ou=Channel directory,dc=TT,dc=org
> pdsn=101.101.101.101,cn=REALM2,ou=Channel
> directory,dc=TT,dc=org
> pdsn=101.101.101.102,cn=REALM2,ou=Channel
> directory,dc=TT,dc=org
>
> So I've got this AuthBy clause to return me the radius attributes
> for a
> given channel (REALM1) and pdsn (101.101.101.102).
>
> Do you think I should write the AuthBy clause differently?
>
> PS: (&(cn=%R)(pdsn=%{NAS-IP-Address})) would not work of course.
>
>
> <AuthBy LDAP2>
> Identifier lookupTunnel
> Host xxx
> Port 389
> AuthDN AAA
> AuthPassword BB
> BaseDN cn=%R,ou=Channel directory,dc=TT,dc=org
> NoDefault
> UsernameAttr
> PasswordAttr
> AuthenticateAttribute NAS-IP-Address
> AuthAttrDef pdsn,NAS-IP-Address,request
> SearchFilter (pdsn=%{NAS-IP-Address})
> AddToReply Reply-Message=SUCCESS
>
> AuthAttrDef
> radiusTunnelServerEndpoint,Tunnel-Server-Endpoint,reply
> AuthAttrDef
> radiusTunnelPassword,Tunnel-Password,reply
> AuthAttrDef
> radiusTunnelMediumType,Tunnel-Medium-Type,reply
> AuthAttrDef radiusTunnelType,Tunnel-Type,reply
> </AuthBy>
>
>
> Cheers / Matt
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Friday, 11 November 2005 2:21 PM
> To: Lohier, Matthew
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) full user name -> rewritten to realm only ->
> want full user name again in LDAP lookup & hooks.
>
>
> Hello Matt -
>
> You should provide your own SearchFilter in the AuthBy LDAP2 clause.
>
> It is not clear to me how your "lookupTunnel" is meant to operate,
> but you can specify a SearchFilter for something other than the
> username:
>
> SearchFilter (cn=%R)
>
> regards
>
> Hugh
>
>
>
> On 11 Nov 2005, at 14:03, Lohier, Matthew wrote:
>
>>
>> Hi Hugh,
>>
>> I didn't know that %R would give me the realm without applying any
>> rewriting (in the manual, it says %R : the realm of the username in
>> the
>> current request AFTER any rewriting was applied). But I've tried
>> without
>> rewriting and with %R as the user name in the lookupTunnel AuthBy
>> (see
>> below).
>>
>> <AuthBy GROUP>
>> AuthByPolicy ContinueUntilIgnore
>> # Rewriting username stripping user and leaving domain.
>> # RewriteUsername s/^.*@//
>> AuthBy lookupTunnel
>> <AuthBy INTERNAL>
>> AuthHook file:"%D/Hooks/checkTunnel.pl"
>> </Authby>
>> </Authby>
>>
>> <AuthBy GROUP>
>> AuthByPolicy ContinueUntilIgnore
>> # StripFromRequest User-Name
>> # AddToRequest User-Name=%u
>> AuthBy lookupSubscriber
>> <AuthBy INTERNAL>
>> AuthHook file:"%D/Hooks/checkSubscriber.pl"
>> </Authby>
>> </AuthBy>
>>
>> <AuthBy LDAP2>
>> Identifier lookupTunnel
>> Host xxx
>> Port 389
>> AuthDN YYY
>> AuthPassword 1burst
>> BaseDN cn=%R,ou=XXX
>> [...]
>> </AuthBy>
>>
>> It finds the LDAP entry but than of course the User-Name is the
>> request
>> in the full name, but I guess I can use the regex to get the realm
>> part
>> of the username.
>>
>> Fri Nov 11 13:40:49 2005: DEBUG: LDAP got result for
>> cn=REALM.NET.AU,ou=XXX
>> Fri Nov 11 13:40:49 2005: DEBUG: Request has User-Name:
>> matt.lohier at iburst.net.au
>>
>> So I guess it would be ok.
>> What do you think?
>>
>> Cheers / Matt
>>
>>
>> -----Original Message-----
>> From: Hugh Irvine [mailto:hugh at open.com.au]
>> Sent: Friday, 11 November 2005 1:36 PM
>> To: Lohier, Matthew
>> Cc: radiator at open.com.au
>> Subject: Re: (RADIATOR) full user name -> rewritten to realm only ->
>> want full user name again in LDAP lookup & hooks.
>>
>>
>> Hello Matt -
>>
>> Instead of using multiple RewriteUsername's, why not just use "%R" to
>> look up the tunnel?
>>
>> See section 6.2 in the Radiator 3.13 reference manual ("doc/
>> ref.html").
>>
>> regards
>>
>> Hugh
>>
>>
>> On 11 Nov 2005, at 12:21, Lohier, Matthew wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> Version: Radiator-3.13 on linux.
>>>
>>> I've noticed some problems with rewriting the user name, and then
>>> using
>>> the %u,%w... variables to use the original name before the
>>> rewriting had
>>> happened.
>>>
>>> I use User-Name in some LDAP lookup with the full name (user at realm),
>>> then rewrite the user name to realm only and do a lookup, but then I
>>> need to do another lookup with the full name again (see below).
>>>
>>> <Handler Client-Identifier=XXX,Request-Type=Access-Request>
>>> AuthByPolicy ContinueWhileAccept
>>>
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueUntilIgnore
>>> AuthBy lookupUT
>>> <AuthBy INTERNAL>
>>> AuthHook file:"%D/Hooks/checkUT.pl"
>>> </Authby>
>>> </AuthBy>
>>>
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueUntilIgnore
>>> # Rewriting username stripping user and leaving domain.
>>> RewriteUsername s/^.*@//
>>> AuthBy lookupTunnel
>>> <AuthBy INTERNAL>
>>> AuthHook file:"%D/Hooks/checkTunnel.pl"
>>> </Authby>
>>> </Authby>
>>>
>>> #
>>> # NEED TO USE THE ORIGINAL USER NAME HERE (before rewriting).
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueUntilIgnore
>>> AuthBy lookupSubscriber
>>> <AuthBy INTERNAL>
>>> AuthHook file:"%D/Hooks/checkSubscriber.pl"
>>> </Authby>
>>> </AuthBy>
>>> </Handler>
>>>
>>> <AuthBy LDAP2>
>>> Identifier lookupSubscriber
>>> Host xxx
>>> Port yyy
>>> AuthDN sss
>>> AuthPassword yy
>>> BaseDN yyy
>>> NoDefault
>>> UsernameAttr cn
>>> PasswordAttr
>>> SearchFilter (cn=%u)
>>> AddToReply Reply-Message=SUCCESS
>>> AuthAttrDef uid,Utid,reply
>>> </AuthBy>
>>>
>>> Note: I cannot modify the ordering of the clause. I use %u (full
>>> name
>>> before rewriting) in the last clause.
>>>
>>> Suppose Clause 1 has happened with user matt.lohier at realm.net.au.
>>> Clause
>>> 2 modified the name to realm.net.au. And now in Clause 3 sorts of
>>> work.
>>> The LDAP query will find the right user (matt.lohier at realm.net.au)
>>> but
>>> Radiator will still try to match the entry with the rewritten user
>>> name
>>> (realm.net.au) (see below) AND more importantly the User-Name
>>> attribute
>>> in the request is still the rewritten one. Annoying!
>>>
>>> Fri Nov 11 12:07:56 2005: DEBUG: LDAP got result for
>>> cn=matt.lohier at realm.net.au,ou=Subscriber
>>> directory,dc=iburstForum,dc=org
>>> Fri Nov 11 12:07:56 2005: DEBUG: LDAP got uid: 001264384002795
>>> Fri Nov 11 12:07:56 2005: DEBUG: LDAP got creationDate: 1131670385
>>> Fri Nov 11 12:07:56 2005: DEBUG: LDAP got ati: 10
>>> Fri Nov 11 12:07:56 2005: DEBUG: Radius::AuthLDAP2 looks for match
>>> with
>>> realm.net.au
>>> Fri Nov 11 12:07:56 2005: DEBUG: Radius::AuthLDAP2 ACCEPT:
>>> Fri Nov 11 12:07:56 2005: DEBUG: Handling with AuthINTERNAL:
>>> Fri Nov 11 12:07:56 2005: DEBUG: AuthHook checkSubscriber()
>>> Fri Nov 11 12:07:56 2005: DEBUG: Checking access request for user
>>> (realm.net.au) and uid (001264384002795).
>>> Fri Nov 11 12:07:56 2005: DEBUG: Request has User-Name: realm.net.au
>>>
>>>
>>> So I did things a bit differently and used
>>> StripFromRequest,AddToRequest
>>> in the Clause 3.
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueUntilIgnore
>>> StripFromRequest User-Name
>>> AddToRequest User-Name=%u
>>> AuthBy lookupSubscriber
>>> <AuthBy INTERNAL>
>>> AuthHook file:"%D/Hooks/checkSubscriber.pl"
>>> </Authby>
>>> </AuthBy>
>>>
>>>
>>> That's a bit better (see below), but Radiator's still trying to
>>> match
>>> the entry with the old user name. It works in this case, but I'm
>>> worried
>>> we can run into problems. That code is in AuthGeneric.pm.
>>> Fri Nov 11 12:15:01 2005: DEBUG: Handling with Radius::AuthLDAP2:
>>> lookupSubscriber
>>> Fri Nov 11 12:15:01 2005: INFO: Connecting to xxx
>>> Fri Nov 11 12:15:01 2005: INFO: Attempting to bind to LDAP server
>>> yyy
>>> Fri Nov 11 12:15:01 2005: DEBUG: LDAP got result for
>>> cn=matt.lohier at realm.au,ou=XXX
>>> Fri Nov 11 12:15:01 2005: DEBUG: LDAP got uid: 001264384002795
>>> Fri Nov 11 12:15:01 2005: DEBUG: Radius::AuthLDAP2 looks for match
>>> with
>>> realm.net.au
>>> Fri Nov 11 12:15:01 2005: DEBUG: Radius::AuthLDAP2 ACCEPT:
>>> Fri Nov 11 12:15:01 2005: DEBUG: Handling with AuthINTERNAL:
>>> Fri Nov 11 12:15:01 2005: DEBUG: AuthHook checkSubscriber()
>>> Fri Nov 11 12:15:01 2005: DEBUG: Request has User-Name:
>>> matt.lohier at iburst.net.au
>>>
>>>
>>> Do you think there's something you can fix here? Or maybe there's a
>>> better way to tackle the problem, and you could show me how?
>>>
>>> Thanks a lot / Matt
>>>
>>>
>>>
>>> ----------------------------------------------------
>>> This email and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom
>>> they are addressed. If you have received this email in error please
>>> notify the system manager. Please note that any views or opinions
>>> presented in this email are solely those of the author and do not
>>> necessarily represent those of the company. The recipient should
>>> check this email and any attachments for the presence of viruses.
>>> The company accepts no liability for any damage caused by any virus
>>> transmitted by this email.
>>> ----------------------------------------------------
>>>
>>> --
>>> 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.
>>
>>
>>
>> ----------------------------------------------------
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom
>> they are addressed. If you have received this email in error please
>> notify the system manager. Please note that any views or opinions
>> presented in this email are solely those of the author and do not
>> necessarily represent those of the company. The recipient should
>> check this email and any attachments for the presence of viruses.
>> The company accepts no liability for any damage caused by any virus
>> transmitted by this email.
>> ----------------------------------------------------
>
>
> 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.
>
>
>
> ----------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed. If you have received this email in error please
> notify the system manager. Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. The recipient should
> check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
> ----------------------------------------------------
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