Hello Daniel -
Probably the simplest way to do this is with a PostSearchHook.
See the following section in the Radiator 4.16 reference manual (“doc/ref.pdf”).
• 5.38.23 PostSearchHook
regards
Hugh
> On 1 Mar 2017, at 00:20, daniel.herrm...@zv.fraunhofer.de wrote:
>
> Hi,
>
> I want to achieve the following using Radiator:
>
> Users connect via VPN to our Cisco ASA using AnyConnect, which authenticates
> the users via RADIUS. The Handler on Radiator is as follows. Basically, users
> belong to a group in our AD, let’s say vpn-inband. The client statement of
> the firewall includes the respective client-identifier to map the request to
> the handler.
>
> --- schnip ---
> ##############################################
> ############# Authenticate VPN ##############
> ############## Cisco ASA VPN #################
> ##############################################
>
> # InBand VPN
> <Handler Client-Identifier=network-security-ib>
> # Require vpn-inband Group
> AddToRequest ADGroup="CN=vpn-inband,CN=xxx"
>
> # Continue Auth until acceptable permission set is found
> AuthByPolicy ContinueUntilAccept
>
> # Try emergency-user before asking AD
> AuthBy AuthByFile
>
> # Try to authenticate against AD
> AuthBy AuthByAD
> </Handler>
> --- schnapp ---
>
> AuthBy AD actually just authenticates against AD:
>
> --- schnip ---
> <AuthBy LDAP2>
> # Define DC to connect to
> Host oob-ldap-proxy
>
> # Identifier to use this AuthBy Clause later
> Identifier AuthByAD
>
> # Administrative user used to perform LDAP queries
> AuthDN xxxxx
> AuthPassword xxxx
>
> # Where to search for users
> BaseDN OU=xxx-User,DC=xxx
> ServerChecksPassword
>
> # Add Check for group membership
> AuthAttrDef memberOf, ADGroup, check
>
> # Reply should include the group names for further processing
> AuthAttrDef memberOf, ADGroups, reply
>
> # There will be no default User
> NoDefault
>
> # LDAP attribute to check the UserName on
> UsernameAttr sAMAccountName
> AuthAttrDef logonHours,MS-Login-Hours,check
> </AuthBy>
> --- schnap ---
>
> So far, this is already working. Let’s now say, some of the users have an
> additional group in AD, say “CN=student,CN=xxx”. In this case, I want to
> restrict the source-IP they may use to connect to the VPN. The Appliance
> itself cannot handle this, but the RADIUS request includes the source IP.
>
> --- snip ---
> Attributes:
> User-Name = "daniel.herrmann"
> Calling-Station-Id = "10.1.0.10"
> --- snap ---
>
> I want to create this logic:
>
> If user has both the inband and student group, he may only connect if the
> Calling-Station-Id is within a specific range, say 10.10.10/24. If the user
> is only in the inband group and not within the student group, he may connect
> from everywhere.
>
> What would be the easiest way to build this in Radiator?
>
> Thanks and best regards
> Daniel
>
>
> --
> Daniel Herrmann
> Network Architect – Fraunhofer Private Cloud
> CCIE #55056 (Routing and Switching)
> Cisco CCDP, CCIP; Fluke CCTT
>
> Fraunhoferstraße 5, 64283 Darmstadt
> Mail: daniel.herrm...@zv.fraunhofer.de
>
> _______________________________________________
> radiator mailing list
> radiator@lists.open.com.au
> http://lists.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc.
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
