I notice the unsecure port in the code above "389". I would be careful communicating with AD using LDAP unsecure because you compromise the entire directory by allowing non-SSL communications with the credentials store of all your Microsoft user base.
Just my 2 cents David On Thu, May 28, 2009 at 11:16 AM, Bruno Melloni <[email protected]> wrote: > 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 > -- 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
