Announcement Announcement Module
Collapse
No announcement yet.
Problem in LDAP-setup Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem in LDAP-setup

    Friends is there any way to authenticate users using LDAP ,i am working on luntbuild(a build automation tool) which is build using spring framework,i need help in resolving how to configure the authentication properties as i need to authenticate users from luntbuild,any help would be appreciated
    Thanks

  • #2
    Hi,

    I've recently been working on an updated LDAP authentication provider which we're looking for feedback on prior to the next release. The code is in CVS (in the package org.acegisecurity.providers.ldap) and there is an LDAP version of the contacts sample application which you can take a look at. It's lacking an LDAP server at the moment, but that will be included later. It should give you an idea of how to set up the configuration.

    The relevant code packages are:

    http://acegisecurity.sourceforge.net...e-summary.html
    http://acegisecurity.sourceforge.net...e-summary.html
    http://acegisecurity.sourceforge.net...e-summary.html
    http://acegisecurity.sourceforge.net...e-summary.html

    Let us know how you get on.

    Luke.

    Comment


    • #3
      Great work!

      Hello Luke,

      I managed to authenticate my users to our Lotus Domino servers. The configuration is much easier than in previous versions.

      I'll try Active Directory and Oracle Internet Directory, too.

      Comment


      • #4
        Great. Please let us know how you get on as we'd like to iron out any potential problems in advance. I think we may require an extra configuration parameter for Active Directory login using Windows domain-style usernames.

        Thanks for the feedback.

        Luke.

        Comment


        • #5
          Configuration for Lotus Domino 6.5.4 and AcegiSecurity 1.0 RC1

          Code:
              <bean
                  id="initialDirContextFactory"
                  class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
                  <constructor-arg value="ldap://myserver:389" />
              </bean>
          
              <bean
                  id="ldapAuthenticationProvider"
                  class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
                  <constructor-arg>
                      <bean class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                          <constructor-arg>
                              <ref local="initialDirContextFactory" />
                          </constructor-arg>
                          <property name="userDnPatterns">
                              <list>
                                  <value>cn={0}</value>
                              </list>
                          </property>
                      </bean>
                  </constructor-arg>
                  <constructor-arg>
                      <bean class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                          <constructor-arg>
                              <ref local="initialDirContextFactory" />
                          </constructor-arg>
                          <constructor-arg>
                              <value>o=groups</value>
                          </constructor-arg>
                          <property name="convertToUpperCase">
                              <value>true</value>
                          </property>
                          <property name="rolePrefix">
                              <value></value>
                          </property>
                      </bean>
                  </constructor-arg>
              </bean>
          The groups have the form
          APPNAME_ROLE/Groups

          where APPNAME is the name off the application (obviously) and ROLE is something like ADMIN, EDITOR or READER. This makes rolePrefix unneccessary.

          Web user names are NOT hierarchical (Flat names unlike Notes names.) but it'd be easy to add something like /USERS in userDnPatterns.

          Next will be Oracle Internet Directory (OID).

          Comment


          • #6
            Configuration for Oracle Internet Directory 10g (OID)

            Code:
                <bean
                    id="initialDirContextFactory"
                    class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
                    <constructor-arg value="ldap://myoracle.server:389/dc=company,dc=com" />
                </bean>
            
                <bean
                    id="ldapAuthenticationProvider"
                    class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
                    <constructor-arg>
                        <bean
                            class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                            <constructor-arg>
                                <ref local="initialDirContextFactory" />
                            </constructor-arg>
                            <property name="userDnPatterns">
                                <list>
                                    <value>cn={0},cn=Users</value>
                                </list>
                            </property>
                        </bean>
                    </constructor-arg>
                    <constructor-arg>
                        <bean
                            class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                            <constructor-arg>
                                <ref local="initialDirContextFactory" />
                            </constructor-arg>
                            <constructor-arg>
                                <value>cn=groups</value>
                            </constructor-arg>
                            <property name="convertToUpperCase">
                                <value>true</value>
                            </property>
                            <property name="groupSearchFilter">
                                <value>(uniquemember={0})</value>
                            </property>
                            <property name="groupRoleAttribute">
                                <value>cn</value>
                            </property>
                            <property name="rolePrefix">
                                <value></value>
                            </property>
                        </bean>
                    </constructor-arg>
                </bean>
            The DN of a group is like cn=APPNAME_ROLE,cn=GROUPS,dc=company,dc=com.
            Again rolePrefix is unneccessary in this context.
            You can refine the groupSearchFilter e.g. (&(objectclass=groupOfUniqueNames)(uniqueMember={0 }))

            Again configuration was easy and works flawlessly.

            Comment


            • #7
              Microsoft Active Directory

              @Luke
              MS AD is a different beast. I don't think the current implementation is able to use it. (Or did I miss something.)
              My problem was that in our domain user and group dns are very deep. Something like cn=Mickey Mouse,ou=FunDepartment,ou=Paderborn,ou=Germany,ou= Europe,dc=Disney,dc=com.
              We have about 500+ ous, so listing them all in userDnPatterns is no option, unfortunatelly.

              Just an idea:
              Extend AbstractLdapAuthenticator (anyone for a good name?)
              authenticate should then first bind with managerDn/managerPassword and search for an entry where sAMAccountName matches username. (sAMAccountName should be variable.)
              This would give an array of DNs.
              Last step is trying to bind all DNs with password. The first that binds without an error is the valid account.

              As far as I can see you can also use this to authenticate against Oracle or Domino when anonymous binding is disabled on these plattforms.

              Are you working on something like this? Or do you have other ideas/plans? If you need help, I could write some code and test it against our Active Directory domain.

              Comment


              • #8
                MS Active Directory

                ok, Acegi can even use MS Active Directory when you read the javadocs.

                First it binds using ldapuser/paderborn/germany/company/com, does the search for the username, re-binds with the found dn and then reads the attribute memberOf. (So it is possible! Forget what I said earlier.)

                Code:
                    <bean
                        id="initialDirContextFactory"
                        class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
                        <constructor-arg value="ldap://myserver:389/dc=company,dc=com" />
                        <property name="managerDn">
                            <value><![CDATA[cn=ldapuser,ou=paderborn,ou=germany,dc=company,dc=com]]></value>
                        </property>
                        <property name="managerPassword">
                            <value>some password</value>
                        </property>
                         <property name="extraEnvVars">
                            <map>
                                <entry>
                                    <key>
                                        <value>java.naming.referral</value>
                                    </key>
                                    <value>follow</value>
                                </entry>
                            </map>
                        </property>
                    </bean>
                
                    <bean
                        id="userSearch"
                        class="org.acegisecurity.providers.ldap.search.FilterBasedLdapUserSearch">
                        <property name="searchSubtree">
                            <value>true</value>
                        </property>
                        <property name="initialDirContextFactory">
                            <ref local="initialDirContextFactory" />
                        </property>
                        <property name="searchFilter">
                            <value>(sAMAccountName={0})</value>
                        </property>
                    </bean>
                
                    <bean
                        id="ldapAuthenticationProvider"
                        class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
                        <constructor-arg>
                            <bean
                                class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                                <constructor-arg>
                                    <ref local="initialDirContextFactory" />
                                </constructor-arg>
                                <property name="userSearch">
                                    <ref local="userSearch" />
                                </property>
                            </bean>
                        </constructor-arg>
                        <constructor-arg>
                            <bean
                                class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                                <property name="userRoleAttributes">
                                   <value>memberOf</value>
                                </property>
                                <property name="convertToUpperCase">
                                    <value>true</value>
                                </property>
                                <property name="rolePrefix">
                                    <value></value>
                                </property>
                            </bean>
                        </constructor-arg>
                    </bean>
                The only problem with this solution is that you get the DN of the group, i.e.
                cn=APPNAME_ROLE,ou=groups,ou=paderborn,ou=germany, dc=company,dc=com. This is not very nice in the taglib.

                Doing a groupsearch for member={0} and using cn as the result will fix this.

                Unfortunatelly in our configuration ou=groups is the second entry in the hierarchy and not the last before dc=company,dc=com.
                Maybe creating another initialDirFactory with root DN dc=com and groupSearchBase dc=company will fix this.

                Has anyone tried this yet?

                btw, setting java.naming.referral to follow got rid of the nasty javax.naming.PartialResultException.

                Comment


                • #9
                  Acegi Securiy and Microsoft Active Directory 2003

                  Ok, this is it. A working configuration for Acegi Security and Microsoft Active Directory 2003.

                  Only one issue remains:
                  I don't know how to configure groupSearchBase for groups in multiple different OUs (e.g. ou=Germany and ou=India).

                  Code:
                      <bean
                          id="initialDirContextFactory"
                          class="org.acegisecurity.providers.ldap.DefaultInitialDirContextFactory">
                          <constructor-arg value="ldap://myserver:389/dc=company,dc=com" />
                          <property name="managerDn">
                              <value>cn=ldapuser,ou=paderborn,ou=germany,dc=company,dc=com></value>
                          </property>
                          <property name="managerPassword">
                              <value>some password</value>
                          </property>
                           <property name="extraEnvVars">
                              <map>
                                  <entry>
                                      <key>
                                          <value>java.naming.referral</value>
                                      </key>
                                      <value>follow</value>
                                  </entry>
                              </map>
                          </property>
                      </bean>
                  
                      <bean
                          id="userSearch"
                          class="org.acegisecurity.providers.ldap.search.FilterBasedLdapUserSearch">
                          <property name="searchSubtree">
                              <value>true</value>
                          </property>
                          <property name="initialDirContextFactory">
                              <ref local="initialDirContextFactory" />
                          </property>
                          <property name="searchFilter">
                              <value>(sAMAccountName={0})</value>
                          </property>
                      </bean>
                  
                      <bean
                          id="ldapAuthenticationProvider"
                          class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
                          <constructor-arg>
                              <bean
                                  class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                                  <constructor-arg>
                                      <ref local="initialDirContextFactory" />
                                  </constructor-arg>
                                  <property name="userSearch">
                                      <ref local="userSearch" />
                                  </property>
                              </bean>
                          </constructor-arg>
                          <constructor-arg>
                              <bean
                                  class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
                                  <constructor-arg>
                                      <ref local="initialDirContextFactory" />
                                  </constructor-arg>
                                  <constructor-arg>
                                      <value>ou=germany</value>
                                  </constructor-arg>
                                  <property name="convertToUpperCase">
                                      <value>true</value>
                                  </property>
                                  <property name="rolePrefix">
                                      <value></value>
                                  </property>
                                  <property name="searchSubtree">
                                      <value>true</value>
                                  </property>
                                  <property name="groupSearchFilter">
                                      <value>member={0}</value>
                                  </property>
                                  <property name="groupRoleAttribute">
                                      <value>cn</value>
                                  </property>
                              </bean>
                          </constructor-arg>
                      </bean>

                  Comment


                  • #10
                    Hi,

                    Thanks a lot for your feedback and testing!

                    On the groupSearchBase issue, can't you just specify the context above your ou's for germany, india etc?

                    Alternatively, I can change the code to take an array of DNs and perform the search within each. Or you can extend DefaultAuthoritiesPopulator. I'll have a look at it and see if I can make some improvements.

                    cheers,

                    Luke.

                    Comment


                    • #11
                      Hi Luke,

                      thinking about it I guess the current implementation solves 99% of all problems. (The remaining 1% is, when you need all groups for a user and you don't have a OU for all groups.)

                      For 'normal' applications it is totally ok to specify a fixed OU. If an application needs groups in different OUs you can nest groups in groups.

                      If I could make a wish I'd prefer a method to look for groups regardless of OU, rather than a list of DNs. [Just for the remaining 1% ;-) ] This would solve the multiple OU-problem without nesting, too.

                      BTW, keep on with your phantastic work. I convinced my boss to take a look a Spring and Acegi and he was surprised how easy it is to build consistent applications. In the next months we will port all our old Lotus Domino applications to Spring/Acegi.

                      Comment


                      • #12
                        can't find packages

                        Hi

                        I have the same challage to conect towards domino ldap.
                        The links metions in the second post don't seam to work. Anyone have a clue where to find them ?


                        http://acegisecurity.sourceforge.net...e-summary.html
                        http://acegisecurity.sourceforge.net...e-summary.html
                        http://acegisecurity.sourceforge.net...e-summary.html
                        http://acegisecurity.sourceforge.net...e-summary.html

                        Comment


                        • #13
                          Originally posted by kanonmicke
                          Hi

                          I have the same challage to conect towards domino ldap.
                          The links metions in the second post don't seam to work. Anyone have a clue where to find them ?


                          http://acegisecurity.sourceforge.net...e-summary.html
                          http://acegisecurity.sourceforge.net...e-summary.html
                          http://acegisecurity.sourceforge.net...e-summary.html
                          http://acegisecurity.sourceforge.net...e-summary.html
                          new url =
                          http://acegisecurity.org/multiprojec...roviders/ldap/

                          Comment


                          • #14
                            I'm trying to test the new LDAP functionality, but recent nightly cvs snapshots fail to build via maven (1.0.2)... it ends in compile errors which I do not have time to go into at the moment. Is there a nigthly build available that includes the latest LDAP packages?

                            cheers


                            UPDATE: managed to build it w/o junit tests (-Dmaven.test.skip). Will report testing results with IBM LDAP...
                            Last edited by roko; Feb 1st, 2006, 11:24 AM.

                            Comment


                            • #15
                              There were issues with CVS HEAD until early February due to the Apache Directory project having some incompatibilities. Luke ended up building a snapshot, and CVS HEAD works as of this moment. Luke has also been working with the Apache DS team to resolve the incompatibilities.

                              Comment

                              Working...
                              X