Monday Aug 31, 2009

Detailed steps to setup OpenSSL certificate authority

Here are the detailed steps to setup OpenSSL as Certificate Authority

Most of the unix operating systems comes with OpenSSL installation, if not, you need to install OpenSSL , then follow the following steps.

Step 1: Run the following command to check openssl is already installed.

$ which openssl (If you see output like /usr/bin/openssl, that means your system already has openssl installed, if not, install openssl)

Step 2: Create directory called openssl-ca

$ mkdir openssl-ca

$ cd openssl-ca

Step 3: Download Makefile file from http://sial.org/howto/openssl/ca/Makefile

Step 4 : Download openssl.cnf file from http://sial.org/howto/openssl/ca/openssl.cnf

Step 5: Edit following line in Makefile( use "-newkey rsa:2048" if running OpenSSL 0.9.8a or higher)


@openssl req -nodes -config openssl.cnf days 1825 -x509 -newkey rsa:2048 -out ca-cert.pem -outform PEM

Step 6: Edit following section of openssl.cnf file as per your per organization details

[ root_ca_distinguished_name ]

commonName = openssl CA

countryName = US (Make sure you specify abbreviation only)

stateOrProvinceName = California (No abbreviation)

localityName = Santa Clara

0.organizationName = Sun Microsystems

emailAddress = mailto:contact@sun.com

Step 7: Run make init to create openssl-ca certificate authority.

$ make init

Step 8: Check all the folders are created to make sure certificate authority is configured properly.

$ ls Makefile crl newcerts private ca-cert.pem index openssl.cnf serial (Note: ca-cert.pem is root certificate)

This concludes the creation of openssl as a certificate authority to generate certificates for your applications.

Monday Aug 24, 2009

Sun Directory 5.2 p4 performance with wildcard ACI's

Recently, i did performance problem debugging effort for a customer who is on Directory 5.2 p4. I found that Wildcard ACI's degrading both read and write performance on DS 5.2 p4. Their current deployment has quit a few wildcard ACI's at root suffix level which causing performance degradation. After removing the wild card ACI's, the performance improved significantly . Also, it looks like same wild card ACI's not causing any performance degradation on Directory 6.3, our 6.3 testing shows no effect on performance with or without wild card ACI's. Just thought of putting out there my findings.

Monday Aug 18, 2008

OpenSSO - How to Configure Attribute Query profile using famadm CLI

Here are the steps to configure Attribute Query Profile using famadm command line tools in OpenSSO.

Step1: On IDP machine using IDP famadm command

- Create Meta data for attribute query profile on IdP using following command.

./famadm create-metadata-templ -u amadmin -f ampass -m mm -x xx -i /idpattr -b test -g test -I /attra -B test -G test -C /authna -D test -E test -y idp

Note:

1. ampass - is password file which contains amadmin password.

2. mm and xx are file names for metadata templates.

3. idpattr - is meta alias name for IDP

4. test - is the out box cert alias name

5. attra - is IDP attribute response meta alias name

6. authna - is IDP authentication meta alias name

7. idp - Entity name for IDP

Step2: On IDP machine using famadm command

- Import Metadata on IDP.

./famadm import-entity -u amadmin -f ampass -m mm -x xx -t test

Step3: On IDP machine using famadm command

-Modify xx file for remote metadata file by changing hosted to 0

- cp xx xx_remote

- change host value to 0 (i.e remote)

Step4: On SP machine using SP famadm command

- Create Metadata for attribute query profile on SP using following command.

./famadm create-metadata-templ -u amadmin -f ampass -m mm -x xx -s /spattr -a test -r test -S /attrq -A test -R test -y sp

Note:

1. ampass - is password file which contains amadmin password.

2. mm and xx are file names for meta data templates.

3. spattr - is meta alias name for SP

4. test - is the out of box cert alias name

5. attrq - is SP attribute request meta alias name

6. sp - is entity name for SP

Step5: On SP machine using SP famadm command

- Import Metadata on SP.

./famadm import-entity -u amadmin -f ampass -m mm -x xx -t test

Step6: On SP machine using SP famadm command

- Modify xx file for remote metadata file by changing hosted to 0

- cp xx xx_remote

- change host value to 0 (i.e remote)

Step7: On SP machine using SP famadm command

- Import SP remote xx_remote data from IDP

