Does Knox support active directory searches using nested OUs and/or multiple AD search strings?

[#1]

1.)Does Knox support active directory searches using nested OUs? I’m reading in some of the documentation that it does not. The main.ldapRealm.userDnTemplate value we are trying to use is samaccountname={0},ou=corp,ou=associates,OU=MY_COMPANY Accounts,DC=amer,DC=qa_my_company,DC=com but the users are not being found.

2.)Does Knox support multiple AD search strings? Not all users that need access to Knox protected services can be found using the single search string above.

Would these require multiple Knox Topology files to be applied at once?

[#2 · Accepted solution]

Hi Wes - It is possible. I used the following knox config in past to do it.

For 2 - You would need a different knox topology.

    <provider>
            <role>authentication</role>
            <name>ShiroProvider</name>
            <enabled>true</enabled>
            <param>
                <!--
                session timeout in minutes,  this is really idle timeout,
                defaults to 30mins, if the property value is not defined,,
                current client authentication would expire if client idles contiuosly for more than this value
                -->
                <name>sessionTimeout</name>
                <value>30</value>
            </param>            
            <param>
                <name>main.ldapRealm</name>
                <value>org.apache.hadoop.gateway.shirorealm.KnoxLdapRealm</value>
            </param>
            <param>
                <name>main.ldapContextFactory</name>
                <value>org.apache.hadoop.gateway.shirorealm.KnoxLdapContextFactory</value>
            </param>
            <param>
                <name>main.ldapRealm.contextFactory</name>
                <value>$ldapContextFactory</value>
            </param>
            <param>
                <name>main.ldapRealm.contextFactory.url</name>
                <!-- ADJUST host, port for your AD setup-->
                <value>ldap://ad.client.com:389</value>
            </param>
            <param>
                <name>main.ldapRealm.contextFactory.authenticationMechanism</name>
                <value>simple</value>
            </param>
            <!-- Param below is ignored-->
            <param>
                <name>main.ldapRealm.userDnTemplate</name>
                <value>cn={0},ou=hadoop,ou=personal,ou=accounts,dc=ad,dc=client,dc=com</value>
            </param>
            <!-- Param above is ignored-->            
			<param>
				<name>main.ldapRealm.userSearchAttributeName</name>
				<value>sAMAccountName</value>
			</param>


			<param>
				<name>main.ldapRealm.userObjectClass</name>
				<value>person</value>
			</param>


			<param>
				<name>main.ldapRealm.contextFactory.systemUsername</name>
				<value>cn=hadoop_knox_id,ou=process,ou=accounts,dc=ad,dc=client,dc=com</value>
			</param>
			<param>
				<name>main.ldapRealm.contextFactory.systemPassword</name>
				<value>passwd_4_hadoop_knox_id</value>
			</param>
			
			<!-- search base used to search for user bind DN and groups -->
			<param>
				<name>main.ldapRealm.searchBase</name>
				<value>ou=personal,ou=accounts,dc=ad,dc=client,dc=com</value>
			</param>


			<!-- search base used to search for user bind DN.
				 Defaults to the value of main.ldapRealm.searchBase. 
				 If main.ldapRealm.userSearchAttributeName is defined, 
				 vlaue for main.ldapRealm.searchBase  or main.ldapRealm.userSearchBase 
				 should be defined -->
			<param>
				<name>main.ldapRealm.userSearchBase</name>
				<value>ou=personal,ou=accounts,dc=ad,dc=client,dc=com</value>
			</param>			


            <param>
                <name>urls./**</name>
                <value>authcBasic</value>
            </param>
        </provider>


        <provider>
            <role>identity-assertion</role>
            <name>Default</name>
            <enabled>true</enabled>
        </provider>

[#3]

Keep in mind that you can broaden the scope of the search by making the value of main.ldapRealm.userSearchBase to possible help with part 2 of the question. However, you need to be careful for two reasons:

1. Performance - The larger the base of the search the more entries that must be searched for the matching userSearchAttributeName.
2. Query Limits - In some LDAP implementation there are limits to how may entires a given query can return so too broad a userSearchBase may result in a failed queries causing authentication failures.