"Jimmy Liang" <[EMAIL PROTECTED]> writes:

> Hi,
>
> Similar to a lot of previous threads, I too am trying to setup an internal
> directory lookup of staff. My initial thought was to use an LDAP server for
> this, whether it be openLDAP, Sun’s Directory server, Microsoft ADAM, or
> whatever. I’ve ran into some issues and am now wondering if using a LDAP
> server was the correct road to go down. Any comments and suggestions on the
> following would be greatly appreciated.
>
> -          One of the main driving forces is to have a web accessible client.
> We’ve found Novell’s eGuide to be a pretty good tool, however, the inability
> to find competitive products lead me to think that the demand in this area is
> low, or that everyone must just write their own?

There are quite a lot java based applications available, running in
tomcat or similar, or write yyour own in java.

> -          We’re doing an initial load of data from a CSV file dumped from our
> HR system. The on-going maintenance portion is what we’re having a problem
> with. Again, the lack of products that does LDAP management is surprising.
> Tech savvy people can use phpLDAPAdmin, but what of the non-tech HR people?
> We’re not planning to allow self updates, just reads.

Most LDAP vendors provide there own administration frontend, or use
ApacheDirectoryStudio or penrose-studio.

> -          We’re also trying to have a printable report of everyone in the
> directory, sort of like a hard-copy phone list. Does anyone have a suggestion
> on how that can be accomplished?

dump the relevant entries and attributes into DSML and proceed
with XSL-FO. 

> -          Lastly, there doesn’t seem to be a standard as to which attribute
> stores which data. Should I be using portalAddress for the full address, or
> separate it out and list the street, city, and st separately? There is also
> some subtle difference between different LDAP servers, like in the Sun One
> Directory server; the telephoneNumber attribute is multi-valued, whereas in
> the Microsoft ADAM server, it only accept a single value.

The standard is RFC 2798 (InetOrgPerson) and RFC 4519 (User
Applications). The attribute type telephoneNumber is decribed in RFC
4519 (2.35) which is not declared to be SINGLE-VALUE, thus it has to
be multi-valued. Any directory server not providing a rfc compliant
attribute type is not protocol compliant.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6


---
You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the 
SUBJECT of the message.

Reply via email to