Skip navigation
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 1 2 Previous Next
  • 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
    276 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:
  • Currently Being Moderated
    May 24, 2013 5:25 AM   in reply to rguggenb

    I think i was able to replicate, in my case this, it had to do with the username ie SamAccountName(logon name) and Distinguished name.

    Lets say the user in ldap exist as Tom DN(CN=Tom,CN=Users,DC=vmlabs,DC=ad,DC=local). But the logon name is tom(lower case).

     

    case1: Login as Tom.

     

    When ldap does the lookup it does find Tom, it creates a user as Tom, it would generates a  login token and the login is successfull.

    If you see in the crx, you will see a new user with Tom.

     

    Delete the user that got created

     

    Case2: login as tom.

     

    Ldap does a look up, and it finds varun, I might be wrong but my hypothesis regarding this behaviour is, it does find the user tom but it fails to create a token for the same maybe because of Dn mismatch. But if you go ahead and check in crx you will find the user created as Tom. But when it tries to authenticate using that name, Ldap rejects that and no Token is generated for the user.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2013 4:33 AM   in reply to Sanjupr

    Hi,

    I am not able to get the user in CQ from the LDAP server, I have configured the ldap_login.conf and repository.xml as required. Can anyone help me out in figuring out what wrong I am doing.

     

     

     

    Thanks & Regards,

    Shailesh

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2013 6:11 AM   in reply to shailesh08

    What is the error that you are getting in the error.logs? And what version of CQ are you using?

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2013 6:28 AM   in reply to Sanjupr

    Hi Sanjupr,

    I am not getting any error in error log, but I am not able to login by the users I create using the LDAP.

    I will share the ldap_login.conf and respository.xml with you

     

    REPOSITORY.XML

    <?xml version="1.0" encoding="ISO-8859-1"?>

    <!-- ===================================================================== == -->

    <!-- $Id: repository-template.xml 78567 2011-06-16 04:27:03Z tripod $ -->

    <!-- ===================================================================== == -->

    <!-- Copyright (c) 1997-2008 Day Management AG                               -->

    <!-- Barfuesserplatz 6, 4001 Basel, Switzerland                              -->

    <!-- All Rights Reserved.                                                    -->

    <!--                                                                          -->

    <!-- This software is the confidential and proprietary information of        -->

    <!-- Day Management AG, ("Confidential Information"). You shall not          -->

    <!-- disclose such Confidential Information and shall use it only in         -->

    <!-- accordance with the terms of the license agreement you entered into     -->

    <!-- with Day.                                                               -->

    <!-- ===================================================================== == -->

    <!DOCTYPE Repository PUBLIC "-//Day Management AG//DTD CRX 2.4//EN"

                                "http://www.day.com/dtd/repository-2.4.dtd">

    <Repository>

        <!--

        virtual file system where the repository stores global state

        (e.g. registered namespaces, custom node types, etc.)

        -->

        <!--

        <FileSystem class="com.day.jackrabbit.fs.cq.CQFileSystem">

            <param name="path" value="${rep.home}/repStore.dat"/>

            <param name="autoRepair" value="false"/>

        </FileSystem>

        -->

        <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">

            <param name="path" value="${rep.home}/repository"/>

        </FileSystem>

     

        <!--

        large binary objects are stored in the data store.

        -->

        <DataStore class="com.day.crx.core.data.ClusterDataStore"/>

     

        <!--

        security configuration

        -->

        <Security appName="com.day.crx">

            <!--

                security manager:

                class: FQN of class implementing the JackrabbitSecurityManager interface

            -->

            <!--SecurityManager class="com.day.crx.core.CRXSecurityManager" workspaceName="" -->

            <SecurityManager class="com.day.crx.core.CRXSecurityManager">

                <!--

                optional user manager configuration

                -->

                <UserManager class="org.apache.jackrabbit.core.security.user.UserPerWorkspaceUserM anager">

                    <param name="usersPath" value="/home/users"/>

                    <param name="groupsPath" value="/home/groups"/>

                    <param name="defaultDepth" value="1"/>

                    <param name="autoExpandTree" value="true"/>

                    <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AccessControlA ction">

                      <param name="groupPrivilegeNames" value="jcr:read"/>

                      <param name="userPrivilegeNames" value="jcr:all"/>

                    </AuthorizableAction>

                    <!--AuthorizableAction class="com.day.crx.core.ntlm.NTLMAuthorizableAction"/>-->

                </UserManager>

     

                <!--

                optional workspace access manager configuration

               -->

            </SecurityManager>

            <!--

            access manager:

            class: FQN of class implementing the AccessManager interface

            -->

            <AccessManager class="org.apache.jackrabbit.core.security.DefaultAccessManager"></Ac cessManager>

            <!--

            Use LoginModule authenticating against repository itself

            -->

            <LoginModule class="com.day.crx.core.CRXLoginModule">

                <param name="anonymousId" value="anonymous"/>

                <param name="adminId" value="admin"/>

                <param name="disableNTLMAuth" value="true"/>

                <param name="tokenExpiration" value="43200000"/>

                <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/ -->

            </LoginModule>

        </Security>

     

        <!--

        location of workspaces root directory and name of default workspace

        -->

        <Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="crx.default" maxIdleTime="5"/>

        <!--

        workspace configuration template:

        used to create the initial workspace if there's no workspace yet

        -->

        <Workspace name="${wsp.name}" simpleLocking="true">

            <!--

            virtual file system of the workspace:

            class: FQN of class implementing FileSystem interface

            -->

            <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">

                <param name="path" value="${wsp.home}"/>

            </FileSystem>

     

            <!--

            persistence manager of the workspace:

            class: FQN of class implementing PersistenceManager interface

            -->

            <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"/>

     

            <!--

            Search index and the file system it uses.

            -->

            <SearchIndex class="com.day.crx.query.lucene.LuceneHandler">

                <param name="path" value="${wsp.home}/index"/>

                <param name="resultFetchSize" value="50"/>

            </SearchIndex>

     

            <!--

            Workspace security configuration

            -->

            <WorkspaceSecurity>

                <AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.ACLProvi der">

                    <param name="omit-default-permission" value="true"/>

                </AccessControlProvider>

            </WorkspaceSecurity>

     

            <!--

            XML Import configuration of the workspace

            -->

            <Import>

                <ProtectedItemImporter class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>

                <ProtectedItemImporter class="org.apache.jackrabbit.core.security.user.UserImporter">

                    <param name="importBehavior" value="besteffort"/>

                </ProtectedItemImporter>

            </Import>

        </Workspace>

     

        <!--

            Configures the versioning

        -->

        <Versioning rootPath="${rep.home}/version">

            <!--

                Configures the filesystem to use for versioning of the respective

                persistence manager

            -->

            <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">

                <param name="path" value="${rep.home}/version"/>

            </FileSystem>

     

            <!--

                Configures the persistence manager to use for the versioning.

                Please note, that the current versioning implementation is based on

                a 'normal' persistence manager, but this could change in future

                implementations.

            -->

            <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"/>

     

        </Versioning>

     

        <!--

            Enable searching the /jcr:system subtree

        -->

        <SearchIndex class="com.day.crx.query.lucene.LuceneHandler">

            <param name="path" value="${rep.home}/repository/index"/>

        </SearchIndex>

     

        <!--

            Cluster configuration.

        -->

        <Cluster>

            <Journal class="com.day.crx.persistence.tar.TarJournal"/>

        </Cluster>

     

        <!--

            Configures extension modules

        -->

        <Modules>

            <!--

               Sample configuration of an EventLoggerModule requiring configuration

               <Module class="com.day.crx.eventlogger.EventLoggerModule">

                   <param name="workspaces" value="crx.default"/>

                   <param name="logWorkspace" value="crx.logger"/>

                   <param name="logPath" value="/logger"/>

               </Module>

            -->

        </Modules>

    </Repository>

     

     

    ldap_login.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="10.242.135.12"

                  port="10389"

                  secure="true"

                  userRoot="ou=users, ou=system"

                  groupRoot="ou=groups, o=example"

                  groupMembershipAttribute="uniquemember"

                  autocreate="create"

                  autocreate.user.mail="profile/email"

                  autocreate.user.givenname="profile/givenName"

                  autocreate.user.sn="profile/familyName"

                  autocreate.group.description="profile/aboutMe"

                  autocreate.group.mail="profile/email"

                  autocreate.group.cn="profile/givenName"

                  autocreate.path="direct"

                  cache.expiration="600"

                  cache.maxsize="100";

    };

     

     

     

    I am able to get the connection from the LDAP server i checked that by creating a connection by using jxplorer VDS.I am using CQ5.5

     

     

     

    Thanks & Regards,

    Shailesh

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2013 6:32 AM   in reply to shailesh08

    Did you deliberately remove the below params?

    authDn=

    authPw=

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2013 6:42 AM   in reply to Sanjupr

    No i copied the ldap_login.conf from somewhere and pasted at  C:\author\crx-quickstart\conf. Is that the ldap_login.conf is not correct and because of that I am facing the issue?

     

     

    Thanks & Regards,

    Shailesh

     
    |
    Mark as:
1 2 Previous Next

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