ktpass mapuser problem

I ran into this issue few times when I try to run ktpass command where I do both mapuser and key generation in one step. The support tool ktpass complains that it cannot fetch user profile.
This can be resolved by doing this as two separate steps instead of one.

Setting password policies on domain controller for Windows Desktop SSO

--------------------------------------------------------------------------------------------

Source: http://technet.microsoft.com/en-us/library/cc781633.aspx#BKMK_2

--------------------------------------------------------------------------------------------

To change password policies:

• For a local computer
  
• For a domain, and you are on a member server or a workstation that is joined to the domain
  
• For a domain, and you are on a domain controller or on a workstation that has the Windows Server 2003 Administration Tools Pack installed
  

For a local computer

1. Open Local Security Settings.
   
2. In the console tree, click Password Policy.
   Where?
   
   • Security Settings/Account Policies/Password Policy
     
3. In the details pane, right-click the policy setting that you want, and then click Properties.
   
4. Select the options that you want, and then click OK.
   

Notes

• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.
  
• To open Local Security Policy, click Start, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Local Security Policy.
  

For a domain, and you are on a member server or a workstation that is joined to the domain

1. Open Microsoft Management Console (MMC).
   
2. On the File menu, click Add/Remove Snap-in, and then click Add.
   
3. Click Group Policy Object Editor, and then click Add.
   
4. In Select Group Policy Object, click Browse.
   
5. In Browse for a Group Policy Object, select a Group Policy object (GPO) in the appropriate domain, site, or organizational unit--or create a new one, click OK, and then click Finish.
   
6. Click Close, and then click OK.
   
7. In the console tree, click Password Policy.
   Where?
   
   • Group Policy Object [computer name] Policy/Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy
     
8. In the details pane, right-click the policy setting that you want, and then click Properties.
   
9. If you are defining this policy setting for the first time, select the Define this policy setting check box.
   
10. Select the options that you want, and then click OK.
    

Notes

• To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.
  
• To open Microsoft Management Console, click Start, click Run, type mmc, and then click OK.
  

For a domain, and you are on a domain controller or on a workstation that has the Windows Server 2003 Administration Tools Pack installed

1. Open Active Directory Users and Computers.
   
2. In the console tree, right-click the domain or organizational unit that you want to set Group Policy for.
   
3. Click Properties, and then click the Group Policy tab.
   
4. Click an entry in Group Policy Object Links to select an existing Group Policy object (GPO), and then click Edit. You can also click New to create a new GPO, and then click Edit.
   
5. In the console tree, click Password Policy.
   Where?
   
   • Group Policy Object [computer name] Policy/Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy
     
6. In the details pane, right-click the policy setting that you want, and then click Properties.
   
7. If you are defining this policy setting for the first time, select the Define this policy setting check box.
   
8. Select the options that you want, and then click OK.
   

Notes

• To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.
  
• To open Active Directory Users and Computers, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.
  

Note

• Password policy ensures that all users are creating passwords that adhere to the guidelines set by administrators. For more information about each of the password policy settings, see "Password policy" in Related Topics.
  

Steps to configure Windows Desktop SSO

Source: http://forums.sun.com/thread.jspa?threadID=5361015&tstart=0
Author: jeffcortade
---------------------

General info

Our environment has external and internal users.
External users are not logging onto a desktop on the AD domain.
Internal users are.
Currently all users have a user in the AD domain and AM authenticates against AD.
The Login method for users is Username and Password.

Our AD has 2 "tiers" We are interested in.

top.hill.com
near.top.hill.com

We use AM 7.1 patch 1 and DS 6 All servers are running windows 2003 r 2

the AM servers are members of the top.hill.com AD domain. there are 4 of them

am01 am02 am03 am04.top.hill.com
Sun Directory servers are the same way
dir01 dir02 dir03 dir04.top.hill.com

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.

shared-state-enable options

Use following parameters in the options field if you would like to enable shared state between auth modules and do not want to relogin to second module on success of first module.

iplanet-am-auth-shared-state-enabled=true shared-state-enabled=true iplanet-am-auth-shared-state-behavior-pattern=useFirstPass

Simple test for Unix auth module in OpenSSO

To do Unix module authentications, we need to start helper daemon. This can be obtained from zip file.

1. Do configuration of port and other information by following steps provided in this doc:
http://docs.sun.com/app/docs/doc/820-3320/ggnpg?a=view

2. Create an auth module say testunix.

3. Create a test user on the unix machine where OpenSSO is running. Commands are:
* useradd testuser
* passwd testuser

4. Start unix helper daemon after unzipping opensso.zip and giving execute permissions.

cd zip-root/opensso/tools/helpers/bin
# ./amunixd

