Re: (RADIATOR) 2.18.3 EAP
On 6 Sep 2001, at 8:02, Hugh Irvine wrote: Note that EAP/LEAP support is being added to Radiator in stages, with EAP/LEAP proxy support being the first. Additional support will be introduced in future revisions. Can I put in a request for EAP-TLS to be one of the next 'stages' to be added? Thanks! M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) 2.18.3 EAP
Hugh, folks, Can anyone give me a pointer as to how to configure use of the new EAP facilities. EAP doesnt appear to be mentioned in the 2.18.3 ref manual on the Radiator site, nor in the distributed documentation, nor goodies file etc. Basically all I can find is the three *.pm modules and two test datafiles in the distribution. even test.pl doesnt seem to use EAP... I don't feel up to guessing usage from the code. Any help much appreciated. M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) filtered logs?
On 9 Aug 2001, at 12:15, Hugh Irvine wrote: the only way to understand what the NAS is doing is to look at a trace 4 debug from Radiator (or the output from your favourite packet sniffer) to see what attributes are present This may either be a help enquiry or a request for a new feature. ;) As noted above there are many instances were a high level trace of transactions for a particular user (or, in this case, for the class of users doing multilink PPP) are required to troubleshoot a config - or indeed just a user with a login problem. However, I find that in trying to follow the transactions for a single user on a production service with reasonably high traffic levels, I'm wading through loads of irrelevant transactions in trying to reconstruct the sequence of communications for a single user. What would be particularly useful is to be able to specify a temporary logfile which could be filtered for a particular username, or a particular class of connection, or a particular realm - as flexible as possible really. Then I could leave my standard logging as it is, and just have a *relevant* trace 4 or 5 for the particular problem I'm looking at for as long as I need it. I've faked this in the past by creating a troubleshooting realm and asking only the user with a problem to try connecting with that realm. Then I can test each of our AuthBY methods one at a time by altering the realm config, and generate a realm-specific log. But its a long-winded way to achieve it, and an artificial setup. (and I can't get a level 4 or 5 trace for the realm without increasing the 'global' level correspondingly and altering all my main logs for as long as I test). Are any alternatives possible? M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) LDAP retries?
Hopefully an easily-answered query. My Radiator installation authenticates using a customised LDAP module (see posts to this list passim). This module is designed to fire off a single authentication attempt. However, the administrators of the LDAP server that I connect to (for complex reasons, I don't 'own' the database I authenticate against) are seeing multiple authentication attempts in rapid succession. This presents problems, because if a dialup users accidentally presents the wrong password, the LDAP server is hit multiple times with that password, and the underlying NDS user object that is being authenticated against registers this as multiple bad attempts at access, and invokes a security lockout (intended to defend against brute force cracking attempts). In effect, one mistake locks the user out for a couple of hours until the security lock expires, even if they subsequently corerect their error. As I mentioned my module makes only one authentication attempt per invocation, but: 1) Could the core Radiator code be calling it more than once for the same login attempt? or (as seems more likely) 2) is the users PC getting impatient waiting for the authentication response, and re-trying whilst radiator is still coping with the previous request? (put another way, is a single radius request from the RAS triggering multiple LDAP responses from Radiator, or is Radiator issuing one LDAP per request as desired, but being repeatedly requested to do this via radius traffic from the RAS?) Any suggestions as to how I can ensure only one LDAP authentication request per dialup login? Its causing us big problems here 8( Thanks, M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === 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.
(RADIATOR) Spam email via Radiator list?
Since signing up to the Radiator mailing list, I've begun to receive large numbers of unsolicited commercial emails (i.e. SPAM) which have the (RADIATOR) list identification mark in their titles, for example: "Subject: (RADIATOR) INCREASE BUSINESS SALES HELLO: THIS IS AN ADVERTISEMENT FOR 50 MILLION E-MAIL ADDRESSES ON CD-ROM. IF YOU HAVE NO INTEREST IN THIS INFORMATION, PLEASE CLICK DELETE. THANK YOU." Examination of the headers shows: Received: from [203.63.154.1] (helo=oscar.open.com.au) by **.***.**.** with smtp (Exim 1.92 #3) ... that open.com.au machines are involved in the mail forwarding chain, and that the actual majordomo mailing list is being used to distribute the spam: Received: (from majordom@localhost) by oscar.open.com.au (8.6.12/8.6.12) id NAA14969 for radiator-list; Thu, 6 Apr 2000 13:40:25 +1000 It is possible to configure majordomo to request moderation on postings containing certain keywords. I'd greatly appreciate it if some efforts were made in that direction... M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === 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.
Re: (RADIATOR) Binding as 'admin' against LDAP
On 14 Mar 00, at 10:26, Felicetti, Stephen A. wrote: I'm authenticating against LDAP, and all is working fine. Here's the problemin order for me to gain access to the password attribute, I must bind as the admin user. Is there anyway to use a NON plain text password in the config file? I can create a non admin user account that can have access to the password attribute, but I would still want that password encrypted. I've hacked a 2.14 module so that it binds as the radius-supplied username(*) using the radius-supplied password and get the authentication or rejection from that - so no admin-user details in the config file and no password attributes in the LDAP tree (it authenticates against the one-way hashed password in the underlying NDS tree, which is suitably secure). (* - actually it does an anonymous bind and search to get the fully qualified DN of the radius username first, and then uses that on an authenticated bind) I understand that 2.15 can do something like this more elegantly than my appalling code (which I posted to the list some months ago during development)..? M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === 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.
(RADIATOR) Password Extraction Probs
I'm still completely at a loss as to how to make the plaintext password
supplied in the radius packet available to the module I am hacking for LDAP
authentication. My perl isnt up to spotting how to get the routines
elsewhere in Radiator to work for me and supply this. Please could someone
talk me through it? (slowly and with no long words, for preference!)
I'm running Radiator-2.14 under FreeBSD 3.2-Release with Perl version
5.005_03 built for i386-freebsd.
The relevant part of my config for testing this function is:
Realm
MaxSessions 2
AuthBy NEWLDAP
Hostx.mcc.ac.uk
Port389
BaseDN c=UK
UsernameAttruid
CheckAttr checkitems
ReplyAttr replyitems
/AuthBy
AcctLogFileName %L/LDAP-detail.%m%y
PasswordLogFileName %L/LDAP-passwd-log.%m%y
ExcludeFromPasswordLog yyy
RejectHasReason
/Realm
The relevant portion of my optimistically-named NEWLDAP module is:
sub findUser
{
my ($self, $name, $p) = @_;
return (undef, 1) unless $self-reconnect;
return (undef, 1) unless $self-anonbind;
my $user;
my @attrs;
push(@attrs, $self-{CheckAttr}) if defined $self-{CheckAttr};
push(@attrs, $self-{ReplyAttr}) if defined $self-{ReplyAttr};
my $result = $self-{ld}-search
(base = $self-{BaseDN},
scope = 'sub',
filter = "($self-{UsernameAttr}=$name)",
attrs = \@attrs);
if (!$result || $result-code() != LDAP_SUCCESS)
{
my $code = $result ? $result-code() : -1;
my $errname = ldap_error_name($code);
$self-log($main::LOG_ERR, "ldap search failed with error
$errn
$self-{ld} = undef;
return (undef, 1);
}
my $entry = $result-entry(0);
if ($entry)
{
$user = new Radius::User;
my $dn = $entry-dn;
$self-log($main::LOG_DEBUG, "LDAP got result for $dn");
my ($attr);
foreach $attr ($entry-attributes())
{
my @vals = $entry-get($attr);
$self-log($main::LOG_DEBUG, "LDAP got $attr: @vals");
$attr = lc $attr;
if ($attr eq lc $self-{CheckAttr})
{
$user-get_check-parse(join ',', @vals);
}
elsif ($attr eq lc $self-{ReplyAttr})
{
$user-get_reply-parse(join ',', @vals);
}
}
}
else
{
$self-log($main::LOG_DEBUG, "No entries for $name found in LDAP
database");
$self-unbind;
return 0;
}
$self-unbind;
# Now we connect and do the login as the user.
return (undef, 1) unless $self-reconnect;
# THIS NEEDS TO BE FIXED
# As you can see, for testing, I've hard-coded a password, because
# trying to extract it directly doesnt seem to work... yet!
my $password = "monday";
# The commented out line below doesnt work!
# my $password = $self-decode_password($self-{Client}-{Secret});
my $result = $self-{ld}-bind ( dn = $entry-dn, password = $password);
if (!$result || $result-code() != LDAP_SUCCESS)
{
$self-log($main::LOG_DEBUG, "USER FAILED TO AUTHENTICATE");
my $code = $result ? $result-code() : -1;
my $error = ldap_error_name($code);
$self-log($main::LOG_DEBUG, "Error Code: $code\nError Name: $error");
$self-unbind;
return 0;
}
$self-log($main::LOG_DEBUG, "USER AUTHENTICATED!");
return $user;
}
1;
Advice, please?
I want to purchase Radiator (its currently on evaluation), but can't unless
what I'm trying to do is at least possible...
Thanks,
M.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark O'Leary,| Voice: +44 (0161) 2756110 | Mark O'Leary,
Network Support Officer, | Fax: +44 (0161) 2756040 | Deputy Warden,
Manchester Computing, UK | Email: [EMAIL PROTECTED] | Moberly Hall, UoM.
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) plaintext pw inside module..?
You may recall I've been trying to authenticate against an NDS password via an LDAP server... I have it mostly working (most code cannabalised from existing modules) except for one thing: I need to get the plaintext version of the password that the NAS sent in its access request packet into a variable. I am grabbing the supplied username as the $name passed to the finduser subroutine (or in other attempts via '$p-getUserName'). Whats the equivalent for getting the password, please? Advice welcomed. Thanks. M. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark O'Leary,| Voice: +44 (0161) 2756110 | Mark O'Leary, Network Support Officer, | Fax: +44 (0161) 2756040 | Deputy Warden, Manchester Computing, UK | Email: [EMAIL PROTECTED] | Moberly Hall, UoM. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Netware LDAP
We would like to authenticate against an LDAP server, but rather than actually look up and return the value of the PasswordAttr field to Radiator, we'd like to send the uid and password, and simply have the LDAP server authenticate this against its one-way hash'ed password for that user and just return an 'accept' or 'reject'... This would be preferable because we use an LDAP server with a Netware NDS back-end that already incorporates an NDS password (i.e. one that isnt accessible via an LDAP attribute) for other services, and rather than extending the schema with a password attribute that is a snapshot of the NDS password, we'd like to use it directly. Has anyone created a solution for this? If not, can anyone offer advice on creating an AuthBy module to perform as described above? M. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark O'Leary,| Voice: +44 (0161) 2756110 | Mark O'Leary, Network Support Officer, | Fax: +44 (0161) 2756040 | Deputy Warden, Manchester Computing, UK | Email: [EMAIL PROTECTED] | Moberly Hall, UoM. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
