01-30-2008 08:03 AM
Hi,
I am trying to get SSO set up with three servers. I have created the certificates and traded, setup a Master and slaves, but when I try to access the peer server I am getting an Apache error of "session is invalid..."
Does anyone have tips for setting up SSO or have an idea of why I am unable to get to the peer?
Solved! Go to Solution.
02-05-2008 09:01 AM
Edit the file AFTER you have the mode configured. That is, set the desired mode, shutdown dmgtd, then edit the file, then restart dmgtd.
01-30-2008 08:52 AM
Also, when I set up the certificates I used the FQDN because, DNS is resolved using the FQDN...would this affect how the certs. and SSO configs interact?
I really appreciate any insight...
01-30-2008 08:51 PM
If the certs are setup using FQDN, then you muse specify FQDN when specifying your SSO master server on each slave. The only things to do when setting up SSO is to make sure the master server has accepted the certs from all slaves, and each slave has accepted the master's cert. Then, make sure all clients can reach the slaves and the master, and the slave servers can reach the master.
When you try to login to a slave server, you should be redirected to the master for authentication. Once successful, you should be sent back to the slave. Therefore, the users you are using must be configured both on the master and on the slaves.
01-31-2008 11:20 AM
The certs have been exchanged. When I set my Master as the Master I get the following message:
Single Sign-On configuration is successful. Please make sure this server named 'enmcisco01' is DNS resolvable.
Notice the servername enmcisco01 needs to be resolvable.....this name is not resolvabe, but enmcisco01.irm.state.gov is. I have the FQDN as the Master Server Name on the Slave, and the cert has the FDQN and it still doesn't work.
The Master Server Name on the master is enmcisco01 and I cannot change it, can it be changed? could this be causing the problem?
01-31-2008 12:28 PM
On the master, edit NMSROOT/lib/classpath/sso.properties, and set your ASName to be the FQDN. Then, make sure you point all slaves to the FQDN.
02-05-2008 09:00 AM
I edited the sso.properties file to se the ASName=servername.domainname and restarted dmgtd. When I tried to set up the master, the setting was changed back to just the servername. Any other ideas of how to get SSO working?
02-05-2008 09:01 AM
Edit the file AFTER you have the mode configured. That is, set the desired mode, shutdown dmgtd, then edit the file, then restart dmgtd.
02-05-2008 09:17 AM
Thank you a million times...this worked like a champ!!!!!
01-31-2008 12:24 PM
Thread hijack: When TACACS is used for authentication only with local fallback, when a user udpates his/her [local] password deliberately via Modify My Profile when logged on to one of the slave servers, is his [local] password change taking place on the master or the slave or both? If only on the slave, does that mean his [local] password goes out-of-sync between the master and slave? The user can still log in of course, as long as TACACS is available.
01-31-2008 12:29 PM
Each server in an SSO domain maintains its own username database. So the password would need to be updated on the master to make any real difference. This is why using a central repository like ACS makes administration much easier. You don't need to do any user management on the LMS servers.
01-31-2008 04:24 PM
:::continuing the hijack:::
Using ACS just for the authentication protocol (wither tacacs+ or Radius) instead of full integration does not incure the wrath of slow performance too!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: