What does it do? 

This extension enables import/update/deletion of users and groups (frontend, backend or both) from a LDAP-directory and provides Single Sign-On (SSO) for frontend users. These features make it the perfect choice when deploying TYPO3 as an intranet CMS.

In case the network topology makes it useful, this extension is able to work with multiple LDAP server configurations, with a priority order based on the manual sorting of configuration records.

This extension is known to work with OpenLDAP and Active Directory (various versions).

Please consult the Frequently Asked Questions for additional information.

Screenshots 

Sponsorship 

Causal Sàrl, a Swiss company actively contributing to TYPO3, has taken over this extension which has been initially developed by Infoglobe, a former Canadian company specialized in open-source software.

Causal Sàrl is regularly working on compatibility updates for new TYPO3 releases.

We would like to thank:

• Support for TYPO3 12 LTS would not have been possible without the support of many members of the TYPO3 community. We would like to thank all of them and their companies for their support.
• Migration wizard from the import scheduler task to the new Symfony command has been sponsored by the GYB (Gymnase intercantonal de la Broye) and hemmer.ch SA.
• Support for TYPO3 11 LTS has been sponsored by TEC Competence UG, Germany.
• All the various developers reportings bugs and providing patches in the bug tracker.

alt Causal Sàrl width 200px Causal Sàrl https://www.causal.ch

alt TEC Competence UG width 200px TEC Competence UG (halftungsbeschränkt) & Co. KG https://www.tec-competence.com

Support 

In case you need help to configure this extension, please ask for free support in TYPO3 Slack or contact the maintainer for paid support.

Web Server 

Everything in this documentation is assuming that I am using Apache as web server. Does Kerberos authentication works with Nginx as well?

We do not have tested this configuration ourselves but you can read an article explaining how to set up Kerberos on Nginx for various versions of Linux at: `https://docs.nginx.com/nginx/admin-guide/dynamic-modules/spnego/`__. Another source (albeit possibly outdated) is available at: `https://medium.com/@meeramarygeorge/setup-kerberos-on-nginx-in-ubuntu-16-04-408a5b95cdee`__.

Users 

Is it possible to have both users manually defined (thus authenticated with a TYPO3 password) and users authenticated with LDAP?

Yes. Both for frontend and backend authentication it is possible to manually define users unrelated to your LDAP server(s). When a user is manually defined, the record's column tx_igldapssoauth_dn is empty and thus, since the LDAP authentication will fail, it will automatically fall back to the standard TYPO3 authentication service. This behaviour may be enabled/disabled globally for backend and/or frontend within Extension Manager.

I have a local user with the same username as a LDAP user but which has been manually created in TYPO3. Which password will be taken into account?

When you manually create a user in TYPO3, it is not related to LDAP. This local user may authenticate with the password you set. However is the user matches a LDAP user and the password provided results into a successful LDAP authentication, the manually created user will be automatically linked to the LDAP user. Afterwards, only the LDAP password will be valid.

I would like to silently and automatically authenticate my users in frontend (Single Sign On / SSO). Since Apache is configured to restrict access using Kerberos, no login form should be needed in my website. Is this possible with this extension?

Yes. You have to activate this option in Extension Manager and ensure you have properly configured mod_ntlm or Kerberos with Apache (or any other supported web server). This extension will look for a username in $_SERVER['REMOTE_USER'] (without any domain part) to silently create the session in TYPO3.

I would like to do SSO in backend just like I do in frontend. Is this possible with this extension?

Yes. This is possible since version 3.2.0. Please keep in mind though that enabling SSO for the backend means it is then impossible for a user to log out. And TYPO3 may behave differently if you show the frontend while having a backend session active (e.g., frontend editing).

How can I find the Bind DN of a given Active Directory account?

It is not always obvious when opening the properties of a given user in Active Directory to figure out the DN to be used. The trick is to open a command prompt and use ``dsquery``. E.g. when looking for the DN of the "administrator" account:

> dsquery user -name administrator
CN=Administrator,OU=Users,DC=example,DC=com

Groups 

Can I import user groups automatically?

Yes you can.

May I manually tweak the name or configuration of imported user groups?

