I updated the user profile associated with my CAC in remedy. I simply added some permissions.
Upon re-opening the web browser, i'm getting authentication failed again. Any ideas what could be going on?
Here's some additional info... It seems to be a coincidence that after modifying my CTM:People record that I was unable to get in. Here's why:
I went back a few steps and removed the J2EE agent from the BMC Realm. I then invalidated any active CAC sessions and removed my user from the subjects tab.
I then readded the J2EE agent under the BMCRealm and in the same browser session I opened the mid-tier in a new tab. I was able to get authenticated. Upon further inspection, it was not my user that was authenticated. the name after "welcome," is 'test' which does not exist on my system. I do however have "Allow guest users" set
If I close the browser and re-open it, I go back to the authentication failed message from ARS and nobody can get in; guest or otherwise.
So all in all I thought we had it working but there are some strange things going on here.
At this point, it sounds like you have the SSO server and mid-tier are properly setup and integrated. The problem is in the AR configuration.
If the error you are seeing in the browser, after getting authenticated against SSO, is ARERR-623 (I think that is the login failed message), then the problem is probably related to the AR server configuration with SSO. Check the SSO AREA plug-in configuration in the AR server to make sure it has the correct URL and amadmin credentials.
Also, verify that the External Authentication (EA) tab has been setup as well. In the EA tab, make sure to select the chaining method of AREA-AR.
Lastly, check the ar.cfg to make sure that the sso plug-in is the first plug-in listed- if you need to change anything I recommend shutting down AR first. Putting the SSO plug-in first will cause it to be the AREA plug-in used by the AR server. When needing to use multiple AREA plug-ins, the hub plug-in will need to be used.
I made those changes with the exception of the chaining method. I had to edit the ar.cfg file to get going again because I got locked out of the user tool. I changed the chaining method ARS-AREA in order to get back in.
Now, the error message on the mid-tier has changed.
The following error(s) occurred while trying to process your request:
Windows Logon fails.
I'm not convinced that I'm past the cookie issue in fact because I'm still seeing invalid session ID log entries.
I also managed to lock myself out of the OpenSSO admin console by setting CAC on the top level realm because my cac user in that realm is not part of the admin group.
I think I'm a bit confused on the documentation as to what Realm is supposed to perform the functions needed to make this work. For instance, the J2EE agent is in the top level realm and not in the BMCRealm. Also, the Subjects tab is in both realms. Who gets stored where and does it matter?
So I may reinstall the whole mess again this weekend. There's nothing like repetition but it will lead to understanding SSO eventually.
I think the 8908 is related to a problem in the AR AREA configuration but someone with AR AREA experience would be able to answer that question.
The BmcRealm is used for user authentication while the root realm is reserved for Atrium SSO administration which includes the agents that are integrated into the system. The data stores in the realm define what subjects are visible within that realm. For example, if you add an AR data store to the BmcRealm, you’ll see the AR users and groups show up in the Subjects tab in the BmcRealm but not the root realm. Since both realms start with the embedded LDAP data store, you see the same list.
I only found one KA for ARERR 
Logon fails due to unknown user or invalid password
-The user was not using Cross Reference Blank Password or AREA/LDAP.
- In addition, the user had a corrupted entry in the user form
Deleting the corrupted user entry and creating a new one resolved this
If further research is required, as Adam says, we may need to engage AR System expertise. However, we may get some additional information by cranking up the logging level in mid-tier:
* In the Mid-tier configuration tool, under the Log Settings link:
- put a check mark against each Log Category
- set the "Log Level" value to "Fine"
- set the "Log Format" to "Detailed Text..."
- note the Log Directory location
* Retry testing of your issue via the browser
* Reset the Mid-tier "Log Level" to "Warning"
* Review the files in the "Log Directory"
Thanks & Regards,
Adam, Something you wrote led to a breakthrough with the authentication error. You mentioned an AR data store in the BMCRealm. I added the data store and the authentication issue went away and I got logged into the mid-tier.
The issue infront of me now is this. The groups that I have added to my people record don't seem to carry over.
I went to the subjects tab in SSO, found my CAC user account and looked at the groups. No groups were associated with the user. I tried to add those groups and received an error message
Plug-in com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo: Unable to find entry: cn=Administrator,ou=groups,dc=opensso,dc=java,dc=net
Now, I can see the groups by going to Access Control-> BMCRealm ->Subjects -> Group tab but I cannot affect any change on them.
Update, I had "Allow guest users" selected in ARS. unchecking that makes authentication fail again. So that was the reason I had no groups. I was coming in as guest.
At this stage, my instinct is that I'd need to review both SSO and Mid-Tier log files to see what's actually happening. I don't know specifically what to look for - just anything that helps understand the interaction.
As you won't be able to send that information, I'm just stuck to know what to advise you.
If you can run the support tool (per Atrium SSO Administration Guide Chapter 12) and also get the Mid-Tier logging per a previous post that I sent, then review the contents to see if you can get a better understanding of what is happening, and then post again, we may have enough to go to the next phase of analysis.
I don't know if Adam has any further suggestions...
Hi Mike & Jim,
First, I would check the login process using the testing URL with the Atrium SSO server: https://
l Plugin: areaatriumsso.dll
Put the areaatriumsso.dll before any other plug-in declaration in the file in order for it to be the plug-in that AR will use.
If it is still failing, then the plug-in logging should be enabled and captured so we can analyze this problem.
I did modify the ar.cfg file and placed the areaatriumsso.dll as the first plugin. After that didn't work, I even went as far as commenting the arealdap plugin.
Does the fact that I can get in as a guest user with my CAC validate that the SSO piece is in fact working?
I got pulled away for a few days so I wont have a chance to look at the logs until thursday.
Jim, I'll pull some logs together from the SSO side and from the mid-tier/tomcat end as well. I'll send them to you both outside of the forum.
Thank you both for your help. You've been instrumental to the progress made so far.
Commenting out the other unused AREA plug-ins is an additional good step. It does sound like the SSO & mid-tier integration is functioning and the last part to get resolved is the AR EA/AREA plug-in configuration. If you could get the logging for the AREA plug-ins turned on with maximum verbosity in the AR server and include with the other logs that would be very helpful.
So after getting some additional help brought to me by our sales team, we were able to get things working. The authentication issue that we were facing at the end of this saga was simply due to a password being set on the user profile tied to the cac user. The password field must be blank.
I think I need to do a bit more configuration to get the chaining how I want it to be.
Thanks to everyone for their help