It's all about the answers!

Ask a question

why does the RTC scheduled builds run with account "ADMIN"?

Karthik Krishnan (8825119163) | asked Aug 26 '13, 3:54 a.m.
retagged Aug 27 '13, 6:52 p.m. by Te-Hsin Shih (2854)
In the scheduled builds in RTC, when I print the user "${buildRequesterUserId}" I see user "ADMIN"
Any reason why?

Example scenario:
We are executing some scripts via ANT which are placed in network share. The useid running the build (jbe and scheduled task) has access to this share. I guess the builds are running as user "ADMIN", the build has no access to this share. 

We have disabled ADMIN user and using LDAP for authentication.

I have noticed this in RTC 3.0.1, RTC 4.0.0 and in in RTC 4.0.2. We are using RTC 4.0.2

I have checked this but not of use in my case

Te-Hsin Shih commented Aug 27 '13, 6:59 p.m.

Are you talking about that Jazz user or the OS user?

Karthik Krishnan commented Aug 28 '13, 9:32 a.m.

I guess it's the Jazz user 

Accepted answer

permanent link
Ralph Schoon (63.3k33646) | answered Aug 29 '13, 8:29 a.m.
Karthik, based on my understanding and experience, you need to try to understand the two different user contexts you are talking about here. LDAP does not play any role here. The ADMIN user also does not play a role in the build process, other than that it is the one used to request the build.

  1. The operating system user that is used to start the JBE (e.g. as a service or in some init process). This user is the user context that the JBE will use to try to access other files on the harddrive of this or other systems. The JBE process inherits the operating system permissions from this user.
  2. The technical build user that is passed to the JBE with its ID and password. This user is used by the JBE to connect to the CCM server and the project area, to load the files from the Jazz SCM system, and to communicate results back etc. This user is only used in the communication to the RTC server and has nothing to do with the operating system user. This user does not require any permissions on your machine. It only has a meaning to RTC and requires the RTC permissions to perform the load and communication. It has to be able to access workspaces for private builds.
The rtc user that requests the build does not play any role in accessing OS resources. Nor does the rtc build user used by the JBE to connect to RTC. The only user you have to make sure has rights to access these files is the operating system user. Make sure to start the JBE's with a user that has these permissions. Automate this e.g. using a service.
Karthik Krishnan selected this answer as the correct answer

Ralph Schoon commented Aug 29 '13, 9:19 a.m.

PS, dependent on how the operating system user starts the JBE more or less of the OS settings and environment might be exported. This depends on the OS, I guess.

One other answer

permanent link
Ralph Schoon (63.3k33646) | answered Aug 28 '13, 4:36 a.m.
It should be unimportant who requests the build. The JBE runs with a Build user (that you used to start the JBE) and you should use that user ID in ANT tasks.

Karthik Krishnan commented Aug 28 '13, 9:32 a.m. | edited Aug 28 '13, 9:33 a.m.

Hi Ralph, reason why I am asking is because there are scripts which are executed as part of the build. These scripts are placed in share location and when the build runs it has no access to these scripts from the network share. Of course the network shares are not accessible by "Everyone" by governed via access control

What I have noticed is when the build is requested by a user who has access to the share, this problem does not happen

Note: The build user as well as the user with which JBE is started has access to the network share

Ralph Schoon commented Aug 28 '13, 10:36 a.m. | edited Aug 29 '13, 5:07 p.m.

Hi Karthik, (comment does not work, so new answer)

as far as I can tell, the build scripts are run from the context of the user that has started the JBE. The user that accesses data in RTC is the user that you pass as parameter when starting the JBE. The user that requests a build is - as far as I can tell - not at all involved in the build and does not pass any credentials to the shell the JBE runs on or to the build script that the JBE actually runs. In fact, if the repository workspace in a private build is not accessible by the build user the build fails.

So I am puzzled why you would see different behavior if different users request the build. 

In production, the build scrips would usually reside in a component in Jazz SCM and loaded during the build. If you rely on external information,you have to make sure the user that launches the JBE process (usually in a service) has the permissions to access these build files (shared location). This should be the only place you should have to worry about it.

Te-Hsin Shih commented Aug 28 '13, 1:11 p.m.

The best way to verify if this problem is caused by the OS user and its privilege to access share drive is to print out the OS user in your script.

Karthik Krishnan commented Aug 29 '13, 3:54 a.m. | edited Aug 29 '13, 5:08 p.m.
 Hi Ralph,
(Too big for comments )

Thanks for the detailed answer. 

Note: We use LDAP authentication
Like I mentioned, the JBE user has access to these files. I still can't figure out the reason. I have seen this in RTC 3.0.1, RTC 4.0.0 and RTC 4.0.2

Another example is that we have some tools which are executed as part of the build. These tools needs license and the license manger is hosted in another server (Ex; QA-C). 

When I login a PC with as the build user I am able to run the tool and the tool is able to fetch the license. 

When the same tool is executed as the part of the build, the tool is unable to fetch the license. My assumption is that, since the build is run as build user, the processes created via the build would also be by the build user. But when I print the user, I only see "ADMIN"

Of course I can use "Runas" but we would have to provide the password as plain text

Somehow something is not clear for me about why the build reports as "ADMIN"

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.