Yes. To do so, you should enable the global option in Extension Manager preventing the automatic synchronization of groups (may be configured separately for backend and frontend). In order to import new groups manually, use the LDAP / SSO backend module. Once imported, you may change their name to fit your needs and conventions.

My server is providing a hierarchy of groups. Is it possible to automatically mirror this structure in TYPO3?

Yes. You should provide a be_groups and/or fe_groups mapping instruction for the LDAP attribute holding the reference to the parent group. E.g.,:

parentGroup = <memberof>

Which servers support the "memberOf" / "groupMembership" attribute?

Windows 2000 and above Active Directory definitely supports this attribute.

My infrastructure provides 2 LDAP servers, one containing group records, the second containing only users but with "memberOf" attributes corresponding to groups found on the other server. Is it possible to map those groups to the users?

Yes. In order to do that, you will need to manually import the LDAP user groups into your TYPO3 website and then configure the global option in Extension Manager that disables the synchronization of user groups. This way, only the configured baseDN for groups will be compared with the groups assigned as "memberOf" attributes, without actively retrieving corresponding group records from the LDAP server.

Security 

Is the effective user's password ever stored in TYPO3?

No. The password provided in the login form is sent directly to the LDAP server and never stored in TYPO3. However, since TYPO3 requires a password to be set for frontend and backend user records, this extension generates and saves a random 20 byte password for the sole purpose of making TYPO3 happy.

Can I encrypt my connection to the LDAP server?

Yes. This extension is supporting SSL-encrypted connection to the LDAP server as well as TLS-based connection.

Which port number is my LDAP server listening on?

It is not possible to answer without knowing your infrastructure but it is worth to mention that

• 389 is the industry standard port for LDAP connections over TCP/IP, and
• 636 is the industry standard port for LDAP connections over SSL.

Server 

Choose your LDAP type (OpenLDAP or Active Directory). This is used internally to follow (or not) referrals returned by the LDAP server and to help you with suggested mapping configuration.

Character set 

Character set of your LDAP connection. Usually utf-8.

Host 

Host of your LDAP. You may use either a host name / IP address or prefix it with a protocol such as ldap://<hostname> or ldaps://<hostname> (latter in case you want to connect with SSL).

Port 

Port your LDAP uses. Default LDAP ports are 389 (ldap://) and 636 (ldaps://).

TLS 

Whether you want to use TLS, that is typically start with an connection on default port 389 and then set up an encrypted connection.

SSL 

Whether you want to use SSL, that is start with an encrypted connection on default port 636.

// Always trust the LDAP server certificate
putenv('LDAPTLS_REQCERT=never');

Bind DN 

DN of the LDAP user you will use to connect to the LDAP server. The DN is composed of a series of RDN's which are the unique (or unique'ish) attributes at each level in the DIT. The following diagram illustrates building up the DN from the RDN's.

Example:

cn=Robert Smith,ou=people,dc=example,dc=com

dsquery user -name <known username>

"CN=John.Smith,CN=Users,DC=MyDomain,DC=com"

dsquery group -name <known group name>

Password 

This password is the same password used in association with the Bind DN user account to connect to the LDAP server.

Base DN 

Full DN path of the directory containing all the users that you want to use with your TYPO3 authentification.

Example:

ou=people,dc=example,dc=com

Filter 

Filter is used to precise which LDAP attribute contains the username of your users and which filter to apply when selecting users to import, either from the backend module or from the Scheduler task.

Example: (uid={USERNAME}) uid is the most common attribute used to keep the username in LDAP but if you are in Active Directory, the field where the username is stored is usually sAMAccountName instead.

You will also be able to add restrictions that allow you to exclude user from specific properties. The syntax used in this field is the standard LDAP search syntax.

Example:

(&(uid={USERNAME})(objectClass=posixAccount))

Mapping 

The mapping is used to fetch other attributes from the LDAP server that we would like users to have. It is quite simple, each line is a new command. Each command has two parts separated by a = (equal sign). the first part is the field from the TYPO3 user that we want to fill and the second part is the value that the field will have.

There are three possible value types you may use:

• a string;
• a LDAP attribute value;
• a custom marker;