./famadm import-entity -u amadmin -f ampass -m /mm -x /xx_remote -t test

Step7: On IDP machine using IDP famadm command

- Import IDP remote xx_remote data from SP

./famadm import-entity -u amadmin -f ampass -m /mm -x xx_remote -t test

Step8: On IDP console, configure attributes which you want to retrieve

- Login IDP console using amadmin

- Click Federation Tab

- Click the IDP entity you created above

- Click Assertion Processing Tab - Add the attributes you want to retrieve like below under Attribute Mapper and Attribute Map

- cn=cn (example)

- sn=sn(example)

- Save configuration.

This concludes configuring Attribute Query Profile on both IDP and SP side, this configuration should get cn and sn attributes from IDP.

Thursday May 08, 2008

Access Manager Windows Desktop SSO

Configuring Windows Desktop SSO in Access Manager is simple and easy, the technology is also simple, basically user presents the Kerberos token to the Access Manager through the SPNEGO protocol to perform Kerberos based SSO to Access Manager. But often configuring WindowsDesktopSSO takes more time than expected. So, here are the few things that needs to be remembered or aware of to configure Windows Desktop SSO.

- Make sure Active Directory is setup properly, because sometimes i have seen Active Directory not letting users to bind unless the user is part of administrator group. So, first, make sure end users can authenticate to AD without any problems. Making sure AD configured properly is very important.

- Access Manager and Active Directory systems clocks should be synchronized.

- Most of the Active Directory environments has multiple domain controllers, so, make sure ktpass run on the Primary Domain Controller, also make sure no typos.

- Access Manager and Domain Controller must have correct DNS entries, both forward and reverse DNS lookup should work.

- Make sure browser supports the SPEGO protocol, and user should be authenticated against domain controller to login to their Desktop.

- Restart the Access Manager after configuring desktop SSO authentication module.

- Enable Access Manager debug logs to troubleshoot the problem by checking amAuth and amAuthWindowsDesktopSSO log files.

Thursday Mar 13, 2008

Three things to remember for successful Identity Manager deployment

Deploying Identity Manager in any organization is bit complex and involved many things, very often customer struggle to have successful IdM (Identity Manager) deployment because of various reasons. To me, identity manager deployment is like eating a big elephant, do not try to eat whole thing at a time. As a experienced IdM senior architect, here are the top three things to remember for a successful IdM deployment.

1. Beat your own politics: We all know Identity management deployment is not as simple as most people think, it gets more complex because of legacy applications, business needs, complexity in current process and number of applications that user needs to be provisioned and managed. Like you all know it is more political then technical. As soon as project started every application owner and team member start thinking about how it is going effect their own application, current process, ownership, job, etc. Thats where the deployment team start facing political difficulties. So you can reduce political difficulties by explaining following benefits by project sponsor/owner to application owners.

- Necessity and importance of project.
- Need of automated identity management system by explaining problems in current process problems.
- More productivity from employees.
- Compliance with government audit policies, and to find who has access to what.
- Reduce helpdesk calls for password resets/ management, and other user management issues.
- Why this is right time to do it.

2. Phased deployment: Deploying IdM in a phased approach is most important for success of the project. As soon as the project is started every application owner want their application provisioning is automated and integrated with IdM as soon as possible. It is not recommended to integrate all applications/resources with IdM in one phase deployment, but at the same time each phase scope should give some justification of IdM deployment by showing benefits to business. So, here are the key things to remember to define scope of each phase.

- Authoritative resources for both employee and contractor should be in Phase1.
- Password management should be in phase 1, it is going to be good business justification for the project which saves lot of money by reducing the help-desk calls.
- Key application/resource (ex: Active Directory or Sun LDAP) should be in Phase.
- Next phase scope should be extension or addition to the previous Phase.
- Do not integrate more than 3 application for each Phase.
- Admin or End user interface customization should handled in separate Phase.

3. Deploy IdM right way and smart way: Follow all possible best practices to do it right, often Application owners or administrators want IdM interface to be customized similar to current process even though IdM interface provides better way of doing things, do not try to implement complex current process in new IdM deployment. And, try not to do huge amount of customization to solve very little problem to support application which are going to deprecated or going away soon, these are just samples, there are many more things like this will come up in IdM deployment, so be careful when designing any end user or admin interface customization.

About

Ashok Anumandla

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today