Hi itc,

not sure I fully understand what you want to acheive, but here is my experience:

unfortunately, to date (there is an ENH request for this), there is no way to "reuse" the authentication when using client tool. So: a user will have to authenticate another time each time it launches a client tool, or one can use an dedicated account (see, not really generic for this.
A solution for your requirement:
(1) user a specific user (ex: login=clientToolUser, pwd=whatever),
(2) deploy this user on each client using clientConnect.conf,
(3) write a .cmd or an ASL which:
(a) grab the class/instance of the object you select in the console (through a notification or the topology),
(b) look at the MemberOf relationship to find the right DM (you mention APM, but I don't know any APM, did you mean ADM or ACM) ?
(c) connect to this DM,
(d) find the class/instance of the object in the related DM
(e) use the SNMPAddress

Hope this helps!

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com

Hi Fred,
against Member... SourceDomainObjectName is more better
Schema of decision exist.
We need technical details.
How grabbing could be performed (dmctl or another means) ?

Wow !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I check it in two minutes.

Mmmm... not sure...

(1) SourceDomainName is the DM source for the notification, so:
(a) what if you are in the topology view (where you can launch tools too)
(b) what if you want to launch a tool from a notification coming from, say NPM or ACM, and the information you need is coming from IP ou MPLS (for example)...

(2) the ex. from nadomad is only working if you have only one source of the notification, but sometimes (more often that you may think, in big setup) events are coming from multiple DM (topology split for ex.)

My 2 cents,

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com

Hi nandomad,
Some problems. We can't avoid inserting username/password for attaching to domain

Fred, I agree,
Parsing of SourceDomainManager is required. In founded list only one Ip manager will exist.

Hi itc,

as I mentioned, you do have to authenticate. For this, the best way is to use a dedicated user for "ClientTool" which you deploy in clientConnect.conf for each user workstation, and in each serverConnect.conf of the DMs you want to connect to. This may be a potentially security hole as this user is now usable by anybody using dmctl or sm_adapter.

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com

Thanks a lot Fred,
All work exelent.
But there is another mean for connecting to Domain manager: remote Java API.
In some places it is used.

Hi itc,

I'm aware of the remote Java API, our performance management product, APG, is 100% Java and the APG to Smarts Adapter uses it extensively. But even in this case, you still have to use a specific user for the connection and write the credentials somewhere. What you can do using Java is something close to what Smarts is doing with clientConnect.conf, i.e. encrypt the file with a key, and decrypt it when needed. But as you have to present some credentiels, anybody with the needed skills can look at the credentials too (if a program can, a human can...). The best solution would be to reuse the credentials of the client console. As I mentioned, there is a enhancement request for this. I don't know if this is something in Smarts' roadmap.

Have a good week end!

--Fred

Frederic Meunier
Solutions Watch4Net Inc
APG & Smarts InCharge integration
http://www.watch4net.com