diff options
Diffstat (limited to '')
| -rw-r--r-- | raddb/sites-available/google-ldap-auth | 225 |
1 files changed, 225 insertions, 0 deletions
diff --git a/raddb/sites-available/google-ldap-auth b/raddb/sites-available/google-ldap-auth new file mode 100644 index 0000000..3be530f --- /dev/null +++ b/raddb/sites-available/google-ldap-auth @@ -0,0 +1,225 @@ +# -*- text -*- +######################################################################### +# +# The file contains a sample virtual server which uses Google +# Secure LDAP for authentication +# +# This file is designed to be used as an inner tunnel virtual +# server for EAP-TTLS-PAP authentication. +# +# Use this virtual server in conjunction with the sample Google +# Secure LDAP module configuration, which is in +# mods-available/ldap_google. +# +# Due to the poor performance of Google Secure LDAP, this +# configuration also caches information around accepts, rejects, +# and LDAP qeuries. See mods-available/cache_auth for the +# configuration of the various "cache" modules used here. +# +# The TTL on these caches should be tuned to match site policies +# - e.g. how long should a user be re-authenticated from a cache +# without performing an LDAP bind. +# +# Typically the caches are beneficial when performing +# authentication for 802.1x wifi where repeated authentications +# occur as users roam. We also recommend enabling the "cache" +# subsection of mods-available/eap. Both kinds of caching can +# be done at the same time, and both kinds of caching will help +# improve system performance and stability. +# +# $Id$ +# +######################################################################### + +server google-ldap { + +# +# This is only for testing, and not needed in general operation. +# +listen { + ipaddr = 127.0.0.1 + port = 18123 + type = auth +} + +authorize { + # + # Perform sanity checks on the supplied user name + # + filter_username + + # + # Perform sanity checks comparing inner and outer user name + # + filter_inner_identity + + # + # Split up user names in the form user@domain + # + split_username_nai + + # + # Check the authentication cache to see if this user + # recently sucessfully authenticated + # + update control { + &Cache-Status-Only := 'yes' + } + cache_auth_accept + + # + # If there's a cached User-Name / User-Password which matches + # what the user sent here, then the user has been + # authenticated. We can then avoid interacting with Google's + # LDAP server, which significantly improves the performance + # of user authentication. + # + if (ok) { + update { + &control:Auth-Type := Accept + } + return + } + + # + # Check the reject cache to see if this user was + # recently rejected + # + update control { + &Cache-Status-Only := 'yes' + } + cache_auth_reject + + # + # If there's a cached User-Name / User-Password which matches + # what the user sent here, then the user has been rejected. + # As with authentication above, we don't need to check + # Google's LDAP server, and can improve performance. + # + # Note that in may cases rejected users will try over and + # over again. This increased load can significantly affect + # performance, and can even prevent other users from + # authenticating! The solution is to just tell the bad users + # to "go away" as quickly as possible, while using minimal + # resources. + # + if (ok) { + update { + &Module-Failure-Message := "Rejected by cache entry" + } + reject + } + + # + # If group membership checks are required, then ensure that + # the relevant "cacheable_" option is set against the ldap + # instance, and call the ldap module here. + # + # If group membership is irrelevant, do not call ldap here + # to improve performance + # + # ldap_google + + # + # As Google LDAP does not return user passwords, + # authentication is only possible by LDAP "bind as user". So + # only PAP and TTLS+PAP will work. + # + # If the request contains a password, then force LDAP "bind + # as user". + # + if (&User-Password && !control:Auth-Type) { + update { + &control:Auth-Type := ldap + } + + # + # Look up a user's DN in the cache. + # + # The standard ldap auth mechanism is 3 steps + # - bind as admin user + # - lookup the user's DN + # - bind as the user + # + # Caching the DN removes the first two steps + # during the lifetime of the cache entry. + # + # If the ldap module is called above, then this cache + # call can be commented out; the DN will have been + # retrieved above by the "ldap_google" module. + # + update control { + &Cache-Read-Only := "yes" + } + cache_ldap_user_dn + + } +} + +authenticate { + # + # Use an LDAP "bind as user" to authenticate. Google will + # check the users' password, and will return success / fail. + # + Auth-Type LDAP { + ldap_google + } + +} + +# +# Google LDAP has no specific session section configuration +# +session { + +} + +# +# In post-auth the various caches get updated. +# +# Add in any additional policy required to set reply attributes +# +post-auth { + # + # Cache the user's DN. See the authorize section for + # how and why this would be used + # + cache_ldap_user_dn + + # + # If a user was authenticated by ldap, add the users name / + # password to the cache of successful authentications. + # + # Otherwise the user was authenticated via the + # cache_auth_accept call above, in the "authorize" section. + # + if (&control:Auth-Type == ldap) { + cache_auth_accept + } + + Post-Auth-Type REJECT { + attr_filter.access_reject + + # + # Record rejects in a cache, as a protection against + # repeated attempts from mis-configured clients. + # + if (&control:Auth-Type == ldap) { + cache_auth_reject + } + + # + # Clear the DN cache entry if it exists. + # If the DN cache is in use, retaining an incorrect + # DN entry could cause issues if the user's DN + # has changed. + # + update control { + &Cache-TTL := 0 + } + cache_ldap_user_dn + + } +} + +} |