Skip to main content
TeamCity is JetBrains’ CI/CD server. Connect a TeamCity server to Oleria to see who has an account, which groups they’re in, which roles they hold on the server and on each project, and which tokens, build agents, and stored secrets can act on your builds. Oleria reads this data from the TeamCity REST API with an access token, or a username and password. You can then review over-provisioned access and take action directly from Oleria. One Oleria integration covers one TeamCity server, either a TeamCity Cloud instance or a TeamCity On-Premises server. To connect another server, add another integration.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your TeamCity server:
  • Server - the server itself, with whether it’s TeamCity Cloud or On-Premises, its version and build number, its authorization mode, whether guest login is on, and its enabled login modules. Oleria also shows which sign-in methods the server offers: password, access token, or SSO through a module such as SAML, LDAP, or a GitHub, GitLab, or Google login.
  • Accounts - every user, with name, username, email, and when they were last active. When the audit log has the user’s creation event, Oleria also shows when the user was created and by whom.
    • Administrators - a user is marked as an administrator when a server-wide role they hold, directly or through a group, includes an administrative permission, such as managing roles, users, authentication settings, or server settings. The user’s highest server-wide role is shown as their account role.
    • MFA - a user with TeamCity two-factor authentication turned on is shown with MFA required. Other users are shown with MFA not required.
    • SSO - a user linked to an external login module, such as SAML, LDAP, or a GitHub or Google login, is shown with SSO. If the user has no TeamCity password, SSO is shown as required.
    • Authentication methods - password, two-factor authentication, SSO, and access token, for users who own an access token that hasn’t expired.
    • Guest - when guest login is on, anonymous visitors appear as one Guest (anonymous) account.
  • Groups - every user group, with its members, its parent groups, and the roles assigned to it. The built-in All Users group contains every user, so roles granted to it apply to everyone. When the audit log has the group’s creation event, Oleria also shows when the group was created and by whom.
  • Roles - one role for each role and scope that’s in use: a server-wide role is shown for All projects, and a project role is shown for that project and its subprojects. Each assignment shows the role’s permissions, including the permissions of roles it includes, and roles that include other roles are linked to them. Oleria also lists every role defined on the server, and marks custom roles.
  • Non-human identities (NHIs):
    • Access tokens - every access token of every user, shown as a personal access token linked to the user who owns it. Each token shows its creation date and expiry. A token that’s limited per project shows its projects and permissions. Expired tokens are shown as disabled.
    • Build agents - every agent, including agents that are disconnected, disabled, or not yet authorized, with its pool, IP address, host, version, registration date, last activity, and who authorized it. An agent is shown as enabled only when it’s both authorized and enabled. JetBrains-hosted agents on TeamCity Cloud are shown as system accounts.
    • Project SSH keys - every uploaded SSH key, with its key type, fingerprint, and whether it’s encrypted. A key is listed once, under the project that owns it.
    • VCS root passwords - VCS roots that sign in to the repository with a password or personal access token, with the VCS type, username, and repository host. When the audit log has the root’s creation event, Oleria also shows when the root was created and by whom.
    • Connections - project connections that hold a secret, with their provider type and client ID. Connections that hold AWS access keys are shown as access keys, with the access key ID and region. JetBrains-managed connections on TeamCity Cloud are shown as system accounts.
    • Cloud profiles - cloud agent profiles that hold a secret, such as AWS access keys. A disabled profile is shown as disabled.
    • Password parameters - password-type parameters defined on a project or build configuration. Inherited parameters are listed only where they’re defined.
    Oleria never reads secret values. TeamCity returns only the names of secure values.
  • Activity - events from the TeamCity audit log, including actions TeamCity takes itself, such as:
    • users created, changed, or deleted, and role and group changes for users and groups
    • roles created, deleted, or changed
    • access tokens created or deleted, two-factor authentication changes, and users signed out of all sessions
    • authentication setting changes
    • build agents authorized, unauthorized, enabled, disabled, or deleted
    • VCS root, project, and build configuration changes
    • SSL certificate and encryption key changes, plugin changes, build approvals, and settings committed to or loaded from version control
    Each event shows who made it and the objects it affected. Events TeamCity makes itself have no user, so they’re shown without an actor. Events Oleria doesn’t recognize are kept as custom events.
