Getting to Know ADAM

ADAM supports authentication by AD through a proxy object and bind redirection. With this method of authentication, users use their domain credentials to sign on to ADAM with a DN. This method of authentication lets you build directories that support applications for users who have AD accounts and for external users who have ADAM accounts. Duplicating user objects in ADAM for users who have accounts in AD raises management concerns and problems with keeping the objects synchronized. To use the ADAM proxy object, you need to import the MS-UserProxy LDIF file and the ADAM server must be a member server in a domain. Users represented in ADAM by proxy objects must have their objectSID attribute in the UserProxy class set to the value of their SID in AD.

ADAM defines four default roles that ADAM instances use as broad authorization controls. Roles are implemented as group objects in ADAM. The predefined roles are Administrators, Readers, Users, and Instances. For a user to hold a role, the user must be added to the role object's multivalued member attribute through the ADSI Edit snap-in, the ldp.exe tool, or programmatically. Roles are limited in scope to partitions and, along with other objects in the directory, are replicated between instances of ADAM in a configuration set. Administrators have full administrative access to an ADAM instance, Readers can view any object in a partition, and Users have only the permissions afforded to them through ACLs. Instances is a largely undocumented role. . . .