Symantec Access Management

Hi All,

Is there any way to understand which command should be applicable to Data DSA & which one is only applicable to router DSA?

Regards,

Neeraj Tati

Hi Neeraj,

All DXcommands should work the same way regardless if you using them to make initial connection to router DSA or data DSA. There should be no difference.

Is there anything in specific that is not working for you or showing odd behavior? If yes, please provide further details on the problem along with exact CA Directory version / SP # / OS platform etc.

Thanks,

Hitesh

Hi Hitesh,

My fault, I mentioned it wrong by putting Title as Dxcommands. I was actually referring to commands related to DSA operations, limits, bind, connection etc.

For e.g. set allow-bind = true | false 

Not sure if it's applicable to both Router & Data DSAs. Because both router & data dsa would behave differently if this property is set to false. 

Data DSA: Ideally when data dsa will refuse any bindings, then router dsa should be smart enough to flag that DSA as unavailable and should create new binding connections with other available nodes.

Router DSA: with this property, router dsa should refuse any new binding requests. And not sure how Siteminder policy server would behave if it's directly connecting to router dsa. Would Policy server mark Router DSA as down?

Regards,

Neeraj Tati

Hi Neeraj,

This can be applicable at any layer - router DSA and/or data DSA.

By default this is turned on. Usually this setting is used if you would want to block the incoming traffic manually via DSA console (aka DXconsole). A good example would be:

- Applications connecting to data DSAs directly and you need to shutdown the DSA for maintenance.

- You would want to block any new binds to DSA to all the pending transactions (mainly if the setup MW and you have MW queues pending) to be finished.

- You connect to DSA console and run 'set allow-bind = false;' which will be effective immediately.

- After that shutdown the DSA and when you restart after planned activity, it will default back to 'set allow-bind = true;' so DSA can be opened to incoming binds.

Same applies to router DSA if you environment is setup in such a way that NOTHING connects to data DSAs directly. Meaning, as all binds are initial made to router DSA(s) which is supposed to chain requests to underlying data DSA(s), you would want to block binds at router DSA(s) first, let the data DSA activity get drained, perform your maintenance task, when you restart, it will set back to 'on' again.

set allow-binds Command -- Enable or Disable New Bindings on a DSA - CA Directory - 12.6 - CA Technologies Documentation 

Hope this addresses your concerns.

Thanks,

Hitesh

Hi Hitesh,

We did try this flag at router level during our performance testing with Siteminder & CA Directory as User store.

Our setup is in a way that Siteminder makes authentication bind to router dsa only and there is a chaining to data dsa below router.

When we set this flag set allow-binds=false at router level and reinitialize the router dsa, we see a lot of AuthReject at siteminder side.

which is strange.

As per my understanding, siteminder makes sub-bind for all user authentication over a persistent connection, which gets refused if we set allow-binds flag as false. And siteminder marks those authentication calls as AuthReject.

Whereas our expectation was if we set this flag as false, siteminder should mark that LDAP router as unavailable and retry all authentication calls to other available router dsa. However, it doesn't happen. We see AuthReject events.

You may try this flag if possible in lab env. So, basically there is no way for us to really achieve zero failures during a planned maintenance on LDAP hosts.

The actual flag is "set allow-binds = true / false".