Michael:
Do you use a service account to establish a secure LDAPS connection
first and then authenticate for each user? I was never able to
authenticate to Microsoft AD unless I connected first with a service
account.
I use the service account to establish the context first. This is
done when the application deploys. The second bean you see tries the
authentication for the CAS user.
<bean id="contextSource"
class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">
<property name="urls">
<list>
<value>ldaps://dotdc1p.dotp.ncp.net/</value>
</list>
</property>
<property name="userName" value="CN=Service
jboss,OU=Service Accounts,DC=dotp,DC=ncp,DC=net"/>
<property name="password" value="aSecretPasswordHere"/>
<property name="baseEnvironmentProperties">
<map>
<entry>
<key>
<value>java.naming.security.authentication</value>
</key>
<value>simple</value>
</entry>
</map>
</property>
</bean>
<bean id="authenticationManager"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
<property name="credentialsToPrincipalResolvers">
<list>
<bean
class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver"
/>
<bean
class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver"
/>
</list>
</property>
<property name="authenticationHandlers">
<list>
<bean
class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler">
<property name="contextSource" ref="contextSource"/>
<property name="filter" value="sAMAccountName=%u"/>
<property name="searchBase"
value="OU=ts,OU=it,DC=dotp,DC=ncp,DC=net"/>
<property name="ignorePartialResultException"
value="yes" />
<property name="allowMultipleAccounts" value="yes" />
</bean>
</list>
</property>
</bean>
David
On Tue, May 26, 2009 at 11:57 AM, Michael A Jones <[email protected]> wrote:
> I have adjusted the log level in ad a bit and I am getting this error:
>
> Internal event: The LDAP server returned an error.
>
> Additional Data
> Error value:
> 0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best
> match of:
> 'CN=Dfs-Configuration,CN=System,DC=ExampleOrganization,DC=local'
>
> Regards
>
> Mike Jones
>
> Identity Management Systems Administrator
> IT Systems
> University of Hull
>
> Tel: 01482 465549
> Email: [email protected]
>
>
> -----Original Message-----
> From: Michael A Jones [mailto:[email protected]]
> Sent: 26 May 2009 16:12
> To: [email protected]
> Subject: RE: [cas-user] Problem authenticating with CAS to Active
> Directory
>
> Thanks for getting back. I'm not sure that is a bad password, as I don't
> specifically get the bad username and password message as part of the
> 52e error. I think it's a general credentials issue somewhere with both
> the username and password being invalid. I have so far used cn=%u and
> sAMAccountname=%u, making sure these attributes are populated in AD, but
> still no luck. I haven't tried the standard uid, as the CAS setup
> doesn't suggest using this for AD.
>
> I'm at a bit of a loss to be honest. Is there any way of finding out
> what credentials it is expecting? I have tried to bind to AD using the
> LDP viewer and it gives the same error. Therefore it's something I think
> to do with the LDAP query being sent by CAS. The DN somewhere must be
> wrong in my config, but I'm not sure what it wants to correct his?
>
> Regards
>
> Mike Jones
>
> Identity Management Systems Administrator IT Systems University of Hull
>
> Tel: 01482 465549
> Email: [email protected]
>
>
> -----Original Message-----
> From: Michael J. Barton [mailto:[email protected]]
> Sent: 26 May 2009 14:29
> To: [email protected]
> Subject: RE: [cas-user] Problem authenticating with CAS to Active
> Directory
>
> Michael,
>
> For what it is worth, the link below suggests that 52e is a "bad
> password"
> error.
>
> http://wiki.caballe.cat/index.php/Active_Directory_LDAP_Errors
>
> We have been using Active Directory (via LDAP) as our CAS authentication
> source for a couple of years now. Recently we had a user that was
> unable to authenticate. It was determined (by trial and error) that she
> had a crosshatch "#" in her password. Once she eliminated the "#" from
> her password she was able to login via CAS. The "#" should not be an
> issue with AD passwords, but I haven't had time to determine whether the
> "#" was really the issue or was simply coincidental.
>
> I looked over the snippet of your deployerContextConfig.xml and it looks
> similar to ours, with the exceptions that we use SSL when talking to our
> domain controllers and since we populate the uid attribute we use uid=%u
> as our filter.
>
> -Michael
>
>
> -----Original Message-----
> From: Michael A Jones [mailto:[email protected]]
> Sent: Tuesday, May 26, 2009 8:23 AM
> To: [email protected]
> Subject: RE: [cas-user] Problem authenticating with CAS to Active
> Directory
>
> Hi there,
>
> Thanks for the advice. I have set my filter to cn=%u abd turned on
> logging.
> The error being thrown up is:
>
> Internal event: The LDAP server returned an error.
>
> Additional Data
> Error value:
> 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error,
> data 52e, vece
>
> This apparently suggests invalid credentials being passed to AD. Not
> sure where to go from here. I have been using my cn value as the login
> username in CAS.
>
> Regards
>
> Mike Jones
>
> Identity Management Systems Administrator IT Systems University of Hull
>
> Tel: 01482 465549
> Email: [email protected]
>
>
> -----Original Message-----
> From: Marvin Addison [mailto:[email protected]]
> Sent: 22 May 2009 14:56
> To: [email protected]
> Subject: Re: [cas-user] Problem authenticating with CAS to Active
> Directory
>
> 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
> --
> 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
> --
> 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
> --
> 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
> *****************************************************************************************
> To view the terms under which this email is distributed, please go to
> http://www.hull.ac.uk/legal/email_disclaimer.html
> *****************************************************************************************
>
--
David L. Whitehurst
http://www.capehenrytech.com … Providing software instruction through
a sea of Technology.
--
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
