Re: Portal V6.1 and custom LDAP attributes in Domino
jwi...@us.ibm.com
http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21327305
VMM knows about many default attributes for various LDAP servers. However, if your custom attribute is unknown to VMM, you might need to add the attribute before you map it. Refer to "resolving the problem" here:
http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21365605
leiz...@yahoo.ca
In Portal V6.0, we were able to configure portal to recognize custom LDAP attributes by modifing files such as wmmLDAPAttribute.xml, wmmAttributes.xml and wmmLDAPServerAttributes.xml. Then using PUMA api, we can lookup those custom attributes easily.
This has been very convenient since our Domino LDAP is always read only and there is no need to use a look-aside database for them.
In Portal V6.1, I searched throughout the InfoCenter and this forum but there seems to be no such simplified procedure. The only way to support non-standard LDAP attributes seem to be enabling LA and add the properties one by one, as described in this InfoCenter article: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/topic/com.ibm.wp.ent.doc_v6101/install/stdaln_add_attributes_win.html
Could anyone advise on whether there is a way to same functionality as in V6.0 without using LA database?
Thanks.
jwi...@us.ibm.com
http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21323296
I do not know what it means in the context of querying attributes, but I would start with making sure the users defined by the properties mentioned in the technote above have full administrative rights for WAS (i.e. can this user log into the WAS Administrative Console and act as an administrator?).
leiz...@yahoo.ca
g.tmp
[wplc-query-attribute-config] [02/23/09 10:35:42.231 EST] CWWIM0005W Could not register as WebSphere Application Server
adminService notification listener.
[wplc-query-attribute-config] [02/23/09 10:35:44.793 EST] CWWIM2000I Initialization of the authorization component compl
eted successfully.
[wplc-query-attribute-config] get config...
[wplc-query-attribute-config] done.
[wplc-query-attribute-config] InternalFileRepository type: FileRepositoryType
[wplc-query-attribute-config] wsedemo type: LdapRepositoryType
[wplc-query-attribute-config] InternalFileRepository type: FileRepositoryType
[wplc-query-attribute-config] wsedemo type: LdapRepositoryType
[wplc-query-attribute-config] Status = Complete
action-post-config:
Mon Feb 23 10:35:44 EST 2009
[echo] executing post-configuration tasks
iseries-switch-back:
Mon Feb 23 10:35:45 EST 2009
[delete] Deleting: C:\IBM\WebSphere\wp_profile\ConfigEngine\config\work\was\wp_portal.properties
[delete] Deleting: C:\IBM\WebSphere\wp_profile\ConfigEngine\properties\wkplc_comp_ascii.properties
[delete] Deleting: C:\IBM\WebSphere\wp_profile\ConfigEngine\properties\wkplc_ascii.properties
cleanup-work-dir:
Mon Feb 23 10:35:46 EST 2009
iseries-switch-back:
Mon Feb 23 10:35:48 EST 2009
[echo] Cleaning up...
[delete] Deleting directory C:\IBM\WebSphere\wp_profile\ConfigEngine\config\work
[echo] Done.
[mkdir] Created dir: C:\IBM\WebSphere\wp_profile\ConfigEngine\config\work
BUILD SUCCESSFUL
Total time: 30 seconds
isIseries currently set to: null
uploading registry
Created admin client: com.ibm.ws.management.AdminClientImpl@4ba04ba0
Created config Service Proxy: com.ibm.websphere.management.configservice.ConfigServiceProxy@64a664a6
CELL: wsedemo
CELL: wsedemo
com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is
denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:473)
at com.ibm.wkplc.was.registry.AdminConfigRegistry.createNewRegistry(AdminConfigRegistry.java:226)
at com.ibm.wkplc.models.compregistry.ResourceWidget.saveResourceToAdminConfig(ResourceWidget.java:362)
at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.syncCacheToRegistry(GenerateNodeRegistryXML.java:41
9)
at com.ibm.wkplc.models.compregistry.RegistryHelper.uploadRegistryToWAS(RegistryHelper.java:83)
at com.ibm.wps.config.tasks.UploadRegistryTask.execute(UploadRegistryTask.java:52)
at com.ibm.wps.config.ConfigEngineListener.buildFinished(ConfigEngineListener.java:279)
at org.apache.tools.ant.Project.fireBuildFinished(Project.java:1848)
at org.apache.tools.ant.Main.runBuild(Main.java:688)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.Main.start(Main.java:150)
at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:861)
at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:236)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:263)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at com.ibm.wps.config.launch.WpsConfigLauncher.process(WpsConfigLauncher.java:243)
at com.ibm.wps.config.launch.WpsConfigLauncher.main(WpsConfigLauncher.java:459)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService M
Bean because of insufficient or empty credentials.
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:811)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:779)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:575)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:402)
at $Proxy0.invoke(Unknown Source)
at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:205)
at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:448)
... 23 more
Return Value: 0 {code}
Best Regards
Leiz
leiz...@yahoo.ca
I finally got sometime to finish this configuration. How ever, the custom LDAP attributes could not be seen by PUMA API. I always get the following error message:
{code}PumaException: com.ibm.portal.puma.AttributeNotDefinedException: EJPSG0007E: One of the attribute specified is not defined for this member type.app-accessLevel: id: CN=wpsadmin,O=PortalDev attributeSubset: null
objectID: [ExtIDImpl '9eAe6IH4K1H8KPDG32H6J1HE3O47P1EA3PK6N9C83316G1D44PK8H9H0' [FFBCD478D43D70998525714F004B2E1E / USER, Domain: [Domain: rel]]]
descriptor: com.ibm.wps.datastore.impl.PrincipalDescriptorImpl@89a27f01
objectID: [ExtIDImpl '9eAe6IH4K1H8KPDG32H6J1HE3O47P1EA3PK6N9C83316G1D44PK8H9H0' [FFBCD478D43D70998525714F004B2E1E / USER, Domain: [Domain: rel]]]
created: 1237215136898
lastModified: 1237220595118
distinguishedName: CN=wpsadmin,O=PortalDev
resourceType: USER
hasLoggedOut: false
lastLoginTime: 1237218461856
markupData: null
stack: com.ibm.wps.um.UserImpl
isExternal: false{code}
To troubleshoot this issue, I checked the WIMConfig.xml file, where I did see custom attribute entries like below:
{code}
PersonAccount
{code}
Using LDAP browser I was able to verify that all custom attributes were visible to the LDAP bind account.
What could be the problem?
Thanks.
jwi...@us.ibm.com
http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21365605
leiz...@yahoo.ca
Thanks.
leiz...@yahoo.ca
I've attached the availableAttributes.html file after running "wp-query-attribute-config". You can see that the attribute has been mapped across the repository.
Thanks.
jwi...@us.ibm.com
EJPSG0007E: One of the attribute specified is not defined for this member type.app-accessLevel
implies that it is referenced by "app-accessLevel" whereas availableAttributes.html implies that it should be referenced by "app_accessLevel" instead. I am not sure why, given that you said wimconfig.xml contains:
or was this a typo?
leiz...@yahoo.ca
It was indeed a typo in wkplc.properties file - I'm sorry for the mistake.
But after fixing the error (removed the app_accessLevel attribute as per info center, and created a new one with correct char), command "wp-validate-standalone-ldap-attribute-config" still reported that the custom attribute is defined in portal but not in LDAP - I have mapped the attribute already.
I also noticed that base entry "o=defaultWIMFileBasedRealm" still exist as a "participatingBaseEntry" of the default realm, and the "OrgContainer" entity type still have "defaultParent" equals "o=defaultWIMFileBasedRealm". Is this correct? The info center procedure doesn't mention changing
or removing this from the default realm.
Thanks.
jwi...@us.ibm.com
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/security/aix_ud_et.html
(AIX link - follow the OS-specific page appropriate for your environment)
You can delete base entries by following these instructions:
leiz...@yahoo.ca
I just wanted to confirm that those "defaultWIMFileBasedRealm" related items will not be required for portal operation, once Domino LDAP has been configured for the federated repository.