Carl, Yesterday I had a clear distinction between the 3.4.2.1 successful login and the 3.5.2.1 failure. I did not it make the attempt for 3.4.2.1 and did not see it in 3.5.2.1. It simply came back with the expired notice.
I am in the process of rebuilding TEST to 3.4.2.1 (including tables for registry). I won't be able to diagnose more of these issues on DEV until that is complete - at which time I can provide better details. Thanks for taking time to respond. I greatly appreciate it. Linda Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 Fairbanks, Alaska 99775 Tel: 907-450-8320 Fax: 907-450-8381 [email protected] | www.alaska.edu/oit/ On Mon, Feb 2, 2015 at 9:33 AM, Waldbieser, Carl <[email protected]> wrote: > Linda, > > Is there any indication (e.g. from proxy logs) that the accounts that are > failing over are actually making requests against the proxy? In other > words, do you have any indication whether the issue is that the fail over > requests are never being made or that the requests are being made but > failing to authenticate? > > Thanks, > Carl Waldbieser > ITS Systems Programmer > Lafayette College > > ----- Original Message ----- > From: "Linda Toth" <[email protected]> > To: [email protected] > Sent: Monday, February 2, 2015 1:04:40 PM > Subject: [cas-user] 3.4.2.1 to 3.5.2.1 in deployerConfigContext.xml > > Good morning, > > FYI - I am aware I need to promote to 3.5.3, but first things first. > > I forwarded this question to our support organizations for CAS and they > have not come up with any explanation yet. I am hoping someone here has > some insight. > > I have not changed the deployerConfigContext.xml file from 3.4.2.1 to > 3.5.2.1. I looked over the distribution, but opted to try it as is. Our > deployerConfigContext.xml file contains a component that allows expired and > new users to fall through to an active directory proxy when they fail to be > authenticated via straight AD LDAP. Our policies at UA expire students > very quickly on some campuses so that they can not use the PC work > stations. This causes issues when they come back to register for the next > semester. > > In 3.4.2.1, I developed a nice configuration that will allow authentication > through one or the other. 3.5.2.1, it only authenticates users that are > not expired, i.e., it is not failing over. > > I have extracted the pertinent sections and placed them in a file, > attached. It is a simple text file. One thing I did not do that may cause > problems is that I did not denote a separate attributeRepository bean. > They are identical for both straight AD and the proxy. Perhaps I should > replicate them with a different name. > > If anyone can pinpoint a modification I should make to accommodate 3.5.2.1 > quickly, I would greatly appreciate it. I very much want to move toward > two-factor authentication and Casifying Shib, but need 3.5.2.1 to do that. > > > Linda Toth > University of Alaska - Office of Information Technology (OIT) - Identity > and Access Management > 910 Yukon Drive, Suite 103 > Fairbanks, Alaska 99775 > Tel: 907-450-8320 > Fax: 907-450-8381 > [email protected] | www.alaska.edu/oit/ > > -- > 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
