(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:21:12 CST 2005
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.
--
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