Oleria refreshes users, groups, roles, and NHIs on its regular sync schedule.
Oleria doesn’t import projects, build configurations, or builds as resources. Oleria reads projects and build configurations only to name role scopes and to find stored secrets.

​
Prerequisites

  • A TeamCity Cloud instance, or a TeamCity On-Premises server reachable from the internet over HTTPS on port 443. See Known limitations.
  • A TeamCity user that Oleria connects as, with System Administrator on TeamCity On-Premises, or a member of Cloud Instance Administrators on TeamCity Cloud.
  • Admin access to the Oleria workspace.
TeamCity has no service accounts. Every access token belongs to a user, and an administrator can’t create a token for another user. The integration acts as the user who owns the token. If that user is deleted, or the token expires or is deleted, discovery stops until you update the integration. Create a dedicated TeamCity user for Oleria that signs in with a TeamCity password, rather than using an employee’s account or an account that signs in through SSO.

​
Permissions

Oleria checks the connection user’s server-wide TeamCity permissions. The System Administrator role grants all of them on TeamCity On-Premises. On TeamCity Cloud, Cloud Instance Administrators grants all of them except change_user. See Remediation actions. When you connect, Oleria rejects a user that has neither view_user_profile nor change_user. A missing optional permission doesn’t block the connection, and Oleria skips the data it couldn’t read.

​
Set up access in TeamCity

1

Create a dedicated user

Sign in to TeamCity as an administrator and create a user for Oleria, such as oleria, with a TeamCity password. On TeamCity On-Premises, assign the user the System Administrator role. On TeamCity Cloud, add the user to the Cloud Instance Administrators group.
2

Create an access token

Sign in as the new user. Select your avatar -> Profile -> Access Tokens -> Create access token. Then fill in the form:
  • Name - enter Oleria.
  • Expiration - choose an expiry that fits your rotation policy. Discovery stops when the token expires.
  • Permissions scope - select Same as current user, so the token carries all of the user’s permissions.
3

Copy the token

Create the token and copy its value. TeamCity shows it only once.
Access tokens work only when token-based authentication is enabled on the server. To connect with a username and password instead, skip the token steps, and make sure the server accepts HTTP basic authentication for the user. The TeamCity interface changes over time. If these steps don’t match what you see, refer to TeamCity’s Managing access tokens documentation.

​
Connect TeamCity to Oleria

1

Open the integration

Sign in to your Oleria workspace, navigate to Integrations, and select TeamCity.
2

Complete the connection form

Fill in the connection form:
3

Authenticate

Select Authenticate. Oleria checks that it can reach the server, that the credential is valid, and that the user has the required permissions before it saves the integration. The integration is named after your server, for example TeamCity (acme.teamcity.com).

​
Edit the connection

You can replace the Access token or Password of an existing integration, for example when you rotate it, or switch the Authentication Method. Leave the field blank to keep the stored value. When you switch the method, enter the new method’s credentials. The Server URL can’t be changed. To connect a different TeamCity server, add a new integration.

​
Verify the integration

Confirm the TeamCity integration appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, groups, roles, and NHIs appear in your Oleria workspace, and that System Administrators are marked as administrators.
When the access token expires or is deleted, discovery stops. Create a new token as the same user and enter it by editing the integration.

​
Remediation actions

Oleria runs actions as the integration’s TeamCity user. Before an action runs, Oleria checks that the user holds the action’s permissions server-wide. Each action needs these TeamCity permissions:
TeamCity Cloud doesn’t grant change_user to Cloud administrators. On TeamCity Cloud, Revoke user sessions and revoking access tokens report a missing permission, and the integration’s Capabilities tab shows Disable NHI accounts as missing a permission, because it checks the permissions of every kind of NHI it can disable.
Oleria refuses these actions and sends no change to TeamCity:
  • Deleting, changing the roles or groups of, or signing out the user this integration connects as, or deleting that user’s access tokens. Oleria also refuses these actions when it can’t confirm which user the integration connects as.
  • Adding users to, or removing them from, the All Users group, because every user is always a member. Create user also refuses All Users in its list of groups.
  • Running user actions on the guest account or an NHI.
  • Unauthorizing a JetBrains-hosted agent on TeamCity Cloud, because JetBrains manages it.
  • Disabling project SSH keys, VCS root passwords, connections, cloud profiles, or password parameters. See Known limitations.
