none
Base DN for LDAP

    Question

  • Hi All, 

    I'm looking for some advice on how Base DN targeting works. 

    I'm researching an appliance product that allows you to add an authentication provider to authenticate users to a service provided by that appliance. In this case I am adding Active Directory via LDAP as an authentication provider.

    I would like to set a Base DN to target a set of groups within an OU down the AD tree and when I do this, the appliance finds the groups and I can add these group within the appliance to provision access to the service.

    Lets say I have a domain called contoso.local with a structure like this;

    contoso.com

    • Accounts

           - Users

           - Admins

    • Groups

           - Application

           - Email

    In this case, I've set my Base DN is ou=application,ou=groups,dc=contoso,dc=com

    The appliance finds the groups within the OU and I can assign a group, say Group1 to access the service provided by the appliance. If I add users to this group however from the Users OU, the appliance can't authenticate them as they do not exist under the Base DN root structure. 

    To my mind, if they are a member of a group I have added and applied permission to within the appliance then it should be able to authenticate them but I'm being told this is not possible. 

    I'm clearly a little rusty on this, but does that sound correct and if so, what are the alternatives? To set the base DN as dc=contoso,dc=com or move other OUs around? How else could I lock this down? 

    Thanks in advance! 


    • Edited by ms1316 Friday, July 13, 2018 2:32 PM
    Friday, July 13, 2018 2:23 PM

All replies

  • The base looks correct for finding the group. You should then be able to retrieve the memberOf attribute of the group, a collection of the distinguishedNames of all direct members of the group. At that point, no search is required, so the base shouldn't matter. I would think the appliance could authenticate using the distinguishedNames. I don't know how the appliance works, or if you can modify the code to enumerate the memberOf attribute of the group.

    If the appliance works as intended with the base set to the DN of the domain, then that shouldn't affect performance much. As long as the scope of the search is subTree (probably the default), both the group and the members should be found. I would never modify the OU structure to accommodate an app.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Friday, July 13, 2018 3:32 PM
  • Not sure how this particular appliance works, but in my experience, most appliances using LDAP in this way will safely work with the Base DN pointing to the domain root, as they can search the entire subtree and will find both your groups and your users in this case.
    Friday, July 13, 2018 5:50 PM
  • Thanks Richard, 

    The easy fix here is to set the Base DN to the domain root, however this means the appliance service account will enumerate all objects accross the entire domain, which isn't itself an issue but I would prefer to have it targated to the group and therefore the members I set.

    I think you've made the point I was looking for; that the appliance should be able to enumerate and authenticate on the distinguishedName value from group membeship, so long as the LDAP account has access to read the referenced users OU and the Base DN does not prevent this from happening.

    I suppose the next question is how they are authenticating and why this might not work as I believe.

    Many thanks... 

    Monday, July 16, 2018 8:43 AM