thanks for the info. I have been using the AD wizard to set the password for my users and have got them to authenticate fine now with CAS. I will also give your command for unicodePwd a go. What I want to do really is to set this password with my identity manager, but I am having problems. It is something I think to do with the SSL settings somewhere and I am trying to seek advice off the appropreate forums. I might have to resort to writing my own code to do this, so will search out and try any LDAP/AD examples I find.
-----Original Message----- From: Michael J. Barton [mailto:[email protected]] Sent: Fri 05/06/2009 14:23 To: [email protected] Subject: RE: [cas-user] Problem authenticating with CAS to Active Directory My understanding is that when doing authentication against Active Directory, that it is using the unicodePwd attribute that is used as the password. In Active Directory, unicodePwd is a write-only attribute (as I suspect userPassword is as well) which is why it appears "unset". I'm also to understand that you cannot query whether the unicodePwd attribute even exists for a user since the attribute is not readable. You can confirm that unicodePwd will set the password by using the admod command: the admod utility, http://www.joeware.net/freetools/ And execute the command, admod -b "<userDN>" unicodepwd::<newpassword> -kerbenc After running the command above on a newly created account, I was able to authenticate via CAS using the new password. The pwdLastSet attribute is a large integer (8 bytes) which represents the number of 100 nanosecond intervals since 1 January 1601. According to Microsoft, http://msdn.microsoft.com/en-us/library/ms679430(VS.85).aspx , if the account is not set to "Don't Expire Password" and the value is 0, then the user must set the password on next logon. I'm by no means an Active Directory expert, but the information above has served me well. I have example C# code snippets for creating/managing AD accounts which I'm willing to share if that would be useful to you. Googling I've seen examples of AD account/password management, using ldapmodify (with varying degrees of success), but I've never tried any of those examples. Hope this sheds some light on things. -Michael From: Michael A Jones [mailto:[email protected]] Sent: Wednesday, June 03, 2009 7:53 AM To: [email protected]; [email protected] Subject: RE: [cas-user] Problem authenticating with CAS to Active Directory Hi there, I have now got my CAS to authenticate with AD. I got it to work using the "cn" attribute as the CAS userid and in order to login successfully, I must also reset the pasword using the wizard in the AD snapin. It appears once this is done an atribute called pwdLastSet is updated. Initially this is set to 0 for my users and then it is updated with a long string of numbers. The attributes userPassword and unicodePassword remain unset. Can someone comment as to what password attribute CAS is using, as it doesn't appear to be userPassword or unicodePassword. What is this pwdLastSet? I am using for reference AD 2003. Regards Mike -----Original Message----- From: Michael J. Barton [mailto:[email protected]] Sent: Thu 28/05/2009 15:38 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
<<winmail.dat>>
***************************************************************************************** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *****************************************************************************************
