[RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
Michael Rodrigues
mrodrigues at education.ucsb.edu
Tue May 6 14:22:33 CDT 2014
Hello,
I've spent lots of time going through debugging output, messing with
hooks, and placing AuthBys and I think I finally have what I want aside
from one issue that I think is specific to my NAS. The inner_identity is
used for the Blacklist checking, as well as in the Access-Accept that
goes to the NAS.
I did end up putting the blacklist in the outer handler because all of
my attempts to grab the inner_identity within the Inner Handler for PEAP
would give me a blank string "". Looking at it, I'm not sure what I get
from having the separate Inner Handlers with the current config.
I think what really helped me wrap my head around this was understanding
the distinction between the Inner User-Name ("anonymous"), the Inner EAP
Identity (my actual username "mrodrigues"), and the Anonymous/Outer
Identity (anything the user decides to enter). Getting the
inner_identity from the Reply (as opposed to the Request) object was
unintuitive, especially since subsequent AuthyBys in an AuthByGROUP
operate on the Request, not the Reply. Some of your previous comments
were helpful in clearing this up.
As far as the NAS issue, while my Accounting packets do show the real
username as I expect, the initial log entry created by the NAS (an
Extreme WM20) that indicates a successful session uses the
Anonymous/Outer Identity. The NAS session table of active users does
show my real name. I suspect that the NAS is using the Anonymous/Outer
Identity to track the transaction but it would be nice to fix if possible.
I've included my config, as well as my modified version of
eap_acct_username_mod.pl:
-----------------------------------------------------------------------------------------------------------------
########## ##########
##### Radiator Configuration #####
######### ##########
## Updated 5/6/2014
## Note this file is derived from pre-testing version provided by
mrodrigues
#This handler catches all "Accounting-Request" packets.
#We only log Start and Stop accounting packets as Alive
#packets are basically useless for our purposes. If you
#would like to grab these packets, delete the "HandleAcctStatusTypes"
#directive below, or edit as obviously necessary.
<Handler Request-Type=Accounting-Request>
#<Log FILE>
#Filename debug.config
#</Log>
</Handler>
#These are the clients from which calls to the RADIUS server are allowed.
#Don't confuse it with the wireless clients, they're different.
<Client 10.99.1.250>
Secret testing123
</Client>
<Handler User-Name=/^host\//>
# AuthBy INTERNAL will reject here
# This catches computers trying to auth
</Handler>
<Handler TunnelledByPEAP=1>
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
<AuthBy NTLM>
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType MSCHAP-V2
AutoMPPEKeys
</AuthBy>
<AuthBy FILE>
Identifier CheckUserBlacklist
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
</AuthBy>
</AuthBy>
</Handler>
<Handler TunnelledByTTLS=1>
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
<AuthBy NTLM>
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType MSCHAP-V2
AutoMPPEKeys
</AuthBy>
<AuthBy FILE>
Identifier CheckUserBlacklist
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
</AuthBy>
</AuthBy>
</Handler>
<Handler>
Identifier OuterHandler
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
<AuthBy FILE>
Identifier CheckMacAddressBlacklist
NoEAP
# Calling-Station-Id attribute is the user's MAC in this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
</AuthBy>
<AuthBy NTLM>
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType PEAP, TTLS, MSCHAP-V2
EAPTLS_CAFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_interm.cer
EAPTLS_CertificateFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_cert.cer
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/cert-srv.pem
EAPTLS_PrivateKeyFile /etc/radiator/certs/radiatordev.key
AutoMPPEKeys
</AuthBy>
<AuthBy INTERNAL>
Identifier FixUserNameForBlacklist
# Get inner_identity after it is exported to the Reply,
then use it to set the Request User-Name
RequestHook sub { my $rq = $_[0]; my $rp = $_[1];
$rq->changeUserName($rp->{inner_identity}); &main::log($main::LOG_DEBUG,
"Changed Request User-Name to $rp->{inner_identity} from Reply
inner_identity"); return $main::ACCEPT;}
</AuthBy>
<AuthBy FILE>
Identifier CheckUserBlacklist
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
</AuthBy>
</AuthBy>
# If Reply is Access-Accept, send User-Name from inner_idenitty for
logging, session table.
PostProcessingHook file:"goodies/eap_acct_username_mod.pl"
</Handler>
#This logs to /var/log/radius/logfile
#Not really necessary, we have SQL logs.
<Log FILE>
Filename logfile
</Log>
-----------------------------------------------------------------------------------------------------------------
eap_acct_username_mod.pl:
-----------------------------------------------------------------------------------------------------------------
sub
{
my ($req, $rep, $handled, $reason) = @_;
if (${$rep}->code() eq 'Access-Accept' )
{
my $rep_username = ${$rep}->{inner_identity};
${$rep}->changeUserName($rep_username);
&main::log($main::LOG_DEBUG, "Hook changed User-Name to
$rep_username for Access-Accept");
}
}
-----------------------------------------------------------------------------------------------------------------
Thanks,
Michael
On 4/22/2014 3:03 AM, Heikki Vatiainen wrote:
> On 04/21/2014 11:15 PM, Michael Rodrigues wrote:
>
>> So if I have three AuthBys in the outer Handler (INTERNAL first for
>> renaming, then two FILEs for checking MAC address and Username) am I
>> correct in assuming that the two AuthBy FILEs will be operating on the
>> request as altered by the initial AuthBy INTERNAL?
> Yes, that is correct. Any modifications to request or reply objects are
> visible for the subsequent AuthBys.
>
>> I made the suggested modification to the hook and it appears to execute,
>> however, it seems to be replacing the username with a blank string ("")
>> during Access-Challeng, and the subsequent AuthBy FILE sections are
>> still using the "anonymous outer identity" when checking against the
>> blacklist files I have.
> Looking at the configuration you sent previously, I'd say the real inner
> identity is available once the inner authentication has completed the
> EAP Identity exchange. That is, there are a number of requests and
> responses to get the TLS tunnel working, after that the real identity is
> sent by the peer over the TLS tunnel. When that has happened, you should
> see the real identity.
>
> It might also be worth considering doing the blacklisting with the inner
> Handler. If you use the outer Handler, it will eventually see the inner
> identity, but with the inner Handler, it will not need to query the
> blacklists for all requests, just the inner requests.
>
> You might want to search for 'Tunnelled' to see what the inner requests
> look like and if they would be more useful for implementing blacklisting
> based on usernames (EAP inner identity). MAC address based blacklisting
> could be in the outer Handler since the MAC is not included in the inner
> auth information.
>
> Thanks,
> Heikki
>
--
Michael Rodrigues
Technical Support Services Manager
Gevirtz Graduate School of Education
Education Building 4203
(805) 893-8031
help at education.ucsb.edu
More information about the radiator
mailing list