(RADIATOR) full user name -> rewritten to realm only -> want full user name again in LDAP lookup & hooks.
Lohier, Matthew
Matthew.Lohier at pba.com.au
Thu Nov 10 21:32:30 CST 2005
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.
----------------------------------------------------
--
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