************************************* Pass-Through authentication with SASL ************************************* Presentation ============ .. include:: delegation.rst Technical description ===================== OpenLDAP is known to be able to use pass-through authentication. This option should be compiled into it. If not, get the sources and use this option in the configure step:: ./configure --enable-spasswd --with-cyrus-sasl This will allow you to store password with this syntax in userPassword attribute: ``userPassword: {SASL}user@domain`` This option is enabled by default in LDAP Tool Box OpenLDAP packages Then you need the saslauthd daemon, which is available on most Linux distributions. The pass-through authentication will then work like this: 1. A BIND operation is received by OpenLDAP with parameters DN1 and PWD1 2. OpenLDAP get DN1 entry and read userPassword attribute 3. DN1 password is a SASL password so OpenLDAP do a SASL authentication with ``user@domain`` and PWD1 credentials 4. SASL authentication daemon use the credentials to look for the user into the backend (for example Active Directory) and gets the matching DN, DN2 5. SASL do a BIND operation with DN2 and PWD1 6. The backend manage the BIND and return response to SASL 7. SASL returns authentication status to OpenLDAP (yes/no) 8. OpenLDAP returns response to the LDAP client Pass-Through authentication on one LDAP directory ================================================= .. image:: images/sasl_delegation.png :alt: schema of SASL delegation :align: center .. TIP:: This is the standard use case: the password is stored in a directory and other LDAP directories delegate authentication to it. .. NOTE:: This chapter allows you to use several LDAP directories as authentication backend, but only for redundancy problems: all directories will have the same data inside. To see how use several directories with different data models, go to next chapter. Step 1: connection to the backend --------------------------------- You need to get all connection parameters to the authentication backend. An example with Active Directory: :Server address: ``ldap://ad.example.com`` :Bind DN: ``CN=Administrator,CN=Users,DC=example,DC=com`` :Bind Password: ``ADpassword`` :Users branch: ``CN=DomainUsers,DC=example,DC=com`` You can check these settings with an ldapsearch:: ldapsearch -x -H ldap://ad.example.com -D CN=Administrator,CN=Users,DC=example,DC=com -w ADpassword -b CN=DomainUsers,DC=example,DC=com Step 2: configure saslauthd --------------------------- First, check that your SASL daemon supports LDAP:: saslauthd -v If not, reinstall an LDAP-aware saslauthd daemon. For RHEL:: yum install cyrus-sasl For Debian:: apt install sasl2-bin Then to activate LDAP as SASL mechanism on Red-Hat systems:: vi /etc/sysconfig/saslauthd :: SOCKETDIR=/var/run/saslauthd MECH=ldap FLAGS="-O /etc/saslauthd.conf" Activate saslauthd on startup:: chkconfig saslauthd on To activate LDAP as SASL mechanism on Debian systems:: vi /etc/default/saslauthd :: START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="ldap" MECH_OPTIONS="/etc/saslauthd.conf" THREADS=5 OPTIONS="-r -c -m /var/run/saslauthd" Activate saslauthd on startup:: systemctl enable saslauthd .. NOTE:: On Debian systems, make sure the -r option is enabled (combine the realm with the login before passing to authentication mechanism):: OPTIONS="-r -c -m /var/run/saslauthd" To finish enter all connection information found at step one:: vi /etc/saslauthd.conf :: ldap_servers: ldap://ad.example.com ldap_search_base: CN=DomainUsers,DC=example,DC=com ldap_timeout: 10 ldap_filter: sAMAccountName=%U ldap_bind_dn: CN=Administrator,CN=Users,DC=example,DC=com ldap_password: ADpassword ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind Main parameters are: :ldap_servers: LDAP URI, space separated for redundancy :ldap_bind_dn: DN for connection :ldap_password: Password for connection :ldap_search_base: Search base :ldap_filter: Search filter :ldap_scope: Search scope In parameters ``ldap_search_base`` and ``ldap_filter``, you can use these variables (example for SASL password ``user@domain``): * %u: ``user@domain`` * %U: user * %d: domain Restart saslauthd:: systemctl restart saslauthd Step 3: communication between OpenLDAP and saslauthd ---------------------------------------------------- The communication between the two daemons are done through a mutex, configured like this:: vi /usr/lib/sasl2/slapd.conf :: pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux Add OpenLDAP user to sasl group (adapt names to your distribution settings, for example ``saslauth`` for RHEL):: usermod -a -G sasl ldap Step 4: OpenLDAP configuration ------------------------------ Edit OpenLDAP configuration to configure the SASL parameters [#f1]_:: sasl-host localhost sasl-secprops none Restart OpenLDAP:: systemctl restart slapd Step 5: be proud ---------------- Now we can use the pass-through authentication. To test it, you need an account in the backend, for example:: # Clement OUDOT, DomainUsers, example;com dn: CN=Clement OUDOT,OU=DomainUsers,DC=example,DC=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectClass: inetOrgPerson cn: Clement OUDOT sn: OUDOT givenName: Clement distinguishedName: CN=Clement OUDOT,OU=DomainUsers,DC=example,DC=com instanceType: 4 whenCreated: 20080617074258.0Z whenChanged: 20080617081856.0Z displayName: Clement OUDOT uSNCreated: 77070 uSNChanged: 78687 name: Clement OUDOT objectGUID:: TB3HuDzG8EOoUKBrMWRnyg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 128581621788125000 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAmtgimaPoR9Go86e7PQgAAA== accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: coudot sAMAccountType: 805306368 userPrincipalName: coudot@example.com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com You can test the SASL part with this command:: testsaslauthd -u coudot -p password Then create an account in OpenLDAP, for example:: dn: uid=coudot,ou=users,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top uid: coudot cn: Clement OUDOT sn: OUDOT userPassword: {SASL}coudot@example.com Now you can bind to OpenLDAP with AD password:: ldapsearch -x -H ldap://ldap.example.com -b dc=example,dc=com -D uid=coudot,ou=users,dc=example,dc=com -w password Pass-Through authentication on several LDAP directories - with OpenLDAP meta backend ==================================================================================== .. image:: images/sasl_delegation_multi_ad.png :alt: schema of SASL delegation on several directories :align: center .. TIP:: You need to install all the components of the previous chapter. This chapter will only describe the evolutions to do. .. NOTE:: This chapter explains how to do Pass-Through authentication on several LDAP backends with OpenLDAP meta backend. This adds complexity as SASL daemon can only be configured to connect to a single remote directory, and OpenLDAP cannot use several SASL authentication daemons. The solution described here use a meta directory between SASL daemon and remote directories. The choice of the backend to contact will be done in the SASL password value, for example ``{SASL}user@LDAP1`` and ``{SASL}user@LDAP2``. Step 1: create the meta directory --------------------------------- Configure a new OpenLDAP instance that will be a meta directory for the LDAP backends, for example [#f1]_:: # Database database meta suffix "dc=local" rootdn "cn=Manager,dc=local" rootpw secret # LDAP 1 uri ldap://ldap1.example.com/ou=LDAP1,dc=local lastmod off suffixmassage "ou=LDAP1,dc=local" "dc=example1,dc=com" idassert-bind bindmethod=simple binddn="cn=admin,dc=example1,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=local" # LDAP 2 uri ldap://ldap2.example.com/ou=LDAP2,dc=local lastmod off suffixmassage "ou=LDAP2,dc=local" "dc=example2,dc=com" idassert-bind bindmethod=simple binddn="cn=admin,dc=example2,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=local" Launch this server on a new port (or another server), that will be accessible from SASL dameon. For example it will be launched on ``_ Step 2: reconfigure saslauthd ----------------------------- Adapt SASL daemon configuration to contact the meta directory:: vi /etc/saslauthd.conf :: ldap_servers: ldap://127.0.0.1:390/ ldap_search_base: ou=%d,dc=local ldap_timeout: 10 ldap_filter: (|(uid=%U)(SAMACCOUNTNAME=%U)) ldap_bind_dn: cn=Manager,dc=local ldap_password: secret ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind The interesting changes are: :ldap_search_base: we use the domain component (``%d``) to match to destination backend, through the meta directory DIT :ldap_filter: we mix the filters with an OR filter, so that the user (``%U``) will be found whatever backend is called Restart saslauthd:: systemctl restart saslauthd Step 3: be really proud ----------------------- Do the tests of the first chapter, with different users in LDAP1 and LDAP2, and appropriate users in the main OpenLDAP server. By playing with the SASL password value, you are able to choose the authentication backend for pass-through authentication. Pass-Through authentication on several LDAP directories - with OpenLDAP ldap backend ==================================================================================== .. NOTE:: This chapter explains how to do Pass-Through authentication on several LDAP backends with OpenLDAP ldap backend. The advantage over the meta backend is the possibility to use the rwm overlay with specific configuration for a backend directory, and for those using the cn=config backend, to manage the configuration into it (as these lines are written, backend meta is not supported in cn=config). Step 1: create the proxy directory ---------------------------------- Configure a new OpenLDAP instance that will be a proxy directory for the LDAP backends, for example:: # Database LDAP for local Manager authentication database ldap suffix "cn=manager,dc=local" rootdn "cn=manager,dc=local" rootpw secret # Database LDAP for LDAP 1 database ldap suffix "ou=LDAP1,dc=local" uri ldap://ldap1.example.com idassert-bind bindmethod=simple binddn="cn=admin,dc=example1,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=local" overlay rwm rwm-suffixmassage "ou=LDAP1,dc=local" "dc=example,dc=com" # Database LDAP for LDAP 2 database ldap suffix "ou=LDAP2,dc=local" uri ldap://ldap2.example.com idassert-bind bindmethod=simple binddn="cn=admin,dc=example2,dc=com" credentials="secret" mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=Manager,dc=local" overlay rwm rwm-suffixmassage "ou=LDAP2,dc=local" "dc=example,dc=com" # Example of rwm configuration for Active Directory rwm-map attribute uid sAMAccountName rwm-map attribute * * Step 2: reconfigure saslauthd ----------------------------- Adapt SASL daemon configuration to contact the meta directory:: vi /etc/saslauthd.conf :: ldap_servers: ldap://127.0.0.1:390/ ldap_search_base: ou=%d,dc=local ldap_timeout: 10 ldap_filter: uid=%U ldap_bind_dn: cn=Manager,dc=local ldap_password: secret ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind We have just changed the ``ldap_search_base`` parameter to use the domain component (``%d``) to match to destination backend, through the meta directory DIT. You can keep a simple ``ldap_filter`` parameter, as we use rwm overlay to match the login attribute in both directories. Restart saslauthd:: systemctl restart saslauthd Step 3: be really proud (indeed, you are awesome) ------------------------------------------------- Do the tests of the first chapter, with different users in LDAP1 and LDAP2, and appropriate users in the main OpenLDAP server. By playing with the SASL password value, you are able to choose the authentication backend for pass-through authentication. .. rubric:: Footnotes .. [#f1] example is given for a `slapd.conf `_ configuration. See `slapd-config manual `_ for more information about corresponding cn=config configuration