1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
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
}
}
}
|
