forked from privacyidea/privacyidea-ldap-proxy
-
Notifications
You must be signed in to change notification settings - Fork 0
/
example-proxy.ini
130 lines (123 loc) · 7.25 KB
/
example-proxy.ini
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
[privacyidea]
# URL of your privacyIDEA installation
instance = http://192.0.2.2
# In case you use HTTPS:
# You can disable hostname validation completely, which is not recommended.
#verify = False
# By default, verify is set to True.
# If verify=True, you can manually pass a HTTPS server certificate (PEM format).
#certificate = /etc/privacyidea/server.pem
# If verify=True but you do not explicitly pass a certficate,
# the server certificate is validated against the OS certificate store.
[ldap-backend]
# Location of the LDAP backend server, specified using the Twisted endpoint string syntax for clients:
# https://twistedmatrix.com/documents/16.4.1/core/howto/endpoints.html#clients
# You can also specify a timeout for connection establishment here (by providing timeout=X)
# CAUTION: STARTTLS is currently unsupported!
# LDAPS can be configured using the Twisted endpoint syntax. Be sure to install the service_identity
# module to enable proper certificate validation. The `trustRoots` option can be used to
# point to a directory containing trusted roots (only .pem files are considered!)
#endpoint = tls:host=foo:port=636:trustRoots=/path/to/pems
endpoint = tcp:host=192.0.2.1:port=389
# If enabled, the LDAP proxy will perform an anonymous bind against the LDAP backend at startup
# to ensure that the connection works and write a message to the log. (default is true)
test-connection = true
[service-account]
# DN and password of the service account for the LDAP backend which is used to forward, e.g., search requests
# or to lookup the User DN in case the "lookup" user mapping strategy is used.
# If the service account is not used in your particular setup, you may leave it blank.
# Be sure to quote the DN.
dn = "cn=service,cn=users,dc=test,dc=local"
password = test
[ldap-proxy]
# Host and port to bind the LDAP proxy to, specified using the Twisted endpoint string syntax for servers
# https://twistedmatrix.com/documents/16.4.1/core/howto/endpoints.html#servers
# CAUTION: STARTTLS is currently unsupported!
# LDAPS can be configured using the Twisted endpoint syntax, most importantly the `privateKey` option.
# See https://twistedmatrix.com/documents/current/core/howto/endpoints.html#servers for more information.
#endpoint = ssl:port=1636:privateKey=/path/to/cert.pem
endpoint = tcp:port=1389
# List of DNs for which Bind Requests should simply be forwarded to the LDAP backend.
# Individual DNs must be quoted and separated by a comma.
passthrough-binds = "cn=service2,cn=users,dc=test,dc=local","cn=admin,cn=users,dc=test,dc=local"
# If this is set to `true`, the LDAP proxy will send a bind request using the credentials of the service
# account (see above) to the LDAP backend once an incoming LDAP user bind has been successfully authenticated
# by privacyIDEA. As a result, subsequent LDAP operations forwarded to the LDAP backend are processed
# in the context of the service account.
bind-service-account = false
# If this is set to `true`, the LDAP proxy will forward search requests to the LDAP backend.
# Mostly useful in conjunction with `bind-service-account`: If both are set to `true`, applications
# may issue search operations after a successful user authentiation.
# If `bind-service-account` is set to false, but `allow-search` is set to true, only the DNs
# in `passthrough-binds` will be able to issue search requests.
allow-search = false
# By default, the LDAP proxy only allows one bind request per connection. For some apps, this may
# be sufficient. However, other apps may reuse a LDAP connection and thus require setting this
# configuration option.
allow-connection-reuse = false
# Currently, ldaptor does not support SEARCH result references which will break
# some apps in combination with AD. This option provides a workaround:
# If it is set to `true`, the LDAP proxy ignores all LDAP SEARCH result references.
# The LDAP Proxy does not send any LDAP SEARCH result references to the application.
ignore-search-result-references = false
# By default, the LDAP Proxy rejects anonymous binds. With the following option, it can be configured
# to forward anonymous binds to the LDAP backend.
forward-anonymous-binds = false
[user-mapping]
# This setting determines the strategy the LDAP proxy uses to determine the username that is sent to privacyIDEA
# from an incoming bind request's DN. There are currently two strategies:
# (1) "lookup": Processing an incoming user bind request, the LDAP proxy connects to the LDAP backend
# using the service account credentials (see above), looks up the user entry using the given DN and retrieves
# the value of a specific attribute (given in the "attribute" setting), which is subsequently used to authenticate
# the user against privacyIDEA
strategy = lookup
attribute = sAMAccountName
# (2) "match": Processing an incoming user bind request, the LDAP proxy extracts the username directly from the
# user DN. For that, it expects a setting "pattern", a regular expression pattern containing one group, the username.
#strategy = match
#pattern = "cn=([^,]+),cn=users,dc=test,dc=local"
[realm-mapping]
# The following configures how the privacyIDEA realm of incoming authentication requests
# is determined.
# The `static` strategy assigns one realm to all authentication requests.
strategy = static
# Realm to use for authentication (may also be left blank to make privacyIDEA use its default realm)
realm =
# The `app-cache` strategy is more sophisticated: Once a bind request is received, it checks
# whether the app cache contains a corresponding app marker (so be sure to enable the bind cache)
# If yes, this app marker is mapped to a privacyIDEA realm according to the mapping defined below.
# If the app cache contains no app marker or the app marker is not mapped to a realm,
# the authentication request fails.
# strategy = app-cache
# [[mappings]]
# This maps the app marker "someApp" to the privacyIDEA realm "somerealm".
# someApp = somerealm
[bind-cache]
# If this setting is enabled, successful user bind requests are added to a so-called "bind cache" in which
# they are kept for a specified time. During that time, incoming bind requests using the same credentials
# are internally replaced with bind requests using the service account credentials.
# The timeout is specified in seconds.
# This feature is EXPERIMENTAL.
enabled = false
timeout = 3
[app-cache]
# If this setting is enabled, the LDAP proxy maintains a so-called "app cache".
# On user login, apps typically perform a LDAP search to locate the user. When
# they have resolved the DN, they perform the actual bind.
# We use the LDAP search to identify the app: For that, we add an expression like
# `objectclass=App-someApp` to the LDAP filter (without changing the filter semantics).
# We call `someApp` an "app marker". If the LDAP proxy witnesses a search request
# whose filter contains an app marker and whose result has exactly one entry,
# the DN of the entry (the user) as well as the app marker are stored in the app cache
# for a specific timeframe. This information may be used by the `app-cache` realm mapping
# strategy (see below).
enabled = false
#timeout = 5
# Attribute containing the app marker
#attribute = objectclass
# Prefix of the app marker
#value-prefix = App-
#
# By default the app cache stores the DN case-sensitive. If you want to
# store the DN case-insensitive set this to true
# case-insensitive = false