Question: I wonder if it is possible to set a cross-instance in one direction only

pavel :

i.e. ACE -> XYZ, but not other way

Michael Woods :

@Chris: No exact date, but expect around end of Sept.

Michael Woods :

@Pavel: Other than using EEM to write a rule, I can't think of a way off hand to do that.

pavel :

@mike what eem policy you have in mind?

Michael Woods :

Pavel: as-job that prevents '^ACE' at the end of teh job name

pavel :

in condition?

Michael Woods :

@Pavel: your right, it won't check the condition field

Michael Woods :

@Pavel: Checkig with some others for ideas

Mark Hanson (CA) :

@Pavel regarding cross-instance, what if you set it up bi-directional then cut the connection one way? you would get errors but...

pavel :

@mark that would preclude new job condition creation

Mark Hanson (CA) :

@Pavel you want to prevent job condition creation for one direction?

pavel :

yes

Mark Hanson (CA) :

@Pavel what about implementing JIL exit?

pavel :

that should work

pavel :

but kind of heavy wieght

Mark Hanson (CA) :

@Pavel would give you nice control over what gets input, plus it would be an option in the future if you needed to expand it

Mark Hanson (CA) :

@Pavel plus an opportunity to flex those C programming skills :-)

pavel :

thanks for the idea

Chris Pace :

is there a way to control what can be ran via ECL? I ask because the way our Global user is setup ECL runs as our Master user, that has access to everything...

Michael Woods :

@Chris: What release of WCC and AE are you and are you using EEM?

Chris Pace :

WCC 11.4 SP1 AE 11.3.6 SP2 and I am using EEM

Michael Woods :

@Chris: Excellent answer When you have the enable EEM checked off on the server definition in EEM in that configuration, an additional parm of -saml is passed on the command. That will make the

secuirty context the logged on user not the userid running the command.

Michael Woods :

@Chris: The other answer is yes, you can control what commands are issued using the CommandExecute resource class

Michael Woods :

@Chris: If your AE policies are solid, you should be good with just allowing them to control what the users are allowed to do.

Chris Pace :

do you have any documentation on the CommandExecute syntax?

Michael Woods :

@Chris: It is documented in the security guide

Chris Pace :

I currently have server/*

Michael Woods :

@Chris: That is the default

Chris Pace :

does CommandExecute use anything other than "server"

Michael Woods :

Yes, you can use the command as well

Michael Woods :

@Chris: resource name uses the format: server/serverName/command or you can use teh named attribute Command in the filters

Chris Pace :

I would like the user logged into WCC, to be the one that the security is compared against. instead of the Global user

Chris Pace :

That security is everywhere else, but not in ECL

Michael Woods :

@Chris: Again, if I log on to WCC as Mike and issue a command to autorep job ABC and I don't have access to it. It will be denied, no matter what teh global user is set to.

Chris Pace :

but that is after you limit it in CommandExecute, right?

Michael Woods :

@Chris: If you do not see this result, please contact me at Michael.Woods@ca.com and we can set up a call to see what is happening. But based on your environment, that should be the case

Michael Woods :

@Chris: No, the CommandExecute is not involved in this. That will be checked to see what commands are allowed to be entered, but not in the security context of the actual command as we are talking about.

Chris Pace :

everything done in ECL, shows up in Autotrack as done under the global user. So right now it is a big loophole.

Michael Woods :

@Chris: Send me an email and we

Michael Woods :

'll find out what is happening

Chris Pace :

ok, sounds good. Sorry to take up so much time.

Michael Woods :

no problem, makes the time go faster

Lenn Thompson (CA) :

Only 5 minutes left. Get in your remaining questions now.

Lenn Thompson (CA) :

thanks for joining today everyone. Keep an eye out in the community for more office hour events.