Table of Contents Table of contents: Radiator® AAA Server <AuthBy IMAP> 3.59 - <AuthBy IMAP> <AuthBy SOAP> 3.61 - <AuthBy SOAP>

3.60. <AuthBy LSA>

This module provides authentication against user passwords on a stand alone server, Windows Active Directory or Domain Controller, by using the Windows LSA (Local Security Authority). Since it accesses LSA directly, it can authenticate passwords with PAP, CHAP, MSCHAP, MSCHAPV2, LEAP, EAP-MSCHAP-V2, EAP-TTLS and PEAP.
<AuthBy LSA> is only available on Windows 7/8/8.1/10 and Server 2008/2012/2016/2019, home editions are not supported. It requires the Win32::Lsa Perl module from Radiator Software.
Radiator Windows MSI package comes with Win32::LSA pre-installed. If you are not using Radiator MSI package, install the Win32::Lsa Perl module for Strawberry Perl from the Radiator distribution's ppm\strawberryperl\ directory:
ppm install Win32-Lsa.ppd
To use <AuthBy LSA>, Radiator must be run on Windows as a user that has the ‘Act as part of the operating system's security policy (SE_TCB_PRIVILEGE) enabled. 'Local System' account that Windows services use by default has this privilege enabled.
Tip
Users can only be authenticated with <AuthBy LSA> if they have the ’Access this computer from the network’ security policy enabled (this is the normal configuration for Windows Domains). <AuthBy LSA> honours the Logon Hours, Workstation Restrictions and ‘Account is Disabled’ flags in user accounts.
Tip
CHAP passwords can only be authenticated if the user has the ‘Store password using reversible encryption’ option enabled in their Windows Account. CHAP challenge must also be 16 octets long. This is the default for the most CHAP implementations.
Tip
See goodies/lsa.cfg and goodies/lsa_eap_peap.cfg for examples on how to configure Radiator to authenticate PAP, CHAP, MSCHAP, MSCHAPV2, LEAP, EAP-MSCHAP-V2, EAP-TTLS and PEAP against Windows user passwords.
Tip
If you are running Radiator on Unix or Linux, and wish to authenticate to Windows Active Directory or to a Windows Domain Controller. For more information, see Section 3.74. <AuthBy NTLM>.

3.60.1. Domain

This optional parameter specifies which Windows domain will be used to authenticate passwords, regardless of whether the user supplies a domain when they log in. It can be the name of any valid domain in your network. The default is to authenticate against local accounts on the machine that Radiator is running on. Special characters are permitted.
Domain OPEN

3.60.2. DefaultDomain

This optional parameter specifies the Windows Domain to use if the user does not specify a domain in their username. Special characters are supported. Can be an Active directory domain or a Windows NT domain controller domain name. Empty string (the default) means the local machine.
DefaultDomain OPEN

3.60.3. Workstation

This optional parameter specifies a workstation name that will be used to check against workstation logon restrictions in the users account. If the user has any workstation restrictions specified in their account, this is the workstation name that will be used to check the restriction. Defaults to an empty string, which means that LSA will not check any workstation logon restrictions.
Workstation WLAN

3.60.4. ProcessName

This optional parameter specifies a process name for LSA internal logging. Defaults to ‘Radiator’.

3.60.5. Origin

This optional parameter specifies a request origin name for LSA internal logging. Defaults to ‘Radiator’.

3.60.6. Source

This optional parameter specifies a source name for LSA internal logging. Defaults to ‘Radiator’.

3.60.7. LSARewriteHook

This optional parameter allows you to define a Perl function to rewrite the username that is passed to LSA. Username passed to LSA API is changed to whatever is returned by this function. The username in request is not changed. This may be needed, for example, with Wi-Fi roaming where roaming username can not be directly used with Windows authentication because of local naming conflicts with roaming requirements.
The following parameters are passed to LSARewriteHook:
  • $_[0]: $p, the current Radius::Radius request object
  • $_[1]: $user, the current username to pass to LSA
Here are some examples:
# We use file instead of inline code
LSARewriteHook file:"%D/lsa-rewrite-hook.pl"
# Use inline code to change our global roaming realm to windows domain
LSARewriteHook sub { my ($user) = $_[1]; \
    $user =~ s/example\.com\z/org.local/; \
    return $user; }

3.60.8. Group

This optional parameter allows you to specify that each user must be the member of at least one of the named Windows Global or Local groups. More than one required group can be specified, one per Group line. Requires Win32::NetAdmin (which may require separate installation with Strawberry Perl). If no Group parameters are specified, then Group checks will not be performed.
# Each user must be in Administrators and/or Domain Users
Group Administrators
Group Domain Users

3.60.9. DomainController

This optional parameter is used only if one or more Group check parameters are set. It specifies the name of the Windows Domain Controller that will be used to check each users Group membership. If no Group parameters are specified, DomainController will not be used. Defaults to empty string, meaning the default controller of the host where this instance of Radiator is running.
Table of Contents Table of contents: Radiator® AAA Server <AuthBy IMAP> 3.59 - <AuthBy IMAP> <AuthBy SOAP> 3.61 - <AuthBy SOAP>