[RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
Michael Rodrigues
mrodrigues at education.ucsb.edu
Mon Jun 9 12:31:34 CDT 2014
Hi Heikki,
Thanks for the reply. I got caught up in other things or I would have
responded sooner.
I got the non-EAP handler setup and made a handler specifically for
Accounting Requests.
The only issue I can find with my config is that users can circumvent my
UserBlacklist by changing the capitalization of their username. I'm
surprised Active Directory allows this, but we had a similar problem
when we were authing against LDAP.
I tried implementing the solution here:
http://www.open.com.au/pipermail/radiator/2013-February/018882.html
But I can still authenticate as "Mrodrigues" when I have "DEFAULT
User-Name = /^mrodrigues$/i Auth-Type = Reject" in the users file. I did
also have the "DEFAULT Auth-Type = Accept" at the end. I tried changing
the default "Accept" to "Reject":
Mon Jun 9 10:07:21 2014: DEBUG: Handling request with Handler
'EAP-Message=/.+/', Identifier 'OUTER_HANDLER'
Mon Jun 9 10:07:21 2014: DEBUG: Deleting session for loo, 10.99.1.250, 80
Mon Jun 9 10:07:21 2014: DEBUG: Handling with Radius::AuthGROUP:
Mon Jun 9 10:07:21 2014: DEBUG: Handling with Radius::AuthFILE:
OUTER_MAC_ADDRESS_BLACKLIST
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE looks for match with
78:d6:f0:97:f7:d3 [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE REJECT: No such user:
78:d6:f0:97:f7:d3 [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthGROUP:
OUTER_MAC_ADDRESS_BLACKLIST result: ACCEPT,
Mon Jun 9 10:07:21 2014: DEBUG: Handling with Radius::AuthNTLM:
OUTER_NTLM_AUTHBY
Mon Jun 9 10:07:21 2014: DEBUG: Handling with EAP: code 2, 9, 80, 25
Mon Jun 9 10:07:21 2014: DEBUG: Response type 25
Mon Jun 9 10:07:21 2014: DEBUG: EAP Success, elapsed time 3.258261
Mon Jun 9 10:07:21 2014: DEBUG: EAP result: 0,
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthGROUP: OUTER_NTLM_AUTHBY
result: ACCEPT,
Mon Jun 9 10:07:21 2014: DEBUG: Handling with AuthINTERNAL:
OUTER_BLACKLIST_REWRITE
Mon Jun 9 10:07:21 2014: DEBUG: Changed Request User-Name to Mrodrigues
from Reply inner_identity
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthGROUP:
OUTER_BLACKLIST_REWRITE result: ACCEPT,
Mon Jun 9 10:07:21 2014: DEBUG: Handling with Radius::AuthFILE:
OUTER_USER_BLACKLIST
Mon Jun 9 10:07:21 2014: DEBUG: Reading users file
/etc/radiator/UsernameBlacklist.txt
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE looks for match with
Mrodrigues [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE REJECT: No such user:
Mrodrigues [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE looks for match with
DEFAULT [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT [loo]
Mon Jun 9 10:07:21 2014: DEBUG: Radius::AuthGROUP: OUTER_USER_BLACKLIST
result: ACCEPT,
Mon Jun 9 10:07:21 2014: DEBUG: AuthBy GROUP result: ACCEPT,
Mon Jun 9 10:07:21 2014: DEBUG: Access accepted for Mrodrigues
*Mon Jun 9 10:07:21 2014: DEBUG: Hook changed User-Name to Mrodrigues**
**Mon Jun 9 10:07:21 2014: WARNING: Invalid reply item Auth-Type ignored*
Mon Jun 9 10:07:21 2014: DEBUG: Packet dump:
It seems as if the regex in the users file just isn't matching
"Mrodrigues". Using the simpler version without regex works fine if the
user file contains:
"mrodrigues Auth-Type = Reject"
Here's my config:
########## ##########
##### Radiator Configuration #####
######### ##########
## Updated 6/9/2014
## Note this file is derived from pre-testing version provided by
mrodrigues
#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.0/24>
Secret testing123
</Client>
#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>
Identifier ACCOUNTING_REQUEST_HANDLER
# Logfile for accounting packets
<Log FILE>
Filename logfile-ad-auth
</Log>
</Handler>
# This catches computers trying to auth
<Handler User-Name=/^host\//>
Identifier COMPUTER_AUTH_HANDLER
<AuthBy INTERNAL>
Identifier COMPUTER_AUTH_REJECT
RequestHook sub { &main::log($main::LOG_DEBUG, "Computer
account authentication requested, rejecting request..."); return
$main::REJECT;}
</AuthBy>
</Handler>
# Inner PEAP handler
<Handler TunnelledByPEAP=1>
Identifier PEAP_INNER_HANDLER
<AuthBy NTLM>
Identifier PEAP_INNER_NTLM_AUTHBY
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType MSCHAP-V2
AutoMPPEKeys
</AuthBy>
</Handler>
# Inner TTLS handler
<Handler TunnelledByTTLS=1>
Identifier TTLS_INNER_HANDLER
<AuthBy NTLM>
Identifier TTLS_INNER_NTLM_AUTHBY
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType MSCHAP-V2
AutoMPPEKeys
</AuthBy>
</Handler>
<Handler EAP-Message=/.+/>
Identifier OUTER_HANDLER
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
<AuthBy FILE>
Identifier OUTER_MAC_ADDRESS_BLACKLIST
NoEAP
# Calling-Station-Id attribute is the user's MAC in this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
</AuthBy>
# Set up the outer tunnel SSL connection
<AuthBy NTLM>
Identifier OUTER_NTLM_AUTHBY
NtlmAuthProg /usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPType PEAP, TTLS
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/radiatordev.key
AutoMPPEKeys
</AuthBy>
# Get inner_identity after it is exported to the Reply, then
use it to set the Request User-Name
<AuthBy INTERNAL>
Identifier OUTER_BLACKLIST_REWRITE
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>
# Check User blacklist
<AuthBy FILE>
Identifier OUTER_USER_BLACKLIST
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
</AuthBy>
</AuthBy>
# If Reply is Access-Accept, send User-Name from inner_identity for
logging, session table.
PostProcessingHook file:"goodies/eap_acct_username_mod.pl"
</Handler>
# Handles and rejects all non-EAP authentication requests
<Handler>
Identifier NON_EAP_HANDLER
<AuthBy INTERNAL>
Identifier NON_EAP_REJECT
AddToReply Reply-Message = Use an EAP method.
RequestHook sub { &main::log($main::LOG_DEBUG, "Non-EAP
authentication requested, rejecting request..."); return $main::REJECT;}
</AuthBy>
</Handler>
#This logs to /var/log/radius/logfile
#Not really necessary, we have SQL logs.
<Log FILE>
Filename logfile
</Log>
Thanks,
Michael
On 5/18/2014 4:26 PM, Heikki Vatiainen wrote:
> On 05/13/2014 11:15 PM, Michael Rodrigues wrote:
>
>> I would like to REJECT any non-EAP in the outer handler. I've tried to
>> rearrange things to have only AuthBy FILE in the outer hanlder, having
>> AuthBy NTLM only in each inner handler.
> Hello Michael,
>
> try this:
>
> <Handler EAP-Message=/.+/>
> # your current config for <Handler>
> </Handler>
>
> # Default Handler
> <Handler>
> # Catches everything non-EAP
> # Could reject with e.g., AuthBy INTERNAL
> </Handler>
>
> Note that the above may require setting another Handler before the
> default to catch the accounting, if this Radiator instances receives
> accounting too.
>
>
>> This would also (I think)
>> require me to move my AuthBy INTERNAL to each inner handler so that it
>> can get inner_identity once it is unpacked after AuthBy NTLM. After this
>> I would AuthBy FILE for blacklist.
>>
>> However, I can't seem to get my outer handler to drop non-EAP requests:
> I'd say the two Handler approach requires you not to rearrange internals
> or require any large changes.
>
> Please let us know how it works.
>
> PS. I've been traveling lately so unfortunately it took a bit longer
> than usual to reply.
>
> Thanks,
> Heikki
>
--
Michael Rodrigues
Technical Support Services Manager
Gevirtz Graduate School of Education
Education Building 4203
(805) 893-8031
help at education.ucsb.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20140609/d0ac837c/attachment.html
More information about the radiator
mailing list