In addition, every field supports stdWrap properties. Multi-valued LDAP attributes are available using field where values have been joined together using a line-feed character (\n).

email = user@domain.com

email = <mail>

name = <sn>, <givenname>

tstamp = {DATE}
email = <mail>
realName = <cn>
lang = fr

pid = 45
tstamp = {DATE}
email = <mail>
name = <cn>
first_name = <givenname>
last_name = <sn>
title = <title>
address = <street>
zip = <postalcode>
city = <l>
telephone = <telephonenumber>

name = <cn>
name.wrap = |-LDAP

telephone {
    field = telephonenumber
    split {
        token.char = 10
        cObjNum = 1
        1.current = 1
        1.noTrimWrap = ||, |
    }
    substring = 0,-2
}

email {
    field = mail
    listNum = 3
    listNum {
        splitChar = 10
    }
}

Base DN 

Full DN path of the directory containing all the groups that are related to your LDAP users and you want to use in your TYPO3 website.

Example:

ou=groups,dc=example,dc=com

ou=groups, dc=example, dc=com

Filter 

Filter to be used to add restrictions that allow you to exclude objects from specific properties. The syntax used in this field is the standard LDAP search syntax.

This field should not be left empty although it is not marked as required. Be sure to always double-check your configuration using the wizard in the backend module.

Example:

(objectClass=posixGroup)

(&(memberUid={USERUID})(objectClass=posixGroup))

usergroup = <memberOf>

Mapping 

Mapping to be used to fetch other attributes form the LDAP server that we would like groups to have. Please see syntax and examples in the description of mapping for users.

LDAP 

BE_USERS 

email = <mail>
realName = <cn>
tstamp = {DATE}
disable = 0
admin = 1

BE_GROUPS 

title = <cn>
tstamp = {DATE}

FE_USERS 

pid = *id of your storage folder*
tstamp = {DATE}
email = <mail>
name = <cn>
last_name = <sn>

# <cn> is of the form "Albert Einstein"
# Extract first name as what comes
# before last "word"/blank space
first_name = <cn>
first_name.replacement.10 {
    search = /^(.*) ([^ ]+)$/
    replace = $1
    useRegExp = 1
}

Test Users and Groups 

As of April 2015, four groups and a few users are available:

• Mathematicians

  • euclid (Euclid)
  • euler (Leonhard Euler)
  • gauss (Carl Friedrich Gauss)
  • riemann (Bernhard Riemann)

• Scientists

  • einstein (Albert Einstein)
  • galieleo (Galileo Galilei)
  • newton (Issac Newton) -- known typo: (Isaac)
  • tesla (Nikola Tesla)

• Italians

  • tesla (Nikola Tesla)

• Chemists

  • boyle (Robert Boyle)
  • curie (Marie Curie)
  • nobel (Alfred Nobel)
  • pastuer (Louis Pastuer) -- known typo: (Pasteur)

Dedicated log file for LDAP 

If you want to redirect every logging information from this extension to var/log/ldap.log and send log entries with level "WARNING" or above to the system log, you may add following configuration to typo3conf/AdditionalConfiguration.php:

$GLOBALS['TYPO3_CONF_VARS']['LOG']['Causal']['IgLdapSsoAuth']['writerConfiguration'] = [
    \TYPO3\CMS\Core\Log\LogLevel::DEBUG => [
        \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
            'logFile' => \TYPO3\CMS\Core\Core\Environment::getVarPath() . '/log/ldap.log'
        ],
    ],

    // Configuration for WARNING severity, including all
    // levels with higher severity (ERROR, CRITICAL, EMERGENCY)
    \TYPO3\CMS\Core\Log\LogLevel::WARNING => [
        \TYPO3\CMS\Core\Log\Writer\SyslogWriter::class => [],
    ],
];

AS exchange 

When initially logging on to a network, users must negotiate access by providing a login name and password in order to be verified by the AS portion of a KDC. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain (in our example, for the realm example.com). The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter her password.

If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC (TGS) can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. The TGT includes time to live parameters, authorization data, a session key to use when communicating with the client and the client's name.

TGS exchange 

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.

The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.

Client/server exchange 

Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

Installing the mod_auth_kerb authentication module 

