qblogin

[turi]

I am trying to use qblogin on a windows box and qblogin --help lists that I can specify the username with --user parameter. Hence I can type this command

qblogin --user diffUserName

and diffUserName should be used instead of the user I am logged in as. Did I get that right? If so, then qblogin is not behaving the way it should. It ignores the --user parameter and still considers the current user I am logged in as. This is important to us because all the end users who submit jobs to the render farm will not have their systems (for e.g. their personal laptops) in our AD but they will have AD accounts which is used by their work PCs which in turn will be part of AD. Hence, qblogin should allow them to specify the AD account instead of the account they are logged in as so that they can submit jobs from their laptops etc.

On the same subject - "windows login" gui that is installed as part of qube does not allow you to specify username and allows you to enter only password. So it seems like it is assuming the current username you are logged in as. Is there a way to change that?

[anthony]

Hey Turi,

     Actually there is no way to specify a user in qube! without already having administrative permissions for the account which is accessing the command (basically you need to be an admin to do this:  qblogin --user <name>).  qube! relies entirely on the os's authentication scheme and we'll probably need to change this and provide an alternate system of authentication later.  If security isn't really a concern, then you could setup all users with impersonation privileges which would allow them to change the user name upon job submission.  This is done with the configuration gui on the supervisor. 

    Thanks,
              Anthony





   

[turi]

Actually there is no way to specify a user in qube! without already having administrative permissions for the account which is accessing the command (basically you need to be an admin to do this:  qblogin --user <name>). 

The way I see it the user logged in to his personal system with qube installed will be an admin on that system. For testing purposes I took my desktop out off AD. I logged in to my system with a local system account with admin privileges. Now on my desktop I should be able to type in qblogin --user <name>, and as per your statement, it should take that <name> and user name, which would be my AD user name. But it doesn't.

qube! relies entirely on the os's authentication scheme and we'll probably need to change this and provide an alternate system of authentication later.  If security isn't really a concern, then you could setup all users with impersonation privileges which would allow them to change the user name upon job submission.  This is done with the configuration gui on the supervisor. 

So, is there no way to have an end user submit jobs without making them admins? What I am trying to understand is how do other companies handle this situation?

[anthony]

Hey Turi,

     You are allowed to give "impersonation" privileges to users under qube! I suspect since all of your users will probably need this feature, you'll want to enable it by default by modifying the supervisor's qb.conf or using the configuration gui on the supervisor to adjust the default permissions per user.

     Impersonation allows a user to submit a job as another user.  This is allowed for situations where security isn't as tight since you are basically allowing a user the ability to run their programs as anybody in the facility.  Keep in mind though, this is all logged in the supervisor so impersonation can be detected after the fact.

     qube! as a rule normally assumes your network is protected at the boundaries security wise.  This is a reasonable assumption since most companies use NFS and other very security weak mechanisms NIS to move data around efficiently rather than securely.  Sort of like the time vs. space inverse proportionality when writing software. Since the network is normally contained, a studio will normally just use NIS, ActiveDirectory or LDAP for authentication.  However in your case, you'll have to do what we do here, which is to allow impersonation and to require the user specify their user's name and domain.

     Thanks,
         Anthony