(RADIATOR) Radiator and LDAP performance

[Hugh Irvine]

Hello Campbell -

It is often the case that you have to make multiple queries to the  
database (be it LDAP or SQL), depending on your overall design.

As long as the LDAP server responds quickly enough, you shouldn't have  
a problem.

What is the expected user population? And what is the expected radius  
request rate per second?

Your observations below are correct, but see Mike's mail about testing  
"Universal Passwords".

regards

Hugh


On 3 Mar 2005, at 00:18, Campbell Simpson wrote:

> Hi people,
>
> I've got a working radiator config that's talking LDAP to Novell  
> eDirectory. Now I'm looking at how efficient the LDAP authentication  
> process is and this is where I need some advice. It looks to me that  
> this is the only proper way to authenticate a user, the problem  
> however is that it requires two binds per authentication request which  
> will obviously have an effect on performance. It also seems to me that  
> 'ServerChecksPassword' and 'HoldServerConnection' are mutually  
> exclusive flags.
>
> First up Radiator needs to be authenticated against the LDAP directory  
> before it can search for the user. So I have an AuthDN and  
> AuthPassword set. Radiator then searches for the username with a  
> custom search filter and gets the contents of the aaareply LDAP  
> attribute. As Novell implement proprietary encryption for the user  
> password I need to use the 'ServerChecksPassword' flag. This means  
> there needs to be a second bind done on the username and password to  
> confirm the correct password.
>
> So the question is is there a way to perform this authentication using  
> only a single bind?
>
> Although eDirextory does support persistent connections (according to  
> Novell) I can't get it working with the 'HoldServerConnection' flag.  
> Should this flag work if the 'ServerChecksPassword' is set as well? As  
> it's doing a bind then search then another bind to the user then it  
> seems to me this can't work?? When I run a packet debug I see the two  
> binds occurring but then radiator sends an unbind request. This all  
> occurs over the same LDAP connection so it seems to be that when you  
> set 'ServerChecksPassword' then radiator will always send and unbind  
> request for the LDAP session even though 'HoldServerConnection' is  
> set.
>
> See below packet capture, this is with 'HoldServerConnection' and  
> 'ServerChecksPassword' set:
>
> thr2 -> 146.171.39.80 LDAP C port=33189 Bind Request
> 146.171.39.80 -> thr2         LDAP R port=33189 Bind Response Success
> thr2 -> 146.171.39.80 LDAP C port=33189 Search Request  
> derefFindingBaseObj
> 146.171.39.80 -> thr2         LDAP R port=33189 Search ResDone Success
> thr2 -> 146.171.39.80 LDAP C port=33189 Bind Request
> 146.171.39.80 -> thr2         LDAP R port=33189 Bind Response Success
> thr2 -> 146.171.39.80 LDAP C port=33189 Unbind Request
>
> Here's my config:
>
> <Realm DEFAULT>
>         PreAuthHook file:"/opt/radiator/realmprefix.pl"
>         RewriteUsername s/\@ip\w\./\@/
>         AcctLogFileName %L/accounting.%R
>         WtmpFileName %L/wtmp.%R
>         PasswordLogFileName %L/auth.%R
>
>         <AuthBy LDAP2>
>                 Host    146.171.39.80
>                 Port    389
> #                HoldServerConnection
>                 ServerChecksPassword
>                 SearchFilter  
> (&(groupMembership=cn=%{GlobalVar:access},ou=servic
> es,ou=THR,ou=Applications,ou=spec,ou=customers,ou=Views,o=META)  
> (uid=%U))
>                 BaseDN   
> cn=%U,ou=%R,ou=external,ou=customers,ou=Views,o=META
>                 Scope   base
>                 AuthDN  cn=THRRadius,o=META
>                 AuthPassword    xxxx
>                 AuthAttrDef     aaareply,GENERIC,reply
>                 Version 3
>                 Debug 255
>                 NoDefault
>
>                 # This is the LDAP attribute to match the radius user  
> name
>                 UsernameAttr   uid
>                 AddToReply  Framed-Protocol = PPP,Service-Type =  
> Framed,NAS-Port
> -Type=%{NAS-Port-Type},NAS-IP-Address=%{NAS-IP-Address}
>
>         </AuthBy>
> </Realm>
>
> Any thoughts?
>
> Thanks
>
> Campbell
>
>
> --  
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 28/02/2005
>
>
> ----------------------------------------------------------------------- 
> -------
> "This communication, including any attachments, is confidential.
> If you are not the intended recipient, you should not read
> it - please contact me immediately, destroy it, and do not
> copy or use any part of this communication or disclose
> anything about it. Thank you. Please note that this
> communication does not designate an information system for
>  the purposes of the Electronic Transactions Act 2002."
> ----------------------------------------------------------------------- 
> -------
>
> --
> 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: I am travelling this week, so there may be delays in our  
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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.