Warning

JUser: :_load: Unable to load user with ID: 1005

ChrisV
ChrisV
Offline
0
I don't see a way in the AppScript, but I'm wondering if there's a way for a particular AppScript to always be run as a different account (ie Admin), regardless of who pushes the button?

I have a situation where I have a script that creates an XML and writes it to a network location (that's restricted access). Currently, I have it being run by notification with the admin account. No problems.

It does limit my options for other XML events where I might want to do it synchronously with the user at the keyboard. I can't/don't want to grant these users access to the network location, but it'd be great if they could still run the AppScript on the transition.

Pipe-dream?
Responses (18)
  • Accepted Answer

    Wednesday, September 25 2013, 07:02 AM - #Permalink
    0
    What version of SBM?- I have this running just like you describe but my appscript does different stuff. The user clicks the button but the appscript is executed by my admin user.

    I'm not sure if the latest version of SBM allows selecting another user to run the script or not. In our case we contacted Serena Professional Services and received a solution that allowed us to have the admin user execute a transition which has a script tied to it.
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 07:03 AM - #Permalink
    0
    I'm in 10.1.2. I'm seeing if I can scam the AppScript by actually assigning the user but I doubt it's going to let me.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 07:05 AM - #Permalink
    0
    here's another idea if it works for you -

    Run the appscript in the notification context and assign the notification to the admin user
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 07:06 AM - #Permalink
    0
    Notification context works great. I was hoping to run it in transition context to make it go synchronously.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 07:09 AM - #Permalink
    0
    The AppScript is running on the SBM AE server. Any file writes will occur with the IIS_USERS permission. I doubt if you can allow that to write to a network drive, although you may be able to map to the network drive and it might work that way.
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 07:11 AM - #Permalink
    0
    Hey, Lynn:

    So we got that to work, actually. I subscribe to the notification with the admin account, and then we use the gsoap App pool send the admin account AD privileges to the target directory, and then Ext.WriteTExtFile() will drop the XML correctly.

    If I try it as a transition context, it uses my credentials, and the XML creation fails for permissions. That's what I'm trying to spoof without actually granting the user the rights to those folders.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 07:14 AM - #Permalink
    0
    Lynn is the man to talk to if you are looking for a solution to have the script executed by another user. Works great for us. If there's not a solution out of the box perhaps the dll load where you pass in the transition and user credentials could help, that is if it's still supported.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 07:17 AM - #Permalink
    0
    Are you using NT Challenge Response authentication?
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 07:23 AM - #Permalink
    0
    Yes, we do.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 07:42 AM - #Permalink
    0
    Unfortunately, that is the way NT CR seems to work, so I'm not sure there is a way around this besides giving everybody that might run this AppScript write permissions to the folder.
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 08:01 AM - #Permalink
    0
    Ok, no problem. I was hoping, but the way I'm doing it will be sufficient. Would've made a few things easier, but not a hurdle.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 08:35 AM - #Permalink
    0
    Could your transition script create the XML file on the SBM server, then do something like Ext.CmdLineWait("...path...\CopyFileAsAdmin.cmd")

    The CMD file would do something like psexec -user Administrator -p Passwd "xcopy a.xml \\server_over_there\c$\A.xml"

    That uses PsExec from the MS SysInternals suite.

    The downside is, of course, that the Administrator password is visible in clear text in the CMD file. This may be a corporate security violation. OTOH, that file is on the SBM server, and if a user has access to files there, you have bigger problems.
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Wednesday, September 25 2013, 08:51 AM - #Permalink
    0
    Yeah, I'm fairly certain the plain-text password would be a no-no, by itself. Awesome suggestion notwithstanding, I'm just going to have to do it all by notification. It's not a big deal - just would've made one or two instances of this script a little nicer.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 25 2013, 09:05 AM - #Permalink
    0
    Another idea on Paul's suggestion would be to create a user variable to use in the script instead so instead of the hardcoded password it would be more like %PWD%, I have done this just to hide from prying eyes but someone savvy enough could still retrieve it, but at least it's hidden and could be tied to a specific user,
    The reply is currently minimized Show
  • Accepted Answer

    Jeff Malin
    Jeff Malin
    Offline
    Monday, September 30 2013, 07:04 AM - #Permalink
    0
    If the concern is with granting all users the ability to read files on the network share, could you grant all "Write-only" access so they can drop the files (via SBM) but not see anything else on the share?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, September 30 2013, 08:55 AM - #Permalink
    0
    That's an idea. Or how about the password is stored in a registry key/value only readable by IIS User? Let Windows native security limit access.
    The reply is currently minimized Show
  • Accepted Answer

    ChrisV
    ChrisV
    Offline
    Monday, September 30 2013, 08:56 AM - #Permalink
    0
    Good ideas. At this point, I've moved all these events to notification context so that the admin account is the one running the script. If I do have need of the transition context, though, I'll keep these in mind (and tell my SysAdmins what's involved so they can balk).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 17 2017, 03:13 PM - #Permalink
    0
    I know this is an old thread but in case someone sees this I am trying to do the same thing. I'd like to know what is meant by using the notification context. How is that accomplished?
    • Steven Healy
      more than a month ago
      Hi Michael,

      Not sure if anyone answered your question about Notification context but the context is dictated by what mechanism your app script is called from.
      It could be from a notification (notification context), a transition (transition context) or self-registration (also its own context). Each of this operations look at the item in different ways so the option for each context are not all the same.

      For a full list of Context types and explanation of each please review the SBM AppScript Contexts section of your SBM script guide (sbms_script_guide.pdf)
    The reply is currently minimized Show
Your Reply

Recent Tweets