A Forum reader recently asked:

“I’m trying to set up Designer (version 2.1.1) to access my identity vault over a tunnel. I’ve setup my laptop to listen on localhost:524… i.e. laptop:524 —> 9524:shell host —> 524:vault

The tunnel works great. I can access ndsd using iManager workstation with no problems. I can create a new project using the import functionality and everything gets imported as I expect.

However… comparing and deploying do not work as I expected. For example if I import my project and perform a comparison Designer tells me everything is unequal. Everything on the eDirectory side appears blank.

Has anyone used Designer over a tunnel before?”

And here is the response from Aaron Burgemeister …


Most protocols work beautifully w/SSH tunnels and they are a great way to reach places prohibited by firewalls, policies, etc. The problem with some protocols (NCP is the one that comes to mind) is that when you do some operations the client is “smart” enough to know exactly
what the IP address of the destination box is. For example, when connecting initially you give it your local IP address, which then forwards through to the eDirectory box, which makes the connection and sends data back.

That data, though, includes referrals to boxes in eDirectory. When you want to update/compare a driver that is server-specific, it is very likely that your Designer box is trying to make a connection directly to that server. A quick way I check this (on Linux) is with the following command:

netstat -anp | grep 'SYN_SENT'

This shows all of my attempted connections which have not been responded-to at all from the destination (server).

If you are on a 10.x.x.x network connecting to a 192.168.x.x network across the Internet, you will see a line trying to connect (from your workstation) to
192.168.x.x which should not be happening (the connection from Designer is being made to localhost, after all).

There are some options here:

1. Assign an aliased IP address for your eDirectory servers
to your local machine.

2. Forward those specific sockets to the destination. For example assign (your server) to your box:

ip addr add lo:1


2 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 5 (2 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

By: ab
Mar 10, 2008
9:32 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow