Ben Steeves wrote: > On 7/21/06, Per Kristiansen <perk at funcom.com> wrote: > >> I had hoped to let the people at HR do the data entry on the "soft" >> information , while the operations people do the "hard" information. > > If people are going to need access to just a few attributes, or you > need to apply business rules to the process before it hits the > directory, you're probably best off building your own interfaces (or a > framework on which to build multiple interfaces). In our case I built > a PERL module that our devs use to talk to the directory that > implements our directory organization principles, neatly abstracting > it out so that they don't have to worry about mundate directory > matters but can concentrate on the business rules and user interface. I like to think of LDAP as a building block toward creating an infrastructure. Think of it like an SQL database, if you are familiar with that - you can set it up, but the structure of the data, as well as permissions on who can do what with the data, is more or less external to the directory/db server. Creating a useful LDAP service, esp if you are integrating lots of end user services against it, is sometimes a bit of an art. You can write a custom interface in perl, java, etc - I prefer php, but that's just me (actually, php's LDAP api is pretty primitive, but php is simple to code in, and has just enough api to do most things you'll want)... Anyway, that lets me create an interface that looks exactly the way I want it to, covers all the components I have working against LDAP, allows me to apply business logic against it, etc. You can find prebuilt generic ldap browsers, but these tend to either not include business logic (see below), or aren't "aware" enough about apps you have (for example, if you are using samba, there may be certain restrictions of the values you put in ldap that a generic browser that just lets you edit fields doesn't know about). Interfaces that ARE aware of some apps you use tend to not know about others - i.e. you might find one that creates users for samba, but knows nothing about your other apps and how they use LDAP, so you may not get a single "complete" admin tool. ACI's in ldap can be used to restrict who can do what - i.e. an ops group that can create users, and HR group that can edit address, phone, etc info on existing users, etc. However, if you want to incorporate business logic (i.e. make uid's all lower case, restrict the state field to only upper case/valid US state abbreviations, etc), you have to have an admin tool that enforces this - there is nothing inherent in LDAP to do this. - Jeff
