1) When constructing your context, use "follow", which makes it nice when you are using a forrest of domains (if thats the right term) for example:
env.put(Context.REFERRAL, "follow");
2) Get the DN from the userid. Here I assume sAMAccountName is used for userid.
SearchControls constraints = new SearchControls();
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
NamingEnumeration results =
ctx.search(organization_,
"(&(sAMAccountName=" + userId + "))",
constraints);
3) You should now how have the DN so you may do subsequent attribute lookups. Through normal JNDI calls. (I think)
I don't do much JNDI stuff, so I can't vouch that the above is in any manner correct. (But I hope it is)
-Tim
Robyne Vaughn wrote:
Tim, Thanks for your reply. I do mean attributes.
I don't know much about JNDI. (excuse me if I don't know the correct
wording).
I do have one little JNDI program which I copied and altered. It hits active directory with an authorized connection name and OU and etc. All of which are hard-coded. Then, I change context to another hardcoded name and OU and can get certain attributes with that info. If I don't specify an OU, I don't find what I'm looking for. The problem is that when a user logs in, I don't know what their OU is. Tomcat handles that for me. I don't know how to plug in the correct "path" in to a user's data. All I know is getRemoteUser and that 1 little piece of info isn't enough to find a user's attributes with. When I look in my logs, I can see what DN tomcat followed to authenticate my user. That hints to me that I ought to be able to extract the "path" (DN?) to use.
All I know about JNDI, I've found out in the last 2 weeks. If you have some coding examples you would care to share. I would greatly appreciate it. (I have seen the sun tutorial - it's incomplete where AD is concerned)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
