I don't think I've ever looked at an AD LDIF, so sAMAccountName may be obfuscated, but it's clearly not what you're using for the test principal:
> [email protected] ... > cn: [email protected] > sAMAccountName: $Z21000-CA6B2SF9KI You might try a filter of cn=%u just for kicks, since the cn clearly has the correct value of the principal you're testing with. As with any sort of authentication problem, the most helpful place to look for clues is in the authentication provider logs, AD in this case. I won't even attempt a suggestion for how to turn up logging or where to look, but I'm sure you can figure that out. If you can get some good log output showing the failed auth attempt, post that here. Once you get this working, I would strongly recommend creating a low-privileged user that is used for the bind attempt used to search for the DN of the authenticating user. (Recall BindLdapAuthenticationHandler uses a 2-step authentication process; initial bind and search for DN, then bind as DN using supplied password credential.) You can avoid disclosing any passwords in the clear by using FastBindLdapAuthenticationHandler if all your users live immediately under one branch, e.g. ou=Identities. Hope that helps, M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
