Showing posts with label tivoli access manager 6.1. Show all posts
Showing posts with label tivoli access manager 6.1. Show all posts

02 January 2013

TAM 6.1 - HPDAC0457E The protected object name is invalid. (status 0x1005b1c9)


A colleague of mine run today into a problem while trying to attach ACL to a protected object seen in the objectspace tree. Although being "seen" by both WPM console and pdadmin client via 

object show /xxx/yyy/subcat

command, trying to use 

acl attach /xxx/yyy/subcat ACL_name

resulted in getting below error:

Error: HPDAC0457E   The protected object name is invalid. (status 0x1005b1c9)

At the same time attaching ACLs to parent and child objects was just fine.

We checked initial loading scripts, and we found that there were only entries for super- and sub- items, like:

/xxx/yyy/ and then for /xxx/yyy/subcat/subsubcat/ but not for the middle one

So what was happening was that /xxx/yyy/subcat wasn't really created before, but only was visible as a tree level, because TAM had to show something in that place. Then the fix was easy, we just created the missing object with

object create /xxx/yyy/subcat "" 10 ispolicyattachabe yes

and then we could successfuly attach ACL to this object.

Hope this helps, enjoy and leave a comment!

30 July 2012

HPDAZ0602E Corrupted file: Insufficient information to contact a Policy Server (SECJ0391E)

Now, a few words about possible problems when configuring external JACC authorization provider for WebSphere App Server, namely - Tivoli Access Manager. The key issue here always lies in obtaining Policy Server's certificate for JRE to authenticate later on. This can be done in various ways (sslsrvcfg, pdconfig etc.) and obviously, the results may vary depending on the way used - at least it seems so.
Anyway, recently I was asked what may be the reason for the following error appearing in the logs:

[7/25/12 10:07:44:950 CEST] 00000013 AMWASConfigMe I   com.tivoli.pd.as.jacc.cfg.TAMConfigController execute() AWXJC0048E   An error occurred during the configuration. The details are: com.tivoli.pd.as.jacc.cfg.ConfigActionFailedException:
[java.lang.IllegalStateException: HPDAZ0602E   Corrupted file: Insufficient information to contact a Policy Server.
]

Wrappered Exception:
java.lang.IllegalStateException: HPDAZ0602E   Corrupted file: Insufficient information to contact a Policy Server..


This one happened during JACC configuration attempt from the WAS admin console, when console reported that action cannot be successfully completed. "Insufficient information" could only mean that JRE is trying to register with Policy Server, but fails to trust/present valid certificate. Unfortunately, we were stubborn, and hoped that action will complete during server restart. But after saving configuration and restarting server, it fails to start! In the logs we could see:

[7/25/12 10:19:49:404 CEST] 00000000 distSecurityC E   SECJ0391E: Error when setting the Policy object to the provider's policy implementation com.tivoli.pd.as.jacc.TAMPolicy. The exception is com.tivoli.pd.as.jacc.util.JACCException: AWXJR0006E   The file, /opt/ibm/WebSphere/AppServer/profiles/PSS1UPRB01DMgr/etc/tam/amwas.PSS1UPRB01DMgr_dmgr.amjacc.properties, was not found.
    at com.tivoli.pd.as.jacc.TAMPolicy.init(TAMPolicy.java:680)
    at com.tivoli.pd.as.jacc.TAMPolicy.<init>(TAMPolicy.java:97)
    at java.lang.J9VMInternals.newInstanceImpl(Native Method)
    at java.lang.Class.newInstance(Class.java:1345)


which meant that WAS has got JACC enabled, but in fact had failed to provide proper configuration file for amwas/jacc. We gave it some thinking and first, we had to recover from this fatal condition: by editing security.xml we disabled security and disabled using JACC in section:

<security:Security xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:orb.securityprotocol="http://www.ibm.com/websphere/appserver/schemas/5.0/orb.securityprotocol.xmi" xmlns:security="http://www.ibm.com/websphere/appserver/schemas/5.0/security.xmi" xmi:id="Security_1" useLocalSecurityServer="true" useDomainQualifiedUserNames="false" enabled="true" cacheTimeout="600" issuePermissionWarning="false" activeProtocol="BOTH" enforceJava2Security="false" enforceFineGrainedJCASecurity="false" appEnabled="true" dynamicallyUpdateSSLConfig="true" allowBasicAuth="true" activeAuthMechanism="LTPA_1" activeUserRegistry="WIMUserRegistry_1" defaultSSLSettings="SSLConfig_1"> <--- change bold to FALSE


