After configuring a SunOne LDAP connector (see attached pdf of config) without errors, I'm not able to get results back from known users in the ldap directory using the Crowd Principals Browser Username search form. I just get no results for known users. I've checked the slapd logs, and I can get a single result back (as expected) from the query run at the command line:

base="ou=people,dc=foo,dc=bar"
filter="(&(objectClass=inetorgperson)(brownShortID=snoopy))"

But no results come back from the Crowd search.

As a side bar, I'm a bit puzzled as to why the application is trying the wildcard search on a username. Adjusting indexes solved initial problems we had with query performance, but it's not ideal for us to be indexing for substring in production.

Complicating matters, I also get no results from the group search on known group names. I've checked that the fields defined in the config page match the names in the schema, but to date, we have yet to be able to map Crowd to our ldap schema for populating users or groups.Ut;s worth noting that we don't have roles in our ldap schema at all. Another observation is that in our configuration, we don't store user password in LDAP; it's plugged into SunOne via Kerberos; but the config page seems to assume we have a password field value. I'm suspicious that there's a config problem relating to one or more of these areas, but not sure where debug next.

What resources are there for debugging configuration problems in Crowd? All the documentation seems to be flowers and bunny rabbits-happy path scenarios-not troubleshooting information for the problems we're seeing. Maybe someone on the technical side can set our expectations for Crowd...there's been misuse of the terms dynamic groups and nested groups in the existing support documentation, and the current Crowd offering is, as one would expect this early in a product's life cycle, a bit short on practical documentation in this area. If we had a technical overview of what configurations are supported with respect to nested groups and dynamic groups and forward references, we'd better understand how to configure our environments. How does Crowd define it's group abstraction layer? Do we need to have groups defined with a forward reference ("memberOf" attribute values on principals)? Or can we search for groups in a highly nested group schema and find groups hanging way out on a branch?

the way I imagine using Crowd is to abstract our highly nested LDAP group schema to a flat schema that Confluence, et. al. can work with. But I'm not at all clear that this is what is intended, nor am I sure that we have a schema that will be supported by the Crowd's founding assumptions. If this is the purpose of Crowd, what are the key operative configuration elements that provide the mapping from a nested LDAP schema?

Thanks!

James