The InetOrgPerson object is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization.

The object class definition is considered an extension to LDAPv3 and, as such, is not included in the RFC 3377 LDAPv3 specifications.

Microsoft released the Windows 2000 inetOrgPerson Kit. The kit, which is freely available, derives inetOrgPerson from the user class within Active Directory’s schema.

Windows Server 2003 Active Directory schema includes the full definition and provides complete manageability of RFC 2798 and the inetOrgPerson LDAP Object Class.

ONE VERY IMPORTANT ITEM

you will need the :
.Net Universal LDAP Connector Documentation
http://www.novell.com/coolsolutions/tools/14274.html

to connect any .Net programming to a remote NDS eDirectory

To access the properties and methods of an object, you need to bind to it.
This creates a reference to the object.
ldapsearch -D “uid=jaaron, ou=People, o=MySite.com” -w “Irrefutable” -b “” -s base “objectclass=*” dn

and then the object should bind and authenticate

[LDAP article binding to Active Directory] [ LDAP binding to Novell LDAP Server]

Depending on your ACL privileges, you will be able to access “downtree”

Access control lists

Access control lists (ACLs) provide a means to protect information stored in a LDAP directory. Administrators use ACLs to restrict access to different portions of the directory, or specific directory entries. Changes to each entry and attribute in the directory can be controlled by using ACLs. An ACL for a given entry or attribute can be inherited from its parent entry or can be explicitly defined.

It is best to design your access control strategy by creating groups of users that you will use when setting the access for objects and attributes. Set ownership and access at the highest level in the tree possible and let the controls inherit down the tree.

heres an interesting project for Single Sign On

LDIF reference here

I use LDAP Browser Editor for all my LDAP exploration

LDAP book reference
An LDAP URL format exists which clients support in varying degree, and which servers return in referrals and continuation references (see RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

Most of the components, which are described below, are optional.

• host is the DNS or IP address of the LDAP server to search.
• port is the network port of the LDAP server.
• DN is the distinguished name to use as the search base.
• attributes is a comma-separated list of attributes to retrieve.
• scope specifies the search scope and can be “base” (the default), “one” or “sub”.
• filter is a search filter, e.g. (objectClass=*) (see RFC 4515).
• extensions are extensions to the LDAP URL format.

For example, “ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com” refers to all user attributes in John Doe’s entry in ldap.example.com, while “ldap:///dc=example,dc=com??sub?(givenName=John)” searches for the entry in the default server. As in other URLs, special characters must be percent-encoded.

There is a similar non-standard “ldaps:” URL scheme for LDAP over SSL.

heres a schema study as viewed in the ScopePane:

ou= MYGROUP ( remember ou is Organization Unit )
|—- cn=jaaronUniqueIdentifier (remember cn is Common Name)
|—- mail=myemailaddress @ mydomain.com
*** the schema consists of jagged data parameters for this objectClass

LDAP provides for a complex level of access control instances, or ACIs. Because the access can be controlled on the server side, it’s much more secure than security methods that work by securing data through client software.

With LDAP ACIs, you can do things like:

• Grant users the ability to change their home phone number and home address, while restricting them to read-only access for other data types (such as job title or manager’s login).
• Grant anyone in the group “HR-admins” the ability to modify any user’s information for the following fields: manager, job title, employee ID number, department name, and department number. There would be no write permission to other fields.
• Deny read access to anyone attempting to query LDAP for a user’s password, while still allowing a user to change his or her own password.
• Grant managers read-only permission for the home phone numbers of their direct reports, while denying this privilege to anyone else.
• Grant anyone in the group “host-admins” to create, delete, and edit all aspects of host information stored in LDAP.
• Via a Web page, allow people in “foobar-sales” to selectively grant or deny themselves read access to subsets of the customer contact database. This would, in turn, allow these individuals to download the customer contact information to their local laptops or to a PDA. (This will be most useful if your sales force automation tool is LDAP-aware.)
• Via a Web page, allow any group owner to add or remove any entries from groups they own. For example, this would allow sales managers to grant or remove access for salespeople to modify Web pages. This would allow owners of mail aliases to add and remove users without having to contact IT. Mailing lists designated as “public” could allow users to add or remove themselves (but only themselves) to or from those mail aliases. Restrictions can also be based on IP address or hostname. For example, fields can be made readable only if the user’s IP address begins with 192.168.200.*, or if the user’s reverse DNS hostname maps to *.foobar.com.

Because your LDAP directory can be customized to store any type of text or binary data, what you store is really up to you. LDAP directories use the concept of object classes to define which attributes are allowed for objects of any given type. In almost every LDAP implementation, you’ll want to extend the basic functionality of your LDAP directory to meet your specific needs, either by creating new object classes or by extending existing ones.LDAP directories store all information for a given record’s entries as a series of attribute pairs, each one consisting of an attribute type and an attribute value. (This is completely different from the way relational database servers store data, in columns and rows.) Consider this portion of my student record, as stored in an LDAP directory:

dn: cn=My University, ou=student, dc=MyWebsite, dc=com
cn: My University Student Info
studentMajor: art
studentClass: 1 nude drawing class
studentClass: 1 paper-sculpture class
studentClass: 1 painting class