<authConfig xmi:id="AuthorizationConfig_1" useJACCProvider="true">  <-- change bold to FALSE   


After that server went up again and we gave a bit thinking to the problem. It turned out to be awfully simple and...well, strange ? We had to add hostname of the WAS machine to policy server's /etc/hosts. Possibly this can be also solved by adding WAS hostname to DNS, anyway, pdmgrd must be able to resolve WAS's IP based on presented hostname. Then, we were able to complete JACC configuration successfully, turn security back on for the whole cell, save and restart and all worked like a wonder!

Why do I say it was strange? Because my suspicion is that different PD.jar packages (or more precisely: pd.* classes) responsible for connecting to Policy Server do this in a different way. I'm too weak a programmer to dig this up and resolve it 100%, but I just know that you may get different results when a) configuring JRE from pdconfig b) using sslsrvcfg and c) configuring JACC from WAS (WebSphere's embedded TAM) - eventually, you just need to see what works best for you.

Good luck, leave a comment if it helped!



30 May 2012

PDJRTE for TAI++ config error: java.lang.NullPointerException at com.tivoli.pd.jutil.jb.getCACert(jb.java:129)

If you work with complex TAM&J2EE deployments, you will most probably come to the point where you need to use TAI++ trust association scheme to tie your J2EE server (either WebSphere or some other) with TAM&WebSeal system. In particular, this is useful when you want to authenticate users in WebSeal to "let them in" to your backend server but leave authorization for J2EE application to it's internal mechanisms (based on LDAP, for example). If you want to read more on TAI/TAI++ you can do it here or here.
However, in TAI++ scenario you will most probably come to the point when you will need to configure your Java Runtime for Policy Director (usually done in pdconfig or with pdjrtecfg directly). What WAS really needs for TAI++ is essentialy address of Policy Server, it's certificate to be trusted (downloaded during PDJRTEconfig) and registration with TAM pdmgrd as a member of security domain. These information is stored in (not strictly set, but reasonable to do it so) .conf and .key files producedafter invoking java com.tivoli.pd.jcfg.SvrSslCfg but first you need to have your PDJRTE configured.

 I tried this with WebSphere App Server's (WAS 7 and TAM 6.1.0.5) java first and usually you do it by sourcing WAS environment first and then using pdconfig. However, in WAS 7 there's a class conflicts of some kind and when you go to pdconfig and choose to configure WAS java (normally /opt/ibm/WebSphere/AppServer/java/jre) to be the runtime for Policy Director in picks proper java, but fails to finish the configuration with nasty error:

Configuration of Access Manager Runtime for Java is in progress.
This might take several minutes.
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at com.tivoli.pd.jcfg.PDJrteCfg.config(PDJrteCfg.java:245)
        at com.tivoli.pd.jcfg.PDJrteCfg.interactCfg(PDJrteCfg.java:1307)
        at com.tivoli.pd.jcfg.PDJrteCfg.invoke(PDJrteCfg.java:1460)
        at com.tivoli.pd.jcfg.PDJrteCfg.main(PDJrteCfg.java:350)
Caused by:
[java.lang.NullPointerException
]

Wrappered Exception:
java.lang.NullPointerException
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:129)
        ... 8 more
Caused by: java.lang.NullPointerException
        at org.apache.harmony.security.fortress.Services$NormalServices.createDefaultProviderInstance(Services.java:286)
        at org.apache.harmony.security.fortress.Services$NormalServices.getService(Services.java:423)
        at org.apache.harmony.security.fortress.Services$NormalServices.access$2100(Services.java:141)
        at org.apache.harmony.security.fortress.Services.getService(Services.java:824)
        at org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:133)
        at java.security.KeyFactory.getInstance(KeyFactory.java:81)
        at com.ibm.security.x509.X509Key.buildX509Key(X509Key.java:275)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:189)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:215)
        at com.ibm.security.x509.CertificateX509Key.<init>(CertificateX509Key.java:112)
        at com.ibm.security.x509.X509CertInfo.parse(X509CertInfo.java:966)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:236)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:222)
        at com.ibm.security.x509.X509CertImpl.parse(X509CertImpl.java:2285)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:227)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:213)
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:51)
        ... 8 more

[java.lang.reflect.InvocationTargetException
]

Wrappered Exception:
java.lang.reflect.InvocationTargetException
        at com.tivoli.pd.jcfg.PDJrteCfg.config(PDJrteCfg.java:51)
        at com.tivoli.pd.jcfg.PDJrteCfg.interactCfg(PDJrteCfg.java:1307)
        at com.tivoli.pd.jcfg.PDJrteCfg.invoke(PDJrteCfg.java:1460)
        at com.tivoli.pd.jcfg.PDJrteCfg.main(PDJrteCfg.java:350)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at com.tivoli.pd.jcfg.PDJrteCfg.config(PDJrteCfg.java:245)
        ... 3 more