5. Login using URL:
http://host:port/opensso/UI/Login?module=testunix

SAML 1.1 cert configuration for Post Profile Assertions in AM 7.0 / 7.1

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.

Debugging SecurID auth module

Background of amsecuridd helper deamon

Access Manager SecurID authentication client is implemented using RSA's ACE/Client API and a helper written in C will communicate between Access Manager SecurId module and the SecurId server

Access Manager SecurId module invokes amsecuridd deamon by opening a socket to localhost:57943 to listent for securid authentication requests. port 57943 is the default port number, if this port number is already occupied different port number can be specified for the SecurID Helper Authentication Port attribute in SecurId service configuration.

The interface to amsecuridd is cleartext through stdin. that's why only localhost connections are permitted to this service. the "backend" of this routine uses the SecurID remote API (v5.*), which does the appropriate encryption of sensitive data.

amsecuridd helper listens on another port to receive its configuration information. by default on the port 58943. if this port is occupied, you can run it on different port, by changing the securid service properties through Access Manager Console For each organization/realm that communicates with a different ACE/Server (which has a different sdconf.rec file), a separate instance of SecurID helper should be run.

How to run amsecuridd helper
This deamon can be invoked in two ways,
# Manual invocation
# Using amserver wrapper script
Starting it manually

amsecuridd requires the following shared libararies

libaceclnt.so => /opt/SUNWam/lib/libaceclnt.so
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libthread.so.1 => /lib/libthread.so.1
libc.so.1 => /lib/libc.so.1
libpthread.so.1 => /lib/libpthread.so.1
libmp.so.2 => /lib/libmp.so.2
libmd5.so.1 => /lib/libmd5.so.1
libscf.so.1 => /lib/libscf.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1

Most of them can be found in OS.

you need to set LD_LIBRARY_PATH to //SUNWam/lib/ to find libaceclnt.so

amsecuridd: Usage [-v] [-c portnum]


[-v] turn on verbose mode; you need to create the debug file by
touch /var/opt/SUNWam/debug/securid_client.debug

[-c portnum] config listening port number; default 58943.

Starting amsecuridd using amserver script

The amserver script can be found in the /SUNWam/bin/ directory

/opt/SUNWam/bin/amserver start
stopping auth helpers ...
done.
starting auth helpers ...
done.

verify the process has been started

ps -ef | grep amsecuridd

root 1725 1 0 10:26:49 pts/3 0:00 /opt/SUNWam/share/bin/amsecuridd -c 58943

How to disable the amsecuridd deamon from being started

if you dont want the amsecuridd deamon started everytime when amserver start is issued do the following Remove the securid from following property from AMConfig.properties com.iplanet.am.daemons for eg: out of box this property will look like this com.iplanet.am.daemons=unix securid after disabling securid com.iplanet.am.daemons=unix
Limitations

SecurId Authentication module is supported only on Solaris Sparc hosts, it is not supported on Solaris x86 and Linux
Troubleshooting SecurID Authentication

Make sure the amsecuridd deamon is running in verbose mode if not restart it with -v option. then follow these steps on the server where the amsecuridd is running

telnet localhost 58943
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Enter SecurID Helper Listen Port [57943]:
Enter SecurID Helper Session Timeout [5]:
Enter SecurID Helper Max Sessions [5]:
Enter Config Path for Server [/opt/ace/data]: /var/tmp/ace.iramya
get_config_info: amsecuridd configured successfully
Connection closed by foreign host.

telnet localhost 57943
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Enter SecurID login: fob56
Enter passcode: 06457646
System generated PIN? (y/n): n
Enter new PIN, containing 4 to 8 digits: 1234
Wait for the code on your token to change, then connect again with the new
PIN
Connection closed by foreign host.

telnet localhost 57943
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Enter SecurID login: fob56
Enter passcode: 123418924721
Authentication passed
Connection closed by foreign host.

The dialog session may be different based on your securid card configuration

You can find more details about the client communication with ACE server in the /var/opt/SUNWam/debug/securid_client.debug file

The passcode is computed like this: your PIN for the fob + the digits displayed on the fob

for example if your fob displayed 18924721 and your PIN for the fob(securid card) is: 1234

then the passcode will be: 123418924721

if the above step works fine then it is the problem in the Access Manager SecurId atuhentication configuration. Run the server in debug mode

In AM 7.0+ you can dynamically enable debug mode by following these steps
Login as amadmin (or top level admin user) to Access Manager Console
Access ://server:port//Debug.jsp?category=AUTHENTICATION&level=3


Try to look into amAuthSecurID file

Realm VS Legacy mode

