Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Crypto Support for LDAP Bind password

Avatar

Level 3

We use LDAP for authentication to the Author server. After configuring LDAP, the bind password used by the user to authenticate to the LDAP server is in plain text in the repository.  We we hoping to encrypt that password using Crypto Support but it does not seem to work.

 

We can encrypt using Web Console -> Main -> Crypto Support to come up with a hash.  We replace the password with that hash in the OSGI node configuration.  LDAP works fine until AEM is restarted.  After the restart the LDAP bind is no longer successful and LDAP no longer works. 

 

OSGI Config node:

 

/apps/system/config.author/org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider-<identifier> 

bind.password = {hash}

 

 

In the error log it shows:
06.10.2020 14:26:03.313 *ERROR* [qtp889165464-1425] org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory unable to bind connection: 80090308: LdapErr: DSID-0C090442, comment: AcceptSecurityContext error, data 52e, v3839

 

I found an entry in this forum from 2015 that indicates the Crypto Support hash may not work with LDAP, but I am hopeful it has been resolved in the last 5 years.

 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/using-hashed-password-for-...

 

AEM 6.4.8.2

 

...

clint

1 Accepted Solution

Avatar

Correct answer by
Level 3

This has been resolved with a call to technical support.  The environment in question was in-place upgraded from AEM 6.1 to AEM 6.4.  Starting in AEM 6.3 the Crypto Keys are stored in the file system by default.  Prior, the keys were stored in the repository.  Because this system was in-place upgraded, the keys stayed in the repository even though it is AEM 6.4.  Normally that is not a problem and the documentation indicates leaving them in the repository is just fine.  However there is at least one potential issue.

 

If the keys are in the JCR repository the Crypto system is read on system start AFTER the LDAP configuration is read.   Therefore the crypto system is not in place to decrypt the password for the purpose of the LDAP bind.  To fix the LDAP issue we moved the Crypto Keys to the file system.

 

Keys in repository  - /etc/key

Keys in file system - /crx-quickstart/launchpad/felix/bundle{id}/data

 

Here is a link on how to synchronize the keys.  It can also be used as a guideline to move them. 
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/crypto-support-in-aem-sync...

 

View solution in original post

1 Reply

Avatar

Correct answer by
Level 3

This has been resolved with a call to technical support.  The environment in question was in-place upgraded from AEM 6.1 to AEM 6.4.  Starting in AEM 6.3 the Crypto Keys are stored in the file system by default.  Prior, the keys were stored in the repository.  Because this system was in-place upgraded, the keys stayed in the repository even though it is AEM 6.4.  Normally that is not a problem and the documentation indicates leaving them in the repository is just fine.  However there is at least one potential issue.

 

If the keys are in the JCR repository the Crypto system is read on system start AFTER the LDAP configuration is read.   Therefore the crypto system is not in place to decrypt the password for the purpose of the LDAP bind.  To fix the LDAP issue we moved the Crypto Keys to the file system.

 

Keys in repository  - /etc/key

Keys in file system - /crx-quickstart/launchpad/felix/bundle{id}/data

 

Here is a link on how to synchronize the keys.  It can also be used as a guideline to move them. 
https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/crypto-support-in-aem-sync...