Caused by:
[java.lang.NullPointerException
]

Wrappered Exception:
java.lang.NullPointerException
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:129)
        ... 8 more
Caused by: java.lang.NullPointerException
        at org.apache.harmony.security.fortress.Services$NormalServices.createDefaultProviderInstance(Services.java:286)
        at org.apache.harmony.security.fortress.Services$NormalServices.getService(Services.java:423)
        at org.apache.harmony.security.fortress.Services$NormalServices.access$2100(Services.java:141)
        at org.apache.harmony.security.fortress.Services.getService(Services.java:824)
        at org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:133)
        at java.security.KeyFactory.getInstance(KeyFactory.java:81)
        at com.ibm.security.x509.X509Key.buildX509Key(X509Key.java:275)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:189)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:215)
        at com.ibm.security.x509.CertificateX509Key.<init>(CertificateX509Key.java:112)
        at com.ibm.security.x509.X509CertInfo.parse(X509CertInfo.java:966)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:236)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:222)
        at com.ibm.security.x509.X509CertImpl.parse(X509CertImpl.java:2285)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:227)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:213)
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:51)
        ... 8 more
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at com.tivoli.pd.jcfg.PDJrteCfg.config(PDJrteCfg.java:245)
        at com.tivoli.pd.jcfg.PDJrteCfg.interactCfg(PDJrteCfg.java:1307)
        at com.tivoli.pd.jcfg.PDJrteCfg.invoke(PDJrteCfg.java:1460)
        at com.tivoli.pd.jcfg.PDJrteCfg.main(PDJrteCfg.java:350)
Caused by:
[java.lang.NullPointerException
]

Wrappered Exception:
java.lang.NullPointerException
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:129)
        ... 8 more
Caused by: java.lang.NullPointerException
        at org.apache.harmony.security.fortress.Services$NormalServices.createDefaultProviderInstance(Services.java:286)
        at org.apache.harmony.security.fortress.Services$NormalServices.getService(Services.java:423)
        at org.apache.harmony.security.fortress.Services$NormalServices.access$2100(Services.java:141)
        at org.apache.harmony.security.fortress.Services.getService(Services.java:824)
        at org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:133)
        at java.security.KeyFactory.getInstance(KeyFactory.java:81)
        at com.ibm.security.x509.X509Key.buildX509Key(X509Key.java:275)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:189)
        at com.ibm.security.x509.X509Key.parse(X509Key.java:215)
        at com.ibm.security.x509.CertificateX509Key.<init>(CertificateX509Key.java:112)
        at com.ibm.security.x509.X509CertInfo.parse(X509CertInfo.java:966)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:236)
        at com.ibm.security.x509.X509CertInfo.<init>(X509CertInfo.java:222)
        at com.ibm.security.x509.X509CertImpl.parse(X509CertImpl.java:2285)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:227)
        at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:213)
        at com.tivoli.pd.jutil.jb.getCACert(jb.java:51)
        ... 8 more

The configuration failed.


Press Enter to continue.


I suppose it is because WAS 7 has it's own PD.jar file which may even be newer than the one supplied with TAM 6.1.0.5 <-- that's the version we're talking here about. Or it is because WAS 7 uses java 6, whereas tam works fine with java 5 - I can't tell exactly.

Anyway, what to do about it? Simply point pdconfig to a different java. For example, bundled with TAM base package is ibm java 5. Install it (it is in /opt/ibm/java2-i386-50/ directory), export it's path:

export PATH=$PATH:/opt/ibm/java2-i386-50/java/jre

and try pdconfig to configure pdjrte again. It should succeed now.

To obtain information for using with TAI++, run now SvrSslCfg with the java you just configured eg.:

/opt/ibm/java2-i386-50/jre/bin/java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id sec_master -admin_pwd ***** -appsvr_id ******-host ***** -mode remote -port 8925 -policysvr tamsec-p2-1:7135:1 -authzsvr tamsec-p2-1:7136:1 -cfg_file domainname.cfg -key_file domainname.key -cfg_action create -domain domainname

and later supply it to WAS as TAI++ inteceptor config item.

Good Luck!

23 March 2012

WPM config - HPDCO1364E The specified domain does not exist. (0x1354a554)

While trying to configure WPM (TAM Web Portal Management), you may encounter this particular error:

HPDCO1364E   The specified domain does not exist. (0x1354a554)