Keep these points in mind:
  • For role, group membership, and build agent actions, if the target is already in the requested state, the action succeeds without making a change, and there’s nothing to revert.
  • Role and group actions change only direct assignments and memberships. A user can still hold a role through a group, or through a role granted to All Users.
  • TeamCity won’t let a user delete another user who has permissions the deleting user lacks, so Delete user fails for such a user.

​
Known limitations

  • The connection is tied to one person. See Prerequisites. TeamCity has no OAuth sign-in for third-party REST API clients. The OAuth sign-in in TeamCity 2026.1 and later is for TeamCity’s own command-line tool and AI agent integrations, and issues a token tied to the signed-in user. Oleria connects with an access token or a username and password.
  • No sign-in events or IP addresses. TeamCity’s audit log doesn’t record sign-ins, failed sign-ins, IP addresses, or user agents, and doesn’t say which access token made a change. Changes Oleria makes through remediation actions appear as changes by the integration’s user.
  • Activity history is limited. Oleria imports at most the last 90 days of earlier activity. TeamCity keeps audit records indefinitely unless server clean-up is enabled, which removes nonessential records after one year. Creation dates of users, groups, and VCS roots come from the audit log, so they’re missing for older objects and when the user lacks view_audit_log.
  • Users can’t be disabled. TeamCity has no disabled state for users, so every user is shown as enabled, and Delete user is the only way to remove access. Deletion can’t be reverted.
  • No password-change or token last-used dates. TeamCity’s API doesn’t report when a user last changed their password or when an access token was last used.
  • Server-wide two-factor settings aren’t known. TeamCity’s API shows whether each user has two-factor authentication on, but not whether the server makes it optional or mandatory. MFA enforced by an external login provider isn’t visible.
  • Authorization mode affects roles. In simple authorization mode, Oleria adds TeamCity’s documented default grants: All Users holds Project Developer for all projects, and the guest account holds Project Viewer for all projects. In per-project authorization mode, the guest account’s roles are configured only in the TeamCity interface and aren’t readable, so the guest account is shown with no roles.
  • JetBrains-hosted agents are temporary. On TeamCity Cloud, JetBrains-hosted agents exist only while they run a build. Oleria shows them only if they exist when it syncs, and can’t disable them.
  • SSH keys and stored secrets can’t be disabled. TeamCity can only delete a project SSH key, which destroys the private key and breaks every VCS root that uses it. VCS root passwords, connections, cloud profiles, and password parameters have no disabled state. Manage them in TeamCity instead.
  • Agent authentication tokens aren’t inventoried. Oleria doesn’t read each build agent’s own authentication token or agent pool tokens.
  • TeamCity Cloud limits remediation. TeamCity Cloud administrators can’t hold change_user, so Oleria can’t revoke access tokens or sign users out on TeamCity Cloud.
  • Operator access isn’t visible. On TeamCity Cloud, JetBrains’ own access to the server doesn’t appear in any API. On TeamCity On-Premises, the super user, which signs in with a token written to the server log, doesn’t appear in any API, so Oleria doesn’t show it.
  • On-premises servers must be reachable. Oleria can connect to TeamCity Cloud (*.teamcity.com) hosts. A TeamCity On-Premises server must be reachable from the internet over HTTPS on port 443. If TeamCity listens on another port, publish it on 443 through a reverse proxy or load balancer first. Addresses that resolve to private or loopback IP addresses are refused. Contact support@oleria.com to allow your server’s host before you connect.

​
Contact us

For questions about this integration, contact us at support@oleria.com.