Phil Mayers wrote:
> I am suggesting that in some sense (and obviously, it's only my opinion,
> and as I say it's only doable to an extent with newer FR versions) the
> following is better:
>
> authenticate {
> Auth-Type PAP {
> krb5
> }
> }
>
> That is, that the Auth-Type be set to refl
George C. Kaplan wrote:
I don't think I understand your examples. A NAS is sending a User-Name
and User-Password, and somehow I have to tell radiusd, "Use Kerberos to
authenticate these users." I don't see how I can do that except by
setting 'Auth-Type = Kerberos' *somewhere*.
I am suggest
On Mar 17, 2006, at 5:45 PM, Phil Mayers wrote:
George C. Kaplan wrote:
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing
to make
this work)
On Saturday 18 March 2006 21:40, George C. Kaplan wrote:
> On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
> > Boian Jordanov <[EMAIL PROTECTED]> wrote:
> >> So, why were %RAD_CHECK and %RAD_REQUEST
> >>
> >>> made read-only?
> >>
> >> Because perl hashes are not ordered.
> >
> > The only requirem
On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
Boian Jordanov <[EMAIL PROTECTED]> wrote:
So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
Because perl hashes are not ordered.
The only requirement is that attributes of the same name be ordered.
This may change the way the modu
Boian Jordanov <[EMAIL PROTECTED]> wrote:
> So, why were %RAD_CHECK and %RAD_REQUEST
> > made read-only?
>
> Because perl hashes are not ordered.
The only requirement is that attributes of the same name be ordered.
This may change the way the module works (I haven't looked), but if
${RAD_REQ
On Friday 17 March 2006 19:21, George C. Kaplan wrote:
> Phil Mayers wrote:
> > Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
> > Auth-Type based on the incoming requests e.g. the "mschap" modules sets
> > Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditt
George C. Kaplan wrote:
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing to make
this work).
Hmm. PAP seems to be the big problem area in thes
Phil Mayers wrote:
> George C. Kaplan wrote:
>> I've been wondering about this, in relation to the rlm_perl module. We
>> see "Don't set Auth-Type in the users file" all over the place, but with
>> rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
>> authorization, I *have to*
George C. Kaplan wrote:
Phil Mayers wrote:
Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
Auth-Type based on the incoming requests e.g. the "mschap" modules sets
Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the
"chap" and "eap" modules. "pap" is a
"George C. Kaplan" <[EMAIL PROTECTED]> wrote:
> I've been wondering about this, in relation to the rlm_perl module. We
> see "Don't set Auth-Type in the users file" all over the place, but with
> rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
> authorization, I *have to* set
Phil Mayers wrote:
> Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
> Auth-Type based on the incoming requests e.g. the "mschap" modules sets
> Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the
> "chap" and "eap" modules. "pap" is a bit more complex a
12 matches
Mail list logo