I'm trying to debug a problem with PEAP/MSCHAPv2 authentication against
LDAP as part of spinning up eduroam. I've included the relevant
Handlers from the configuration below, and the inner authentication part
of the (sanitized) log from an attempt to authenticate. Despite the
password being c
On 11/1/2012 5:53 PM, alan buxey wrote:
> hi,
>
> this log looks like the client is doing
>
> PEAPv0/EAP-MSCHAPv2 rather than PEAPv0/MSCHAPv2 - is that correct?
I believe so (I didn't realize it was possible to do the latter...)
For comparison, here is a log file from the currently working versi
On 11/2/2012 2:02 PM, Heikki Vatiainen wrote:
> I just noticed you have EncryptedPasswordAttr in the LDAP config
> section. EncryptedPasswordAttr should used only for crypt(3) format
> hashes. Since you have NThashed passwords, you should use PasswordAttr.
> See the reference manual for details.
>
IIRC, this is the symptom we saw when our wireless controllers weren't
returning all of the State attributes (see the thread from Neil at
Iowa). For diagnosis, bump your Trace level up to 4 for a while, and
observe the State attributes being sent and returned.
On 5/17/2013 7:12 AM, Michael Hu
On 6/27/2013 3:01 PM, Mueller, Jason C wrote:
Quick summary again, when using ipv6::: and bindv6only set to 0:
* Both IPv4 and IPv6 traffic gets to Radiator
* IPv6 works with everything I have tried
* IPv4 clients will not match on the proper client stanza, only the DEFAULT
client stanza
Perha
I have a need to handle multiple authentication methods which returns
something like this:
AuthBy LDAP2
if result = ACCEPT
then
AuthBy DUO
else
AuthBy RADIUS
with the ultimate authentication result coming from either the DUO or
RADIUS module. I tried to figure out a way to arrange
AuthBy LDAP2
>
> AuthByPolicy ContinueUntilAccept
> AuthBy DUO
> AuthBy RADIUS
>
>
>
> regards
>
> Hugh
>
>
> On 7 Nov 2013, at 08:51, Christopher Bongaarts wrote:
tinue. This might be a good thing too?
>
> Thanks,
> Heikki
>
>
> On 11/07/2013 08:31 PM, Christopher Bongaarts wrote:
>> That would seem to yield the effective logic:
>>
>> AuthBy LDAP2
>> if result = ACCEPT
>> then
>> AuthBy DUO
>> if r
On 7/24/2015 3:17 PM, David Zych wrote:
> so I installed the latest Net::SSLeay 1.70 from cpan and successfully
> got rid of the warnings.
>
> After I deployed these changes to production, we were pleasantly
> astonished to discover that El Capitan and iOS 9 clients were suddenly
> able to connect
On 7/30/2015 12:43 PM, Nick Lowe wrote:
> 1.46 doesn't work.
Quickly looking through the release notes, 1.53 has a change that seems
relevant.
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota
For our PEAP and TTLS EAP methods, we don't use client certificates, so
we'd like to avoid specifying an EAPTLS_CAFile (or CAPath) setting
altogether. But if I omit it (or try something nefarious like
EAPTLS_CAFile /dev/null), auth always fails with the error:
ERR: TLS could not load_verify_lo
11 matches
Mail list logo
