(RADIATOR) LDAP questions

[Hugh Irvine]

Hello Ben -

Sorry - now I'm confused - what exactly do you want to do with usernames and 
passwords? And on the Handler question, no you cannot have Handlers inside 
other Handlers. Again if you can give me a bit more detail I will try to 
suggest something sensible.

regards

Hugh


On Thu, 27 Dec 2001 05:03, Ben Carter wrote:
> Hi Hugh,
>
> Merry Christmas!!!
>
> > On Sun, 23 Dec 2001 10:48, Ben Carter wrote:
> > > Hi all,
> > >
> > > I was wondering if anyone could help me out with the following:
> > >
> > > 1) I have "HoldServerConnection" in my <AuthBy LDAP2> clauses but
> >
> > radiator
> >
> > > still seems to re-connect each time to LDAP. The LDAP server I am using
> >
> > is
> >
> > > iplanets (formerly Netscape) and handles multiple searches in a single
> > > connection with no problem.
> >
> > What version of Radiator are you running? There is a mention of this in
> > the
> > history file ("doc/history.html").
>
> We're running version 2.19!
>
> > > 2) We have a bunch of dialup ports with another provider to give us
> > > unmetered connections for customers of that telco. Most of these users
> >
> > need
> >
> > > to be authenticated using only their Calling-Station-ID (i.e. they DO
> >
> > NOT
> >
> > > have a username and password). We also have a few people who have a
> > > username and password as a way of bypassing the Calling-Station-ID
> >
> > check.
> >
> > > My problem is Radiator expects passwordattr to be defined and insists
> > > on checking the username and password with those in ldap and if they
> > > don't match it rejects them. Obviously in an environment were we are
> > > using the calling-station-id to authenticate the user this is always
> > > going to fail
> >
> > as
> >
> > > they don't supply a username and password!! We have got around this
> >
> > problem
> >
> > > in a very dirty way by using a PostSearchHook to fool radiator into
> > > thinking this is an EAP request (my config file is below). Is there a
> > > better way to do this or can the mandatory checking of username and
> > > password be removed from radiator? (you also get an LDAP error every
> >
> > time
> >
> > > the user has no password and it can't find the passwordattr in LDAP)
> > >
> > > Also, from the config file below, it shows that we check to see if the
> > > username and password (the override Calling-Station-ID users) is valid
> > > BEFORE we check Calling-Station-ID. As our customers are split approx
> >
> > 98%
> >
> > > calling-station-id authenticated versus 2% user/pass authenticated this
> >
> > is
> >
> > > very inefficient resulting in 2 LDAP queries for 98% of users, if we
> >
> > could
> >
> > > have it the other way around it would be only 1 search for the 98% and
> > > 2 searches for the 2%.
> >
> > I think I would add a PreClientHook that would check to see if there is a
> > User-Name and User-Password present in the Access-Request, and if not
> > then add the Calling-Station-Id as both the User-Name and User-Password.
> >
> > Then you can add a Handler that checks for a User-Name that is all digits
> > and
> > uses the appropriate AuthBy clause.
> >
> > There are some example hooks in the file "goodies/hooks.txt".
>
> Ah my fault, when I said the users don't have a username and password
> that's not exactly correct. They don't have one for their dialup connection
> (its done via CSID) but they do have one for the mail accounts, so users
> being users they use those (or some weird derivative that only they know
> how they came up with) for their dialup. So I can't check if the username
> and password is NULL without calling all the users and saying "Hey, don't
> put a username or password in your dialup" which we could of done when we
> first started but there are too many users to do that now!!
>
> On the Handler thing, can you have a handler in a handler as I'm production
> testing Handlers by NAS-group to implement per-NAS-group session limits?
>
> Ben.

-- 
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.
===
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.