Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
3. Will disabling machine authentication have any affect on SSO so that a user can login to a domain computer and automatically authenticate to the wifi (assuming the proper GPOs are in place). The recent Windows versions seem to have a number of possibilities to choose which account, user or computer, does the wifi authentiation. However, I have not looked more closely how these settings work with group policies. It would be interesting to hear how it works, so please let us know if you decide to test it. I just wanted to follow up on this as I have done some testing. I was able to use GPOs to allow SSO with a domain user account despite dropping requests for computer authentication. The user's credentials are used to authenticate to the wireless network before the rest of the logon process. I'm using Windows 7 clients and Server 2008R2. Thanks, Michael -- Michael Rodrigues Technical Support Services Manager Gevirtz Graduate School of Education Education Building 4203 (805) 893-8031 h...@education.ucsb.edu ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Wireless client verification of Radiator's SSL cert EAP/PEAP
Hi everyone, Thanks for all of the input, I think between that and the eduroam paper my questions have been answered. The breakdown of differences between various clients is rather useful as well. Even in the absence of client side configuration, some of the clients (notably OS X) present some details about the cert to the user that they can verify manually (name, fingerprint, expiry date). Thanks, Michael -- Michael Rodrigues Technical Support Services Manager Gevirtz Graduate School of Education Education Building 4203 (805) 893-8031 h...@education.ucsb.edu ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Wireless client verification of Radiator's SSL cert EAP/PEAP
Hi, I've been searching around the list and the Internet trying to figure out how a wireless client can verify the hostname of the SSL cert provided by Radiator through the NAS as an SMTP or HTTP client would, but I can't seem to find anything insightful. I'm not concerned with how the client uses the SSL chain and its included CAs to verify the cert cryptographically. For one, the client doesn't have Internet to make a reverse lookup until they accept the cert. Second, even if they were allowed DNS before authentication, someone controlling the network could easily catch and spoof the reverse lookup reply to make their cert look legitimate (assuming it was cryptographically legitimate). I'm doing some development/testing and I notice that iOS and Windows 8 seem to see my certificate as valid but not verified. I setup a PTR record to match my host and cert name but it didn't seem to make any difference. I monitored tcpdump while authenticating from OS X and I see no PTR requests I realize each client can have a different implementation. Is it even possible to legitimately verify a certificate hostname for clients using PEAP and EAP? I'd like to be as secure as possible without resorting to client-side certificates. Thanks, Michael -- Michael Rodrigues Technical Support Services Manager Gevirtz Graduate School of Education Education Building 4203 (805) 893-8031 h...@education.ucsb.edu ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
The syntax in the link below and what you have has a small but important bug. Try something like this (notice the comma).: DEFAULT User-Name = /^mrodrigues$/i, Auth-Type = Reject:Blacklisted Otherwise it should go as Hugh wrote. 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: I think it should go as in the example as soon as you have correctly separated the reply attributes with a comma. Thanks, Heikki I was hoping it was something simple like a missing newline. It works with the comma, so I have the added advantage of being able to add arbitrary Reply attributes, as compared to the RewriteUsername to lowercase method. Thanks for your help on this; the list is always helpful, and I could spend all day tweaking Radiator. Thanks, Michael -- Michael Rodrigues Technical Support Services Manager Gevirtz Graduate School of Education Education Building 4203 (805) 893-8031 h...@education.ucsb.edu ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
TTLS_INNER_NTLM_AUTHBY
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of=AD+Domain Users
Domain AD
EAPTypeMSCHAP-V2
AutoMPPEKeys
/AuthBy
/Handler
Handler EAP-Message=/.+/
Identifier OUTER_HANDLER
AuthBy GROUP
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
AuthBy FILE
IdentifierOUTER_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
IdentifierOUTER_NTLM_AUTHBY
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of=AD+Domain Users
Domain AD
EAPTypePEAP, 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
AddToReplyReply-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
h...@education.ucsb.edu
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
On 5/6/14, 1:15 PM, Heikki Vatiainen wrote:
On 05/06/2014 10:22 PM, Michael Rodrigues wrote:
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.
In many cases the outer Handler contains an AuthBy FILE that only
handles PEAP and TTLS outer authentication, that is, establishing the
TLS tunnel. Note that if the incoming request is not an EAP request,
this AuthBy will also try to authenticate the user. If non-EAP
authentication is not desired, this AuthBy FILE can reject the non-EAP
attempts.
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. 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:
(There's another TunnelledByEAP handler but it's otherwise identical to
the PEAP one)
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 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
NoEAP
Identifier CheckUserBlacklistPEAPInner
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
/AuthBy
/AuthBy
/Handler
Handler
Identifier OuterHandler
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
AuthBy FILE
NoEAP
Identifier CheckMacAddressBlacklist
# Calling-Station-Id attribute is the user's
MAC in this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
/AuthBy
AuthBy FILE
Identifier OuterTunnelAuth
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
/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
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
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
h...@education.ucsb.edu
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
On 4/9/2014 8:01 AM, Heikki Vatiainen wrote:
On 04/08/2014 11:36 PM, Michael Rodrigues wrote:
When untarring the patches tarball patches-4.12.1-20140407.tar.gz in the
Radiator directory and testing the build, test 1d fails to pass. Am I
applying the patches correctly? I read that there was information on the
site where the patches are downloaded, but I don't have direct access to
it as a colleague maintains the account.
Thanks for letting us know about this. The patches do not have the
recently updated test.pl. Test 1d does a Status-Server request against
Radiator and it now fails because it does not add Message-Authenticator
in the request. This requirement was just recently added in Radiator.
Status-Server requests with a correct Message-Authenticator will be
ignored from now on.
Updated test.pl was going to be in the next release, but it was
unfortunately not tagged to be in the patch set meanwhile. It will be in
the next patch set.
I'm using:
Ubuntu 12.04
Please make sure the system is updated with the latest OpenSSL patch for
the Heartbleed vulnerability.
Thanks for the heads up on this, I have since updated.
I also need to rewrite the outer identity before my AuthBy FILE sections
that check that the user is not on the blacklist. As configured, it will
check their anonymous ID against the blacklist, which does me no good.
I tried adding an AuthBy INTERNAL to the outer handler, using the perl
snippet you had suggested with RequestHook. I get a hook error whenever
it is called. I'm not a perl guru but I tried changing ${$_[1]} to
just $_[1] and got rid of the SCALAR error, but I was still getting a
Hook error with no specific information.
Code: Access-Request
Identifier: 155
Authentic: 130hZ30145187;199159164C211240sT5
Attributes:
User-Name = anonymous-username
NAS-IP-Address = 10.99.1.250
NAS-Port = 86
EAP-Message = 200131anonymous-username
Message-Authenticator =
144111395132u~@7150m155q5{221
Fri Apr 18 09:22:30 2014: DEBUG: Handling request with Handler '',
Identifier ''
Fri Apr 18 09:22:30 2014: DEBUG: Deleting session for
anonymous-username, 10.99.1.250, 86
Fri Apr 18 09:22:30 2014: DEBUG: Handling with Radius::AuthGROUP:
Fri Apr 18 09:22:30 2014: DEBUG: Handling with AuthINTERNAL:
Fri Apr 18 09:22:30 2014: ERR: Error in RequestHook(): Not a SCALAR
reference at (eval 40) line 1.
Fri Apr 18 09:22:30 2014: DEBUG: Radius::AuthGROUP: result: IGNORE,
Hook error
Fri Apr 18 09:22:30 2014: DEBUG: AuthBy GROUP result: IGNORE, Hook error
For that you might consider an AuthBy INTERNAL that is evaluated before
the blacklists. This AuthBy has RequestHook that you can use to modify
the request before it is passed to the blacklist AuthBys.
Thanks,
Heikki
Here's the updated config:
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 NTLM
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 TunnelledByTTLS=1
AuthBy NTLM
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of=AD+Domain Users
Domain AD
AutoMPPEKeys
/AuthBy
/Handler
Handler
AuthBy GROUP
AuthByPolicy ContinueWhileAccept
AuthBy INTERNAL
RequestHook sub { my $rp = ${$_[1]};
$rp-changeUserName($rp-{inner_identity}); }
DefaultResult ACCEPT
/AuthBy
# Make sure MAC address is not blacklisted..
AuthBy FILE
NoEAP
# Calling-Station-Id attribute is the user's
MAC in this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
/AuthBy
# Make sure USERNAME is not blacklisted..
AuthBy FILE
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.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
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
I tried building 4.12.1 and it builds fine without the patches.
When untarring the patches tarball patches-4.12.1-20140407.tar.gz in the
Radiator directory and testing the build, test 1d fails to pass. Am I
applying the patches correctly? I read that there was information on the
site where the patches are downloaded, but I don't have direct access to
it as a colleague maintains the account.
I'm using:
Digest::MD5 2.53
Digest::MD4 1.9
Digest::SHA 5.70
Net::SSLeay 1.42
perl 5.14.2
linux 3.5
Ubuntu 12.04
I also need to rewrite the outer identity before my AuthBy FILE sections
that check that the user is not on the blacklist. As configured, it will
check their anonymous ID against the blacklist, which does me no good.
Thanks,
Michael
On 4/7/2014 7:24 AM, Heikki Vatiainen wrote:
On 04/02/2014 09:49 PM, Heikki Vatiainen wrote:
PostAuthHook sub { my $rp = ${$_[1]};
$rp-changeUserName($rp-{inner_identity}); }
PEAP and TTLS both export the inner EAP identity (or TTLS inner username
when EAP is not used). The inner identity is exported to outer reply
message and can be retrieved as above.
Note: I noticed that if EAP, for example EAP-MSCHAP-V2, is used for
inner TTLS, the export seems not to work currently. We'll need to check why.
This is now fixed in the latest patches for 4.12.1. The EAP identity or
User-Name from TTLS tunnelled message is now available with
$rp-{inner_identity}.
Thanks,
Heikki
--
Michael Rodrigues
Technical Support Services Manager
Gevirtz Graduate School of Education
Education Building 4203
(805) 893-8031
h...@education.ucsb.edu
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
#EAPTLS_CertificateFile /etc/radiator/certs/cert-srv.pem
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
#EAPTLS_PrivateKeyPassword whatever
AutoMPPEKeys
/AuthBy
/AuthBy
PostAuthHook file:goodies/eap_acct_username.pl
/Handler
#This logs to /var/log/radius/logfile
#Not really necessary, we have SQL logs.
Log FILE
Filename logfile
/Log
On 3/26/2014 2:35 PM, Heikki Vatiainen wrote:
On 03/26/2014 07:33 PM, Michael Rodrigues wrote:
1. How do I allow only directory users to authenticate, while
preventing machine accounts from being authenticated?
Use a Handler to catch these:
Handler User-Name=/^host\//
# AuthBy INTERNAL with reject here
/Handler
should do the trick. I would also consider using a separate Handler for
inner and outer requests. See goodies/eap_peap.cfg for an example.
2. Will the eap_acct_username.pl prevent users from showing up as
'anonymous' in my accounting requests for all allowed types of auth?
(PEAP, TTLS, MSCHAP-V2)
This hook seems to return User-Name with Access-Accept to tell the NAS
to use this username for the subsequent Accounting-Requests. I'd
consider using a Hook, maybe PostAuthHook, in the inner Handler to write
the real username in the outer requests EAP context. When the final
Access-Accept is returned to the client, a PostAuthHook in the outer
Handler can set the User-Name. This could be done after the
authentication works otherwise.
3. Will disabling machine authentication have any affect on SSO so that
a user can login to a domain computer and automatically authenticate
to the wifi (assuming the proper GPOs are in place).
The recent Windows versions seem to have a number of possibilities to
choose which account, user or computer, does the wifi authentiation.
However, I have not looked more closely how these settings work with
group policies. It would be interesting to hear how it works, so please
let us know if you decide to test it.
Here's my configuration:
Remove DupInterval 0 if you have it with real RADIUS clients. It should
only be used for local loopback testing and it's not usually necessary
there either.
Thanks,
Heikki
## ##
# Radiator Configuration #
# ##
## Updated 03/26/14 mbr
## 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
#AuthBy SQL
#DBSourcedbi:mysql:radius:127.0.0.1:3306
#DBUsername radius
#DBAuth xxx
#HandleAcctStatusTypes Start,Stop
# This statement inserts the accounting information into the SQL databasee.
#AcctSQLStatement insert into ggse_public
values('%{Acct-Session-Id}','%{Framed-IP-Address}','%{User-Name}','%{Acct-Status-Type}','%{Extreme-SSID}','%{Connect-Info}','%{Acct-Delay-Time}','%{Timestamp}','%{Calling-Station-Id}',NULL);
# This will log messages from within the SQL insert statement
#Log FILE
#Filename debug.config
#/Log
#/AuthBy
#/Handler
#below was added on 2/4/13 to catch ALL iterations of logins that are
BlackListed.
RewriteUsername tr/A-Z/a-z/
#These are the IPs from which calls to the RADIUS server are allowed.
Client 10.99.1.250
Secret testing123
DupInterval 0
/Client
Handler
#This is only tentative and hasn't been tested. This keeps people from
circumventing the logs by making their outer identity anonymous. This
script copies the inner identity to the outer identity; you can't
authenticate without the correct inner identity.
PostProcessingHook file:/etc/radiator/eap_acct_username.pl
AuthBy GROUP
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
AuthBy FILE
NoEAP
# Calling-Station-Id attribute is the user's MAC in this
case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
/AuthBy
# Make sure USERNAME is not blacklisted..
AuthBy FILE
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
/AuthBy
AuthBy NTLM
Domain AD
EAPTypePEAP, TTLS, MSCHAP-V2
EAPTLS_CAFile /etc
[RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
Hi all,
I've been using RADIATOR for 4 or 5 years using EAP-TTLS PAP against an
LDAP database. We now have an Active Directory that is synced with LDAP,
so all users and their passwords are now in AD. With the LDAP database,
we had to configure every client manually (these are student computers
we don't own) for wireless to work. This could sometimes take 20-30
minutes with Apple clients and involved installing SecureW2 on Windows.
My goal now is to transition to using AuthBy NTLM with PEAP, TTLS, and
MSCHAP-V2 in place of AuthBy LDAP2 so users can just type their
username and password when prompted, while maintaining backwards
compatibility with the EAP-TTLS PAP machines that were already
configured. The config I have does do this, but it also allows domain
computers to authenticate as computers; I don't want this. So it comes
down to a few questions:
1. How do I allow only directory users to authenticate, while
preventing machine accounts from being authenticated?
2. Will the eap_acct_username.pl prevent users from showing up as
'anonymous' in my accounting requests for all allowed types of auth?
(PEAP, TTLS, MSCHAP-V2)
3. Will disabling machine authentication have any affect on SSO so that
a user can login to a domain computer and automatically authenticate
to the wifi (assuming the proper GPOs are in place).
Here's my configuration:
## ##
# Radiator Configuration #
# ##
## Updated 03/26/14 mbr
## 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
#AuthBy SQL
#DBSourcedbi:mysql:radius:127.0.0.1:3306
#DBUsername radius
#DBAuth xxx
#HandleAcctStatusTypes Start,Stop
# This statement inserts the accounting information into the SQL databasee.
#AcctSQLStatement insert into ggse_public
values('%{Acct-Session-Id}','%{Framed-IP-Address}','%{User-Name}','%{Acct-Status-Type}','%{Extreme-SSID}','%{Connect-Info}','%{Acct-Delay-Time}','%{Timestamp}','%{Calling-Station-Id}',NULL);
# This will log messages from within the SQL insert statement
#Log FILE
#Filename debug.config
#/Log
#/AuthBy
#/Handler
#below was added on 2/4/13 to catch ALL iterations of logins that are
BlackListed.
RewriteUsername tr/A-Z/a-z/
#These are the IPs from which calls to the RADIUS server are allowed.
Client 10.99.1.250
Secret testing123
DupInterval 0
/Client
Handler
#This is only tentative and hasn't been tested. This keeps people from
circumventing the logs by making their outer identity anonymous. This
script copies the inner identity to the outer identity; you can't
authenticate without the correct inner identity.
PostProcessingHook file:/etc/radiator/eap_acct_username.pl
AuthBy GROUP
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
AuthBy FILE
NoEAP
# Calling-Station-Id attribute is the user's MAC in
this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
/AuthBy
# Make sure USERNAME is not blacklisted..
AuthBy FILE
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
/AuthBy
AuthBy NTLM
Domain AD
EAPTypePEAP, TTLS, MSCHAP-V2
EAPTLS_CAFile /etc/radiator/certs/demoCA/cacert.pem
EAPTLS_CertificateFile /etc/radiator/certs/cert-srv.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/cert-srv.pem
EAPTLS_PrivateKeyPassword whatever
AutoMPPEKeys
/AuthBy
/AuthBy
/Handler
#PostProcessingHook file:/etc/radiator/eap_acct_username.pl
#This logs to /var/log/radius/logfile
#Not really necessary, we have SQL logs.
Log FILE
Filename logfile
/Log
Thanks,
Michael
--
Michael Rodrigues
Technical Support Services Manager
Gevirtz Graduate School of Education
Education Building 4203
(805) 893-8031
h...@education.ucsb.edu
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