Within an intranet.example.com shell, install the package:

$ sudo apt-get install libapache2-mod-auth-kerb krb5-user

In additional to libapache2-mod-auth-kerb, this will install the dependency package krb5-config and then show you a configuration wizard asking for:

• Default Kerberos version 5 realm. Use EXAMPLE.COM (in capital letters).
• The KDC. My Active Directory server is ws2008r2.example.com, replace by your own. In a larger organization, you probably have two domain controllers, for redundancy reason.
• The administration server. This is typically the same as the LDAP/Active Directory server or in case of multiple domain controllers, this should be normally set to the master.

Settings you provide are then stored within configuration file /etc/krb5.conf which should look like this after the wizard configuration:

[libdefaults]
    default_realm    = EXAMPLE.COM

[realms]
    EXAMPLE.COM = {
        kdc          = ws2008r2.example.com
        #kdc          = other-kdc.example.com
        #master_kdc   = ws2008r2.example.com
        admin_server = ws2008r2.example.com
    }

[domain_realm]
    .example.com     = EXAMPLE.COM

[logging]
    kdc              = SYSLOG:NOTICE
    admin_server     = SYSLOG:NOTICE
    default          = SYSLOG:NOTICE

You should now check that Kerberos works on intranet.example.com. Do a basic check using kinit:

1. Ensure that intranet can reach KDC ws2008rs2 via the network (ping, ...).
2. Have a username and password in Windows Domain EXAMPLE.COM. In this example einstein is used as username.

3. Within the shell, type:

   $ kinit einstein@EXAMPLE.COM

   Copied!

   If everything is OK the command will ask you for einstein's domain password and terminates without an error message.

   Note

   If command fails with

   kinit: Cannot resolve servers for KDC in realm "example.com" while
   getting initial credentials

   Copied!

   then it most probably means that you did not pay attention to writing the realm in CAPITAL LETTERS.

4. Finally use klist to show the initial ticket you have got from the KDC:

   $ klist
   Default principal: einstein@EXAMPLE.COM
   
   Valid starting    Expires           Service principal
   31/10/2014 13:12  31/10/2014 23:11  krbtgt/EXAMPLE.COM@EXAMPLE.COM
           renew until 01/11/2014 13:12

   Copied!

Creating a service principal for the web server 

SPNEGO requires that a Kerberos service principal be created for the web server. The service name is defined to be HTTP, so for the server intranet.example.com the required service principal name is HTTP/intranet.example.com@EXAMPLE.COM.

1. Create a dummy account in Windows Domain EXAMPLE.COM. It is used like a machine account but is nevertheless a standard user account. In this example the name of dummy account is kerbdummy1.

2. Log in to the domain controller ws2008r2 and use the Windows command line tool ktpass to map the dummy account kerbdummy1 to the service principal HTTP/intranet.example.com@EXAMPLE.COM. You need that service principal to kerberize host intranet:

   C:\>ktpass
     -princ HTTP/intranet.example.com@EXAMPLE.COM
     -mapuser kerbdummy1@EXAMPLE.COM
     -crypto AES256-SHA1
     -ptype KRB5_NT_PRINCIPAL
     -pass very!$longp@ssw0rd
     -out C:\temp\intranetkeytab

   Copied!

   Note

   If you have to target Windows XP machines, AES256-SHA1 is not supported. Use the legacy crypto RC4-HMAC-NT instead.

   Warning

   Even if you target recent machines such as running Windows 8.x, AES256-SHA1 may not be supported either. Please check section Basic authentication prompt is always shown for details.

3. Copy file C:\\temp\\intranetkeytab from the domain controller ws2008r2 to the location where it should reside on host intranet, in our example /etc/apache2/http_intranet.keytab and make www-data its owner.

   Note

   An alternate way to create the needed keytab file is with the help of kadmin directly on your Linux machine. Please refer to www.microhowto.info for instructions.

