Here's what you can do. You can bind to ADAM as a Windows user, you do this
by using a secure bind type. Make sure the windows user has sufficient
rights to read ADAM objects. The simplest (but the most coarse) way to do
this is to add Authenticated Users or Domain Users as a member of ADAM's
Readers group.

Now, you can create an object in ADAM to store your user's data. You create
your own class in the schema with all required attributes. Now, you have to
link your AD user to your ADAM "user data" object somehow. One way is to use
some ADAM attribute as a key. For example, you create an octet string
attribute userSid, and put your AD user's sid there. Then, after you bind,
you get user's SID from the token and do a search in ADAM for
(userSid=sidValue). Make sure userSid is an indexed attribute.

UserProxy provides exactly this type of functionality. objectSid that is
written in the proxy object is the key pointing to an AD user. When you do a
proxy bind, you automatically have the "user data" object, it is your proxy.
You are free to extend the proxy class with your own attributes.

The downside of using userProxy is that it only supports simple ldap binds,
which are not secure. The password travels across the wire in clear text.
And this is your user's Windows password! By default, we require that proxy
bind is done on an encrypted connection (SSL or encrypted LDAP).

So, in general, we recommend that you implement your own "linking" and use
secure bind and authenticate as a windows principal. But I see that it is
way simpler for you to use userProxy, and many people actually use them for
this exact reason.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm