Notes
Notes
Notes
Note
those are the real hostnames of those systems this is important as apparently kerberos does not like dns aliases.
Users access Access Manager services via
http://am.hill.com/amserver/UI/Login
this is just a DNS name pointed to the external interface of the Load Balancers. All traffic currently goes through there all agents are configured to use that for the LoginURL etc ...
So internal and external users all use that URL through the external interface of the LB.
So desktop SSO
Fun
steps.
all machines are already present in AD as they are joined to the the top.hil.com domain.
find each of those systems in AD and right click on them go to properties. Check the little box that says "Trust Computer for delegation" OK it and ok the resulting scary warning.
Reboot all of the AM machines after doing this.
install the support tools from the windows CD on your DC for top.hill.com if they are not already installed.
you will need the kpass utility to make this work.
Create a User for each host in the Users tree of top.hill.com
AM01
AM02
AM03
AM04
add them each to the administrators group and set password to never expire.
on the dc in a command window
create a working directory someplace and CD into it.
As a domain admin for top.hill.com you have to do this. that should be obvious but hey ...
cd into that directory
then run the following substituting your values obviously
you will do this for each host substituting the AM0X with your hostname.
So a total of 8 command for me.
ktpass -princ HTTP/AM0X.top.hill.com@TOP.HILL.COM -pass YourPasswordHere /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL -mapuser AM0X /out AM0X.HTTP.keytab
ktpass -princ host/AM0X.top.hill.com@TOP.HILL.COM -pass YourPasswordHere /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL -mapuser AM0X /out AM0X.host.keytab
This generates files in your working directory. These will get copied to each of your AM hosts.
On each AM host create a directory to hold the keytab files
I did it on c:\etc\keytab you will referance the path to this in the Auth modules.
copy all the files you created on the DC to that directory on everyhost.
configure 4 new desktopSSO authentication modules
I named mine
desktopAM01 desktopAM02 desktopAM03 desktopAM04
save all the time as the console is such fun each change click save
once they are created configure each of them something like this
WindowsDesktopSSO params:
principal: HTTP/AM0X.top.hill.com@TOP.HILL.COM
keytab file: c:\etc\keytab\AM0X.HTTP.keytab
realm : TOP.HILL.COM
kdc server: dc0X.top.hill.com
the kdc server is one of the DCs in the top.hill.com domain.
domain principal: false
auth level: any number you like depends on your env 0 works fine unless you are doing something with this.
Once all four are configured.
reboot all the AM servers and restart the webcontainer so AM is accessable.
now loginto a desktop as a user in the near.top.hill.com domain
then acess AM like so
http://am0X.top.hill.com/amserver/UI/Login?module=desktopAM0X
this should take your directly to your successpage without prompting for a username password set.
Once all four work
I setup a link on the login pages of each with a distinct hostnamed URL
"internal Users Login Here" thish points to the above link + a goto
http://am0X.top.hill.com/amserver/UI/Login?module=desktopAM0X&goto=dynamicallygeneratedurlfromtheoriginalrequest
4 holes are configured on the external LB for each am host and the associated hostnames are published externally.
not pretty but i think this is the only way to get it working.
If anyone Knows of a way to get this working using a dns alias such as
AM.hill.com .... which has no associated host or a DC at that level please let me know.
Have a nice day.
cd zip-root/opensso/tools/helpers/bin5. Login using URL:
# ./amunixd
Commands to setup SAML 1.1 in cert mode in a simple way so that POST profile assertions work.
1) Generated a key using command
/usr/jdk/entsys-j2se/bin/keytool -genkey -keyalg rsa -alias test -dname
"cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass
11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass
11111111 -validity 180
2) ftp keystore.jks to SP provided you do not need to setup different certs for IdP and SP.
3) For IdP, do
/opt/SUNWam/bin/ampassword -e 11111111 >
/etc/opt/SUNWam/config/.storepass
4) For IdP, do
/opt/SUNWam/bin/ampassword -e 11111111 > /etc/opt/SUNWam/config/.keypass
5) Edit AMConfig.properties in IdP
a) com.sun.identity.saml.xmlsig.certalias=test
b) com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
c) com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass
6) For SP, do
/opt/SUNWam/bin/ampassword -e 11111111 >
/etc/opt/SUNWam/config/.storepass
7) For SP, do
/opt/SUNWam/bin/ampassword -e 11111111 > /etc/opt/SUNWam/config/.keypass
8) Edit AMConfig.properties in SP
a) com.sun.identity.saml.xmlsig.certalias=test
b) com.sun.identity.saml.xmlsig.storepass=/etc/opt/SUNWam/config/.storepass
c) com.sun.identity.saml.xmlsig.keypass=/etc/opt/SUNWam/config/.keypass
9) If any other algo other than dsa is used to generate key, make sure it is correct in /opt/SUNWam/locale/amSAML.properties. Change algorithm name from
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#dsa-sha1 - to -
xmlsigalgorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1
10) Restart AM.
To verify that the cert indeed got generated properly, do
/usr/jdk/entsys-j2se/bin/keytool -list -v -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111
******* Basic Keytool commands - Not needed to quickly configure AM as above ********
# use keytool to setup keystore for xmlsig required by SAML postprofile
sample one can use the same keystore.kjs for different servers, just may need
to regenerated the keypass and storepass with 11111111
com.sun.identity.saml.xmlsig.certalias=test
com.sun.identity.saml.xmlsig.keystore=/etc/opt/SUNWam/config/keystore.jks
/usr/jdk/entsys-j2se/bin/keytool -genkey -keyalg dsa -alias test -dname
"cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass
11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass
11111111 -validity 180
/usr/jdk/entsys-j2se/bin/keytool -certreq -alias test -file request.csr
-keypass 11111111 -keystore /etc/opt/SUNWam/config/keystore.jks
-storepass 11111111 -storetype JKS
# to generate self-signed cert
/usr/jdk/entsys-j2se/bin/keytool -selfcert -alias test -dname "cn=samlsource,ou=SUN Java System Access Manager,o=Sun,c=US" -keypass 11111111 -keystore /etc/opt/SUNWam/config/keystore.jks -storepass 11111111
# submit the content of request.csr to CA Server. Let us call this approved cert as mycert.cer and root CA as myroot.cer
# install root CA
/usr/jdk/entsys-j2se/bin/keytool -import -file
/home/gc111264/ps/keep/myroot.cer -keypass 11111111 -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111
# install mycert.cer
/usr/jdk/entsys-j2se/bin/keytool -import -alias test -trustcacerts -file
mycert.cer -keypass 11111111 -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111
# print a cert
/usr/jdk/entsys-j2se/bin/keytool -printcert -file "mycert.cer"
# list an alias
/usr/jdk/entsys-j2se/bin/keytool -list -alias test -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111
# list all certs
/usr/jdk/entsys-j2se/bin/keytool -list -v -keystore
/etc/opt/SUNWam/config/keystore.jks -storepass 11111111
Generating a self-signed certificate
A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). Whenever the -genkey command is called to generate a new public/private key pair, it also wraps the public key into a self-signed certificate.
You may occasionally wish to generate a new self-signed certificate. For example, you may want to use the same key pair under a different identity (distinguished name). For example, suppose you change departments. You can then:
1. copy (clone) the original key entry. See -keyclone.
2. generate a new self-signed certificate for the cloned entry, using your new distinguished name. See below.
3. generate a Certificate Signing Requests for the cloned entry, and import the reply certificate or certificate chain. See the -certreq and -import commands.
4. delete the original (now obsolete) entry. See -delete.
To generate a self-signed certificate, use the -selfcert command, as in
keytool -selfcert -alias dukeNew -keypass b92kqmp
-dname "cn=Duke Smith, ou=Purchasing, o=BlueSoft, c=US"
The generated certificate is stored as a single-element certificate chain in the keystore entry identified by the specified alias (in this case "dukeNew"), where it replaces the existing certificate chain.