You are most probably using non-default (not "Default") domain. Apparently, WPM has a problem with specifying different domain name than default, but this occurs in version 6.1.0.0. What you need to do is to upgrade to fp5 (or lower fp, but I tested it with fp5)
  1. get 6.1.0-TIV-TAM-FP0005-LIN.tar.Z file (for Linux x86)
  2.  gunzip and tar -xf it
  3. install with: rpm -Uhv PDWPM-PD-6.1.0-5.i386.rpm
  4. try pdconfig
after fixpacking it should suggest you (get from configured Java Runtime) correct domain name.

Good luck, leave a comment.

07 February 2012

SECJ0053E and AWXJR0044E: PolicyConfiguration exists = false

If you are working on WAS with JACC configured against Tivoli Access Manager (or other external authorization provider, but I assume TAM is the most popular) in your application development cycle you may stumble upon the following error sequence:
[2/7/12 11:24:45:304 CET] 000000c8 SecurityColla A   SECJ0053E: Authorization failed for defaultRealm/username while invoking (Bean)XyEAR-2.2#XyzBean.jar#soapAction:5 JACC Authorization failed for bean: xyzvBean
[2/7/12 11:24:45:660 CET] 0000003d AMWASJACCMess I   com.tivoli.pd.as.jacc.TAMPolicy implies(ProtectionDomain, Permission): permission = perm.toString()
0x864297004
AWXJR0044E   The access decision for Permission, (javax.security.jacc.EJBMethodPermission xyz), was denied because either the PolicyConfiguration or RoleConfiguration objects did not get created successfully at application installation time.  RoleConfiguration exists = true, PolicyConfiguration exists = false.

It is more probable to occur right after application update (new version deployed, for instance).

Here are the things you may do to steer out of this trouble:

 


  1. Ensure all necessary protected object exist in TAM policy database (use pdadmin or WPM - TAM console deployed on WAS)
  2. Update role definition in your authorization provider with:

    Global security > External authorization providers

    choosing "Update with application names listed" and typing in your application name (as appears in Enterprise Applications tab), then Apply

  3. If point 2. fails, follow this sequence: stop application, remove application from server, stop application server, clean temp directories for this server, start server and redeploy application. It should bind with TAM properly this time. After that, restart the server again.
 Good luck.

20 December 2011

pdadmin login fail after migration

There are time that you want to do some unusual stuff with Tivoli Access Manager such as migrate whole TAM instance to a different machine/environment. I did that when trying to replicate KVM environment to a different location, with changing target KVMs IPs to exactly match original one and all the rest as well, including LDAP.

That last component replacement seemed to be a bit too harsh for TAM, and despite copying secAuthority suffix data 1:1, after starting KVM machine and trying to log into pdadmin, I failed to authenticate.

After some investigation it turned out that after copying security suffix data into LDAP, you then need to apply TAM acls to secAuthority objects with ivrgy tool, such as:

/opt/PolicyDirector/sbin/ivrgy_tool -h ldap_host -389 -D "<LDAP_admin_id>" -w <LDAP_admin_pwd> add-acls domain_name

where domain_name is usually Default, but you may also have something more fancy :)

good luck, feel free to comment.

14 October 2011

UTF-8 characters in pdadmin (TAM 6.1)

Recently I came across the following problem: how to import LDAP users that have UTF-8 (Polish) characters into TAM with pdadmin? When you simply run pdadmin and use user import command, you will get the result as in following example:

user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"

Could not perform the administration request
Error: HPDMG0755W   The specified Distinguished Name (DN) does not exist. (status 0x14c012f3)


As you can easily add these users with Web Portal Manager, that means there is *the way* to do it with pdadmin, which is useful if you want to import more than ten-s of users...

A little googling and the solution to this problem is to use command files as input to pdadmin, which contain UTF-8 characters of your choice. but that's a little peculiar as you need to prepare the command file as ANSI type :)

So, that's what you need to do:
  1. prepare command file, setting UTF-8 encoding first so you get:

    user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"
  2. change the encoding to ANSI and you see:

    user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"
  3. save the file (say: tam_import.txt) and copy it to your target system using binary mode (most safe in terms of transmission of some strange stuff)
  4. before running pdadmin set shell to use your locale:

    export LANG=pl_PL.utf-8

  5. and you can finally use your file:

    pdadmin -a sec_master -p your_password tam_import.txt
And that should be all. for file conversion you can use text editor of your choice, my preference is the ultimate Notepad++ (seriously guys, n++ is awesome!!) and for transfer any scp client (WinSCP, I prefer).

Good luck guys, and come back for more.