Skip navigation

CQ5

Currently Being Moderated

LDAP set up with CQ 5.5

Mar 26, 2012 5:56 AM

These instructions: http://dev.day.com/docs/en/cq/current/core/administering/ldap_authenti cation.html#Switching On LDAP Authentication does not seem to be updated for 5.5, because the file crx-quickstart\server\etc\ldap_login.conf does not exist(even the server directory does not exist). Could any one help?

 
Replies
  • Currently Being Moderated
    Mar 26, 2012 7:11 AM   in reply to Murali Vusthipalli

    see the user comment at the bottom of said documentation page:

     

    "Upgaded a 5.4 instance to 5.5 and LDAP does not work right away. You need to provide the full path to the ldap_login.conf on the start script."

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2012 12:59 PM   in reply to Murali Vusthipalli

    again, the documentation is outdated. log levels are managed via the system console (e.g. http://localhost:4502/system/console/configMgr). consult the logging docs: http://dev.day.com/docs/en/cq/current/deploying/configure_logging.html - i think they're reasonably up to date for instance, add a logger for the ldap package.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 6:00 AM   in reply to Murali Vusthipalli

    it is the java package name of the login module as referenced in your JAAS configuration.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 6:06 AM   in reply to Murali Vusthipalli

    yes, or just the package name to have all classes: com.day.crx.security.ldap

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 2:49 PM   in reply to Murali Vusthipalli

    Hi Murali,

     

    The problem is probably due to a misconfiguration in your ldap_login.conf or repository.xml file. Make sure your repository.xml is a valid XML (i.e. all tags, quotes are properly closed).  If you're still having problems please post your repositor.xml and ldap_login.conf.

     

    Hope this helps.

    Ron

     
    |
    Mark as:
  • Justin Edelson
    249 posts
    Nov 24, 2010
    Currently Being Moderated
    Mar 29, 2012 5:43 AM   in reply to Murali Vusthipalli

    Murali-

    I believe you are missing a semi-colon after cache.maxsize="200" and there's an extra semi-colon after autocreate.group.cn="rep:fullname"

     

    The semi-colon has to go at the end of the options, not in the middle.

     

    I'm a bit surprised that JAAS isn't complaining about this with a meaningful (or even not-so meaningful) error message.

     

    Justin           

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2012 9:49 AM   in reply to Murali Vusthipalli

    Hi Murali,

     

    The documentation is outdated for 5.5.  I haven't been able to find that feature in 5.5, but if your CQ instance is properly connected to your LDAP then you should just be able to login with your LDAP credentials.  Since you have autocreate="create" within your ldap_login.conf file, it should automatically create/sync that account from LDAP to CQ.

     

    Cheers,

    Ron

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2012 10:10 AM   in reply to Murali Vusthipalli

    Any errors in the error.log?  You may need to enable debug logging for LDAP to get more info.  My guess CQ can't find the user in LDAP.  The problem might be your values for 'userRoot' in your ldap_login.conf.  From looking at your authDn "CN=Murali,OU=Users Accounts (UnSorted),DC=us,DC=ad,DC=com", I suspect your userRoot should be ""OU=Users Accounts (UnSorted),DC=us,DC=ad,DC=com".  Give that a try.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2012 10:57 AM   in reply to Murali Vusthipalli

    Glad it hear it's working now.  As for different userRoots, not sure if you can use a more top level userRoot (e.g. DC=us,DC=ad,DC=com) with a userFilter.  You may need to check with you LDAP admin.   But you may be able to just simply setup this other userRoot as a separate LDAP server.  Checkout this KB article - http://dev.day.com/content/kb/home/Crx/CrxSystemAdministration/HowToMu ltipleLdapServer.html

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2012 2:48 PM   in reply to Murali Vusthipalli

    Problem seems to be your groupRoot of "CN=eBT-IWOV,OU=eBT,OU=User and Group Accounts,DC=us,DC=ad,DC=com".  I'm assuming your group ID/name is 'eBT-IWOV'.  Since the default groupNameAttribute is "cn", try setting your groupRoot to "OU=eBT,OU=User and Group Accounts,DC=us,DC=ad,DC=com".  You will need to restart CQ for the changes take affect.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 30, 2012 9:54 AM   in reply to Murali Vusthipalli

    From my understanding, the way CQ's LDAPUserSync work is that it will import and create the LDAP groups that is under the defined groupRoot that that user is a member of.  One problem is that CQ's LDAPUserSync isn't compatible with your LDAP Schema.  We had this problem initially because of the way we were storing groups in LDAP.

     

    We were initially storing our group information in an object which has a member of locally defined attributes and stores the members of the group in multi-valued "memberUid" attributes (e.g. Murali). CQ assumes that the value of the member attribute has the form of the fully qualified name (e.g. uid=Murali,OU=Users Accounts (UnSorted),DC=us,DC=ad,DC=com).  So when it searches for group members it searches for "memberUid=uid=Murali,OU=Users Accounts (UnSorted),DC=us,DC=ad,DC=com" which produces no match.

     

    Now, we have since changed our LDAP schema to match this, however, we are still unhappy with the CQ LDAPUserSync.  Problem we have discovered is that when it creates CQ groups pulled from LDAP, it creates the group with the ID using the principal-name which is the full DN in LDAP.  For example, it will actually create the LDAP group of eBT-IWOV as /home/groups/C/CN/CN=eBT-IWOV,OU=eBT,OU=User and Group Accounts,DC=us,DC=ad,DC=com (if using <param name="defaultDepth" value="3"/> for the com.day.crx.core.CRXUserManagerImpl in repository.xml).  This is a problem for us because it would result in a very flat group hiearchy in the repository, creating 1000's of group records under the same node of /home/groups/C/CN/.

     

    Since CRX2.2 (CQ5.4) the UserManager API has been updated to allow for creating groups with arbitrary groupd IDs (e.g. CN valud of the LDAP group).  However, we were disappointed to discover that in 5.5 the LDAPUserSync hasn't been updated yet to make use of new API.  So since 5.4, we've been managing groups manually using scripts and we automate the synching vai cron job.

     

    Within the CQ Higher Education group, I don't believe anyone uses the LDAPUserSync for group integration simply because of its limitations.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 31, 2012 12:42 PM   in reply to Murali Vusthipalli

    For new Adobe CQ5.5 users I feel this thread needs a bit of clarity on LDAP integration with CQ. I wrote a blog about the topic: http://www.citytechinc.com/us/en/blog/2012/03/adobe_cq5_5_and_ldap.htm l but will elaborate here.

     

    The changes to LDAP setup between CQ 5.4 and 5.5 are minimal (and mainly just not particularly clear) but the documentation on the support site has yet to reflect it. In CQ 5.5 (a fresh install) you will not get a /crx-quickstart/server/etc/sample_ldap_login.conf file to modify. However, it's still appropriate to use in 5.5 as JAAS configs are a standard for the JVM. Also, beware if you enable JAAS in the quickstart script that comes with 5.5, it has an order of parameters issue and JAAS configs won't parse correctly, you'll need to specify the JAAS config prior to the -jar JVM option.

     

    In short if you are a new CQ user to 5.5 and looking for LDAP integration simply use the sample on the support site but refernce the configuration in the JVM as a command-line option rather than trying to figure out why /server/etc no longer exists.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 12, 2012 2:39 AM   in reply to C. Vozar - CITYTECH

    Hi,

     

    I'm getting the following error after a login with correct credentials (authentication works):

     

    java.lang.IllegalArgumentException: Invalid token ''

            at org.apache.jackrabbit.api.security.authentication.token.TokenCredenti als.(TokenCredentials.java:42)

            at com.day.crx.security.token.impl.TokenAuthenticationHandler.createCred entials(TokenAuthenticationHandler.java:528)

            at com.day.crx.security.token.impl.TokenAuthenticationHandler.extractCre dentials(TokenAuthenticationHandler.java:345)

            at org.apache.sling.auth.core.impl.AuthenticationHandlerHolder.doExtract Credentials(AuthenticationHandlerHolder.java:75)

    at org.apache.sling.auth.core.impl.AbstractAuthenticationHandlerHolder.e xtractCredentials(AbstractAuthenticationHandlerHolder.java:60)

            Truncated. see log file for complete stacktrace

     

     

    Any ideas on how to troubleshoot?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 15, 2012 8:16 AM   in reply to rguggenb

    The invalid token error followed by empty single quotes '' is coming out of jackrabbit code that checks if the token is null or an empty string.

     

        if (token == null || token.length() == 0) {
                throw new IllegalArgumentException("Invalid token '" + token + "'");
        }

     

    The way it works for me:

     

    1. Log in as an administrator.  I use admin
    2. Delete any LDAP created test user account so logging in will be creating the account using LDAP.
    3. Log into the the Felix (Web) Console as admin and keep this window open for the duration of this test.
    4. Log out of CQ but not the Felix (Web) Console.  Since the console uses HTTP basic auth you can do this.
    5. Log out all users from CQ.
    6. Use the Felix console CRX Login Tokens display to see that there are no tokens.
    7. Configure CQ to use LDAP and try to log in to the test account that had no CQ account created yet.
    8. The CQ will return error 500 as jackrabbit throws "Invalid token '' "
    9. Your account will be created anyway from the LDAP data.
    10. Use the Felix console CRX Login Tokens display to see that there is no token for your account.
    11. Delete the cookie from your web browser with the host name of your CQ URL and the value "login-token".
    12. Try to login to CQ using your LDAP account again.  This time you will get a login token and things will be normal.

     

    Why doesn't the first login attempt get a CRX Login Token?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 15, 2012 2:51 PM   in reply to kstailey

    Also the cookie that comes back on the first LDAP login that creates the QA account has three fields and the second one is not filled in.

     

    The details of a sample cookie from the create followed by the cookie content from the second login:

     

    b7649c06-ad22-4115-8947-773f030f5579::crx.default

    b7649c06-ad22-4115-8947-773f030f5579:cbb60011-7526-4282-b89f-b44777def323_f9c7d8a78e20d620:crx.default

     

    The LDAP login that creates the CQ account has a cookie with an empty second colon separated field.  Most likely that field would have the CRX Login Token if there was one.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2012 7:03 AM   in reply to kstailey

    Tokens are stored in the user's home directory jcr node tree.

     

    There is no home directory jcr node tree for an LDAP user that has never logged in.  Autocreate mode specifies that the account is created on demand including the home directory.

     

    If the user's LDAP CN is Adams\, Alice

    and LDAP sAMAccountName is A-Adams

     

    Then on the first login, autocreate causes these nodes to be created

     

    /home/users/Adams\, Alice/A-Adams

    /home/users/Adams\, Alice/A-Adams/profile

    /home/users/Adams\, Alice/A-Adams/rep:policy

    /home/users/Adams\, Alice/A-Adams/rep:policy/allow

     

    What is not created is:

     

    /home/users/Adams\, Alice/A-Adams/.tokens

     

    I think that the routine that creates the .tokens node is executed prior to the one that creates the parent node of .tokens (in this case /home/users/Adams\, Alice/A-Adams).  The result is that it fails to create the .tokens node.

     

    The second LDAP login works, the home directory already exists and the .tokens node is created.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 19, 2012 1:30 AM   in reply to Murali Vusthipalli

    Same problem here. First time login does not work for LDAP user because of blank token. Are there any workarounds/config changes that will help first-time login to succeed?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2012 8:39 AM   in reply to vijaynagpal

    If your LDAP (AD) user name contains upper case letters you must type them in exactly as they are in LDAP (AD) in order to avoid this error.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 18, 2013 12:51 PM   in reply to Ron @ SFU

    Hello Ron,

     

    I have a similar problem, i have doublecheck with my repository.xml, it's exactly the same as Murali posted.. and my ldap_login.conf, i actually name my config file jaas.conf, here is the content of my jaas.conf:

     

    com.day.crx {

                 com.day.crx.core.CRXLoginModule sufficient;

              com.day.crx.security.ldap.LDAPLoginModule required

                   principal_provider.class="com.day.crx.security.ldap.principals.LDAPPr incipalProvider"

                   host="my ldap server"

                   port="389"

                   secure="false"

                                             authDn="cn=dcp,ou=users,o=com"

                                             authPw="XXXXXX"

                   userRoot="ou=users,o=com"

                                             userFilter="(objectclass=user)"

                                             userIdAttribute="cn"

                   groupRoot="ou=groups,o=com"

                   groupMembershipAttribute="member"

                   autocreate="create"

                                             autocreate.user.membership="contributor"

                   autocreate.user.mail="profile/email"

                   autocreate.user.givenname="profile/givenName"

                  autocreate.user.sn="profile/familyName"

                  autocreate.path="direct"

                  cache.expiration="600"

                  cache.maxsize="1000";

    };

     

    I tested the config by running the following comment:

     

    java -Djava.security.auth.login.config=c:/cq/author/crx-quickstart/etc/jaas.conf -Xmx1024M -XX:MaxPermSize=256M -jar cq5-author-p4502.jar

     

    I have been look at it for a day now and don't seem to figure out.. I am running CQ5.5 on my localhost. Any help will be great.

     

    Thanks,

    Silka B.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points