If you get to the point of punting, the following method will authenticate
against AD. It relies on nothing but the user's ID and PW. You will need to
download spring's LDAP to use it.
If you write a custom Authenticator (very easy task), you can make it call this
method for the actual authentication step.
And of course, you can test this method independently of CAS, to make sure you
got it right.
private static final String ATTRIBUTE_FOR_USER = "sAMAccountName";
String returnedAtts[] = null; // Null returns all info. Use only to
find out which fields are available.
private String domain = "ntDomain.company.com";
private String adHost = "adServer.ntDomain.company.com";
private String adPort = "389";
private String dn =
"DC=ntDomain,DC=company,DC=com";
public Attributes authenticate(String username, String password) {
Attributes attrs = null;
String searchFilter = "(&(objectClass=user)(" + ATTRIBUTE_FOR_USER +
"=" + username + "))";
SearchControls searchCtls = new SearchControls();
searchCtls.setReturningAttributes(returnedAtts);
searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
String searchBase = dn;
Hashtable<String, String> environment = new Hashtable<String, String>();
environment.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
environment.put(Context.PROVIDER_URL, "ldap://"; + adHost + ":"+adPort);
environment.put(Context.SECURITY_AUTHENTICATION, "simple");
environment.put(Context.SECURITY_PRINCIPAL, username + "@" + domain);
environment.put(Context.SECURITY_CREDENTIALS, password);
LdapContext ctxGC = null;
try {
ctxGC = new InitialLdapContext(environment, null);
NamingEnumeration<SearchResult> answer =
ctxGC.search(searchBase, searchFilter, searchCtls);
while (answer.hasMoreElements())
{
SearchResult sr = (SearchResult)answer.next();
attrs = sr.getAttributes();
if(attrs != null){
return attrs;
}
}
}catch(AuthenticationException e) {
Logger.getLogger(this.getClass().getName()).debug(
"Authentication failure: username="+username);
return null;
}catch(NamingException e){
Logger.getLogger(this.getClass().getName()).error("LDAP
Authentication Error: ", e);
}
return attrs;
}
-----Original Message-----
From: Michael J. Barton [mailto:[email protected]]
Sent: Thursday, May 28, 2009 9:38 AM
To: [email protected]
Subject: RE: [cas-user] Problem authenticating with CAS to Active Directory
I agree with David. If you have an AD sys admin, check with them.
Active Directory typically uses the unicodePwd attribute for storing its
passwords and my (limited) understanding of AD is that the attribute is not
easily settable via standard LDAP tools.
http://msdn.microsoft.com/en-us/library/cc223248(PROT.13).aspx
Have you tried using the Active Directory Users and Computers (ADUC) to
manually reset one of your CAS users passwords and then see if you can
authenticate via CAS? I suspect you will as ADUC will set the "right" password
attribute in AD.
If you don't have access to ADUC, you can download the admod utility,
http://www.joeware.net/freetools/
And execute the command,
admod -b "<userDN>" unicodepwd::<newpassword> -kerbenc
to set the unicodepwd attribute for one of your CAS user accounts and then test.
There may be other variables at play, what version of AD (2003, 2008, ADAM),
what schema extensions, etc.
Based on the attributes you listed, it appears the AD schema has been extended
to include eduPerson attributes. I don't know whether this affects how AD
stores passwords or not (I kind of doubt it).
Don't know if any of this will be useful, but I thought I'd pass it along.
-----Original Message-----
From: David Whitehurst [mailto:[email protected]]
Sent: Thursday, May 28, 2009 9:50 AM
To: [email protected]
Subject: Re: [cas-user] Problem authenticating with CAS to Active Directory
E.g. my login user on the Microsoft network is dlwhitehurst . When I
use "dlwhitehurst" in the CAS login, it's ultimately passed to AD as
the sAMAccountName=%u
Also, if you have an expert for AD, it would be beneficial to work
together with that individual.
David
On Thu, May 28, 2009 at 8:34 AM, Michael A Jones <[email protected]> wrote:
> Hi there,
>
> I think I might have tracked down the cause of my problems with CAS and
> AD. The connection context side is ok now. I am using a bind security
> context with a service account. It looks like an issue now with user
> attributes being populated to AD from my IDM system, so it's not
> necessarily a CAS issue anymore. Worth reporting though I think.
> I need some help tracking down which attributes I should be using. From
> IDM I am populating the following in AD:
>
> givenName
> sn
> title
> eduPersonAfilliation
> eduPersonCourseName
> mail
> userPassword
> cn
>
> I am populating the cn and assumed this would be the userid to be used
> for CAS and the userPassword, as the password in CAS. However this isn't
> the case. I created a test user from the AD console and this user is
> authenticating ok in CAS. For this user the userid is a concatenation of
> the firstname then initials then a period/fullstop and then the
> lastname. Then the password is the password that I set in the AD console
> user creation wizard.
>
> This combination works ok for this user. I have tried the same format of
> login credentials for my other users, but not getting any success. It
> seems the Username or Password or both not being populated in the same
> way based on my attributes by my IDM system. I am quite new to AD in
> general so I am not sure where to start as yet on investigating this
> issue.
>
> Comments appreciated.
>
> 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: 27 May 2009 15:14
> To: [email protected]
> Subject: Re: [cas-user] Problem authenticating with CAS to Active
> Directory
>
> Again, I believe it would be helpful to clarify a few things:
>
> - Administrator is a service account in this case. (It is by all
> measures a poor choice, but meets the criteria.)
> - The username/password properties in your contextSource bean are
> _not used_ with the fast bind handler.
> - If you need to use a service account to search for users, you need
> to use BindLdapAuthenticationHandler.
>
> If all the users you wish to authenticate have DNs like
> [email protected],OU=Identities,DC=ExampleOrganization,DC=local,
> then you should be able to use FastBindLdapAuthenticationHandler as
> follows:
>
> <bean
> class="org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler"
>>
> <property
> name="filter"
> value="cn=%u,ou=Identities,dc=ExampleOrganization,dc=local" />
> <property name="contextSource" ref="contextSource" />
> </bean>
>
> <bean id="contextSource"
>
> class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">
> <property name="urls">
> <list>
> <value>ldap://198.168.0.1</value>
> </list>
> </property>
> <property name="baseEnvironmentProperties">
> <map>
> <entry key=java.naming.security.authentication" value="simple" />
> </map>
> </property>
> </bean>
>
> (Note org.springframework.ldap.core.support.LdapContextSource replaces
> org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource as of
> CAS 3.3.2.)
>
> Assuming [email protected] is a valid CN, you should be able to
> authenticate with that username.
>
> Testing with LDP is the way to go. If you can bind with a DN in LDP,
> the same settings will work in CAS. Spend your time testing with LDP
> until you get a DN/password pair that works, then come back to CAS and
> test.
>
> 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
> *****************************************************************************************
> 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
--
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