4. Check if the KDC sends correct tickets by checking in detail:

   • ticket's kvno must match kvno in keytab
   • principal name in ticket must match the principal name in keytab

   $ kvno HTTP/intranet.example.com@EXAMPLE.COM
   HTTP/intranet.example.com@EXAMPLE.COM: kvno = 4
   
   $ klist -e
   Ticket cache: FILE:/tmp/krb5cc_0
   Default principal: HTTP/intranet.example.com@EXAMPLE.COM
   
   Valid starting    Expires           Service principal
   31/10/2014 14:53  01/11/2014 00:52  krbtgt/EXAMPLE.COM@EXAMPLE.COM
           renew until 01/11/2014 14:53, Etype (skey, tkt): aes256-cts-hmac-sha1-96, ...
   31/10/2014 15:09  01/11/2014 00:52  HTTP/intranet.example.com@EXAMPLE.COM
           renew until 01/11/2014 14:53, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
   
   $ klist -e -k -t /etc/apache2/http_intranet.keytab
   Keytab name: FILE:http_intranet.keytab
   KVNO Timestamp        Principal
   ---- ---------------- ---------------------------------------------------------
      4 01/01/1970 01:00 HTTP/intranet.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)

   Copied!

5. Check that the key has been correctly added to the keytab by attempting to use it to authenticate as the service principal, then view the resulting ticket-granting ticket using klist:

   $ kinit -k -t /etc/apache2/http_intranet.keytab HTTP/intranet.example.com
   $ klist
   Ticket cache: FILE:/tmp/krb5cc_0
   Default principal: HTTP/intranet.example.com@EXAMPLE.COM
   
   Valid starting    Expires           Service principal
   31/10/2014 14:11  01/11/2014 00:10  krbtgt/EXAMPLE.COM@EXAMPLE.COM
           renew until 01/11/2014 14:11

   Copied!

   Note

   if command fails with

   kinit: Generic preauthentication failure while getting initial credentials

   Copied!

   It may be related to using a legacy crypto. Try to edit file /etc/krb5.conf and update it to actively specify older cryptos:

   [libdefaults]
       default_realm = EXAMPLE.COM
       default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
       default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5

   Copied!

Specifying the authentication method to be used 

Apache must be told which parts of which web sites are to use authentication provided by mod_auth_kerb. This is done using the AuthType directive with a value of Kerberos.

In order to protect the whole TYPO3 website, add following snippet to your virtual host configuration:

<Location />
    AuthType Kerberos
    AuthName "Intranet of example.com"
    KrbMethodNegotiate on
    KrbMethodK5Passwd off
    # Allow shorter username (without realm):
    KrbAuthRealms EXAMPLE.COM
    KrbServiceName HTTP
    Krb5Keytab /etc/apache2/http_intranet.keytab

    # Disable the verification tickets against local keytab to
    # prevent KDC spoofing attacks
    # It should be used only for testing purposes
    KrbVerifyKDC off
</Location>

If you are using ``libapache2-mod-auth-gssapi``, add the following snippet instead:

<Location />
		SSLRequireSSL
		AuthType GSSAPI
		AuthName "Intranet of example.com"
		GssapiBasicAuth On
		GssapiCredStore keytab:/etc/apache2/http_intranet.keytab
		GssapiLocalName On
		require valid-user
</Location>

Note

If there is a need for the web site to be accessible to its authorized users from machines that are not part on the Kerberos realm, you may let mod_auth_kerb ask the user for her password using basic authentication and then validate that password by attempting to authenticate to the KDC. Please note however that this is significantly less secure than true Kerberos authentication:

To do so, change:

KrbMethodK5Passwd on

Copied!

Specifying a list of authorized users or user groups 

Having an authentication method does not by itself restrict access to the web site until you disallow access by anonymous users using Require directive:

<Location />
    # ...
    Require valid-user
</Location>

Please refer to the Apache documentation if you want to restrict access to certain users or groups (if so, you will certainly need to use another authorization module such as mod_authnz_ldap).

Final step is to reload the Apache configuration:

$ sudo apache2ctl configtest
Syntax OK
$ sudo service apache2 force-reload

You will need to access your website from a machine within your domain or by authenticating with the basic authentication dialog, if enabled. TYPO3 will then read the authenticated username from $_SERVER['REMOTE_USER'] and silently create the frontend user session, if it does not exist yet. You do not need any frontend login plugin for your website.

Case of option switches 

Basic authentication prompt is always shown 