http://host:port/amserver/SMSServlet?method=isRealmEnabled

if true then realm mode else legacy mode.

Comparison chart of Realm and Legacy mode functionality wise.

http://docs.sun.com/app/docs/doc/819-4669/6n6q9stbf?a=view

AM server Application module URL

The URL to login into AM server into Application module is:
http(s)://host:port/amserver/UI/Login?module=Application&IDToken0=amadmin&IDToken1=password

For ex:
http://avatar.red.iplanet.com/amserver/UI/Login?module=Application&IDToken0=amadmin&IDToken1=admpassword

Few steps to start a simple load test using Mercury LoadRunner 8.1:

1. Install Load Runner server and controller on a windows machine say Load Runner 8.1 on a machine star.sun.com

2. Go to start-> Programs -> Mercury -> LoadRunner. You will get 3 options in the GUI.
* Create/Edit Scripts * Run Load Tests * Analyze Load Tests

3. Choose Create / Edit Scripts option. It will open Virtual User Generator console. On the left tab, choose new Vuser script.

4. In the dialog box, you have few options. Choose Web (HTTP / HTML).

5. It will take you to "Start Recording" box options. Provide broser type, start url - the first url to hit when the script starts, choose Action for "Record into Action" option. This is the place where you can generate load.

6. Now record the script by doing UI operation like the way you test from a browser. Save it.

7. Provide Scenario options and start the test.

8.If you choose Run Load Tests. It will open a controller console.

9. In the controller console, it will show you previous scripts that you have created or imported earlier.

Configure reverse proxy in few seconds.

Sometimes we may have to configure a load balancer in front of bunch of web servers or just one web server to test some problem. Configuring load balancer could take time. A simple way to do this is to configure reverse proxy plugin in a web server or an app server that is already deployed. It takes few seconds to do this.

For ex: If you have Sun Web sever 7.0 configured, it takes few seconds to do this.

Click on Configurations tab and select the configuration.
Click Virtual Servers tab and select the virtual server.
Click Content Handling > Reverse Proxy tab.
Click New Proxy URI button.

Specify values for the following parameters:
URI - The reverse proxy URI
Server URL - Comma separated URLs of the remote server.
If multiple values are given, the server will distribute load among the specified servers.

If you want to simply route all requests to another web server or app server you can say
URI - /
Server URL - http://avatar.red.iplanet.com:80/opensso

Let us say this reverse proxy plugin is configured on http://bull.red.iplanet.com:5555
webserver, with above paramters, any http request to bull.red.iplanet.com:5555 will be routed
to avatar.red.iplanet.com:80 and user accessing bull,red,iplanet.com:80 will never know that
he is indeed accessing avatar.red.iplanet.com:80.

Steps to configure Enterprise DSEE 6.x

The following steps will help in configuring Sun Enterprise DSEE 6 that comes with JES5 installer.

1. Install all components of DSEE during installation of JES5.

2. To start DS admin console,

# /usr/sbin/smcwebserver status
The output should resemble the following:
Sun Java(TM) Web Console is stopped

# /usr/sbin/smcwebserver start

3. If cacaoadm is not yet started, start it
# /usr/sbin/cacaoadm start

4. Check if DSCC is initialized properly.
# cd /opt/SUNWdsee/dscc6/bin

# ./dsccsetup status

The response should resemble the following:

***
DSCC Application is registered in Sun Java (TM) Web Console
***
DSCC Agent is registered in Cacao
***
DSCC Registry has not been created yet
***

This response indicates that the installer has installed the DSCC packages but did not create a DSCC instance.

Start the DSCC configurator.

# ./dsccsetup install

The response should resemble the following:

### 'install' subcommand is obsolete.
### Use 'ads-create' subcommand instead.
Choose password for Directory Server Manager:

When prompted, type the directory-admin-password.

The response should resemble the following:
Confirm password for Directory Service Manager: Creating DSCC registry...
DSCC Registry has been created successfully.

Confirm that your new DSCC instance is running.

# ps -ef | grep dscc6

The response should resemble the following:

/opt/SUNWdsee/ds6/lib/64/ns-slapd -D /var/opt/SUNWdsee/dscc6/dcc/ads -i /var/opt

If the DSCC instance is not running, start it.

# /opt/SUNWdsee/ds6/bin/dsadm start /var/opt/SUNWdsee/dscc6/dcc/ads

5. Enable web console to start on system reboots
/usr/sbin/smcwebserver enable

6. Login to the console now.
* Access https://machine:6789/
* Login using root credentials of machine where this DSEE is installed. Remember it is root password of the machine.
* Click on DS console
* Enter admin password that you had provided during JES installation.

You can administer DS instances now.