[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-ldap-dev
Subject:    Re: managing AD users through Net::LDAP
From:       Guillaume Rousse <Guillaume.Rousse () inria ! fr>
Date:       2008-10-08 16:12:27
Message-ID: 48ECDBEB.5030703 () inria ! fr
[Download RAW message or body]

Peter Karman a écrit :
> Guillaume Rousse wrote on 10/07/2008 04:08 AM:
>> Hello list.
>>
>> Thanks to archives of this ML, as well as source code from
>> Net::LDAP::Class::User::AD package, I'm able to create functional AD
>> user entries from Net::LDAP. 
> 
> Any particular reason you didn't just use Net::LDAP::Class::User::AD
> directly?
Mainly because I'm mostly investigating the issue currently, and I need 
to understand everything happening behind the cover if I want to 
convince my colleagues to drop their mixed perl-VB import procedure :)

Once I get a prototype, I may eventually switch to Net::LDAP::Class, but 
  I'm trying to keep our two sync scripts (ldap -> ldap, ldap -> ad) 
parallel, and this would make me convert the other one also. I'm not 
decided yet.

>> Third, is there a recommended practice for organising user and group
>> entries in AD ? In OpenLDAP world, the standard practice is to have a
>> 'user' and a 'group' branch, whereas AD setup I saw sofar had a more
>> subdivised organisation (one branch per group, for instance).
>>
> 
> I don't know of recommended practices; I can, however, speak to how
> Net::LDAP::Class::User::AD does it and how we do it at $work, which are
> different (despite the fact that I wrote Net::LDAP::Class).
> 
> NLCUA assumes you are using the primaryGroupID attribute in AD, since
> that attribute is required for Unix compatability even though AD doesn't
> itself use it. In other words, the Net::LDAP::Class basic API assumes
> every user has a primary group and so the AD classes implement that API.
>  AD has Security Groups which can be used like OpenLDAP groups, and that
> is what Net::LDAP::Class::Group::AD assumes.
> 
> However, at $work we use OrgUnits with AD in a way analogous to how
> OpenLDAP uses primary groups. We use Security Groups in AD to control
> which resources a a User has access to (e.g., we have just a few
> Security Groups, while we have 100s of OrgUnits). I actually have a
> Net::LDAP::Class-derived class for OrgUnit and each User class uses a
> OrgUnit class as its primary group.
> 
> I think the $work approach succeeds because of our particular security
> requirements. I hope that Net::LDAP::Class::*::AD can also work for
> folks implementing Unix-style organization for their AD server.
OK, thanks for the explanation. I'll go the for OU-based organisation, 
then.


-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
[prev in list] [next in list] [prev in thread] [next in thread]