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? > 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. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
