Hi, I'm in an organization where we're thinking of deploying a department and role based OU structure. So depending on people's responsibilities one has limitations on their PC, or Account. However I notice that applications who use Ldap to verify credentials against Samba, have problems when people get moved around as logically their Ldap referral "cn= ou = ou- .. " changes. So the 'list of users' under ..\users\ gets split and scattered, over a new OU structure. Several applications have problems with this, as i noted with some test users. Applications like GLPI /NeXT cloud/ Kopano/ password tools/ inhouse db's/ etc So I wonder what is the common used practice here ?. 1- Simply don't use multiple OU's, if its not that well supported. Just use a common single domain policy only (only use \users and \computers). 2- Use some kind of wildcard Ldap url (possible?). Not sure if its a "common practice" method for application to use such a solution. 3- Try to solve it for each application independent, (contact vendors / dig up old DB code etc). 4- something else i might be missing ?
On 04/11/2020 09:28, Peter Boos via samba wrote:> Hi, > > I'm in an organization where we're thinking of deploying a department and role based OU structure. > So depending on people's responsibilities one has limitations on their PC, or Account. > > However I notice that applications who use Ldap to verify credentials against Samba, > have problems when people get moved around as logically their Ldap referral "cn= ou = ou- .. " changes. > So the 'list of users' under ..\users\ gets split and scattered, over a new OU structure. > > Several applications have problems with this, as i noted with some test users. > Applications like GLPI /NeXT cloud/ Kopano/ password tools/ inhouse db's/ etc > > So I wonder what is the common used practice here ?. > > 1- Simply don't use multiple OU's, if its not that well supported. > Just use a common single domain policy only (only use \users and \computers). > 2- Use some kind of wildcard Ldap url (possible?). > Not sure if its a "common practice" method for application to use such a solution. > 3- Try to solve it for each application independent, (contact vendors / dig up old DB code etc). > 4- something else i might be missing ?The problem with using OU's, is that a user can only be in one OU, so what if the user needs to be in more than one ? I would rely on group membership instead. Rowland
> The problem with using OU's, is that a user can only be in one OU, so > what if the user needs to be in more than one ? > > I would rely on group membership instead. >Yes, but this is really just a thing to thing about and howto layer you GPO's. And as Rowland said use groups whereever you can. It does make things way better to maintain. Read these before you "just" deploy things.. https://social.technet.microsoft.com/wiki/contents/articles/52587.active-directory-design-considerations-and-best-practices.aspx https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning Greetz, Louis
My organization has several next cloud instances running with users in different ou's without any issue On Wed., Nov. 4, 2020, 2:39 a.m. L.P.H. van Belle via samba, < samba at lists.samba.org> wrote:> > The problem with using OU's, is that a user can only be in one OU, so > > what if the user needs to be in more than one ? > > > > I would rely on group membership instead. > > > > Yes, but this is really just a thing to thing about and howto layer you > GPO's. > > And as Rowland said use groups whereever you can. > It does make things way better to maintain. > > Read these before you "just" deploy things.. > > https://social.technet.microsoft.com/wiki/contents/articles/52587.active-directory-design-considerations-and-best-practices.aspx > > > https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning > > > Greetz, > > Louis > > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >