summaryrefslogtreecommitdiffstats
path: root/raddb/sites-available/google-ldap-auth
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--raddb/sites-available/google-ldap-auth225
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
+
+ }
+}
+
+}