Problem is that, although you set KrbMethodK5Passwd off in your Apache configuration, the browser of your domain machines/computers always shows the basic authentication dialog and does not seem to silently pass your user credentials to the web server.

Apache's error log shows:

[debug] [client X.X.X.X] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] [client X.X.X.X] Acquiring creds for HTTP@intranet.example.com
[debug] [client X.X.X.X] Verifying client data using KRB5 GSS-API
[debug] [client X.X.X.X] Client didn't delegate us their credential
[debug] [client X.X.X.X] GSS-API token of length 9 bytes will be sent back
[debug] [client X.X.X.X] GSS-API major_status:000d0000, minor_status:000186a5
[error] [client X.X.X.X] gss_accept_sec_context() failed: Unspecified GSS failure.
                         Minor code may provide more information (, )

It turns out that although the domain controller is MS Windows Server 2008r2 and the domain machine is using MS Windows 8.1, the account does not support Kerberos AES 256 bit encryption by default.

To fix this problem, either switch to RC4 for your Apache keytab file or enable the enhanced security option for the user accounts on your domain controller.

Apache's error log when everything is working properly:

[debug] [client X.X.X.X] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] [client X.X.X.X] Acquiring creds for HTTP@intranet.example.com
[debug] [client X.X.X.X] Verifying client data using KRB5 GSS-API
[debug] [client X.X.X.X] Client didn't delegate us their credential
[debug] [client X.X.X.X] GSS-API token of length 185 bytes will be sent back
[debug] [client X.X.X.X] kerb_authenticate_a_name_to_local_name einstein@EXAMPLE.COM -> einstein

KrbLocalUserMapping on

Another problem with the basic authentication prompt always shown might show up as follows in Apache's error log:

[error] [client X.X.X.X] gss_accept_sec_context() failed: Unspecified GSS failure.
                         Minor code may provide more information (, Wrong principal in request)

Although the reason is most probably that the reverse DNS of the web server is not exactly identical to what was specified in the keytab file, in one case, it turned out the problem was the very same as above, namely that the account did not support Kerberos AES 256 bit encryption.

Sources:

• http://www.microhowto.info/howto/configure_apache_to_use_kerberos_authentication.html
• http://www.grolmsnet.de/kerbtut/
• http://technet.microsoft.com/en-us/library/bb742516.aspx
• http://www.oracle.com/technetwork/articles/idm/weblogic-sso-kerberos-1619890.html

Hooks 

Syntax 

• Your custom marker should be surrounded by opening and closing curly braces {...}.
• Parameters are delimited by semi-colons (;).
• A parameter is a pair of parameter name and parameter value delimited by a pipe (|).
• First parameter should always be hookName.
• Parameter value may contain references to LDAP attributes using the standard syntax with <>.

Registration 

In your extension (in the ext_localconf.php file), register the hook using a code like:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['ig_ldap_sso_auth']['extraMergeField']['myCustomHook']
	= \VendorName\Extension\YourClass::class;

where myCustomHook corresponds to one of the hookName parameters you use in your mapping.

Your class has to implement a method extraMerge which will receive the following arguments:

$field

The name of the corresponding field in the mapping.

$typo3Record

An array containing the current user/group record from TYPO3.

$ldapRecord

An array containing the current user/group record from LDAP.

$ldapAttributes

An array containing LDAP attributes found in your mapping definition.

$hookParameters

An associative array with all hook parameters found in your mapping definition (thus including hookName).

Your method should simply return a string for the value to be given to $field.

\Causal\IgLdapSsoAuth\Library\Authentication::replaceLdapMarkers($hookParameters['param2'], $ldapRecord);

Version 4.0.0 

• Configuration option useExtConfConfiguration has been removed completely. This option was used to enable configuring LDAP settings via PHP code instead of a database record. In an attempt to streamline and be more consistent with internal types, this option has been removed. If you were using this option, you will need to migrate your custom code to use the PSR-14 event ConfigurationLoadedEvent instead.

How to contribute 

This extension is using the same contribution workflow as for TYPO3 Core, but with GitHub PRs for the review process. Please read more about the workflow in the TYPO3 Core Contribution Guide.