Dave,

        I'll try my best to clarify things....Here's my scenario: I
instituted a policy that will allow me to limit those people that are
dialing into the NAS. I added an attribute to each users LDAP entry that is
a valid dialin user. Radiator then checks whether this attribute exists for
the specific user currently requesting authentication. If the attribute AND
username don't exist within the same entry, it rejects them. I was
originally using the AuthAttrDef check function. The problem with this, was
if the attribute didn't exist for a user, it wasn't checked, and
authentication went through. Since I have 1000s of users in LDAP, I didn't
want to add this extra attribute to everyone, only the users that are aloud
to dialin. I choose the altmail5 attribute because I couldn't think of any
reason that I would need it for anything else in the future, and I wasn't
about to redo the schema by adding a NEW attribute that would make more
sense.


This is the line I use in the config file:   SearchFilter
(&(uid=%{User-Name})(altmail5=*))

(&(uid=%{User-Name})(altmail5=*))   Is an LDAP search perimeter that is
passed right through to the LDAP server. All Radiator looks for is a yes or
no answer from LDAP. I used RFC2254 to determine the correct syntax.
http://www.cis.ohio-state.edu/htbin/rfc/rfc2254.html

This filter uses the AND operator. When radiator searches LDAP for the
entry, it must contain both the username, AND the altmail5 attribute (which
can contain any value because of the *) Conversely, you can place a static
value there for a more exact match.

Here's an example of the debug. Notice the %{User-Name} variable is replaced
during the processing...I added that line to make things a little clearer
when I was working on the syntax which can via according to the LDAP version
being used.

Tue Aug  8 18:10:56 2000: DEBUG: Handling request with Handler 'Realm='
Tue Aug  8 18:10:56 2000: DEBUG: Rewrote user name to ochs
Tue Aug  8 18:10:56 2000: DEBUG:  Deleting session for ochs, x.x.x.x, 20002
Tue Aug  8 18:10:56 2000: DEBUG: Handling with Radius::AuthLDAP2
Tue Aug  8 18:10:56 2000: DEBUG: Connecting to xxx, port 389
Tue Aug  8 18:10:56 2000: DEBUG: This is the SearchFilter we are using:
(&(uid=ochs)(altmail5=*))
Tue Aug  8 18:10:56 2000: DEBUG: LDAP got result for
uid=ochs,ou=People,o=Fox Chase Cancer Center,c=US
Tue Aug  8 18:10:56 2000: DEBUG: LDAP got userpassword: xxxx
Tue Aug  8 18:10:56 2000: DEBUG: Radius::AuthLDAP2 looks for match with ochs
Tue Aug  8 18:10:56 2000: DEBUG: Radius::AuthLDAP2 ACCEPT: 
Tue Aug  8 18:10:56 2000: DEBUG: Access accepted for ochs


I'd imagine that this can be used in many ways. But there would have to be
experimentation to see if it will work for you.
This is only a guess, but if you want to have two sets of customers dialin
in, you may need to use handlers, and two Authby clauses...each with a
different searchfilter function.

hth,

Steve

-----Original Message-----
From: Dave Kitabjian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 9:30 AM
To: 'Felicetti, Stephen A.'; 'Robin Gruyters'; '[EMAIL PROTECTED]'
Subject: RE: (RADIATOR) Check Attribute in LDAP


So Stephen,

If I understand you correctly, this "patch" basically implements the
Check Item with NEGATIVE LOGIC, correct? Rather than having Radiator
check for a MATCH, it checks for a MISMATCH to allow authentication?

If so, this is similar to what we're looking for. We want to define 2
types of customer:
        A - these can call regular phone #s (only)
        B - these can call regular phone #s AS WELL AS an 800#

Is this something that we would screen with a Check attribute or a Reply
attribute? That continues to puzzle me. Ideally, we'd like to configure
it with a single Reply attribute for those in group B, and have some
type of logic in the Radiator .cfg file implement the above logic.

Can your patch handle this? Can any of you comment on the proper way to
implement this? I'm going to be required to put some rules on our 800#
very soon...

Thanks in advance!

Dave

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Felicetti, Stephen A.
> Sent: Tuesday, August 08, 2000 4:20 PM
> To: 'Robin Gruyters'; [EMAIL PROTECTED]
> Subject: RE: (RADIATOR) Check Attribute in LDAP
> 
> 
> Robin,
> 
> I'm not sure if I follow exactly what you want to do. But 
> I'll give it a
> shot.
> I have this line in my config file under <Authby LDAP2>:
> 
> AuthAttrDef altmail5,NAS-Port-Type,check
> 
> It allows me to compare the LDAP attribute 'altmail5' against 
> the radius
> attribute 'NAS-Port-Type'. If they don't match, it rejects the
> authentication. If altmail5 does not exist for that user, 
> then it isn't
> checked, and authentication goes through.
> 
> With code written by Hugh and Mike, I've also implemented a 
> new LDAP search
> feature that allows me to query the user's LDAP entry for the 
> existance of a
> specific attribute. If the attribute does not exist, it rejects the
> authentication. Is this closer to what you want to do? If so, 
> it'll require
> 2.16.1, plus new code and patches.
> 
> As far as I know (Hugh can confirm this) this new feature is still in
> testing mode, and hasn't been added to the general release. 
> I've been using
> it here for 1 week now without a problem.
> 
> Let me know if I can help!
> 
> Steve
> 
> 
> -----Original Message-----
> From: Robin Gruyters [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 08, 2000 12:21 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Check Attribute in LDAP
> 
> 
> HI,
> 
> Just one question. Is it possible to check an attribute like:
> 
> if "AccountStatus" exists on the LDAP do Access-Type=Reject
> 
> So no ocheck on attribute from the NAS, only on de LDAP.
> -- 
> Regards,
> 
>  Robin Gruyters - [EMAIL PROTECTED] - WISH BV - nic-hdl: RG3771-RIPE
>  http://www.wish.net - tel: +31(0)413242500 - fax. +31(0)208762628
>  PGP key ID DEB8C991 - Head Engineering / Web Designer / B.O.F.H.
>  BOFH excuse: Incorrect time syncronization
> 
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
> 
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
> 

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to