+=head1 CONFIGURATION
+
+Once a user has been accepted by the LDAP server, there are several possibilities for how Koha will behave, depending on
+your configuration and the presence of a matching Koha user in your local DB:
+
+ LOCAL_USER
+ OPTION UPDATE REPLICATE EXISTS? RESULT
+ A1 1 1 1 OK : We're updating them anyway.
+ A2 1 1 0 OK : We're adding them anyway.
+ B1 1 0 1 OK : We update them.
+ B2 1 0 0 FAIL: We cannot add new user.
+ C1 0 1 1 OK : We do nothing. (maybe should update password?)
+ C2 0 1 0 OK : We add the new user.
+ D1 0 0 1 OK : We do nothing. (maybe should update password?)
+ D2 0 0 0 FAIL: We cannot add new user.
+
+Note: failure here just means that Koha will fallback to checking the local DB. That is, a given user could login with
+their LDAP password OR their local one. If this is a problem, then you should enable update and supply a mapping for
+password. Then the local value will be updated at successful LDAP login and the passwords will be synced.
+
+If you choose NOT to update local users, the borrowers table will not be affected at all.
+Note that this means that patron passwords may appear to change if LDAP is ever disabled, because
+the local table never contained the LDAP values.
+
+=head2 auth_by_bind
+
+Binds as the user instead of retrieving their record. Recommended if update disabled.
+
+=head2 principal_name
+
+Provides an optional sprintf-style format for manipulating the userid before the bind.
+Even though the userPrincipalName is one intended target, any uniquely identifying
+attribute that the server allows to be used for binding could be used.
+
+Currently, principal_name only operates when auth_by_bind is enabled.
+
+=head2 Active Directory
+
+The auth_by_bind and principal_name settings are recommended for Active Directory.
+
+Under default Active Directory rules, we cannot determine the distinguishedName attribute from the Koha userid as reliably as
+we would typically under openldap. Instead of:
+
+ distinguishedName: CN=barnes.7,DC=my_company,DC=com
+
+We might get:
+
+ distinguishedName: CN=Barnes\, Jim,OU=Test Accounts,OU=User Accounts,DC=my_company,DC=com
+
+Matching that would require us to know more info about the account (firstname, surname) and to include punctuation and whitespace
+in Koha userids. But the userPrincipalName should be consistent, something like:
+
+ userPrincipalName: barnes.7@my_company.com
+
+Therefore it is often easier to bind to Active Directory with userPrincipalName, effectively the
+canonical email address for that user, or what it would be if email were enabled for them. If Koha userid values
+will match the username portion of the userPrincipalName, and the domain suffix is the same for all users, then use principal_name
+like this:
+ <principal_name>%s@core.my_company.com</principal_name>
+
+The user of the previous example, barnes.7, would then attempt to bind as:
+ barnes.7@core.my_company.com
+
+=head1 SEE ALSO
+
+CGI(3)
+
+Net::LDAP()
+
+XML::Simple()
+
+Digest::MD5(3)
+
+sprintf()
+